Intel julkaisi 12 uutta haavoittuvuutta ja suunnittelee säännöllisiin päivityksiin siirtymistä

[Kaotik]

Intel on ryvettynyt kuluvan vuoden aikana kilpailijoitaan useammin prosessoreiden haavoittuvuuksia koskevissa paljastuksissa. Loppua haavoittuvuuksille ei näy ainakaan toistaiseksi, sillä yhtiö on julkaissut jälleen tiedon muun muassa uuden Spectre-tyyppisen haavoittuvuuden olemassaolosta.

Intel julkaisi eilen tiedon yhteensä kahdestatoista haavoittuvuudesta, joista yksi on sukua Spectren ykkösvariantille. Haavoittuvuuden löysivät Vladimir Kiriansky ja Carl Waldspurger, jotka nettosivat samalla 100 000 dollarin palkkion yhtiön buginmetsästysrahastosta. Kaikki nyt julkaistut haavoittuvuudet eivät koske kuitenkaan yhtiön prosessoreita, vaan mukana on myös mm. UEFI-, ohjelmisto sekä Optane-haavoittuvuuksia. Kaikeksi onneksi haavoittuvuuksille julkaistiin samalla päivitykset.

Jatkossa Intel harkitsee The Registerin mukaan siirtymistä neljännesvuosittain oletuksena julkaistaviin päivityksiin. Tämä helpottaisi ainakin loppukäyttäjien työtä, kun päivityksiä tietäisi tarkastaa aina tiettyinä ajankohtina täysin satunnaisten julkaisujen sijasta. Poikkeuksen sääntöön tekisivät luonnollisesti kriittiset haavoittuvuudet, jotka vaativat pikaisempaa paikkausta.

Lähde: The Register, Intel

Linkki alkuperäiseen uutiseen (io-tech.fi)

 

[Threadripper]

Lisää Spectreä siis tulee kuten oli helppo ennustaa. Toistaiseksi kuitenkin aika mietoa tavaraa, koska Spectre 1 patsi tehoaa tähänkin. Odotuksissa "Meltdown 2" joka aiheuttaa vielä enemmän haloota kuin Meltdown aiheutti.

 

[Taneli-]

Eipä tämä hyvä uutinen ole mutta ehkä tavallaan odotettavissa. Voi hyvinkin olla että tulevaisuudessa myös AMD siirtyy neljännesvuosittain julkaistaviin päivityksiin.

Siitä olen tosin tyytyväinen että ehdin hyvissä ajoin myydä oman 2600K prosessorini(+emo +8Gb muistia) nyt kun molemmilta valmistajilta on tullut useampiytimellisiä prosessoreita ja ilmoitusta että vanhoihin malleihin (sekä osittain uusiinkin) on tullut ties mitä haavoittovuuksia mitä vanhoissa ei ehkä edes ikinä korjata (tai emolevyn tekijöiden vastuulla => ei ikinä korvata) uskon että myyntihinnat tippuvat roimasti.

 

[rlame]

Koskeeko näistä joku myös amd ryzenia vai onko pelkästään intel ongelma? Onko näistä odotettavissa jotain käytännön ongelmia?

 

[Sami Riitaoja]

Siis nyt julkaistiin kuinka voidaan aiheuttaa spekulatiivisilla storeilla koodinmuutoksia, Meltdown-prossuilla tämä saadaan tehtyä vain lukuoikeuksillakin olevaan koodinosaan eli raudalla sandboksattu koodi karkaa Meltdown-prossuista, eikä tähän taida mitään halpaa ja hyvää keinoa korjaukseen olla tarjolla, rautapäivitystä ainakin tuossa whitepaperissa toivotaan.

https://arxiv.org/pdf/1807.03757.pdf

 

[Hannibal]

No näiden osalta toimitaan kuten pitää. Julkaistaan ongelma vasta kun on vastaus valmiina. Eihän näistä ongelmista sinällään päästä eroon ennenkuin koko prossa pistetään uusiksi. Eivät varmasti mainosta koska, ettei tule taukoa myyntiin...
Mutta tuskin vielä vähään aikaan. Ensi vuonna olisi jo aika nopeasti jottei korjata wanhoja ja luoda samalla uusia ongelmia.

 

