Czym jest podatność na bash CVE-2014-6271 (Shellshock) i jak ją naprawić?

Ostatnio pojawiły się informacje dotyczące „CVE-2014-6271” (patrz USN-2362-1 ), która jest podatnością na ataki w Bash. Skąd mam wiedzieć, czy mam na to wpływ, jak mogę to naprawić i dlaczego powinienem się tym przejmować?

Zostało to zaprojektowane jako kanoniczna odpowiedź na tę lukę, ze względu na jej zasięg i wagę.

Co to jest Bash?

Bash jest domyślną powłoką interaktywną w Ubuntu. Kiedy łączysz się z terminalem (przez emulator terminala, przez tty lub ssh), zwykle wpisujesz polecenia, które bashbędą czytać i wykonywać. Nawet jeśli w ogóle nie korzystasz z terminala, nadal masz Bash.

Na Ubuntu /bin/shnie jest bash (to dash). Ta luka dotyczy tylko bash.

Jak exploit wpływa na mnie?

Bash i system operacyjny śledzą zestaw zmiennych środowiskowych, które opisują bieżącego zalogowanego użytkownika, gdzie szukać programów na dysku twardym i inne tego typu funkcje. Tworząc zmienną środowiskową o określonej strukturze, osoba atakująca może wykonać kod przy następnym uruchomieniu Bash.

Atakujący może ustawić tę zmienną środowiskową na wiele sposobów:

• Zdalnie połącz się z usługą, taką jak SSH, za pomocą określonej konfiguracji, takiej jak git over ssh. Jak ostrzega Mitre, użycie ForceCommandopcji sshd jest wektorem ataku. Nie dotyczy to kont, których powłoka nie jest bash.
• Nakłanianie do ustawiania zmiennej środowiskowej.
• Powodowanie innego programu do ustawienia zmiennej środowiskowej, która ma tę spreparowaną wartość. Na przykład możesz mieć serwer WWW i skrypt, który musi ustawić zmienną środowiskową z określoną treścią użytkownika. Nawet jeśli ten skrypt tworzy własny i nie dotyka innych zmiennych środowiskowych, wystarczy. Wystarczy jedna zmienna środowiskowa o dowolnej nazwie i spreparowanej wartości, aby exploit się powiódł .
• Inne sposoby, o których tu nie wspomniałem.

Gdy ustawią tę zmienną, następnym razem bashotworzy się z dowolnego powodu, kod atakującego zostanie uruchomiony. Jest to szczególnie przerażające sudo -s, ponieważ powoduje bash jako superużytkownik (reguła użytkownika administracyjnego, która ma pełną kontrolę nad danymi i programami twojego komputera). Nawet jeśli uruchomisz bash jako zwykły użytkownik, pliki tego użytkownika można usunąć.

Ważne jest, aby pamiętać, że nawet jeśli sam nie używasz basha, wiele programów samo się odradza jako część ich działania. Nawet w tym przypadku jesteś wrażliwy. Jednak Ubuntu /bin/shnie jest bash, więc dotyczy to tylko programów, które jawnie wywołują bash, a nie domyślnej powłoki skryptowej.

Według Mitre:

wektory zawierające funkcję ForceCommand w OpenSSH sshd, moduły mod_cgi i mod_cgid w serwerze Apache HTTP Server, skrypty wykonywane przez nieokreślonych klientów DHCP oraz inne sytuacje, w których ustawienie środowiska odbywa się przez granicę uprawnień po wykonaniu Bash.

Czy jestem wrażliwy?

Użyj dpkg, aby sprawdzić zainstalowaną wersję pakietu:

dpkg -s bash | grep Version

Spowoduje to wyszukanie informacji o bashpakiecie i przefiltrowanie danych wyjściowych, aby pokazać tylko wersję. Wersje są trwałe 4.3-7ubuntu1.4, 4.2-2ubuntu2.5i 4.1-2ubuntu3.4.

Na przykład widzę:

wlan1-loopback% dpkg -s bash | grep Version
Version: 4.3-7ubuntu1.4

i może stwierdzić, że nie jestem bezbronny.

Jak zaktualizować?

Standardowy menedżer aktualizacji zaoferuje tę aktualizację. Jest to doskonały przykład tego, jak ważne są aktualizacje zabezpieczeń, bez względu na to, jakiego systemu operacyjnego używasz i jak dobrze jest utrzymywane.

