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


58

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?



Aby zobaczyć, jakie działania wpływają na OSX, zobacz security.stackexchange.com/questions/68123/…
user151019,

Zaktualizowałem to pytanie, aby było mniej dupe, a bardziej prośbą o poradę dla laików.
Hairboat

1
Firma Apple wydała teraz poprawkę: support.apple.com/kb/DL1769
AT

Odpowiedzi:


46

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


7
„lub serwer WWW, na którym działają skrypty po stronie serwera” - lub aplikacja działa i nasłuchuje na otwartym porcie, który umożliwia wykonywanie wywołań RPC, które kończą się uruchamianiem poleceń powłoki. Może to być dowolna liczba rzeczy, ponieważ istnieje wiele standardowych aplikacji wykonujących swoje RPC. Myślę, że ta odpowiedź jest bardzo naiwna. Bardzo łatwo jest przypadkowo „uruchomić serwer WWW” w trakcie uruchamiania aplikacji, która działa jak klient-serwer.
Ian C.

3
@IanC. Czy możesz podać przykład, w którym od razu system OS X byłby naprawdę wrażliwy? Na przykład, czy coś takiego jak WebEx lub GotoMeeting zbliżyłoby się do możliwości Basha? Chodzi o to, że nie mogę wymyślić prostego scenariusza instalacji OS X, który naprawdę ujawniłby różne rzeczy. Czy możesz?
JakeGould,

8
Konto gościa nie jest dostępne dla ssh. W rzeczywistości nie jest nawet możliwe udostępnienie go ssh, IIRC. Faktem jest, że dla zdecydowanej większości użytkowników systemu OS X luka w bash nie stanowi żadnego problemu. Dla tych z nas, gdzie jest to problem, musimy ponownie skompilować bash, gdy tylko będzie dostępna przetestowana poprawka, ale nie jest to teraz.
lbutlr,

3
@IanC. Dobra, uczciwe przykłady. Nadal jednak nie rozumiesz: w jaki sposób można wykorzystać taką lukę w każdym podanym przez Ciebie przykładzie? W każdym przypadku użytkownik musiałby mieć dostęp do systemu na początek, a potem co? Nie jestem z tego powodu nonszalancki, ale nadal nie rozumiem, jakie byłoby ryzyko? Ktoś - na przykład - musiałby przebrnąć przez interfejs API Plexa, aby zrobić coś dokładnie w bash, aby zrobić coś poza normalnymi prawami użytkownika i uprawnieniami dostępu?
JakeGould,

6
@danielAzuelos „Wszyscy są narażeni, dopóki konto gościa jest otwarte: [!” Konto gościa nie ma nic wspólnego bash. Więc strach opiera się na czym dokładnie? Co więcej, nawet jeśli konto gościa jest otwarte i w jakiś sposób bashnadaje się do użytku, to co? Z tego, co widzę, przypuszczenie, że użycie tego exploita nie miałoby podwyższonych uprawnień ani niczego podobnego. Poważnie, jestem gotów zrezygnować ze swojego stanowiska, ale wydaje się to bardziej jak panika oparta na nie bardzo, podczas gdy OpenSSL był prawdziwym problemem.
JakeGould,

37

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


4
Dzięki. Zaktualizowałem pytanie - jeśli stwierdzimy, że jesteśmy podatni na atak, w jaki sposób użytkownik komputera Mac może to naprawić?
łódź do włosów

3
@abbyhairboat Wysłałem moją odpowiedź. O ile nie prowadzisz serwera wystawionego na świat zewnętrzny, nie ma praktycznego ryzyka. Administratorzy serwerów są tymi, którzy muszą się tym martwić.
JakeGould,

1
→ abby: zobacz tę pokrewną odpowiedź: apple.stackexchange.com/a/146851/22003 .
dan

2
Spróbuj tego env X="() { :;} ; echo busted" /bin/sh -c "echo completed"- nawet po załataniu mojego systemu, ten wykrztusza „zepsute” w linii poleceń. Bah.
Trane Francks,

1
@ Mark nope, zsh jest bezpieczny. musisz zamienić „bash -c” na „zsh -c”, aby go przetestować.
ismail

3

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


1
Te są nieistotne. Każde z nich ze swojej natury zapewnia użytkownikom dostęp do uruchamiania poleceń w systemie, więc jeśli masz je włączone, intencją użytkownika jest umożliwienie użytkownikom uruchamiania poleceń. Błąd Shellshock jest środkiem dla użytkowników, dla których nie zamierzano wykonywać poleceń, np. Użytkownik uruchomionego serwera WWW. Więc twoja odpowiedź powinna brzmieć „Wyłącz udostępnianie w sieci” (ale to tylko jedna rzecz do sprawdzenia)
Josh

Jestem zirytowany, że Apple nie radziło wyłączać tych ustawień. Kto by ich umożliwił? Ja bym. Jestem użytkownikiem komputera Mac od 1986 roku, pełnoetatowym programistą aplikacji internetowych (więc ssh to moje życie) i tata (więc konto gościa dla dzieci nie jest takim złym pomysłem). Znam wielu ludzi, którzy są tacy jak ja, i używają laptopów Apple. Chcesz nas stracić? Pozostawienie tej luki w zabezpieczeniach jest dobrym sposobem.
minopret

2

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”. :)