[IcePen]

Ne on nää prosessorien haavoittuvuudet tainneet tulla uudeksi trendiksi hyökkäys keinojen tehtailijoilla, mikä ei sinällään ole hyväjuttu kun se kasvattaa riskiä sille että joku löytää prosessori/piirisarja aukon jonka ainut korjauskeino on uuden prosessorin/emolevyn hankkiminen.

 

[Taneli-]

Njaa, kuitenkin on olemassa meitä jääräpäitä joita ei vaan kiinnosta, kuten ei kiinnosta tehonkulutus yms. muutkaan komponenttien haittapuolet.

Juu, kyllähän yllättävän moni porskuttaa vielä esim. windows XP:llä ilman ensimmäistäkään päivitystä tai service packkia...

 

[hkultala]

Siis nyt julkaistiin kuinka voidaan aiheuttaa spekulatiivisilla storeilla koodinmuutoksia, Meltdown-prossuilla tämä saadaan tehtyä vain lukuoikeuksillakin olevaan koodinosaan eli raudalla sandboksattu koodi karkaa Meltdown-prossuista, eikä tähän taida mitään halpaa ja hyvää keinoa korjaukseen olla tarjolla, rautapäivitystä ainakin tuossa whitepaperissa toivotaan.

https://arxiv.org/pdf/1807.03757.pdf

Se "karkaaminen" on edelleenkin vain spekulaatiivista, ja sitä voidaan käyttää käytännössä vain muiden sivukanavahyökkäysten toteuttamiseen.

Mitään oikeasti voimaan astuvaa kirjoitusta laittomiin osoitteisiin ei tuolla mekanismilla voida tehdä.

 

[Sami Riitaoja]

Se "karkaaminen" on edelleenkin vain spekulaatiivista, ja sitä voidaan käyttää käytännössä vain muiden sivukanavahyökkäysten toteuttamiseen.

Mitään oikeasti voimaan astuvaa kirjoitusta laittomiin osoitteisiin ei tuolla mekanismilla voida tehdä.

Kyllä mutta tuo antaa aivan huiman paljon tehokkaamman aseen hakkerille käyttöön, eli kuhan saadaan spekulatiivisella storella koodipolulle hyppykäsky boksatun ohjelman dataan sinne voidaan sijoittaa hyökkääjän oma konekielinen koodi ajettavaksi, sillä edellytyksellä että myöskin NX-bitti käsitellään samoin kuin muutkin oikeudet. Eli Meltdownista kärsivässä prossussa oikeastaan kaikki tietoturvaan viimevuosikymmeninä lisätty tavara on poissa käytössä spekulatiivisessä koodin ajossa.

Ei tässä tietysti mitään helppoa hakkerointikeinoa ole mutta mahdollisuudet raudan puolesta on järjestetty liki niin hyviksi kuin mahdollista. Tuo Intelin kustantama selostushan ei revittele liiemmin mahdollisuuksilla, tyytyy vain toteamaan että Sandboksaus saadaan rikotttua.....

Meltdown -> kokeillaan lukea suojattua dataa -> V1.2 buffer overflow:lla hyppykäsky omaan koodiin - nyt on kaksi helpointa keinoa toteutettu Meltdown prossuilla julkisesti ja tuskin se siihen tulee jäämään.

 

[hkultala]

Kyllä mutta tuo antaa aivan huiman paljon tehokkaamman aseen hakkerille käyttöön, eli kuhan saadaan spekulatiivisella storella koodipolulle hyppykäsky boksatun ohjelman dataan sinne voidaan sijoittaa hyökkääjän oma konekielinen koodi ajettavaksi, sillä edellytyksellä että myöskin NX-bitti käsitellään samoin kuin muutkin oikeudet. Eli Meltdownista kärsivässä prossussa oikeastaan kaikki tietoturvaan viimevuosikymmeninä lisätty tavara on poissa käytössä spekulatiivisessä koodin ajossa.

