Projekt niedawno Grsecurity ogłoszono poprzez publikację szczegóły i demo metoda ataku na nową podatność (już wymienione jako CVE-2021-26341) na procesorach AMD związanych z wykonywaniem instrukcji spekulacyjnych po bezwarunkowych operacjach skoku do przodu.
Słaby punkt pozwala procesorowi na spekulacyjne przetwarzanie instrukcja bezpośrednio po instrukcji skoku (SLS) w pamięci podczas wykonywania spekulatywnego. Jednocześnie taka optymalizacja działa nie tylko w przypadku operatorów skoków warunkowych, ale także instrukcji zawierających bezpośredni skok bezwarunkowy, takich jak JMP, RET i CALL.
Instrukcje rozgałęzienia bezwarunkowego mogą zawierać dowolne dane, które nie są przeznaczone do wykonania. Po ustaleniu, że w oddziale nie ma wykonania kolejnego oświadczenia, procesor po prostu cofa stan i ignoruje wykonanie spekulacyjne, ale ślad wykonania instrukcji pozostaje w ogólnej pamięci podręcznej i jest dostępny do analizy przy użyciu metod pobierania kanałów bocznych.
Firma AMD udostępnia aktualizację zalecanych środków łagodzących, łagodzących G-5, w oficjalnym dokumencie „Techniki oprogramowania do zarządzania spekulacjami dotyczącymi procesorów AMD”. Łagodzenie G-5 pomaga wyeliminować potencjalne luki związane ze spekulacyjnym zachowaniem instrukcji rozgałęzień.
Procesory AMD mogą przejściowo wykonywać instrukcje po bezwarunkowej gałęzi forward, co może skutkować aktywnością pamięci podręcznej
Podobnie jak w przypadku eksploatacji Widmav1, atak wymaga obecności określonych sekwencji instrukcji (gadżetów) w jądrze, co prowadzi do spekulacyjnego wykonania.
W tym przypadku zablokowanie podatności sprowadza się do zidentyfikowania takich urządzeń w kodzie i dodania do nich dodatkowych instrukcji blokujących wykonanie spekulacyjne. Warunki do wykonania spekulatywnego można również stworzyć za pomocą nieuprzywilejowanych programów uruchomionych na maszynie wirtualnej eBPF.
W wyniku tego dochodzenia odkryto nową lukę CVE-2021-26341 [1] , które szczegółowo omówimy w tym artykule. Jak zwykle skupimy się na technicznych aspektach luki, sugerowanych przez AMD działaniach łagodzących oraz aspektach eksploatacji.
Aby zablokować możliwość budowania urządzeń z wykorzystaniem eBPF, zaleca się wyłączenie nieuprzywilejowanego dostępu do eBPF w systemie ("sysctl -w kernel.unprivileged_bpf_disabled=1").
Luka dotyczy procesorów opartych na mikroarchitekturze Zen1 i Zen2:
Biurko
- Procesor AMD Athlon™ X4
- Procesor AMD Ryzen™ Threadripper™ PRO
- Procesory AMD Ryzen™ Threadripper™ drugiej generacji
- Procesory AMD Ryzen™ Threadripper™ trzeciej generacji
- Układy APU AMD serii A siódmej generacji
- Procesory do komputerów stacjonarnych AMD Ryzen™ z serii 2000
- Procesory do komputerów stacjonarnych AMD Ryzen™ z serii 3000
- Procesory AMD Ryzen™ z serii 4000 do komputerów stacjonarnych z kartą graficzną Radeon™
Ruchomy
- Procesor mobilny AMD Ryzen™ z serii 2000
- Procesory mobilne AMD Athlon™ z serii 3000 z kartą graficzną Radeon™
- Procesory mobilne AMD Ryzen™ z serii 3000 lub procesory mobilne AMD Ryzen™ drugiej generacji z kartą graficzną Radeon™
- Procesory mobilne AMD Ryzen™ z serii 4000 z kartą graficzną Radeon™
- Procesory mobilne AMD Ryzen™ z serii 5000 z kartą graficzną Radeon™
Chromebook
- Procesory mobilne AMD Athlon™ z kartą graficzną Radeon™
Serwer
- Procesory AMD EPYC™ pierwszej generacji
- Procesory AMD EPYC™ drugiej generacji
Wspomina się, że jeśli atak się powiedzie, podatność umożliwia określenie zawartości dowolnych obszarów pamięci.
Ze względu na tę lukę możliwe jest zidentyfikowanie łagodnych konstrukcji kodu, które tworzą ograniczone, ale potencjalnie możliwe do wykorzystania urządzenia SLS na dotkniętych nią procesorach. Jak pokazano na przykładzie eBPF, możliwe jest również wykorzystanie luki w ręcznie zbudowanych urządzeniach do samodzielnego wstrzykiwania. Przedstawiona metoda może być wykorzystana np. do złamania łagodzenia KASLR jądra Linux.
Na przykład badacze przygotowali exploit, który pozwala określić układ adresu i ominąć mechanizm ochrony KASLR (kernel memory randomization) poprzez wykonanie kodu bez uprawnień w podsystemie jądra eBPF, oprócz innych scenariuszy ataków, które mogłyby spowodować wyciek zawartość pamięci jądra nie jest wykluczona.
W końcu jeśli chcesz dowiedzieć się czegoś więcej na ten tematmożesz sprawdzić szczegóły W poniższym linku.