Jak załatać lukę w zabezpieczeniach Shellshock na przestarzałym systemie Ubuntu, którego nie mogę zaktualizować?

22

Mam system, którym administruję zdalnie (w odległości 2 stref czasowych), na którym działa Ubuntu 9.04, Jaunty. Z różnych powodów, głównie dlatego, że jestem naprawdę ostrożny z próbą przeprowadzenia aktualizacji dystrybucji z tak daleka, nie mogę zaktualizować jej do nowszej wersji. Oczywiście nie jest już obsługiwany i nie ma żadnych oficjalnych łatek. Czy są dostępne instrukcje dotyczące sposobu łatania kodu i ponownej kompilacji bash, aby usunąć luki w zabezpieczeniach?

— Mikołaj
źródło

5

Jakie badania przeprowadziłeś na ten temat? Najprostszym rozwiązaniem byłoby samodzielne przebudowanie i załatanie. Być może będziesz musiał to zaakceptować, aby po prostu zaktualizować serwer.

— Ramhound,

Tak, to moja opcja rezerwowa. Serwer jest w drodze do wyjścia, staram się tylko, aby kulejąc, dopóki nie pojawią się fundusze na jego wymianę. Gdybym był na miejscu, ugryzłbym kulę i wykonał aktualizację, ale bardzo rzadko robię to bez żadnych problemów i bez możliwości włożenia w to ręki wolałbym nie ryzykować, jeśli nie mam do.

— Claus

Tylko kilka słów kluczowych na stronie, aby ludzie mogli to znaleźć. Pracowałem także dla systemu Mac, OS X, Mavericks na podstawie testu opublikowanego na stronie arstechnica.com/security/2014/09/…

1

pozostaw to niezałatane, „utykając” szybko się zmieni. Wyraźnie, używasz dystrybucji, która pojawiła się pięć lat temu . Pomoc zakończyła się w październiku 2010 r. Masz wiele innych luk w zabezpieczeniach, o które musisz się martwić.

— tedder42

29

Ukradnij to od AskUbuntu , od kogoś, kto ukradł to z Hacker News. Pracowałem dla dwóch starych serwerów

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

Aktualizacja: Właśnie zauważyłem, że jeśli nie dodasz --prefix=/do komendy config, skończysz na /usr/local/bin/bashtym, że jest aktualna i /bin/bashnadal będzie podatna na ataki.

— unkilbeeg
źródło

W skrypcie występuje błąd: sekwencja „0 25” powinna wynosić „1 26”. Jeśli czytasz to i możesz edytować odpowiedź, zaktualizuj ją. Dzięki!

— joelparkerhenderson

Chociaż ./configure --prefix=/ && makeprzebiega dobrze, make installwydaje się, że wymagasudo

— Stewart

Dziękujemy za udostępnienie tego - uczciwy sposób na załatanie różnych rzeczy podczas migracji. Niektórzy ludzie mają wiele vms i ich odbudowanie nie jest realistyczne. Kluczem jest wykorzystanie tego jako natychmiastowej poprawki przy rozwiązywaniu go w dłuższej perspektywie poprzez aktualizację instalacji.

— Jas Panesar

@ rubo77 Musi być teraz 1 27 (nowy patch 27 jest najważniejszy)

— joelparkerhenderson

1

Dodano łata 28. To nie wydaje się, aby naprawić usterkę, CVE-2014-7186 / 7187.

— unkilbeeg

2

Istnieje również rozwiązanie polegające na aktualizacji twojego source.list do najnowszego, a następnie za pomocą apt-get, aby zaktualizować tylko bash. Jest to bardzo szybkie i napisałem o tym artykuł . Oto, co właściwie robisz:

Uaktualnij do najnowszych zaufanych repozytoriów apt-get Ubuntu (w razie potrzeby możesz także zmienić adresy URL old-repositories.ubuntu.com, sprawdź link):

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

Upgrade bash / Apply fix:

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

I ewentualnie zmień z powrotem repozytoria apt-get.

— Erik Duindam
źródło

Działa idealnie!

— Peter Kruithof

-1

Polecenie powinno być

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

— ColdenZero
źródło

2

To nie pomoże; jak powiedział OP, nie jest już obsługiwany, więc nie będzie aktualizacji dla bash.

— Andrew Ferrier

-3

Jedną z prostych opcji jest po prostu nie używanie bash. Upewnij się, że dashjest zainstalowany i /bin/shjest to dowiązanie symboliczne dash, a nie bash. (Jest to ustawienie domyślne w niektórych wersjach Debiana, ale nie jestem pewien co do Ubuntu.) Jeśli masz konta użytkowników dla dostępu ssh z wymuszonymi poleceniami, musisz również zmienić ich powłoki logowania. Być może będziesz musiał sprawdzić, czy nie ma żadnych skryptów, używając jawnie bash; grepping dla #!/bin/bashpowinni je znaleźć.

— R ..
źródło

5

To trochę jak powiedzenie: „odkryliśmy, że możesz mieć

— błędy segregacyjne

3

Bliższą analogią byłoby powiedzenie komuś, kto ma błąd w GCC, aby spróbował zadzwonić. Oba implementują ten sam język (z różnymi, ale czasami nakładającymi się zestawami niestandardowych rozszerzeń) i jest mało prawdopodobne, że faktyczna potrzeba to „bash”, a raczej „interpretera powłoki”.

— R ..

Tak jak powiedziałeś, istnieją skrypty, które mogłyby jawnie używać bash. Nawet jeśli grepujesz za istniejącymi plikami używającymi bash, w przyszłości ktoś może dodać nowy skrypt do systemu, który używa basha jawnie. To samo dotyczy systemów wbudowanych, które używają busyboksa (/ bin / sh wskazuje na busyboksa), ale mają również zainstalowane bash. Najlepszą rzeczą jest aktualizacja bash w podatnych systemach.

— jcarballo

Większość skryptów Unix / Linux wymaga bash lub innej nowoczesnej powłoki, takiej jak ksh lub zsh. Mają one wiele funkcji, których ludzie oczekują w dowolnym języku, ale nie są obecne w powłokach typu „bare-bone”, takich jak (BusyBox) ash / Dash / sh (wersja oryginalna). Te prostsze powłoki mają tylko 20-30% funkcjonalności większych powłok, co czyni je szybszymi. Wymagają one jednak szerokiego użycia zewnętrznych narzędzi do wielu typowych operacji, takich jak zaawansowana obsługa ciągów i dopasowywanie wzorców. Bash i takie mogą popiół itp. skrypty. Ale nie na odwrót.

— DocSalvager,