Mitään arkkitehtuurillista tilaa ei jää voimaan mistään spekulatiivisesti suoritetusta.

Storet ei mene store-puskuria pidemmälle (toki menevät sieltä siis store->load-forwardilla seuraaville spekulatiivisesti suoritetuille käskyille, mutta eivät mene edes L1-välimuistiin asti) ja ne flushataan sieltä store-puskurista kun haarautumisennustushuti huomataan.
Muuta IOta tekevät käskyt eivät tee IOtaan ennen kuin commit-vaiheessa (joka ei tapahdu).

Ja kaikkien rekisterien arvot peruutetaan tilaan ennen sitä haarautumisenennustushutia.

Ainoa mikä on muuttunut on ei-arkkitehtuurillinen tila (se, mitkä osoitteet on välimuisteissa ja TLBssä, mitä haarautumisenennustus ennustaa yms.), ja sitä muuttamalla ei pystytä muuttamaan minkään ohjelman mitään dataa tms. koska ei-arkkitehtuurillista tilaa ei käytetä inputtina yhtään millekään laskennalle.

Kaiken mitä se koodi tekee, sen pitää tehdä sivukanavien kautta.

Rowhammer on edelleenkin, näiden julkaisun jälkeenkin, ainoa tunnettu tapa sivukanavahyökkäyksellä kirjoittaa mitään arkkitehtuurillisesti näkyvää.

Ja järeimmissä prossuissa ROB-puskurin koko on n. 200 käskyn luokkaa(well-sarjassa 192, lake-sarjassa 224, zenissä 192). Se on maksimimäärä koodia, mitä voi spekulatiivisesti olla suorituksessa. Käytännössä usein selvästi vähemmän, koska rajoittavia tekijöitä on muitakin.

 

[Nerkoon]

Jos Intel on oikeasti siirtymässä säännöllisiin päivityksiin, niin se on aika lailla sama kuin myöntää oman softan laadun olevan alta kaiken arvostelun. Ei sinänsä yllätä kun olen jo vuosia ihmetellyt miten Intelin näytönohjainajurit voivat olla niin järjettömän bugisia.

 

[Kaotik]

Jos Intel on oikeasti siirtymässä säännöllisiin päivityksiin, niin se on aika lailla sama kuin myöntää oman softan laadun olevan alta kaiken arvostelun. Ei sinänsä yllätä kun olen jo vuosia ihmetellyt miten Intelin näytönohjainajurit voivat olla niin järjettömän bugisia.

Ei ole. Ideana on helpottaa elämää sillä, ettei käyttäjän tarvitse arpoa milloin mihinkin juttuun on päivityksiä, vaan ne voi tarkistaa neljännesvuosittain kätevästi yhdestä paikkaa. Kriittiset päivitykset toki erikseen

 

[Sami Riitaoja]

Mitään arkkitehtuurillista tilaa ei jää voimaan mistään spekulatiivisesti suoritetusta.

No olenko niin muka väittänyt?

Nyt on siis keino ajaa prosessorin spekulatiivinen osa ajamaan hyökkääjän omaa koodia, tähän voi vielä lisätä mahdollisuuksiksi sen että ko. koodi lienee mahdollista ajaa ring0-oikeuksilla. Tarjoaa aika hyvän mahdollisuuden tutkia sandboksatun isäntäohjelman dataa.

 

[Sami Riitaoja]

koska ei-arkkitehtuurillista tilaa ei käytetä inputtina yhtään millekään laskennalle.

Näinhän se menisi jos prosessori toimisi niin kuin pitää. Meltdownista kärsivissä prosessoreissa ongelma nimenomaan on että ei-arkkitehtuurillista tilaa käytetään inputtina spekulatiivisessa laskennassa mikä mahdollistaa datan vuotamisen ulospäin.

 

[hkultala]

Näinhän se menisi jos prosessori toimisi niin kuin pitää. Meltdownista kärsivissä prosessoreissa ongelma nimenomaan on että ei-arkkitehtuurillista tilaa käytetään inputtina spekulatiivisessa laskennassa mikä mahdollistaa datan vuotamisen ulospäin.

