Buta kérdés: mi lenne egy Meltdown-nál is durvább hiba esetén?

Security-all

[Csak az olvassa, akit földhöz ver az unalom, mert csak agyalgattam...]

Kedves HUP-osok!

A témában igen laikus nagyok, bár azért a lényegét megértettem ennek a mostani hibának. Tisztán öncélú agyalásként eszembe jutott, mi lenne, ha egy olyan hiba is előjönne, amit nem lehet kernelből megjavítani. Jó, persze, ha a kernel egy virtuális gépet futtatna, ami emulálva hajtana végre mindent, az persze minden hardver-hibát kivédene, de nem 1-30% sebességvesztéssel, hanem nagyságrendivel.

Tehát mi lenne, ha olyan hardverbe kódolt hibára derülne fény, melyet szoftveresen csak töredékére visszaeső sebesség mellett lehetne korrigálni vagy bele kellene törődni, hogy amely processzek egy CPU-n futnak, azok pedig látják a másik területét, ha nagyon akarják. Át lehetne ilyen világra állni komoly informatikai fennakadások nélkül? A védelmi vonalakat tök máshol kellene felhúzni? (Pl. az intenzív számításokra fenntartott gépen nem futhatna web browser, ...)

  • 4263 megtekintés

( nxu | 2018. 01. 09., k – 00:28 )

A Spectre pontosan ilyen.

"While makeshift processor-specific countermeasures
are possible in some cases, sound solutions will require
fixes to processor designs as well as updates to instruc-
tion set architectures (ISAs) to give hardware architects
and software developers a common understanding as to
what computation state CPU implementations are (and
are not) permitted to leak."

+ annyit tennék hozzá, hogy a Meltdown-ra adott workaround is csak a kernel memóriát védi a userspace-től. Egy userspace folyamaton belül gyakorlatilag nem tudsz read műveletet címre korlátozni -> az in-process sandboxing megoldások innentől felejtősek. Vagyis pontosan az történik amit az OP leírt, máshova kell áthelyezni a védelmi vonalat. Minden browserben innentől tényleg muszáj lesz per-tab processeket csinálni.

És ha a Meltdown-ra sikerül is a jövőbeli processzorokat patchelni (tegyük fel most a gondolatkísérlet kedvéért, hogy az AMD ezt tényleg megoldotta, ez azt bizonyíthatja, hogy lehetséges durva teljesítményesés nélkül), a Spectre-re jelen pillanatban úgy néz ki, hogy az elképzelhető hardveres patchelési megoldások (PCID-alapú taggelés a különféle hidden channel mediumnak használható belső adatszerkezeteken) is csak process-ek között tudnak izolációt adni, in-process izoláció visszaállítására gyakorlatilag nincs épkézláb ötlet.
---
Régóta vágyok én, az androidok mezonkincsére már!

Például a Java SecurityManager-re épülő Sandbox ilyen. Az Applet-ek erre épülnek, már ahol még használják őket.
Ennek van .NET-es megfelelője is, azt hiszem Code Access Security néven.

A legtöbb javascript engine is próbál sandboxolni.
---
Régóta vágyok én, az androidok mezonkincsére már!

"Minden browserben innentől tényleg muszáj lesz per-tab processeket csinálni."

Bocs, ez azt jelenti, hogy a mostani hibák (Meltdown, Spectre) processzek közt nem látnak át? Én eddig így értettem. Vagy arról van szó, hogy ha majd javítják a hibákat hardveresen az új CPU-kban, akkor már processzek közt nem lesz keresztbe olvasás? Az in-process izoláció számomra nem tűnik olyannak, ami nélkül nem lehet élni.

De az eredeti kérdés az volt: ha lenne olyan hiba, ami a *processzek közti* izolációt tenné lehetetlenné akkor mit lehetne tenni? Ahogy lentebb írták: csak sokszorosan elleőrzött processzeket szabadna elindítani? Pl. browserből semmit, a helyi programokat meg egy "rosszszándék-szűrővel" le kellene ellenőrizni előbb, hogy kavarnak-e idióta memóriaolvasós trükkökkel? Lehetne ilyen szűrőt írni?

Az én megértésem szerint a Meltdown process-ek között nem lát át. (Az már csak következmény, ha a teljes fizikai memória be van mappelve a user folyamat virtuális címterébe - ahogy a Linuxnál defaultból volt - akkor beleolvashat másik process memóriaképébe is).

A Spectre bizonyos variánsai viszont átláthatnak. Ráadásul a Spectre nem egy (illetve két) konkrét támadási forma, hanem egy sebezhetőségi osztály, aminek számos további variánsát lehet még előállítani. Ezek egy része ellen lehet a CPU hardver módosítással védekezni (belső adatszerkezetek PCID-vel taggelése, hogy ne lehessen folyamatok között side-channelnek használni), más része ellen előreláthatólag nem, vagy csak extrém nagy teljesíŧményvesztéssel. Például a DRAM bankok nyitottsági állapotát is praktikusan lehet side-channelnek használni, ezt demonstrálták korábban a DRAMA támadásban: https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper_pessl.pdf. Ez viszont a CPU-n kívül esik, és nem lehet PCID taggeléssel megoldani, ráadásul CPU magok között is tud szivárogtatni.

