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:

bug bounty

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: