Preorder drugiego tomu książki sekuraka: Wprowadzenie do bezpieczeństwa IT. -15% z kodem: sekurak-book
Intel zapłacił za podatność $100 000 – szczegóły
Najpierw na platformie Hackerone pokazała się dość enigmatyczna informacja o przyznaniu w ramach programu bug bounty nagrody w wysokości $100 000:
A niewiele później otrzymaliśmy szczegóły – są to nowe odmiany najniebezpieczniejszego pierwszego wariantu znanej podatności Spectre (przypominamy, oryginalna podatność umożliwiała wykradanie pamięci z systemu operacyjnego oraz z innych aplikacji). Nowe odmiany zostały oznaczone jako: 1.1 (CVE-2018-3693) oraz 1.2
Jeśli ktoś chce wgryźć się w techniczne szczegóły – zapraszam do lektury tej pracy, która jak się okazuje była sponsorowana częściowo przez… samego Intela. Nie jest to swoją drogą rzadki model współpracy: dajmy sensownym badaczom budżet na dalszy research, a jeśli rzeczywiście znajdą coś dużego to przyznamy osobną nagrodę.
Wracając do szczegółów, techniki pokazane w ramach Spectre 1.1 są w stanie ominąć niektóre zabezpieczenia na Spectre 1 (czyli wracamy do możliwości czytania pamięci z danej maszyny – zawierającej np. hasła dostępowe czy inne ciekawe dane):
Much like classic buffer overflows, speculative out-of-bounds stores can modify data and code pointers. Data-value attacks can bypass some Spectre-v1 mitigations, either directly or by redirecting control flow. Control-flow attacks enable arbitrary speculative code execution, which can bypass fence instructions and all other software mitigations for previous speculative-execution attacks. It is easy to construct return-oriented-programming (ROP) gadgets that can be used to build alternative attack payloads.
Choć przykładowo tutaj mamy informację, że zabezpieczenia przed Spectre 1 są już wystarczające (?).
Spectre 1.2 z kolei umożliwia ominięcie pewnych restrykcji na zapis do pamięci – w szczególności można pisać do bloków oznaczonych jako read-only (w ten sposób np. wyskakując z sandboksów):
In a Spectre1.2 attack, speculative stores are allowed to overwrite read-only data, code pointers, and code metadata, including vtables, GOT/IAT, and control-flow mitigation metadata. As a result, sandboxing that depends on hardware enforcement of read-only memory is rendered ineffective.
Co robić? Niestety sytuacja wygląda jak poprzednio (czyli trochę paniki, sprzeczne informacje, brak informacji).
Przykładowo, SUSE pisze:
Mitigations needed for this are similar to Spectre Variant 1.Speculative fences need to be added in affected places throughout the Linux Kernel and hypervisor code.
Both Kernel and Hypervisor fixes will be provided in the near future.
These issues are likely to primarily impact operating systems and virtualization platforms, and may require software update, microcode update, or both.
czyli zespol OpenBSD mial racje wylaczajac HT ;)