Tehát a Spectre variánsok nagy részénél valószínüleg a hardveres fix annyit ér el, hogy a processek közötti szivárgást zárja be, a processen belülit nem. Más lehetséges variánsoknál viszont a processek közötti szivárgás sem tűnik egyszerűen bezárhatónak.

In process izoláció nélkül valószínűleg lehet élni, de itt is számítani kell teljesítményvesztésre, ahol trusted/untrusted határ közé mindig process szeparálást is be kell építeni. Ennek fejlesztési költsége sem kicsi (masszív architekturális átalakítás), lassít, a memóriaigényt is megdobja.
---
Régóta vágyok én, az androidok mezonkincsére már!

( joco01 v | 2018. 01. 09., k – 12:00 )

Alapvetően csak akkor van baj, ha rosszindulatú program fut a gépeden. Jó esetben az ember megbízható helyről tölt le cuccot (pl. Play store) vagy nyílt forrás (many eyeballs). Másik védelmi vonal a vírusirtó. Egy speciális eset a web, ahol elég könnyen lehet kártékony JS-be futni, de ez ellen is van védelem, a JS célzott vagy teljes tiltása. A CPU-ba épített védelem csak egy a sok közül.

A számológép app nem fog hirtelen a szövegszerkesztő ellen fordulni csak úgy, egy offline desktop gép mindenféle CPU védelem nélkül is elfutna. A CPU védelem eredeti célja szerint inkább bugok ellen védi a rendszert, hogy egy app hibája ne vezessen teljes rendszerhalálhoz. Mellékesen támadások ellen is jó.

Amúgy elég szomorú, ha mikrokód frissítéssel nem javítható ez a hiba. Azt gondolnám, hogy többek között erre jó. Ha jól értem, akkor a Meltdown és Spectre ellen is védene, ha branch mispredict esetén menne egy clflush. Egyszerűnek tűnik, de laikus vagyok.

A fejlesztők névvel, címmel, bankkártyával, fizetéssel regisztrálnak, van kártékony szoftverekre automatikus szűrés, és emberi moderáció is.

Tudom, hogy mindet ki lehet játszani külön-külön, de még akár egyben is. Semmilyen rendszer se tökéletes. De több védelem együtt akkor is hasznos dolog.

Szerintem nem olvastad el, amit írtam.

Kifejezetten írtam, hogy tudom, hogy nem tökéletes a rendszer. Se a Play, se a többi. Ennek ellenére mégis nagyságrendekkel jobb, mint a netről random letöltött APK-kat futtatni.

És a vírusirtók és egyebek sem tökéletesek. És amint látjuk, még a CPU/kernel védelem sem mindig az. A lényeg az, hogy törekedni kell, minél több védelmet együtt használni, frissíteni, stb.

Nem szabad abba a hibába esni, hogy csak egy védelmi vonal van. Erről szól az eredeti téma, hogy mi van akkor, ha. Hát az van, hogy ha az egyik védelem elesik, még van mellette más is.

De elolvastam.

> Kifejezetten írtam, hogy tudom, hogy nem tökéletes a rendszer. Se a Play, se a többi. Ennek ellenére mégis nagyságrendekkel jobb, mint a netről random letöltött APK-kat futtatni.

En az allitasod kerdojeleztem meg, h a play store megbizhato.

> És a vírusirtók és egyebek sem tökéletesek

Ezaz, van itt egy nagy kulonbseg.
A virusirtok megbizhatoBBak. Azzal nem lenne problemam, ha a play store-ra is megbizhatoBBkent hivatkoznal.
De miert tekintsek a play store megbizhatokent?

( uid_16313 | 2018. 01. 09., k – 15:28 )

Igazából szerintem ez már régen így van, csupán a lehetséges, és már adott sebezhetöségek felfedezése tart tovább, mint kellene. Vagy éppen fel sem fedeznek réseket, amiket mások régóta kihasználnak.

Tulajdonképpen a hibátlan hardver és szoftver az kb. olyan, mint a balesetmentes közlekedés. Müködhet ideig-óráig, szerencsés esetben akár hosszú távon is, de a baleset lehetösége mindig adott, és nem biztos, hogy mindig a felhasználó a hibás benne.

Èn már jó ideje nem hiszek abban, hogy létezik hálózatba kötött gépeknél biztonság. Ahogy elérem én a távoli eröforrásokat, ugyanúgy érnek engem is el, és a "védelmi vonal" ezer sebböl vérzik.

Mint általában mindig, a megoldás egy papír lenne: "csak saját felelösségre". Aláírva, és minden meg van oldva egy csapással.

--
robyboy

