Ogen Dogen 2 728 Właściciel Opublikowano 3 Stycznia 2018 Właściciel Udostępnij Opublikowano 3 Stycznia 2018 Odkryto błąd w architekturze procesorów (nie tylko tych produkowanych przez Intela). Rezultatem jest dziura, która objawia się bardzo groźnym wyciekiem informacji przechowywanych w pamięci jądra. Aby usunąć tę dziurę trzeba… wymienić procesor albo zainstalować łatki, które znacznie spowolniają jego pracę (od 5% do 52%, w zależności od tego, do czego głównie wykorzystujecie komputer). Co więcej, problem dotyczy nie tylko użytkowników domowych komputerów. Dziura zagraża także “chmurom” Amazon EC2, Microsoft Azure i Google Compute Engine. Szykujcie kasę na nowy komputer Teoretycznie, mamy przerąbane. Błąd na poziomie procesora oznacza, że w zasadzie dotyczy on każdego systemu operacyjnego. Jak informuje The Register: Cytuj the flaw is in the Intel x86-64 hardware, and it appears a microcode update can’t address it. It has to be fixed in software at the OS level, or go buy a new processor without the design blunder. Ale problem nie dotyczy tylko Intela. Podatne są także procesory ARM, czyli większość urządzeń Internetu Rzeczy. Ten błąd nie występuje w procesorach AMD. Wstępne informacje jednego z inżynierów AMD to potwierdzają. Ale cytowane przez nas niżej dokumenty wskazują, że AMD ma inne problemy. W takiej sytuacji zalecalibyśmy Wam po prostu wygodne rozgoszczenie się w fotelu i przyglądanie temu jak płonie świat. Ale aż takiej tragedii nie ma. Póki co aktywnych ataków brak. Ale jak pokazuje życie, to pewnie tylko kwestia czasu… Jak odkryto i łatano te błędy? Historia jak z filmu… Historia tego błędu zaczyna się od czerwcowej pracy naukowej kilku badaczy pokazującej jak omijać ASLR atakiem KAISER oraz lipcowego artykułu objaśniającego jak można odczytywać pamięć jądra z poziomu użytkownika. Potem dziura była dyskutowana w wąskich kręgach, nałożono embargo na ujawnienie szczegółów ataku i rozpoczęto tworzenie łatek. O kulisach całego zamieszania w szczegółach najlepiej opowiada artykuł pt. The mysterious case of the Linux Page Table Isolation patches. W kontekście bezpieczeństwa procesorów warto też rzucić okiem na tą publikację i ten wykład, jaki w zeszłym tygodniu miał miejsce podczas konferencji 34C3: Łatki już (prawie) są… Patche na Linuksa już są. Na Windows też — póki co mają je betatesterzy, ale w najbliższy wtorek zostaną one udostępnione wszystkim. Na 10 stycznia przewidziano restart chmury Microsoftu a na piątek downtime chmury Amazonu. …i są bardzo bolesne Łatki wprowadzają Kernel Page Table Isolation, czyli mechanizm separacji pamięci jądra od procesów użytkownika (inną nazwą poprawki miał być FUCKWIT, Forcefully Unmap Complete Kernel With Interrupt Trampolines). Taka separacja jest kosztowna i spowoduje spowolnienie pracy procesora. O ile? O 5% do 52%. Wszystko zależy od konkretnych zadań jakie procesor wykonuje. Poszczególni twórcy aplikacji ujawniają wyniki swoich testów szybkości sprzed i po zaaplikowaniu patchy. I tak, wedle grsecurity, spadek wydajności może wynieść nawet 63% na procesorze Skylake i7-6700. Postgresowe wyniki też są bolesne — w najgorszym przypadku 23% spadek wydajności: pgbench SELECT 1, 16 clients, i7-6820HQ CPU (skylake): pti=off: //bez patcha tps = 420490.162391 pti=on: //z patchem tps = 350746.065039 (~0.83x) pti=on, nopcid: tps = 324269.903152 (~0.77x) Najmniej problem odczują posiadacze starszych iPhonów. Te od dawna są sztucznie zwalniane przez Apple A może nie aplikować patchy? Co nam grozi? W uproszczeniu, oprogramowanie uruchamiane przez użytkowników musi wykorzystywać kernel do niektórych operacji takich jak nawiązanie połączenia sieciowego. Aby takie przekazanie kontroli od użytkownika do jądra i z powrotem było wydajne, dane wykorzystywane przez kernel są obecne w tzw. page tables danego procesu. Wprowadzone patche przesuwają kernel na całkowicie odseparowany zakres adresów. Każde wywołanie wymaga przełączania się pomiędzy tymi zakresami (użytkownikowym i kernelowym). Przełączanie nie jest natychmiastowe, bo zmusza procesor do zrzuty cache i przeładowania pamięci. To właśnie powód owego spowolnienia. Brak separacji oznacza, że atakujący mogą łatwiej exploitować błędy bezpieczeństwa (uzyskiwać dostęp do kernela) z poziomu użytkownika, obchodząc mechanizmy ASLR. A JavaScript w przeglądarce nie powinien takiego swobodnego dostępu posiadać. Albo program jednego użytkownika uruchamiany na współdzielonym serwerze w chmurze. No to może lepiej wymienić procka? Na razie wszystko wskazuje na to, że ci którzy mają Intela i chcą przy Intelu pozostać, muszą poczekać na wyprodukowanie nowego, wolnego od tego błędu procesora. Albo przesiąść się na AMD. PS. CEO Intela sprzedał pod koniec roku wszystkie akcje Intela, jakie mógł… Ale być może po prostu unika nowego podatku wprowadzanego w Kalifornii. Aktualizacja 3.01.2018, 11:00 Błąd w procesorach AMD to inny błąd. Tekst artykułu został zmodyfikowany, aby było to czytelniejsze. Źródło: niebezpiecznik.pl 1 Ogen Dogen, 3 Stycznia 2018 Zaloguj się, aby zobaczyć zawartość tej notki! Odnośnik do komentarza Udostępnij na innych stronach Więcej opcji udostępniania...
`RЕďvΞιΝ 1 339 Opublikowano 3 Stycznia 2018 Udostępnij Opublikowano 3 Stycznia 2018 Hej! Nie widzisz zawartości tego postu? Zaloguj się lub Zarejestruj nowe konto, aby korzystać ze wszystkich dostępnych funkcji! Odnośnik do komentarza Udostępnij na innych stronach Więcej opcji udostępniania...
Ogen Dogen 2 728 Właściciel Opublikowano 3 Stycznia 2018 Właściciel Udostępnij Opublikowano 3 Stycznia 2018 Hej! Nie widzisz zawartości tego postu? Zaloguj się lub Zarejestruj nowe konto, aby korzystać ze wszystkich dostępnych funkcji! Odnośnik do komentarza Udostępnij na innych stronach Więcej opcji udostępniania...
ACe w AXA? 45 Opublikowano 4 Stycznia 2018 Udostępnij Opublikowano 4 Stycznia 2018 Hej! Nie widzisz zawartości tego postu? Zaloguj się lub Zarejestruj nowe konto, aby korzystać ze wszystkich dostępnych funkcji! Odnośnik do komentarza Udostępnij na innych stronach Więcej opcji udostępniania...
Rekomendowane odpowiedzi