Як виправити вразливість оболонки на застарілій системі Ubuntu, яку я не можу оновити?


22

У мене є система, яку я адмініструю віддалено (за 2 часові зони), яка працює на Ubuntu 9.04, Jaunty. З різних причин, головним чином з того, що я дуже захоплююсь спробою зробити оновлення дистрибутива з тих пір, я не можу оновити його до більш нової версії. Очевидно, це більше не підтримується, і немає жодних офіційних патчів. Чи є вказівки щодо того, як я можу виправити код і перекомпілювати bash, щоб усунути вразливості оболонки?


5
Які дослідження ви провели з цього приводу? Найпростішим рішенням, ймовірно, було б відновити та закріпити його самостійно. Можливо, вам доведеться прийняти це просто час оновити сервер.
Рамхаунд

Так, це мій запасний варіант. Сервер вже виходить, я просто намагаюся тримати його кульгаючим, поки не надійдуть кошти для його заміни. Якби я був на місці, я кусав би кулю і робив оновлення, але мені дуже рідко здається, що це проходить без зачіпки, і не маючи можливості покласти на це руки, я б швидше не ризикував, що якщо мене не буде до.
Клаус

Просто отримуйте кілька ключових слів на сторінці, щоб люди могли це знайти. Також працював для мене на Mac, OS X, Mavericks на основі тесту, опублікованого на arstechnica.com/security/2014/09/…

1
залиште його незакріпленим, «кульгаючи» швидко зміниться. Будьте дуже зрозумілі, ви використовуєте дистрибутив, який вийшов п'ять років тому . Підтримка закінчилася в жовтні 2010 року. У вас є ще багато вразливих ситуацій.
tedder42

Відповіді:


29

Викрав це у AskUbuntu , у того, хто його викрав у Hacker News. Працював на двох старих серверах для мене

mkdir src
cd src
wget http://ftp.gnu.org/gnu/bash/bash-4.3.tar.gz
#download all patches
for i in $(seq -f "%03g" 1 28); do wget http://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-$i; done
tar zxvf bash-4.3.tar.gz 
cd bash-4.3
#apply all patches
for i in $(seq -f "%03g" 1 28);do patch -p0 < ../bash43-$i; done
#build and install
./configure --prefix=/ && make && make install
cd .. 
cd ..
rm -r src

Оновлення: Я щойно помітив, що якщо ви не додасте --prefix=/до команди конфігурації, ви закінчите це, /usr/local/bin/bashщо є актуальним, і /bin/bashвсе ще буде вразливим.


У скрипті є помилка: послідовність "0 25" повинна бути "1 26". Якщо ви читаєте цю інформацію та можете відредагувати відповідь, оновіть її. Спасибі!
joelparkerhenderson

Поки ./configure --prefix=/ && makeпробіжки прекрасні, make installздається, вимагаютьsudo
Стюарт

Дякуємо за те, що виклали це - гарний спосіб виправити речі під час міграції. Деякі люди мають багато vms, і не реалістично відновлювати кожне. Ключовим є використання цього методу як негайного виправлення при вирішенні більш тривалого терміну шляхом оновлення інсталяції.
Яс Панесар

@ rubo77 Зараз йому повинно бути 1 27 (новий 27 патч є найважливішим)
joelparkerhenderson

1
Додано патч 28. Це , очевидно, виправляє вразливість CVE-2014-7186 / 7187.
unkilbeeg

2

Також є рішення оновити ваш source.list до найновішого, а потім використовувати apt-get для оновлення лише bash. Це дуже швидко, і я написав статтю про це. Ось що ви робите в основному:

Оновіть до останніх Ubuntu "надійних" сховищ apt-get (можливо, вам також доведеться змінити URL-адреси old-repositories.ubuntu.com, якщо ви їх використовуєте, перевірте пов'язану статтю):

sudo sed -i 's/YOUR_OS_CODENAME/trusty/g' /etc/apt/sources.list

Оновіть bash / apply fix:

sudo apt-get update
sudo apt-get install --only-upgrade bash

І, можливо, змінити сховища apt-get.


Працювали чудово!
Peter Kruithof

-1

Команда повинна бути

sudo apt-get update && sudo apt-get install --only-upgrade bash

2
Це не допоможе; як сказав ОП, він більше не підтримується, тому оновлення для bash не буде.
Ендрю Фер’є

-3

Один простий варіант - просто не використовувати bash. Переконайтеся, що dashвстановлено, і /bin/shце символьне посилання на dash, ні bash. (Це за замовчуванням для деяких версій Debian, але я не впевнений у Ubuntu.) Якщо у вас є облікові записи користувачів для доступу до ssh з примусовими командами, вам також потрібно змінити їх оболонки для входу. Можливо, вам також знадобиться перевірити наявність скриптів, явно використовуючи bash; жартуючи за, #!/bin/bashслід знайти їх.


5
Це трохи схоже на те, що ми говорили: "Ми виявили, що у вас може бути segfaults в C ++, просто використовуйте Java замість цього" ...
DevSolar

3
Більш близька аналогія - це сказати, що хтось із помилкою в GCC переживає помилку. Обидва реалізують одну і ту ж мову (з різними, але іноді перекриваються наборами нестандартних розширень), і навряд чи реальна потреба полягає в "bash", а швидше в "інтерпретаторі оболонки".
Р ..

Як ви вже сказали, є сценарії, які можуть явно використовувати bash. Навіть якщо ви хочете за існуючі файли, які використовують bash, в майбутньому хтось може додати новий скрипт у систему, яка явно використовує bash. Те ж саме стосується вбудованих систем, які використовують busybox (/ bin / sh вказує на busybox), але також встановлено bash. Найкраще - оновити bash у вразливих системах.
jcarballo

Більшість сценаріїв Unix / Linux вимагає bash або іншої сучасної оболонки, наприклад ksh або zsh. Вони мають велику кількість функціональних можливостей, яких люди очікували будь-якою мовою, але їх немає в оболонках "голих кісток", таких як (BusyBox) зола / тире / ш (оригінал). Ці простіші снаряди мають лише 20-30% функціональності більших оболонок, що робить їх швидшими. Однак вони вимагають широкого використання зовнішніх утиліт для багатьох поширених операцій, таких як вдосконалена обробка рядків та відповідність шаблонів. Баш і такі можуть бігати попелом, et.al. сценарії. Але не навпаки.
DocSalvager
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.