"Èn már jó ideje nem hiszek abban, hogy létezik hálózatba kötött gépeknél biztonság. Ahogy elérem én a távoli eröforrásokat, ugyanúgy érnek engem is el, és a "védelmi vonal" ezer sebböl vérzik."

Bár nem vagyok szakmabeli - csak egy egyszerű fehasználó - egyetértek. Talán (már nem emlékszem) trey írta itt annak idején, hogy két fajta számítógép létezik, amit feltörtek és amit fel fognak törni.

Mindeközben ezerrel jön az IoT....

( hajbazer v | 2018. 01. 10., sze – 23:57 )

A Spectre / Meltdown is tekinthető nagyságrendi sebességcsökkenésnek. A 30% azt jelenti, hogy elveszítetted nagyjából az egyharmad erőforrását a processzorodnak.

Egyébként nagyjából az lenne, ami most. A hardvergyártó bennfentes részvényesei
target="_blank">(például a CEO) eladná a részvényeit, majd elkezdene a cég undorítóbbnál undorítóbb módon mosakodni, PR-kampányokat indítani, leporolni magáról a felelősségnek még a szikráját is. Utána többszázmillió emberrel kidobatnák a frissítéssel taccsra vágott teljesítményű számítógépet, és vetetnének helyette újat, ami szintén tele van hibával, csak azok még nem ismertek. A többszázmillió ember pedig megfelelő marketing-hadjárat után engedelmeskedne, hiszen a múltat el kell engedni™ és az újabb™ = jobb. Ha a technológiai piac kicsit is racionálisan működne, sem az Intel, sem a Microsoft, sem a hozzájuk hasonló, velejéig arrogáns, a piacot és a fogyasztóikat rendre megtévesztő, érdekeiket magasról leszaró, csak a pénzért ámokfutó megavállalatok nem tudnának fennmaradni.

"A Spectre / Meltdown is tekinthető nagyságrendi sebességcsökkenésnek. A 30% azt jelenti, hogy elveszítetted nagyjából az egyharmad erőforrását a processzorodnak."

Nem akarlak elkeseríteni, de a nagyságrendi eltérés az egy tizes szorzó vagy osztó.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Leírtam, hogy mit jelent a nagyságrendbeli eltérés. Szorzást valahol általános iskola közepén tanítják. Nem kell hozzá Mérnök Úrnak lenni.

Egyébként meg kimérték már többen, hogy erősen feladatfüggő, hogy 1-2% vagy 10-30%. Jellemzően az IO igényesebb feladatoknál jön a nagyobb százalék.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

"Hétköznapi használatban a „nagyságrendekkel több/kevesebb” egyszerűen a „sokkal több/kevesebb” erősebb formája.[1] (Ehhez hasonló például a „hatványozottan nő/csökken” kifejezés is, ami köznapi használatban szintén nem szó szerint értendő)"
https://hu.m.wikipedia.org/wiki/Nagyságrend

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

De nem veti, csak hajasbazár veri a nyálát a vakvilágba, hogy meglegyen a kis kognitív disszonanciája.

Átlag, otthoni use-casekben 1-2% a mérések alapján. Amennyire néztem, leginkább az IO intenzív feladatoknál van visszaesés, pl. adatbázis-kezelők alatt. (Ott viszont tényleg fájó tud lenni.)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

( toMpEr | 2018. 01. 11., cs – 00:00 )

Valószínű releváns:

https://arxiv.org/pdf/1710.00551.pdf

In this paper, we present novel Rowhammer attack and exploitation primitives, showing that even a combination of all defenses is ineffective [..] We present 29 bit offsets, each allowing an attacker to obtain root privileges in practice. Coaxing the operating system into relocating any binary page takes 2.68s with our stealth-optimized variant, and only 36.7µs with our speed-optimized variant. Finally, we leveraged Intel SGX to hide the full privilege-escalation attack, making any inspection or detection of the attack infeasible. Consequently, our attack evades all previously proposed countermeasures for commodity systems

Érdemes megfigyelni a szerzőket: Daniel Gruss (TU-Graz), Michael Schwarz (TU-Graz), Daniel Genkin (University of Pensilvania). A többi szerző neve változik, de ezek a nevek mindegyiken ott szerepelnek, gyakorlatilag az összes közelmúltbeli alapvető hardveres sebezhetőség-típus felfedezése egyazon a kutatócsoporthoz köthető: Meltdown, Spectre, Rowhammer, Drama
---
Régóta vágyok én, az androidok mezonkincsére már!

Alapvetően az elsőre gondoltam. De a többi is érdekes.

"This work was supported in part by the European Research Council (ERC) under the European Union’s Horizon 2020 research and innovation programme (grant agreement No 681402).

This work was supported in part by NSF awards #1514261 and #1652259, financial assistance award 70NANB15H328 from the U.S. Department of Commerce, National Institute of Standards and Technology, the 2017-2018 Rothschild Postdoctoral Fellowship, and the Defense Advanced Research Project Agency (DARPA) under Contract #FA8650-16-C-7622."

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™