Czy komputery Mac są podatne na błąd powłoki Bash?

Red Hat niedawno ogłosił poważny błąd bezpieczeństwa w powłoce Bash. Niektórzy nazywają to błędem „shellshock”. Skoro OS X jest zbudowany na Uniksie, czy jest podatny na ataki wykorzystujące ten błąd?

Czy jako użytkownik końcowy muszę się martwić natychmiastową poprawką? Czy może lepiej jest czekać na oficjalną aktualizację oprogramowania od Apple?

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:

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

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

Tak!

Wpisz to w swojej powłoce

env x='() { :;}; echo vulnerable' bash -c 'echo hello'

Jeśli to mówi, vulnerablejesteś wrażliwy.

Jeśli to mówi

bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
hello

więc jesteś dobry.

Edycja: link do poprawki

Jako użytkownik końcowy sprawdź, czy:

• twoje konto gościa jest wyłączone:

  Preferencje systemowe> Użytkownicy i grupy> Użytkownik-gość
  

• twój sshdostęp jest wyłączony:

  Preferencje systemowe> Udostępnianie> Logowanie zdalne
  

Domyślnie oba są wyłączone w Mavericks.

Jako użytkownika końcowego , to bezpieczniej czekać na oficjalną aktualizacją zabezpieczeń firmy Apple ustalające tę bashlukę.

Wszystkie maszyny Mac OS X są technicznie podatne na „Shellshock”, dopóki Apple nie wyda aktualizacji zabezpieczeń, która łata bash, ale ...

Twoje pytanie powinno brzmieć: czy mogę zostać zaatakowany zdalnie?

Jest tak wiele programów, które używają bashz roztargnieniem, że udzielenie odpowiedzi na to pytanie jest niezwykle trudne. Jeśli martwisz się, zasugeruję kilka zmian w System Preferencescelu zapobiegania zdalnym atakom:

• Wyłącz WSZYSTKIE usługi udostępniania w Preferencjach udostępniania.
• Włącz zaporę w obszarze Bezpieczeństwo i prywatność.

Jeśli szczególnie się martwisz, naciśnij Firewallprzycisk opcji, aby:

• Usuń zaznaczenie Automatically allow signed software to receive incoming connections.
• Sprawdzić Block all incoming connections.

Nadal istnieje spora szansa, że ​​jesteś podatny na atak poziomu za pomocą DHCP, Bonjour itp., Ale hej, jeśli potrzebujesz innej usługi, możesz oczywiście pozostawić ją uruchomioną, mając nadzieję, że nie zostanie wykorzystana. Musisz też pozostawić zaporę bardziej otwartą. Prawdopodobnie będzie dobrze, jeśli maszyna mieszka za inną zaporą ogniową.

Czy są też lokalne ataki eskalacji uprawnień włączone przez „Shellshock?” Tak, prawie na pewno. Nie martwiłbym się jednak, ponieważ Mac OS X ma wystarczająco dużo podobnych ataków. Apple nie szybko łata błędów związanych z eskalacją uprawnień lokalnych. Apple często tworzy je za pomocą usług obsługujących Apple Script. Załóżmy, że wszystkie maszyny Mac OS X są zawsze podatne na ataki lokalne. Jeśli chcesz uczestniczyć w konferencjach hakerów, takich jak DEFCON, kup sobie w tym celu Linux-a.

Aktualizacja: Istnieją instrukcje dotyczące ponownej kompilacji własnego naprawionego basha oraz inne pytania na ten temat . Zrobię to sam, ale IMHO to przesada, jeśli nie uruchomisz żadnych serwerów i włączysz zaporę Apple.

Aktualizacja: Jeśli nie masz doświadczenia w korzystaniu z terminala, execsnoopwspomniany tutaj program o nazwie pozwala sprawdzić, czy procesy bash są zwykle wywoływane przez procesy serwera. To nie magiczna kula, ponieważ proces serwera może wywołać bash tylko w nietypowych sytuacjach, ale da ci to dobry pomysł.

Wreszcie, Apple nie jest zbyt dobry w usuwaniu luk w zabezpieczeniach, ale są dobre w PR, więc zostanie to naprawione stosunkowo szybko. Dlatego rozsądne jest myślenie: „Nie muszę biegać szybciej niż niedźwiedź, muszę tylko biegać szybciej niż ogromna liczba łatwych do wykorzystania serwerów w Internecie”. :)

Zrobiłem to narzędzie, gdy tylko usłyszałem o tej usterce. Udostępni ci link do artykułu, aby załatać powłokę, jeśli narzędzie stwierdzi, że jesteś podatny na atak.

Wymaga systemu Mac OS X 10.6 i nowszych wersji.