2
Nie ma szans, że komputery Mac są podatne na atak za pomocą DHCP, ponieważ nie używa Bash.

1
Skąd to wiesz? Wstępne doradztwo było podatnym na ataki klientem DHCP. Wiele artykułów spekuluje, że klienci DHCP systemu Mac OS X i / lub iOS mogą być podatni na ataki. Należy założyć, że wszystkie serwery są wrażliwe, chyba że udowodniono inaczej.
Jeff Burdges

1
Nie, nie powinny; to jest absolutny FUD. Możesz zbadać zarówno otwarty kod źródłowy dla implementacji dhcp w OS X, jak i sam mierzyć połączenia systemowe w celu weryfikacji.

3
@JeffBurdges, OS X nie używał powłoki exec z DHCP od 10.3, a wcześniej ten bash nie był zainstalowany w systemie. DHCP w OS X po prostu nie stanowi problemu z Shellshock. (Jeszcze jedno, o co się martwić. :))
Trane Francks

1
→ Jeff: proszę rozważyć: strings /usr/libexec/bootpd | egrep '/bin|bash'i nm -a /usr/libexec/bootpd | egrep 'fork|exec'. Czytając te polecenia w różnych wersjach MacOS X, możesz ponownie rozważyć swoją analizę ryzyka z powodu dhcpdMacOS X… ale to jedno :(.
dan

2

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.


3
Może to tylko ja ... ale pomysł uruchomienia kodu jakiejś przypadkowej osoby w celu przetestowania exploita wydaje się być naprawdę złym pomysłem, gdy równie łatwo można wkleić ciąg (to oczywiście tylko uruchomienie testu i nic więcej) do okno terminala.
Joe

Zgadzam się, dlatego źródło znajduje się na code.google.com/p/shellshock-check
Thomas Jones

Czasami jednak może oferować łatwość użycia do testowania wielu systemów.
Thomas Jones

Nie widzę korzyści z tego. Sprawdzanie podatności jest znacznie łatwiejsze poprzez wklejenie prostego wiersza poleceń w oknie terminala.
Albert Godfrind

Jednak podczas testowania wielu maszyn, szczególnie w moim przypadku, ponieważ tak właśnie robię, włożenie dysku flash i otwarcie Shellshock Check.app jest znacznie łatwiejsze niż otwarcie Safari, wyszukanie polecenia bash w celu sprawdzenia, a następnie otwarcie terminalu, wklejenie tego polecenie, a następnie naciśnij klawisz Enter. Podłączenie dysku flash i otwarcie jednej aplikacji jest znacznie szybsze.
Thomas Jones
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.