USN Biuletyn stwierdza, że nowe wersje zostały dopuszczone do Ubuntu 14.04 Trusty Tahr, 12.04 Precise Pangolin i 10.04 Lucid Lynx. Jeśli nie korzystasz z żadnej z tych wersji LTS, ale korzystasz z rozsądnie nowej wersji, najprawdopodobniej będziesz w stanie znaleźć załatany pakiet.

Najpierw sprawdź, czy ty

Jeśli jesteś wrażliwy, powinieneś najpierw pobrać najnowsze listy pakietów:

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

Pierwsze polecenie upewnia się, że masz najnowszą listę pakietów, która zawiera poprawioną wersję, a drugie polecenie instaluje najnowszą (stałą) wersję bash.

Chociaż wydaje się, że błąd pojawia się w grze dopiero po pojawieniu się basha, nadal dobrym pomysłem jest natychmiastowe ponowne uruchomienie komputera, jeśli jest to możliwe.

Ukradnij to od cft w Hacker News . Jeśli masz problemy ze swoimi repozytoriami, takimi jak ja (Odroid-XU), to powinno działać dobrze, jeśli chcesz łatać / kompilować ze źródła.

TMPDIR=/tmp/bash-src
mkdir $TMPDIR
cd $TMPDIR
#download bash
wget http://ftp.gnu.org/gnu/bash/bash-4.3.tar.gz
#download all patches
for i in $(seq -f "%03g" 1 999); do 
  wget http://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-$i
  if [[ $? -ne "0" ]]; then
    MAX=$(expr $i - 1)
    break;
  fi
done
tar zxf bash-4.3.tar.gz 
cd bash-4.3
#apply all patches
for i in $(seq -f "%03g" 1 $MAX);do
  echo apply patch bash43-$i
  patch -p0 < ../bash43-$i
done
#build and install
./configure && make
sudo make install
cd ../..
rm -r $TMPDIR

Następnie uruchomić:

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

A jeśli dostaniesz:

bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
this is a test

Więc wszyscy jesteście dobrzy!

UWAGA: make install zainstaluje bash /usr/local/bin, więc /bin/bashnie jest modyfikowany i można go wywołać z curl !!

Uwaga: Poprawka zabezpieczeń dla CVE-2014-7169 została wydana jako standardowa aktualizacja zabezpieczeń. Nie trzeba dodawać dodatkowych ppa, aby otrzymać tę łatkę. Potrzebne są tylko następujące elementy.

sudo apt-get update

sudo apt-get upgrade

Aby upewnić się, że poprawiłeś bash poprawnie, uruchom następujące polecenie

dpkg -s bash | grep Version

Jeśli korzystasz z 14.04 LTS, powinieneś zobaczyć wynik:

Version: 4.3-7ubuntu1.4

Jeśli korzystasz z 12.04 LTS, twój wynik powinien wynosić:

 Version: 4.2-2ubuntu2.5

Jeśli masz 11.04: użyj poniższych kroków (zadziałało to dla mnie)

cd ~/
mkdir bash
wget https://ftp.gnu.org/gnu/bash/bash-4.3.tar.gz
for i in $(seq -f "%03g" 0 25); do wget https://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-$i; done

jeśli nie zostanie pobrany wymagany patch, zainstaluj pakiet ftp

apt-get install ftp
for i in $(seq -f "%03g" 0 25); do wget https://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-$i; done
tar zxvf bash-4.3.tar.gz
cd bash-4.3
for i in $(seq -f "%03g" 0 25);do patch -p0 < ../bash43-$i; done
./configure && make && make install
apt-get install build-essential
./configure && make && make install

Aby sprawdzić, czy łatka została zastosowana:

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

Używam Natty 11.04, który jest EOL (i zaktualizowałem /etc/apt/sources.list, aby używać old-releases.ubuntu.com), więc muszę budować ze źródła. Chciałem zbudować .deb, więc przynajmniej zarządzanie pakietami jest „świadome”, że wersja bash nie jest domyślną wersją. Nie odnoszę 100% sukcesu - jednak pakiet jest zarejestrowany jako „nowszy”, a bashplik binarny został naprawiony, więc oto co zrobiłem:

apt-get source bash
wget https://gist.githubusercontent.com/drj11/e85ca2d7503f28ebfde8/raw/31bd53ed2e47b220d3c728f5440758e0f76769de/gistfile1.c -O bash_CVE-2014-6271.patch
wget https://gist.githubusercontent.com/drj11/239e04c686f0886253fa/raw/046e697da6d4491c3b733b0207811c55ceb9d927/gistfile1.c -O bash_CVE-2014-6271_plus.patch
cd bash-4.2/

