Status
Firma Apple wydała poprawki bezpieczeństwa Bash dla Shellshock i powiązanych luk w zabezpieczeniach jako „ OS X bash Update 1.0 ”. Można je zainstalować za pomocą normalnej aktualizacji systemu dla osób korzystających z systemu OS X Mountain Lion 10.8.5 lub OS X Mavericks 10.9.5 (są uwzględnione w aktualizacji zabezpieczeń 2014-005 ), a także można je zainstalować ręcznie. Oficjalne poprawki Apple są również dostępne dla OS X Lion 10.7.5 i OS X Lion Server 10.7.5, ale są one dostępne tylko poprzez ręczne pobranie. Poprawki zabezpieczeń są dostępne pod różnymi adresami URL w zależności od wersji systemu operacyjnego:
(Jeśli zostaną wydane nowe łatki, umieść je tutaj, ale zachowaj również te istniejące w celach informacyjnych).
Poprawka Apple zajmuje się Shellshock i kilkoma innymi podatnościami i jest w porządku dla większości ludzi. tl; dr ludzie mogą przestać czytać tutaj.
JEDNAK uwaga zwrócona na bash przez błąd Shellshock spowodowała, że wielu badaczy rzuciło okiem na bash i wciąż znajduje się coraz więcej (trudnych do wykorzystania) luk w zabezpieczeniach. Jeśli jesteś bardzo zaniepokojony bezpieczeństwem (ponieważ być może używasz OS X Server do hostowania publicznie dostępnej strony internetowej), możesz chcieć (starać się) nadążać za lukami i łatkami, które pojawiają się podczas samodzielnej kompilacji bash. W przeciwnym razie nie przejmuj się tym.
Spójrz, jak Apple wyda kolejną aktualizację, która zaatakuje w przyszłości, gdy kurz ustąpi po znalezieniu kolejnych luk w zabezpieczeniach.
Dostępny jest oficjalny zestaw poprawek samej wersji bash 3.2, łatek 52, 53 i 54 (które odpowiadają łatkom 25, 26 i 27 Bash 4.3), które naprawiają zarówno CVE-2014-6271, jak i CVE-2014-7169, a także „Koniec gry” wyświetlony poniżej. Zostało to przetestowane przeze mnie ( @alblue ) i post został odpowiednio zaktualizowany (a następnie dokonano dodatkowych aktualizacji: patrz poprawka 41 dla postu, który zatrzymuje się w patchu 54).
Zgłoszono wiele dodatkowych luk w zabezpieczeniach przed bash. Według postu Michała Zalewskiego, jeśli masz łatkę 54 (i prawdopodobnie oficjalną łatkę Apple'a) „nie ma sensu obsesyjnie myśleć o statusie tych pojedynczych błędów, ponieważ nie powinny one już stanowić zagrożenia dla bezpieczeństwa:”
CVE-2014-6271 - oryginalny RCE znaleziony przez Stephane'a. Naprawiono przez bash43-025 i odpowiednie wpisy z 24 września dla innych wersji.
CVE-2014-7169 - błąd tworzenia pliku / zużycia tokena znaleziony przez Tavis. Naprawiono przez bash43-026 & co (26 września)
CVE-2014-7186 - prawdopodobnie katastrofa 10+ tutaj-doc, odkryta przez Floriana i Todda. Naprawiono przez bash43-028 & co (1 października).
CVE-2014-7187 - niezawierające się, prawdopodobnie nie-sekundowe ryzyko, znalezione przez Floriana. Naprawiono przez bash43-028 & co (1 października).
CVE-2014-6277 - problem niezainicjowanej pamięci, prawie na pewno RCE znaleziony przez Michała Zalewskiego. Nie ma jeszcze konkretnej łatki.
CVE-2014-6278 - iniekcja polecenia RCE znaleziona przez Michała Zalewskiego. Nie ma jeszcze konkretnej łatki.
Robi się dość mylące. Na szczęście Chet Ramey, oficjalny opiekun bash, opublikował CVE do mapowania łatek . Jego post dotyczy poprawek do wersji bash 4.3, ja (@OldPro) przetłumaczyłem je na łatki do wersji bash 3.2, co dotyczy OS X. Ponadto, od czasu tego postu opublikował łatkę 57, więc dodałem to poniżej:
bash32-052 CVE-2014-6271 2014-09-24
bash32-053 CVE-2014-7169 2014-09-26
bash32-054 exported function namespace change 2014-09-27 ("Game Over")
bash32-055 CVE-2014-7186/CVE-2014-7187 2014-10-01
bash32-056 CVE-2014-6277 2014-10-02
bash32-057 CVE-2014-6278 2014-10-05
Zobacz post Davida A. Wheelera, aby uzyskać oś czasu i więcej szczegółów.
@alblue opublikował instrukcje kompilacji poprzez łatkę 55. Ja (@OldPro) dodałem łatę 56 i 57 do instrukcji, ale jej nie przetestowałem.
Testowanie oryginalnej luki w zabezpieczeniach
Możesz ustalić, czy jesteś podatny na pierwotny problem w CVE-2014-6271 , wykonując ten test:
$ env x='() { :;}; echo vulnerable' bash -c 'echo hello'
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
hello
Powyższe dane wyjściowe są przykładem bashwersji niezabezpieczonej . Jeśli zobaczysz słowo vulnerablena wyjściu tego polecenia, bashoznacza to, że jesteś podatny na atak i powinieneś zaktualizować. Poniżej znajduje się podatna na atak wersja systemu OS X 10.8.5:
Testowanie pod kątem nowej luki w zabezpieczeniach
Nastąpiła aktualizacja oryginalnego postu, a Bash 3.2.52 (1) jest nadal podatny na odmianę luki, zdefiniowaną w CVE-2014-7169
$ rm -f echo
$ env X='() { (a)=>\' sh -c "echo date"; cat echo
sh: X: line 1: syntax error near unexpected token `='
sh: X: line 1: `'
sh: error importing function definition for `X'
Thu 25 Sep 2014 08:50:18 BST
Powyższe dane wyjściowe są przykładem bashwersji podatnej na atak . Jeśli w danych wyjściowych polecenia pojawi się data, oznacza to, że bashjest on podatny na ataki.
Wyłączanie automatycznie importowanych funkcji, aby zapobiec „Game Over”
Badacze zauważyli, bez klasyfikowania go jako podatności, że skrypt może przejąć funkcję w podpowłoce przy użyciu funkcji importowania automatycznego:
$ env ls="() { echo 'Game Over'; }" bash -c ls
Game over
Powyższy kod w systemie, którego dotyczy problem, wyświetli się Game Overzamiast oczekiwanego katalogu ls. Oczywiście echo 'Game Over'można go zastąpić dowolnym niecnym kodem. Stało się to znane jako błąd „Game Over”.
Przed udostępnieniem łatki 54 zarówno NetBSD , jak i FreeBSD domyślnie wyłączały automatyczne bashowe funkcje basha, częściowo po to, aby zapobiec „Game Over”, ale głównie po to, aby zawierać dalsze błędy w parserze (takie jak CVE-2014-7169 ) wciąż jest wykrywany i dodał nową flagę wiersza poleceń--import-functionsaby ponownie włączyć stare domyślne zachowanie. Ja (@alblue) przygotowałem łatkę (w stosunku do wersji 3.2.53), z której mogą korzystać inni, jeśli chcą również przyjąć to zachowanie, i umieściłem ją poniżej. Domyślnie ta łatka nie jest włączona w skrypcie kompilacji poniżej. Uważam (@OldPro), że ta łatka nie jest już konieczna ani dobrym pomysłem, ponieważ łamie wsteczną kompatybilność, a luki, przed którymi chroni, są bardzo dobrze usuwane przez łatkę 54 i wcześniejsze łatki, a włączenie tej nieoficjalnej łatki zapobiega stosowaniu przyszłych łatek .
(Uwaga do redaktorów pytań; proszę nie włączać tego domyślnie, ponieważ jest to nieoficjalna łatka).
a0c5c4d66742fddd0a35001cb91798a5fbf8a2f5 import_functions.patch
Łata można włączyć, uruchamiając export ADD_IMPORT_FUNCTIONS_PATCH=YESprzed uruchomieniem kompilacji. Pamiętaj, że włączenie tej poprawki spowoduje wyłączenie poprawki 54 i wszelkich przyszłych poprawek, ponieważ nie można zagwarantować, że przyszłe poprawki będą zgodne z nieoficjalną łatką.
Apple Patch ma lukę Game Over
Jak wskazał @ake_____ na Twitterze, oficjalna łata Apple jest nadal podatna na blokowanie się plików wykonywalnych przez środowisko:
$ env '__BASH_FUNC<ls>()'="() { echo Game Over; }" bash -c ls
Game Over
Użytkownicy powinni sami zdecydować, jak ważne jest to. Uważam (@OldPro), że nie ma się czym martwić, ponieważ nie ma znanego exploita dla tego zachowania (nie otrzymał nawet identyfikatora CVE), ponieważ generalnie nieuprzywilejowani zdalni napastnicy nie mogą ustawić nazwy zmiennej środowiskowej, a atakujący z uprawnieniami nie mogą wykorzystaj to, aby uzyskać uprawnienia, których jeszcze nie mają (przynajmniej nie bez wykorzystania dodatkowej podatności).
Aby zapewnić trochę tła, bash pozwala definiować funkcje, a ponadto pozwala eksportować te funkcje do podpowłoki za pomocą export -fpolecenia. Kiedyś było to realizowane przez tworzenie zmiennej środowiskowej o tej samej nazwie co funkcja z wartością ustawioną na definicję funkcji. Więc
$ ls () { echo 'Game Over'; }
$ export -f ls
$ echo $ls
Game Over
Stało się tak, ponieważ export -f lsutworzono zmienną środowiskową o nazwie ls. Luka „Game Over” polegała na tym, że można bezpośrednio utworzyć tę zmienną środowiskową bez konieczności wcześniejszego definiowania funkcji, co oznacza, że jeśli można wstrzyknąć poprawną nazwę zmiennej, można przejąć polecenie. Apple próbował to naprawić, utrudniając utworzenie zmiennej o właściwej nazwie. Oficjalna łatka bash 54 w rzeczywistości uniemożliwia utworzenie zmiennej o właściwej nazwie poprzez użycie nazw zmiennych, które zawierają %znak, który nie jest dozwolony w nazwie zmiennej, skutecznie umieszczając wyeksportowane definicje funkcji w innej, zarezerwowanej przestrzeni nazw.
Jeśli żadne z powyższych nie ma dla ciebie sensu, nie przejmuj się tym. Na razie nie masz nic przeciwko łatce Apple.
Binaria systemowe
OS X 10.9.5 (najnowsza stabilna wersja w tej chwili) jest dostarczany z Bash v3.2.51:
$ bash --version
GNU bash, version 3.2.51(1)-release (x86_64-apple-darwin13)
Copyright (C) 2007 Free Software Foundation, Inc.
Możesz uzyskać i ponownie skompilować Bash w następujący sposób , pod warunkiem, że masz zainstalowany Xcode (i uruchomiłeś xcodebuildprzynajmniej raz, aby zaakceptować licencję):
$ # If you want to disable auto-imported functions, uncomment the following
$ # export ADD_IMPORT_FUNCTIONS_PATCH=YES
$ mkdir bash-fix
$ cd bash-fix
$ curl https://opensource.apple.com/tarballs/bash/bash-92.tar.gz | tar zxf -
$ cd bash-92/bash-3.2
$ curl https://ftp.gnu.org/pub/gnu/bash/bash-3.2-patches/bash32-052 | patch -p0
$ curl https://ftp.gnu.org/pub/gnu/bash/bash-3.2-patches/bash32-053 | patch -p0
$ # See note above about ADD_IMPORT_FUNCTIONS_PATCH
$ [ "$ADD_IMPORT_FUNCTIONS_PATCH" == "YES" ] && curl http://alblue.bandlem.com/import_functions.patch | patch -p0
$ [ "$ADD_IMPORT_FUNCTIONS_PATCH" == "YES" ] || curl https://ftp.gnu.org/pub/gnu/bash/bash-3.2-patches/bash32-054 | patch -p0
$ [ "$ADD_IMPORT_FUNCTIONS_PATCH" == "YES" ] || curl https://ftp.gnu.org/pub/gnu/bash/bash-3.2-patches/bash32-055 | patch -p0
$ [ "$ADD_IMPORT_FUNCTIONS_PATCH" == "YES" ] || curl https://ftp.gnu.org/pub/gnu/bash/bash-3.2-patches/bash32-056 | patch -p0
$ [ "$ADD_IMPORT_FUNCTIONS_PATCH" == "YES" ] || curl https://ftp.gnu.org/pub/gnu/bash/bash-3.2-patches/bash32-057 | patch -p0
$ cd ..
$ # Note: DO NOT ADD SUDO TO XCODEBUILD HERE
$ xcodebuild
$ build/Release/bash --version # GNU bash, version 3.2.57-release
$ build/Release/sh --version # GNU bash, version 3.2.57-release
$ sudo cp /bin/bash /bin/bash.old
$ sudo cp /bin/sh /bin/sh.old
$ sudo cp build/Release/bash /bin
$ sudo cp build/Release/sh /bin
(Uwaga: możesz uruchomić to, kopiując i wklejając powyższy blok kodu, przechodząc do terminalu, a następnie uruchamiając pbpaste | cut -c 2- | sh. Zawsze zachowaj ostrożność podczas uruchamiania losowych skryptów z Internetu ...)
Po tym wersja Bash powinna mieć wersję 3.2.57:
$ bash --version
GNU bash, version 3.2.57-release (x86_64-apple-darwin13)
Copyright (C) 2007 Free Software Foundation, Inc.
Ze względów bezpieczeństwa i po przetestowaniu zaleca się, aby chmod -xstare wersje upewniły się, że nie zostaną ponownie użyte, lub przenieść je do witryny kopii zapasowej.
$ sudo chmod a-x /bin/bash.old /bin/sh.old
Inne odpowiedzi zawierają rozwiązania dla tych, którzy używają MacPorts lub Homebrew; nie rozwiązują problemu, po prostu instalują dodatkowe wersje Bash. Przeczytaj te odpowiedzi, jeśli chcesz je uaktualnić.
Dzięki
Podziękowania dla Cheta, który opiekuje się bashiem i udostępnia te łatki. Dziękujemy wszystkim innym, którzy skomentowali to i poprawili to z czasem.
Teraz Apple wypuścił prawdziwą poprawkę, choć może być nadal przydatna. Ponieważ wydali tylko poprawkę dla Lion i nowszych, a oficjalna łatka zawiera GNU bash, wersja 3.2.53 (1) -release (x86_64-apple-darwin13), jednak Game over bug jest nadal nieco podatna. W tym momencie przebudowanie własnej wersji Bash w wersji 3.2.57 jest prawdopodobnie bezpieczniejsze niż poleganie na łatce Apple'a, chyba że zrobisz to źle.