Ei. Täysin päinvastoin.

Spekulatiivisella laskennalla saadaan muutettua ei-arkkitehtuurillista tilaa, ja joillain profilointikäskyllä saadaan sitten (ei-spekulatiivisesti) luettua se ei-arkkitehtuurillinen tila.

Voisitko nyt yrittää ymmärtää, mitä spekulatiivinen suoritus tarkoittaa, ja mitä arkkitehtuurillinen ja ei-arkkitehtuurillinen tila tarkoittaa.

Meltdown-alttius tarkoittaa vain sitä, että muistiaccessien tietyt oikeudet tarkastetaan/tarkastuksiin reagoidaan vasta commit-vaiheessa eikä execute-vaiheessa, minkä takia dataa ladataan muistista välimuistiin sekä välimuistista seuraaville spekulatiivisesti suoritetuille käskyille. Näistä ensimmäinen mahdollistaa ei-arkkitehtuurillisen tilan muuttumiseen välimuistin osalta, ja näistä jälkimmäinen mahdollistaa sen "tähtäämisen" välimuistin/muistin osalta haluttuun osoitteeseen.

Mikään mikä suoritetaan (vain) spekulatiivisesti ei näy arkkitehhtuurillisena tilana. Käskyjen muutoksen arkkitehtuurilliseen tilaan astuu voimaan vain jos käsky commitoidaan (mitä ei tapahdu käskyille, jotka suoritetaan vain spekulatiivisesti). Ne oikeustarkastuksen tehdään aina ennen kuin sivuvaikutukset astuu voimaan.

 

[jive]

Mielenkiintoista kuulla mitä Linus kommentoi. Menee aika karvaiseksi softakehitys jos kolmen kuukauden välein joutuu uusimaan arkkitehtuurioptimoinnit.

Turvakriittiset ja mission critical sovellukset pitänee jatkossa toteuttaa jollain muulla arkkitehtuurilla. Tai ehkä Intel kaivaa IA64:sen naftaliinista

 

[jive]

Ei ole. Ideana on helpottaa elämää sillä, ettei käyttäjän tarvitse arpoa milloin mihinkin juttuun on päivityksiä, vaan ne voi tarkistaa neljännesvuosittain kätevästi yhdestä paikkaa. Kriittiset päivitykset toki erikseen

On myös käyttäjiä joita tuon luokan muutokset voivat isommin häiritä. Minun näkökulmastani katsottuna kaikki spekulatiivisen suorituksen arkkitehtuurit alkavat olla ulkona tulevista tuotteista.

 

[Kaotik]

On myös käyttäjiä joita tuon luokan muutokset voivat isommin häiritä. Minun näkökulmastani katsottuna kaikki spekulatiivisen suorituksen arkkitehtuurit alkavat olla ulkona tulevista tuotteista.

Niin siis ei tässä nyt ole mistään sellaisesta puhuttu, että joka neljännes tulisi jotain prosessorin tietoturvafirmwarepätsejä, vaan yleisesti intelin päivityksiä

 

[hkultala]

Mielenkiintoista kuulla mitä Linus kommentoi. Menee aika karvaiseksi softakehitys jos kolmen kuukauden välein joutuu uusimaan arkkitehtuurioptimoinnit.

Ei ole tainnut kommentoida näistä vielä mitään, tajuaa että nämä ovat vaan variaatioita alkuperäisiin specre- ja meltdown-exploitteihin, pohjimmiltaan syyt näihin on aivan samat, ja Linus ranttasi silloin jo ihan tarpeeksi ja sanoi kaiken oleellisen sanottavansa

Ainoa millään tavalla asiaan liittyvä kommentti minkä Linusilta olen näiden jälkeen nähnyt on liittynyt ehdollisiin siirtokäskyihin ja niiden ehdon ennustamiseen:

Real World Technologies - Forums - Thread: ARM launches site to spread FUD about RISC-V

