Vlákno názorů k článku
Nový vzdálený útok NetSpectre od Pavel Snajdr - No, par dni chodim a mam z toho...

No, par dni chodim a mam z toho hlavu v kyblu... Jak tohle vyresit? Kdyz zarovnam paketum timing na neco, ze ceho to nepujde poznat, udelam z toho par desetimegabitovou ukapavaci linku...

Nekdo nejaky napady na neco, co nevyzaduje kvalitni in-line zdroj nahodnyho casovani? Cilova implementace bude na FPGA, takze se da dost vymyslet, otazkou je ta strategie na mitigaci.

Ideas?

Chtěl bych vidět od někoho nezávislý opakování experimentu (netvrdím, že si vymýšlí, ale autoři zvyknout přehánět a vybrat si "ty případy, kde to funguje"). Hlavně ty podmínky jsou celkem striktní na to, aby to šlo vůbec měřit.

Hmm, pro LAN z 6.1.1: "We measured a standard deviation of the network latency of 15.6 μs. Applying the three-sigma rule [70], in at least 88.8 % cases, the latency deviates ±46.8 μs from the average. This is nearly 3 orders of magnitude larger than the actual timing difference the attacker wants to measure, explaining the large number of measurements required."

Z 6.1.3 to taky vypadá, že musí být cíl a oběť "blízko a na rychlé lince" - stejný segment/HW kde je to virtualizováno. 20M pokusů na 1 bit.

Taky jsem si není jistý protiopatřeními - "Another method to mitigate NetSpectre is to add artificial noise
to the network latency." Neplatí, že šum se známým statistickým rozdělením lze "odprůměrovat"?

Presne k tomu jsem dosel jako k reseni - FIFO s nejakym casove randomizovanym vybiranim, pocet cyklu na delay == cislo nactene z nejakeho kvalitniho zdroje random cisel. Akorat totiz kreslim scale-out system pro vpsFree, abychom mohli nekde hostovat i veci, kterym se opravdu da verit. Dosel jsem k tomu, ze nevadi az tak zranitelny procesor sam o sobe (kdyz ho s nikym nesdilis, ani pameti teda), cca staci, kdyz si clovek je schopny zachovat integritu bezicich veci a nevystavi ven interface s prilis malou latenci.

Pak jsme teda zpatky na levelu, ze v te hromade pointerove C magie muzou byt fajne 0days, ale to uz je kazdeho byznys, at si bezi treba OpenBSD, nebo neco v Rustu ;)

Kdyz ty pakety pujdou do trochu hlubsiho FIFO (tj. nutne tam potrebuju dolepit DDR pamet), bude prostor pro vetsi vychylku a myslim, ze by tim mela byt vic zastrena pripadna nekvalita RNG. Co mne stve, je potreba tam ten RNG vubec mit...

Problém je, že šum sieťovej komunikácie nie je známy.

Čo robia v tom článku je odmeranie hostigramov pre 0 a 1 a potommeranie histogramov pre neznáme hodnoty..

To je problem teoreticky. Pak prijde praxe a to, ze vetsina cloud provideru ma beefy top of rack switche, takove StrataXGS Trident II+ ma 150ns port-to-port latenci, i kdyz dela L3 forwarding.

>Z 6.1.3 to taky vypadá, že musí být cíl a
>oběť "blízko a na rychlé lince"

nemusí, ale narastie Vám

"latency deviation" a teda jedno meranie sa predĺži a bude nutný väčší počet meraní

Na information leak - zjištění adresy na obejití ASLR a použít to na jiný útok (buffer/heap overflow) to bohatě stačí.

Jenom proto, ze tomu nerozumis a neumis si domyslet souvislosti, neznamena, ze to neni vazny problem.

A kdybys k tomu jeste nebyl liny si ten paper otevrit:

"While this is comparably slow, it shows that remote Spectre
attacks are feasible between independent instances in the public
cloud. In particular, APTs typically run for several weeks or months.
Such an extended time frame is clearly sufficient to leak sensitive
data, such as encryption keys or passwords, using the NetSpectre
attack in a cloud environment."