Как я могу исправить уязвимость в оболочке в устаревшей системе Ubuntu, которую я не могу обновить?

22

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

— Клаус
источник

5

Какие исследования вы провели на эту тему? Самым простым решением, вероятно, будет восстановление и исправление самостоятельно. Возможно, вам придется принять это просто пора обновить сервер.

— Ramhound

Да, это мой запасной вариант. Сервер выходит из строя, я просто пытаюсь держать его в покое, пока не появятся средства для его замены. Будь я на месте, я бы укусил пулю и сделал бы обновление, но у меня очень редко бывают такие проблемы без заминки, и, не имея возможности взять его в руки, я бы предпочел не рисковать, если бы у меня не было к.

— Клаус

Просто добавьте несколько ключевых слов на страницу, чтобы люди могли найти это. Также работал для меня на 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=/команду configure, то в конечном итоге /usr/local/bin/bashона будет актуальна и по- /bin/bashпрежнему будет уязвимой.

— unkilbeeg
источник

В скрипте есть ошибка: последовательность «0 25» должна быть «1 26». Если вы читаете это и можете редактировать ответ, пожалуйста, обновите его. Благодарность!

— joelparkerhenderson

В то время как ./configure --prefix=/ && makeпробеги хорошо, make installкажется, требуютsudo

— Стюарт

Спасибо за то, что выложили это - честный способ исправления ошибок во время миграции. У некоторых людей много vms, и перестроить каждый из них нереально. Использование этого в качестве немедленного исправления при решении более долгосрочной проблемы с помощью более обновленной установки является ключевым.

— Jas Panesar

@ rubo77 Теперь это должно быть 1 27 (новый патч 27 - самый важный)

— joelparkerhenderson

1

Добавлен патч 28. Это делает по- видимому, устранить уязвимость CVE-2014-7186 / 7187.

— unkilbeeg

2

Также есть решение обновить ваш sources.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 / примените исправление:

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

И, возможно, изменить обратно apt-get репозитории.

— Эрик Дуиндам
источник

Работал отлично!

— Питер Крайтоф

-1

Команда должна быть

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

— ColdenZero
источник

2

Это не поможет; Как сказал OP, он больше не поддерживается, поэтому обновление для bash не будет.

— Эндрю Ферье

-3

Один простой вариант - просто не использовать bash. Убедитесь, что dashустановлен и /bin/shэто символическая ссылка dash, а не bash. (Это значение по умолчанию в некоторых версиях Debian, но я не уверен в Ubuntu.) Если у вас есть учетные записи пользователей для доступа по ssh с помощью принудительных команд, вам также необходимо изменить их учетные записи. Вам также может понадобиться проверить любые сценарии, явно использующие bash; grepping для #!/bin/bashдолжен найти их.

— Р..
источник

5

Это немного похоже на высказывание: «мы обнаружили, что в C ++ могут возникнуть ошибки, просто используйте вместо этого Java» ...

— DevSolar

3

Более близкая аналогия - рассказать кому-то, кто испытывает ошибку в GCC, попробовать clang. Оба реализуют один и тот же язык (с разными, но иногда перекрывающимися наборами нестандартных расширений), и маловероятно, что фактическая потребность в «bash», а скорее в «интерпретаторе оболочки».

— R ..

Как вы сказали, есть сценарии, которые могут явно использовать bash. Даже если вы выполните поиск существующих файлов, использующих bash, в будущем кто-то может добавить новый скрипт в систему, которая явно использует bash. То же самое касается встроенных систем, которые используют busybox (/ bin / sh указывает на busybox), но также имеют установленный bash. Лучше всего обновить bash в уязвимых системах.

— jcarballo

Большинство сценариев Unix / Linux требуют bash или какой-либо другой современной оболочки, такой как ksh или zsh. Они обладают множеством функциональных возможностей, которые люди привыкли ожидать на любом языке, но их нет в «пустых» оболочках, таких как (BusyBox) ash / Dash / sh (оригинал). Эти простые оболочки имеют только 20-30% функциональности больших оболочек, что делает их быстрее. Однако они требуют широкого использования внешних утилит для многих общих операций, таких как расширенная обработка строк и сопоставление с образцом. Баш и тому подобное могут запустить пепел, эт.ал. скрипты. Но не наоборот.

— DocSalvager