I'm pushing for at least Intel to just make it architectural that cmov and arithmetic cannot cause the Spectre-v1 kind of issues.

Because it is, in my opinion, completely unacceptable to say "hey, we don't have a security issue now, but we want to keep the door open to screwing up in the future".

Face it, data speculation is broken. It was broken before, but now it's known to be unacceptable.

Before the Spectre issue, I think it was understandable if somebody said "we might do cmov with speculation".

Mutta tämä ei siis ota kantaa näihin uusiin variaatioihin vaan spectreen yleisesti.


ARM ehti muistaakseni jo ennen spectreä ja meltdownia speksata joitain käskyjä siten, että niiden suoritusaika ei saa riippua siitä, mitä dataa se käsittelee. Tässä pointtina oli nimenomaan estää tietyntyyppiset (vanhemmanmalliset) sivukanavahyökkäykset niiden käskyjen osalta.

 

[Kaotik]

Mielenkiintoista kuulla mitä Linus kommentoi. Menee aika karvaiseksi softakehitys jos kolmen kuukauden välein joutuu uusimaan arkkitehtuurioptimoinnit.

Turvakriittiset ja mission critical sovellukset pitänee jatkossa toteuttaa jollain muulla arkkitehtuurilla. Tai ehkä Intel kaivaa IA64:sen naftaliinista

Siis ei tässä ole mitään isoja arkkitehtuuri päivityksiä tms tulossa kerran kolmeen kuukauteen vaan ylipäätään Intel aikoo ajoittaa ei kriittiset päivitykset ihan mihin tahansa tuohon sykliin satunnaisin väliajoin ilmestyvien sijaan. Intelillä on aika paljon muitakin päivityksiä kuin prossujen firmwaret

 

[jive]

Siis ei tässä ole mitään isoja arkkitehtuuri päivityksiä tms tulossa kerran kolmeen kuukauteen vaan ylipäätään Intel aikoo ajoittaa ei kriittiset päivitykset ihan mihin tahansa tuohon sykliin satunnaisin väliajoin ilmestyvien sijaan. Intelillä on aika paljon muitakin päivityksiä kuin prossujen firmwaret

Jokainen muutos joka rullataan UEFI:in IMEen tai ihan mihin tahansa alustakomponenttiin tarkoittaa askelta lähemmäksi sitä ettei avoimet alustat ja projektit pysy muutosten perässä, jolloin x86 arkkitehtuuri karkottaa loputkin avoimen softan kehittäjät.

Kommenttini oli alunperin siihen että olisi tietyillä sovellusalueilla paljon tarpeellisempaa että asiat tehtäisiin kerralla oikein eikä lähettyttäisi rajatta tilannetta, jossa suorittimistakin tulee tulostimia. Muutoksen ei tarvitse olla iso, jotta sen vaikutusten analysointiin kuluu tolkuttomasti aikaa ja rahaa.

 

[Kaotik]

Jokainen muutos joka rullataan UEFI:in IMEen tai ihan mihin tahansa alustakomponenttiin tarkoittaa askelta lähemmäksi sitä ettei avoimet alustat ja projektit pysy muutosten perässä, jolloin x86 arkkitehtuuri karkottaa loputkin avoimen softan kehittäjät.

Kommenttini oli alunperin siihen että olisi tietyillä sovellusalueilla paljon tarpeellisempaa että asiat tehtäisiin kerralla oikein eikä lähettyttäisi rajatta tilannetta, jossa suorittimistakin tulee tulostimia. Muutoksen ei tarvitse olla iso, jotta sen vaikutusten analysointiin kuluu tolkuttomasti aikaa ja rahaa.

Ehken ilmaissut itseäni hyvin, koitetaan uusiksi:
Ei Intel ole tekemässä mitään muuta muutosta kuin vaihtamassa julkaisusykliä päivityksille - samat päivitykset tulisivat joka tapauksessa kuten ne ovat tähänkin asti tulleet mutta jatkossa ne tulisivat säännöllisin väliajoin eikä satunnaisin väliajoin.