Biorąc pod uwagę, że Bash 3.2 (wersja dostarczona przez OS X) jest podatny na exploit zdalnej realizacji znany jako „Shock Shock” ( CVE-2014-6271 i CVE-2014-7169 ), w jaki sposób odbudować Bash i zabezpieczyć mój system przed oficjalna łatka Apple?

AKTUALIZACJA: Pamiętaj, że Apple wydało teraz oficjalną łatkę. Szczegóły poniżej .

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:

• http://support.apple.com/kb/DL1769 - Mavericks (10.9.5 i nowsze)
• http://support.apple.com/kb/DL1768 - Mountain Lion (10.8.5)
• http://support.apple.com/kb/DL1767 - Lion & Lion Server (10.7.5)

(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.

Macports

Otrzymasz wersję bash 4.3.28 (1), która załatała zarówno luki (CVE-2014-6271 i CVE-2014-7169), jak i niektóre później odkryte. Jest to przydatne, jeśli zmieniłeś powłoki, aby użyć bash Macports, aby uzyskać funkcje wersji 4.

Nie rozwiąże to problemu standardowych skryptów systemu operacyjnego jako „mają” #!/bin/shlub #!/bin/bash„pierwszy wiersz”. Tego rodzaju problem powoduje, że Macports stara się nie używać dostarczonych wersji Apple, ponieważ Macports zwykle jest aktualizowany szybciej, np. Ma nowszą wersję bash)

Możesz sprawić, by terminal używał tego jak w odpowiedzi Homebrew

Aby zainstalować MacPorts postępuj zgodnie z poniższymi instrukcjami , które są
1. Zainstaluj Xcode i Xcode wiersza polecenia Narzędzia
2. zgadzasz się Xcode licencji w terminalu: sudo xcodebuild -license
3. Pobierz DarwinPorts pkg dla danej wersji OS X: linki są na stronie
4. Uruchom pkg

Kiedy masz zainstalowane Macports, potrzebujesz najnowszych wersji, odbywa się to przez uruchomienie

sudo port selfupdate

i ponownie skompiluj lub pobierz najnowsze pliki binarne przez

sudo port upgrade outdated

UWAGA dotycząca oficjalnej aktualizacji bash Apple OS X 1.0: Ta aktualizacja oprogramowania wprowadza tylko oficjalną wersję Apple bash do wersji 3.2.53. Wersja łatki 3.2.54 oferuje następującą zmianę:

Ta łatka zmienia kodowanie używane przez bash dla eksportowanych funkcji, aby uniknąć kolizji ze zmiennymi powłoki i aby uniknąć polegania tylko na zawartości zmiennej środowiskowej w celu ustalenia, czy interpretować ją jako funkcję powłoki.

W przypadku użytkowników, którzy już załatali system z plikami binarnymi 3.2.54, możesz albo zastąpić skompilowane pliki binarne łatką Apple, albo możesz zostawić rzeczy takimi, jakie są, ale nie jest to zalecane. Chociaż Apple pozostawił wersję binarną w wersji 3.2.53, łatka Apple zawiera poprawkę do poniższego testu exploita:

env X='() { (a)=>\' sh -c "echo date"; cat echo

Oznacza to, że oficjalny plik binarny Apple 3.2.53 zawiera równoważne zabezpieczenia do binarnego pliku binarnego GNU 3.2.54. Niefortunny punkt zamieszania, ale taki właśnie jest. Poprawka Apple'a nie jest na wpół upieczona. Wydaje się, że jest to kompletna naprawa problemu. W związku z tym poniższą mapę drogową do kompilacji wanilii bashi shze źródła GNU należy uznać za historyczny artefakt i być może skonsultować ją jako szablon, w jaki sposób robić łatki w przyszłości, jeśli będą one konieczne.

UWAGA: W przypadku waniliowego źródła GNU shma problemy z podnoszeniem uprawnień, które powodują awarie w różnych instalatorach, np. Adobe Flash. Zdecydowanie polecam trzymać się plików binarnych załatanych przez Apple. Uważaj ten schemat łatek za przestarzały i odradzany.

Dostępna jest nowa poprawka GNU bash 3.2.55, która opisuje następującą poprawkę:

Opis błędu:

Istnieją dwa przepełnienia bufora lokalnego w parsowaniu.y, które mogą spowodować, że powłoka zrzuci rdzeń, gdy otrzyma wiele dokumentów tutaj dołączonych do jednego polecenia lub wielu zagnieżdżonych pętli.

Delikatnemu czytelnikowi pozostawiamy decyzję, czy usiąść z oficjalnymi łatami binarnymi z łatami Apple, czy też rzucić własne, aby poradzić sobie z nowymi możliwymi exploitami. Osobiście będę trzymać się plików binarnych Apple.

Ten post szczegóły jak skompilować i zainstalować wanilię bashi shna OS X. Wybrałem ten szlak jako następujące przykłady szczegółowo za pomocą Apple konkretnego źródła, nie zostawiaj mnie z poprawnym zmiany plastra. YMMV. Ta instalacja waniliowa ma jednak na celu zastąpienie plików binarnych OS X, tak że gdy Apple wreszcie wyda aktualizację zabezpieczeń, te waniliowe zamiany zostaną przejęte przez ich odpowiednich odpowiedników Apple.

Moja podstawowa konfiguracja to:

OS X Lion 10.7.5 i Xcode 4.6.3 z zainstalowanymi wszystkimi narzędziami wiersza poleceń.

Moje kroki, aby to naprawić:

Pobierz podstawowy kod źródłowy bash dla 3.2.48 z:

https://ftp.gnu.org/gnu/bash/bash-3.2.48.tar.gz

Pobierz poprawki bash3.2.49, .50, .51, .52, .53, .54 i .55 z:

https://ftp.gnu.org/gnu/bash/bash-3.2-patches/

Zapisałem je jako $ filename.patch, np. Bash3.2.50.patch.

CD do katalogu pobierania i…

Rozpakuj główną gałąź źródłową:

tar xzvf bash-3.2.48.tar.gz

cd bash-3.2.48

Zakładając, że zmieniłeś nazwę pobranych plików łat, jak opisano wcześniej,

cp ../*.patch .

Następnie …

for file in *.patch ; do
  patch -p0 < $file
done

Powinno to pokazać udane łaty różnych plików. Jeśli nie, przygotuj się na eksplorację i dochodzenie.

Kolejny:

sudo cp /bin/bash /bin/bash_old
sudo cp /bin/sh /bin/sh_old
sudo chmod -x /bin/bash_old
sudo chmod -x /bin/sh_old

To w zasadzie utworzyło kopię zapasową starych, wrażliwych powłok bash i sh i usunęło ich uprawnienia do wykonywania. To daje ci możliwość przywrócenia poleceń w razie potrzeby, ale tymczasem usuwa ich zdolność do zadawania obrażeń.

Kolejny:

./configure --prefix=/ ; make ; sudo make install

To powinno poprawnie skonfigurować, skompilować i zainstalować nowy plik bash bash w / bin. Po zakończeniu zamknij Terminal i otwórz ponownie.

Powinieneś, wszystko szczęśliwe i uśmiechnięte, być w stanie bash --versionzobaczyć teraz 3.2.55, np .:

Gaia:Downloads trane$ bash --version
GNU bash, version 3.2.55(1)-release (i386-apple-darwin11.4.2)
Copyright (C) 2007 Free Software Foundation, Inc.

Dokładne dane wyjściowe powyższego polecenia będą się różnić w zależności od wersji OS X.

Powinieneś także być w stanie przetestować swoją podatność na atak bashi stwierdzić, że jest w porządku.

UWAGA: Do tej pory naprawiliśmy tylko bash, ale /bin/shplik wykonywalny jest nadal w stanie podatności. Zwykłe kopiowanie bashna szczycie shto styl pracy w systemie Linux. W shimplementacji OS X występują jednak pewne różnice bash, dlatego warto ponownie wyciągnąć kompilator. Więcej informacji na temat różnic bashi shróżnic w systemie OS X można znaleźć tutaj:

https://apple.stackexchange.com/a/89327/91441

W katalogu pobierania wykonaj:

make clean

W swoim ulubionym edytorze otwórz plik Makefile.ini przewiń do wiersza 99. Zamierzamy zmienić wiersz Programu, aby binarny plik wyjściowy był shzamiast tego bashtaki:

Program = sh$(EXEEXT)

Zapisz to i wtedy

./configure --prefix=/ --enable-xpg-echo-default --enable-strict-posix-default
make ; sudo make install

Teraz zbudujesz shprawie dokładnie tak, jak zrobiłby to Apple.

Ostatnia uwaga: w niektórych (wszystkich?) Systemach Apple wydaje się umieszczać bashbugplik wykonywalny /usr/bin. Nasz kompilacja to umieści /bin. Ostatnie kroki tutaj:

sudo mv /usr/bin/bashbug /usr/bin/bashbug_old
sudo chmod -x /usr/bin/bashbug_old
sudo mv /bin/bashbug /usr/bin/bashbug

Dla każdego, kto zmaga się z kompilacją ze źródła, od 29 września Apple oficjalnie wydało łaty na Mac OS X 10.9.5, 10.8.5, a także 10.7.5:

• Aktualizacja OS Bash 1.0 - OS X Mavericks
• Aktualizacja OS Bash 1.0 - OS X Mountain Lion
• Aktualizacja OS Bash 1.0 - OS X Lion

Po pierwsze, załatanie bash i sh tej luki może uszkodzić niektóre skrypty na komputerze Mac. Naprawdę nie musisz tego robić, chyba że oferujesz usługi internetowe w publicznym Internecie bezpośrednio z komputera Mac. Jeśli więc nie jest to naprawdę konieczne, poczekaj, aż pojawi się oficjalna aktualizacja zabezpieczeń firmy Apple.

Ostrzegam, oto kilka instrukcji, jak wykonać tę aktualizację za pomocą Brew na Mavericks 10.9.

Najpierw potwierdź, że używasz przestarzałego basha:

$ which bash
/bin/bash
$ /bin/bash --version
GNU bash, version 3.2.51(1)-release (x86_64-apple-darwin13)
Copyright (C) 2007 Free Software Foundation, Inc.

Najbardziej aktualny bash to 4.3.25

Jeśli nie masz zainstalowanego Xcode, będziesz potrzebować narzędzi wiersza poleceń Xcode, które mogą być zainstalowane przez

$ xcode-select --install

Lub z portalu dla programistów .

Aby zainstalować Brew ( http://brew.sh ):

$ ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Następnie wykonaj:

$ brew doctor

Postępuj zgodnie z instrukcjami, jeśli występują problemy. Rozwiązano tutaj wiele typowych problemów .

Następnie zaktualizuj napar do najnowszej listy pakietów:

$ brew update

Aby uzyskać najnowszą wersję bash 4.3.25:

$ brew install bash

To instaluje bash w /usr/local/Cellar/bash/4.3.25/bin/bash

Stary bashi shnadal istnieje w /bin, więc po instalacji zmienisz nazwę starych plików wykonywalnych na nowy plik.

$ sudo mv /bin/bash /bin/bash_old
$ sudo mv /bin/sh /bin/sh_old

Jeśli jesteś bardzo paranoikiem, możesz usunąć uprawnienia do wykonywania w bash_old

$ sudo chmod a-x /bin/bash_old /bin/sh_old

Następnie utwórz symboliczne łącze do nowej wersji bash 4.3.25, którą zainstalowałeś.

$ sudo ln -s /usr/local/Cellar/bash/4.3.25/bin/bash /bin/bash
$ sudo ln -s /usr/local/Cellar/bash/4.3.25/bin/bash /bin/sh

Uruchom ponownie i jest zakończony.

Ostrzeżenie - może to zepsuć niektóre istniejące skrypty powłoki, które mogą polegać na wersji bash 3.2 lub różnicach, jakie Mac shma w stosunku do Linuksa sh. Istnieje znacznie bardziej wyrafinowana odpowiedź na zastąpienie bash i sh ze źródeł, od odpowiedzi @TraneFranks w tym samym wątku.

OS X 10.6.8 - Snow Leopard

Wpis @AlBlue jest bardzo kompletny. Jednak na moim serwerze OS X 10.6.8 jego poprawka nie będzie działać. Apple nie ma poprawki dla 10.6.8, a kroki wyjaśnione przez @AlBlue nie działają z Xcode 3.2.6 (która jest najnowszą wersją dla Snow Leopard). Otrzymuję błąd:

** BUILD FAILED **

The following build commands failed:
sh:
    CodeSign /Users/bas/bash-fix/bash-92/build/Release/sh
bash:
    CodeSign /Users/bas/bash-fix/bash-92/build/Release/bash
(2 failures)

Z tego powodu używam brew.sh . Skomentuj swoje przemyślenia, gdy masz lepsze rozwiązanie dla systemu OS X 10.6.8 Snow Leopard. Zobacz także komentarz @Jerome, że miał udaną łatkę na OS X 10.6.8 Snow Leopard przy użyciu rozwiązania @ AlBlue. Tak czy siak:

Najpierw zainstaluj napar z następującym oneliner:

ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Aktualizacja brew

brew update

Teraz wystarczy zainstalować najnowszą wersję bashi zastąpić bieżącą:

brew install bash
sudo sh -c 'echo "/usr/local/bin/bash" >> /etc/shells'
chsh -s /usr/local/bin/bash
sudo mv /bin/bash /bin/bash-backup
sudo ln -s /usr/local/bin/bash /bin/bash

Możesz ustawić domyślną powłokę logowania Command (complete path)dla Terminal.app w jej preferencjach ( Command,)

Uwaga: w komentarzach niektórzy użytkownicy nie uważają tej metody za odpowiednią. Ale dla mnie jest to jedyna zrozumiała metoda aktualizacji BASH na OS X 10.6.8 Snow Leopard.

Możesz postępować zgodnie z instrukcjami tutaj: https://github.com/tjluoma/bash-fix Zasadniczo wykonaj następujące czynności w terminalu:

curl -s https://raw.githubusercontent.com/tjluoma/bash-fix/master/bash-fix.sh | zsh -f