Teraz w (pod) katalogu bash-4.2/znajduje się: plik bash-4.2.tar.xz, który należy rozpakować, aby dostać się do bashźródła; oraz o nazwie podkatalog debian.

Wprowadziłem następujące zmiany, aby uniknąć zależności texlive: w bash-4.2/debian/control:

Source: bash
...
Build-Depends: autoconf, autotools-dev, patch, bison, libncurses5-dev,
# texinfo, debhelper (>= 5), texi2html, locales, gettext, sharutils, time, xz-ut
ils
 debhelper (>= 5), locales, gettext, sharutils, time, xz-utils
# Build-Depends-Indep: texlive-latex-base, ghostscript
Build-Depends-Indep: ghostscript

... oraz w bash-4.2/debian/rules:

binary-doc: bash-install #bash-doc-build
        dh_testdir
        dh_testroot
        mkdir -p $(d_doc)/usr/share/doc/$(p)
        dh_installdocs -p$(p_doc) 
ifeq ($(with_gfdl),yes)
        #cp -p build-bash/doc/bashref.pdf $(d_doc)/usr/share/doc/$(p)/.
        #dh_link -p$(p_doc) \
        #    /usr/share/doc/$(p)/bashref.pdf /usr/share/doc/$(p_doc)/bashref.pdf
else
        rm -f $(d_doc)/usr/share/doc-base/bashref
endif
        rm -f $(d_doc)/usr/share/info/dir*
        #cp -p build-bash/doc/bash.html build-bash/doc/bash.pdf \
        #    $(d_doc)/usr/share/doc/$(p)/
        #dh_link -p$(p_doc) \
        #    /usr/share/doc/$(p)/bash.html /usr/share/doc/$(p_doc)/bash.html \
        #    /usr/share/doc/$(p)/bash.pdf /usr/share/doc/$(p_doc)/bash.pdf
        dh_installchangelogs -p$(p_doc) bash/CWRU/changelog
        ...

Aby zmienić wersję, w tym bash-4.2/katalogu wykonaj:

bash-4.2$ dch --local patchCVE

... i wypełnij notatki w dzienniku zmian, gdy zostaniesz o to poproszony. Zapewni to wywołanie .deb (i powiązane metadane) (w moim przypadku) bash_4.2-0ubuntu3patchCVE1_i386.deb.

Następnie możesz spróbować budować za pomocą polecenia dpkg-buildpackage -us -uclub debuild. Uwaga - którykolwiek z nich rozpakuje ponownie źródło z zip - zastępując w ten sposób wszelkie łatki, które mogłeś mieć! Mimo to uruchom jeden z nich, aby źródło zostało rozpakowane i zbudowane (uwaga debuildmoże nadal nie działać z powodu texlive, ale powinna rozpakować i zbudować źródło).

Następnie zastosuj łatki; uwaga, powinieneś użyć -p1tutaj, ponieważ obecnie znajdujesz się w bash-4.2/katalogu:

bash-4.2$ patch -p1 < ../bash_CVE-2014-6271.patch 
bash-4.2$ patch -p1 < ../bash_CVE-2014-6271_plus.patch 

Następnie odbuduj łataną wersję, uruchamiając:

bash-4.2$ fakeroot debian/rules build 

To odbuduje plik wykonywalny; aby to przetestować:

bash-4.2$ env VAR='() { :;}; echo Bash is vulnerable!' ./build-bash/bash -c "echo Bash Test"

Aby skompilować pliki .deb, uruchom:

bash-4.2$ fakeroot debian/rules binary

Spowoduje to zapisanie plików .deb w katalogu nadrzędnym; aby wyświetlić ich zawartość:

bash-4.2$ dpkg -c ../bash_4.2-0ubuntu3patchCVE1_i386.deb

Aby zainstalować .deb:

bash-4.2$ sudo dpkg -i ../bash_4.2-0ubuntu3patchCVE1_i386.deb

Jednak z jakiegoś powodu ten plik .deb zawiera niepoprawiony plik binarny (?!), Więc musiałem dodatkowo wykonać:

bash-4.2$ sudo cp bash-4.2/build-bash/bash /bin/

... a potem test zaczął się dla mnie poprawnie:

$ env VAR='() { :;}; echo Bash is!' bash -c "echo Bash Test"
bash: warning: VAR: ignoring function definition attempt
bash: error importing function definition for `VAR'
Bash Test