Tak, jesteś technicznie wrażliwy. Więc jeśli masz ochotę spanikować lub obciążyć panikowanego klienta za kilka godzin paniki, idź na całość!
Ale w rzeczywistości, chyba że zezwolisz na dostęp SSH ze zdalnych połączeń lub serwera WWW, który obsługuje skrypty po stronie serwera, nie jesteś zagrożony. Jesteś naprawdę bezbronny tylko wtedy, gdy ktoś, kogo nie znasz, może zdalnie uzyskać dostęp do twojego komputera i zrobić to w sposób, w którym można wykonać polecenie Bash.
Oznacza to, że komputer stacjonarny Mac - który tak naprawdę nie uruchamia żadnych aplikacji serwerowych - nie stanowi większego ryzyka. Jestem gotów zjeść przysłowiowe „skromne ciasto”, ale nie sądzę, aby większość użytkowników komputerów Mac była zagrożona pod koniec dnia.
Dlatego problem ten dotyczy głównie administratorów systemów na serwerach Mac OS X i Unix / Linux wystawionych na świat, a nie użytkowników komputerów stacjonarnych, którzy nie umożliwiają udostępniania SSH.
Być może istnieje skrajne ryzyko tworzenia złośliwego oprogramowania lub wirusów dla komputerów Mac w celu wykorzystania tego ryzyka, ale wątpię w to.
EDYCJA: Aby wyjaśnić, w jaki sposób ten problem - moim skromnym zdaniem - nie jest tak naprawdę problemem dla większości przeciętnych użytkowników, tak, mogę uruchomić następujące polecenie bashw systemie Mac OS X 10.9.5:
env x='() { :;}; echo vulnerable' bash -c 'echo hello'
I widzę to:
vulnerable
hello
Zgadnij co? To jest przerażające tylko, jeśli nie racjonalnie o tym pomyślisz. Musiałem być już zalogowany na komputerze Mac, aby nawet otworzyć terminal. Aby zignorować to, co powiedziałem o SSH powyżej, aby przejść do rzeczy, mogę uruchomić ten test, nawet jeśli SSH jest włączony, nadal musiałbym się zalogować. A potem - powiedzmy, że dostaję dostęp przez SSH - polecenie nie pozwala mi zrobić NIC, poza moimi normalnymi prawami użytkownika, takimi jak to:
env x='() { :;}; echo vulnerable' bash -c 'cat /etc/ssh_host_rsa_key'
Oznacza to, że jeśli naprawdę jesteś podatny na wykorzystywanie przez tego hacka, twoje podstawowe zabezpieczenia w systemie musiałyby być tak zagrożone, że fakt, że bashma wadę, jest naprawdę najmniejszym z twoich problemów.
Jest to problem związany z ogólną kwestią kontroli i praw, ponieważ może to pozwolić na niezamierzony dostęp, ponieważ zachowanie wykracza poza oczekiwane normy. Ale moim skromnym zdaniem nie stanowi ryzyka na równi z OpenSSL lub odmianą ogrodniczą „pozwól mi zostawić hasło na notatce przyklejonej do ekranu”.
Pod koniec dnia wciąż łatam wszystkie moje serwery Linux / Unix, które uruchamiam zgodnie ze standardową procedurą. Z radością załatam komputery Mac, którymi zarządzam, gdy poprawka zostanie wydana. Ale do praktycznego codziennego użytku czuję się dobrze, nie martwiąc się tym, ponieważ nie rozumiem, jak wada, która nie pozwala na podniesienie uprawnień użytkownika, ma znaczenie.
AKTUALIZACJA: Oficjalne słowo od Apple opublikowane tutaj ; mój nacisk:
„Ogromna większość użytkowników OS X nie jest narażona na niedawno zgłoszone luki w zabezpieczeniach bash”, powiedział rzecznik Apple w iMore. „Bash, powłoka poleceń UNIX i język zawarty w OS X, ma słabość, która może umożliwić nieautoryzowanym użytkownikom zdalne uzyskanie kontrola wrażliwych systemów. W systemie OS X systemy są domyślnie bezpieczne i nie są narażone na zdalne wykorzystanie bash, chyba że użytkownicy skonfigurują zaawansowane usługi UNIX.
Pracujemy nad tym, aby szybko zapewnić aktualizację oprogramowania naszym zaawansowanym użytkownikom systemu UNIX. ”
Tłumaczenie: Co powiedziałem powyżej o tym, że jest to problem z serwerem, a nie problem z klientem? Dokładnie.
OSTATECZNY AKTUALIZACJA: Dla każdego, kto zmaga się z kompilacją ze źródła, od 29 września Apple oficjalnie wydało łaty dla Mac OS X 10.9.5, 10.8.5 oraz 10.7.5:
JESZCZE KOLEJNA AKTUALIZACJA: A teraz, Apple właśnie wydało dziś kombinację aktualizacji zabezpieczeń, która obejmuje również bashaktualizację !
Uwaga: Aktualizacja zabezpieczeń 2014-005 zawiera zawartość bezpieczeństwa aktualizacji OS X bash Update 1.0