Az AMD CPU-kat érintő Sinkclose biztonsági sebezhetőség engem személy szerint ...

AMD

(* Megjegyzés az AMD figyelmeztetőjéhez: The researchers who discovered the flaw in AMD's chips contend that the vulnerability impacts all AMD chips extending back to 2006. However, AMD has not listed Ryzen and Threadripper 1000 and 2000 and other previously released products as impacted by the vulnerability. We are following up for further details regarding the disparity.)

Érint téged?

AZ nem érintett, ez meg igen. Pont a NAS_ban van ilyen. Mondjuk szerencse, hogy fizikailag is hozzá kell tudni férni a géphez, hogy kihasználják. Meg windows driver lesz a linuxos NAS-hoz :D

hup.hu##article[data-comment-user-id="16401"]

hup.hu##article[data-comment-user-id="4199"]

Probléma:

10 hónapja ismert a hiba, az AMD azóta ült a javításán. Ki tudja nem volt-e ismert mások előtt már korábban is. Ha kihasználták, akkor a támadó olyan bootkit malware-t plántálhatott a gépedre, ami az OS és víruskeresők számára detektálhatatlan:

They alerted AMD to the flaw in October of last year, they say, but have waited nearly 10 months to give AMD more time to prepare a fix.

[...]

Nissim and Okupski say they agreed with AMD not to publish any proof-of-concept code for their Sinkclose exploit for several months to come, in order to provide more time for the problem to be fixed. But they argue that, despite any attempt by AMD or others to downplay Sinkclose as too difficult to exploit, it shouldn't prevent users from patching as soon as possible. Sophisticated hackers may already have discovered their technique—or may figure out how to after Nissim and Okupski present their findings at Defcon.

trey @ gépház

( nehai v | 2024. 08. 13., k – 11:16 )

Van ilyen CPU-m, de nem érint. Ilyenkor mit jelöljek be?

„Az összeomlás elkerülhetetlen, a katasztrófa valószínű, a kihalás lehetséges.” (Jem Bendell)

Tehát, akkor "érint". Akkor is érint egyébként, ha van érintett CPU-t, de arra telepítettél AMD által kiadott mitigáló microcode frissítést. Csak akkor a hibára tettél egy sebtapaszt. Ami vagy működik vagy nem. Ez meg a babzsákfejlesztő aznapi produktumától függ. Jó napja volt vagy sem. Volt teszt, vagy sem. Stb.

trey @ gépház

( Raynes v | 2024. 08. 13., k – 11:26 )

Szerkesztve: 2024. 08. 13., k – 12:23

Érint sajnos, itthon több gépet is. Most már biztosan tudom róla, hogy ezek a sérülékenységek a procigyártótól vannak eredeztetve, hogy elavultassák a korábbi procijaikat, hogy menjen az ember újat venni.

Ha figyelmesen megnézitek, a legújabb 9000-es sorozat pont nem érintett, az összes többi Zen-alapú termék igen. Szerencse a tököm, ez szándékos. Nem tudom ezeket már komolyan venni. hajbazernek volt igaza ebben is, ignorálni kell ezeket, mást nem tud az ember tenni. Azt mondanám is az AMD-nek, hogy nem rohanok minden ilyen trükk után új procit venni, mert 1) tisztességtelen módszer a részükről, 2) nem ’rom a pénzt.

Gondolom lesz rá valami folt vagy mikrokód, vagy Linux kernel szintjén, ami természetesen lassítani fog, megint azért, hogy újat vetessenek.

Egy gépem van, amiben az ősi i5-2520M nincs érintve, de az meg számos más Intel sec bugot tartalmaz, szóval nincs előrébb semmivel.

Szerk.: az AMD prociknak az a szerencséjük, főleg a Zen-től kezdődően, hogy van bőven bennük erőtartalék, ha a foltokkal lassítják is, még akkor se válnak használhatatlanná.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Amit betettél második linknek, hogy az érintett procik listája, ott pörgettem végig, kézzel és kereséssel is, és ott nem szerepel a most megjelent 9000-es széria.

Egyébként ez az érintett vagyok szöveg se áll meg egészen, mert a procijaimat érinti, de pl. a kódjaimat nem, mert azok mind opensource-ok, és nem a netről random weboldalakról származó, zárt forráskódos szutykok, amikben ki tudja mi van.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Ha figyelmesen megnézitek, a legújabb 9000-es sorozat pont nem érintett, az összes többi Zen-alapú termék igen. Szerencse a tököm, ez szándékos. Nem tudom ezeket már komolyan venni. hajbazernek volt igaza ebben is, ignorálni kell ezeket, mást nem tud az ember tenni. Azt mondanám is az AMD-nek, hogy nem rohanok minden ilyen trükk után új procit venni, mert 1) tisztességtelen módszer a részükről, 2) nem ’rom a pénzt.

Az AMD-t 2023 Októberében figyelmeztették a hibára, így az nem meglepő, hogy a Ryzen 9 nem érintett, hiszen azt már bőven utána addták ki.
Inkább az a meglepő, hogy a Ryzen 8000 érintett, mert az is most lett elérhető, április körül emlékeim szerint. 

Gondolom lesz rá valami folt vagy mikrokód, vagy Linux kernel szintjén, ami természetesen lassítani fog, megint azért, hogy újat vetessenek.

Van rá mikrokód javítás, de leginkább csak a 2020 utáni modellekre (és a Embedded procikra készült javítás csak októberre várható). Tesztelők alapján a teljesítményre elenyésző hatással van, de persze kérdés, hogy van-e BIOS frissítés az adott géphez, vagy ha nincs, akkor hogyan kerül fel a friss mikrokód a procira... 

Nagy Péter

Van rá mikrokód javítás, de leginkább csak a 2020 utáni modellekre (és a Embedded procikra készült javítás csak októberre várható). Tesztelők alapján a teljesítményre elenyésző hatással van, de persze kérdés, hogy van-e BIOS frissítés az adott géphez, vagy ha nincs, akkor hogyan kerül fel a friss mikrokód a procira... 

Mondjuk rátölti a kernel vagy a bootloader. 

https://wiki.archlinux.org/title/Microcode

Mondjuk igen, pont a hiba jellege miatt rátölthet egy random windows EXE is, amit valaki betesz az indítópultba :-D
Viszont nekem a Windowsom nem hogy ezt a mikrokódot, de még az ezt megelőzőt sem töli be rá, és nem tudom, hogy valaha be fogja-e tölteni.

Nagy Péter

Azt hiszem, hogy a Windows is tud egy jó ideje mikrokód-frissítést betölteni, az egy másik kérdés, hogy nem transzparens a működése, meg zárt kód, nincs rendesen logolva mit csinál, így csak hihetsz benne, hogy betölti a megfelelőt.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Lehet, hogy tudja, sőt, lehet, hogy a betöltés eredményét látom is, de ha lekérdezem a mikrokód verzióját, akkor az nem az aktuális, de még csak nem is az azt megelőző. Az AMD szerint azóta már adtak ki újabbat, még a mostani javítás előtt is, ami még nincs rajta. Azt nem tudom, hogy a BIOS mit tölt rá indításkor, meg azt sem, hogy mi lenne rajta a BIOS nélkül (valószínűleg az elsők egyike, mert a gépet abban a hónapban vettem, amikor megjelent ez a CPU sorozat), szóval lehet, hogy ez, amit látok, már egy Windowsos frissítés eredménye, és csak egyszerűen az ezt követő mikrokódokat nem tartották fontosnak a Microsoftnál, így azt kihagyták.

De a megnyugtató az lenne, ha BIOS szinten kapnék egyet a javított verzióból, és akkor soha többé nem kellene az oprendszereket ellenőrizni, hogy most milyen frissítés van fent, és mit tölt be éppen.

Nagy Péter

Megvan a BIOS fájl? Mert akkor belenézel Ryzen SMU checker-rel, és megmondja mit lát benne:

https://www.hardwareluxx.de/community/threads/ultimative-am4-uefi-bios-…

https://filehorst.de/d/eGvdbFup

Azt meg h. mit töltött be a windows mikrokód update-t, megmondja bármelyik népszerűbb rendszerdiagnosztikai program (hwinfo64, aida64 és társai). Ha meg nem akarsz külső programot hozzá, a registry-ből is kolvasható:

 

For first core, look at:

HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\CentralProcessor\0

For example:

"Update Revision" = 0xba - current latest microcode (from mcupdate_*.dll)

"Previous Update Revision" = 0xb3 - default original microcode version (from BIOS)

"Identifier" - Intel64 Family 6 Model 15 Stepping 11

"Platform Specific Field 1" - 0x80

Microcode is taken from c:\Windows\System32\mcupdate_GenuineIntel.dll (or mcupdate_AuthenticAMD.dll) using "Identifier" and "Platform Specific Field 1". For Intel, you can search for "DataVersion" UTF-16 string from mcupdate_GenuineIntel.dll to see all included ucode versions. For cpu id from example: "6fb-80,ba" (format is FamilyModelStepping-PF,ucRevision in hex).

( elod v | 2024. 08. 13., k – 12:01 )

Nem érint mert nincs még használatban Ryzen-em itthon. Munkában érinthet, van jó pár laptop, de elég kicsi a valószínűsége annak, hogy ezt ki is fogják tudni használni.

AMD részéről nagyon trehány, hogy a 3000-es szériát kihagyják a patch-elésből.

Azt csak hiszed, hogy otthon nem érint. Ez a bug nem, de az Intel procidban lesz még jó pár másik, amit majd a jövőben találnak meg. Ha más nem, a Meltdown-nak is vannak új verziói, alvariánsai pedig azt már több körben is foltozták.

Csak az nem érintett, aki barlangban él, és kovakővel pattintgatja a tüzet.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Pont ez az, hogy engem sem érdekel, ezzel kezdtem. Ezek a bugok annyira mindennaposak már, meg mindenkit érintenek, hogy felesleges vele foglalkozni. Az ember a procit úgyse cseréli, mint a gatyát. Ha egy pendrive lenne, az még oké, de a procit a legtöbb ember nem cseréli, használja, amíg lehet. RAM-ot, SSD-t vesznek, bővítenek, de már a GPU upgrade se gyakori a CPU lecserélése egyenesen ritkaságszámba megy, max. csak hobbisták meg egyes extrém foglalkozásúak cserélgetik (akik rendereléssel, végeselem-számítással, stb. foglalkoznak).

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Mondjuk az AMD oldalon inkább cserélnek CPU-t, mert az AM4 foglalat pl. elég sokáig kitartott, és azért ott elég nagy előrelépések voltak sebesség szintjén.
Én olyan céget ismerek, ahol nagyon régi AM4-es CPU-kat cseréltek viszonylag újakra, mert így Win11 kompatibilisek lettek a gépek, viszonylag olcsón, meg sokat gyorsultak is. (Ryzen 3 2200G-t Ryzen 5 5600G-re)

Nagy Péter

( Friczy v | 2024. 08. 13., k – 13:12 )

Utolsó AMD processzorom valami AMD64 sorozat volt, azt cseréltem le annak idején egy Sandy Bridge-re (az se most volt), azóta nincs AMD itthon. Intelből is csak elég régiek :)

( kikadff v | 2024. 08. 13., k – 13:16 )

Szerkesztve: 2024. 08. 13., k – 13:44

Jók ezek a CPU sérülékenység szavazások. Eddig kiderült belőle, hogy a hup népének ~37 %-a AMD-t használ, az Intel használók ~96 %-ának 13. gennél régebbi procija van. Még valami szaftos Apple CPU sérülékenység volna jó.

A betegséged neve: irtózás az egyenes válaszadásról

Az emberek nem szeretnek egyértelmű válaszokat adni, mert azzal felelősség jár. Szeretnek mismásolni ... Sajna itt is lehet egyértelmű választ adni ... 🤷‍♂️

Itt is látszik ez (meg a fanboyság) a szavazatok számán :D

"Jajj, hát ezt meg észre se vettem!!"

Pszichológiai okai vannak ennek.

trey @ gépház

( zrubi v | 2024. 08. 13., k – 13:17 )

Érintett a gamer gépem...

De ha egy desktopon a támadónak már eleve ring0 hozzáférése van, az ugye már régen rossz...

Persze - ahogy ez is jól mutatja - lehet még fokozni ;)

 

De emiatt parázni inkább az érintett szerver üzemeltetőknek/tulajdonosoknak kell.

 

szerintem.

zrubi.hu

Az a szomorú, hogy nem hogy, 4, hanem van, ahol 10+ éves szerverekkel tolják az ipart keményen. Mondjam, vagy mutassam, hogy azokhoz mennyi update lesz? Ez azt jelenti, hogy ha egy ilyen szervert felbasznak root-ra, akkor az utána nyugodtan tekinthető kukának.

trey @ gépház

a gyártók hozzáállása baromi egyszerű:

minden modell X év után 'out of support' státuszba kerül = onnantól nincs többé hozzá semmilyen javítás, patch suppot, még alkatrész sem.

Az X persze változó, de általában 5-6 év.

 

De aki ilyen sezerveren futtatja a szarait, az tisztában is kell legye ezzel, mert általában már eleve ezért volt occó az a (használ) vas :)

zrubi.hu

ha a gyartoi support alatt jon ki uj agesa es azt a gyarto elerhetove teszi a szerverehez, akkor mar csak az a kerdes, hogy a mostani <=5-6 eves szerverekben levo cpuhoz az amd ad-e ki uj agesat. (https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7014…) ha igen, akkor az uzemelteto felteszi. ha nem, akkor lehet venni intel szervert, a piac dont. az ennel regebbi szervereknel pedig kockazatelemzes alapjan majd eldontik hogy vallaljak-e a rizikot, vagy valamilyen modon csokkentik.

az informatika egy kozos kockazatvallas. a gyarto kockaztat, hogy valaki megveszi-e a termeket, a felhasznalo kockaztat, hogy amit vesz az hasznalhato.

neked aztan fura humorod van...

ha egyszer igy hivjak. :) ha jol tudom az agesat az amd adja ki es a szerver gyartok meg beleteszik a bios frissitesbe, vagy mas modon toltik be, ezt irja rola:

Mitigation Option 1: Platform Initialization (PI)(Requires FW flash)

Mitigation Option 2: μcode (Hot loadable)

a link szerint a kovetkezo data center platformok kaptak agesa javitast, de hogy melyik brand szerverben van ilyen, azt nem tudom, en sem hasznalok ilyet:

1st Gen AMD EPYC™ Processors formerly codenamed "Naples"
2nd Gen AMD EPYC™ Processors formerly codenamed "Rome"
3rd Gen AMD EPYC™ Processors formerly codenamed “Milan" and “Milan-X”
4th Gen AMD EPYC™ Processors formerly codenamed "Genoa", “Genoa-X”, “Bergamo”, and “Siena”

neked aztan fura humorod van...

:) mokas a stilusod.

https://shop.szerver.hu/termek/dell-poweredge-r6615-1u-rack-szerver-10x…

kineztem egyet, 5 ev garanciat ir.

ha ebben benne van az is, hogy a gyarto az o reszerol beszallitonak szamito amd altal szallitott agesa javitasokat is adja ezido alatt a vegfelhasznalonak, akkor minimum 5 eves epyc cpuhoz meg kell lennie agesa javitasnak, de legyen 6 ev.

https://en.wikichip.org/wiki/amd/epyc

eszerint a zen 1 epyc 2017 juniusban jott ki, 7 eve.

https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7014…

eszerint az 1.0.0.M agesa elerheto ra, ami foltozza a hibat.

neked aztan fura humorod van...

en azt, hogy intel eseten egy gyarto vajon jobban megcsinalja-e :)

az agesa-t beledobni a firmware-be kb. a kontrolcekontrolve kategoria es minden amd chipset/CPU eseten ugyanaz a kod. ezert van, hogy meg konzumer vason is kapsz ilyet 5-6 ev tavlatabol:
 

Version 0318

8.04 MB

2018/06/22

First release BIOS
============
Version 4604

10.8 MB

2024/04/08

Update AGESA version to ComboV2PI 1.2.0.Ca.
Fix AMD processor vulnerabilities security

remeljuk az "opencompute farvizen" ez is megvalosul: https://www.gamingonlinux.com/2023/06/amd-reveals-initial-open-source-o… :)

mivel a szerver gyarto szempontjabol az amd es intel beszallitonak minosul, en egy ropke tesztelest meg beiktatnek, hogy utolag ne kelljen egymasra mutogatni, hogy kinek a hibajabol nem mukodik jol a szerver bios frissites utan, de igen, lehet kulonbseg attol fuggoen is, hogy melyik beszallito cpuja van a szerverben, akar beszallitoi szerzodesben kikotve, amire nem latunk ra.

neked aztan fura humorod van...

az agesa "as is" kerul be a firmware-be. ezert mondtam, hogy az a resz nem gayrtofuggo. tesztelesrol szo sem esett, egyertelmu, hogy illik tesztelni a firmware-t mielott kiadjak. (meg alairni meg skinezni meg...)
en pl. kertem/kaptam mar gyartotol spec. nekem keszitett bios-t, amiben beallithato a PCI-E LTR L0&L1. amd-nel ez nem olyan nagy mutatvany, pont az miatt, hogy az agesa-hoz ilyenkor nem kell nyulni.

Viszont a fasz gyártók mondhatják, h. lófaszt tesszük bele az agesa-t kontrolc-kontrolv a régebbi alaplapok bios-ba (TBD mi számít éppen réginek; van 1 olyan elmélet h. minden amit már eladtak a vevőnek), mert azzal is munkánk van, és az új alaplapokat is el kell adni valahogy.

szerencsere amd jellemzoen nem csak egy termeke megjeleneseig supportal egy chipsetet. es ha a kedves lapgyarto nem akar lemaradni/kimaradni, RMA-val szopni (hidd el, az nagyobb bukta, mint a kontrolcvekontrolve :)), ad a laphoz frissitest is.
random kinai gyarto random legolcsobb fos (brutto 20k) lapjanak random biosai :) ha nem akarja tesztelgetni, max kiadja, mint "beta", nem vallal ra semmit, kiprobalod, mukodik, orulsz alapon.

tehat a mellekelt abra nem ezt mutatja.

vannak otleteim, de nem feltetlenul allnak osszhangban a gyartok rovidtavu gazdasagi erdekeivel:

- kevesebb elektronikai hulladek keletkezzen

- az ugyfelek a legkozelebbi eszkozbeszerzeskor is az o termekuket valasszak

ettol meg igazad van, nem lesz ilyen :)

foleg ha mukodik a Mitigation Option 2.

neked aztan fura humorod van...

minden gyarto amd/epyc szerverben hasznalnal epyc cpu-t es minden epyc cpu-nal agesat.

hogy pontosan mi az adott gyartonal a szerver fantazianeve vagy szama, azt nem tudom, de feltetelezem a weboldalukon lehet ra szurni.

neked aztan fura humorod van...

( trey | 2024. 08. 13., k – 20:25 )

lol @ 240 szavazat 🤣🤣

trey @ gépház

( kleinie | 2024. 08. 13., k – 22:10 )

Már nem érint és még nem érint!

Anno akkor építettem gépet amikor drága volt minden. Így egy Ryzen 5 5700G lett, mert a videókártya árak is az egekben voltak. Mikor lentebb mentek az árak vettem egy RX6800XT videókártyát. Azóta eladtam az 5700G-t és a memóriámat. Ezeket most fogja váltani egy Ryzen 5950X és 64 GB memória.

( asch v | 2024. 08. 14., sze – 11:43 )

Van egy Ryzenem, ami SSH-n elérhető netről. De ha jól értem onnan nem támadható, csak helyi futtatással, ugye? .... Ugye? UGYE? Remélem.

Várjunk csak! A ring -2 az nem az, amin keresztül az NSA backdoor működik? Az a szint, ahová én a processzor tulajdonosa se vagyok beengedve? És ring 0-ból lett elérhető, ami az én szintem?

Mert ha így van, akkor ez a bug valójában áldás, mert végre teljesen tulajdonba vehetem a processzoromat általa, akár ki is zárhatom az NSA-t végre a saját gépemből! Van leírás rá, hogy _ne telepítsem_ az új mikrokódot és hogy bemenjek ring -2-be és kipucoljam az NSA-t végre onnan?

De azt jól tudom, hogy ez a ring -2 az a rész, amire nekem a processzor tulajdonosaként sincsen jogom betekinteni, és titkosított sehol el nem érhető forráskódú szoftvert futtat? Amiben az urban legendek szerint az NSA backdoor is lakik? Ez egy remek lehetőség volna, hogy valami white hat hacker megtörje a sajátját és visszafejtse, hogy mik vannak ott ebben a ringben. Érdekelne, de nyilván annyira nem, hogy beletegyem a szükséges 1-2-3 évet, amit óvatosan becsülnék erre a feladatra. Kellene közösségi finanszírozást indítani a projektre.

A system management mode (SMM) egy borzasztó régi bedohosodott pókhálós sötét sarka az x86-nak. Én első emlékeim valamikor Pentium MMX korszakból vannak, ahol az alaplapon már nevén volt nevezve (persze elmagyarázva nem volt, hogy mi az), de wikipedia szerint 386-osban lett bevezetve.

Általánosságban ha a BIOS vagy UEFI firmware nincs full titkosítva, akkor meg lehet találni benne azt a kódot ami SMM-ben fut. Mivel az SMM borzasztó régi, régebben pedig abszolút nem volt divat titkosítani (de még aláírni sem) a BIOS-t, ezért régebbi rendszereken nem titok mi volt benne.

Értelemszerűen, ha coreboot BIOS-t használsz (az az 1-2 hardver, amin támogatott...), akkor még a forráskódja is nyílt.

Az nem csak urban legend, hogy az NSA csinált olyan backdoort ami valamilyen szinten használt System Management Mode-ot, Snowden által leakelt doksikban benne volt. Alapvetően ez célzott supply chain attack része volt, az akkori doksik alapján sem úgy kellett érteni a dolgot, hogy mindenkinél alapból ott a backdoor.

UPDATE: amúgy corebootban böngészgetve lehet izgi dolgokat találni: https://github.com/coreboot/coreboot/commit/33aa2901f85b8a37b0984e378b405465e17f2ce6 voltak itt korábban (Zen előtt) is érdekes issue-k, S3 powersave állapotból visszatéréshez például az SMM locknak kikapcsolt állapotban kellett maradnia. Ha én lettem volna a security researcherek helyében, tuti hogy a power state váltások környékén keresgélnék valami olyan corner-case-t, vagy versenyhelyzetet, ahol az SMM lock "kikapcsolva felejtődik" legalább átmenetileg. Tényleg nagyon várom, hogy kijöjjön a rendes leírás.

Régóta vágyok én, az androidok mezonkincsére már!

Az Intel ME-t szokták Ring -3-nak csúfolni (technikailag nem az, mert nem a fő CPU privilégiumszintje, hanem egy teljesen független beágyazott processzoron fut).

Na arra viszont igazak, amiket írtál fentebb. Az mindig is zárt, full titkosított firmware image-et használt. Például azt, hogy belül Minix-et futtat, csak sebezhetőségek kihasználásával sikerült visszafejteni. Erre valóban csak konteó (nem volt megerősítve), hogy az NSA megrendelésére került bele backdoor. Bár tekintve, hogy milyen balfék biztonsági hibái is voltak (pl Zero touch provisioning-et érdemes elolvasni) nem kell különösebben konteósnak sem lenni, hogy valakinek az jusson eszébe, hogy némelyik szándékos backdoor volt.

Régóta vágyok én, az androidok mezonkincsére már!

( dorsy v | 2024. 08. 14., sze – 11:45 )

Ring 0 is accessible to the kernel, which is a central part of most operating systems and can access everything.

CVE

CVSS

CVE Description

CVE-2023-31315

7.5 (High) AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H

Improper validation in a model specific register (MSR) could allow a malicious program with ring0 access to modify SMM configuration while SMI lock is enabled, potentially leading to arbitrary code execution.

vihar a biliben, akinek ring0 access-e van, az egyebkent is azt csinal amit akar :)

 ez van a cve-ben, meselj meg!
a linkedbol idezve:

Attackers need to access the system kernel to exploit the Sinkclose vulnerability, so the system would have to already be compromised. The hack itself is a sophisticated vector that is usually only used by state-sponsored hackers, so most casual users should take that into account.

vótmá'

But they argue that, despite any attempt by AMD or others to downplay Sinkclose as too difficult to exploit, it shouldn't prevent users from patching as soon as possible. Sophisticated hackers may already have discovered their technique—or may figure out how to after Nissim and Okupski present their findings at Defcon.

trey @ gépház

ha elotte rootig tortek a gepedet es atjutottak az osszes selinux/apparmoron is, akkor mar nem k*ara mindegy? :)

Nem teljesen. Ugyanis eddig egy újratelepítés kb. megoldotta a problémát. Most meg sok sikert ahhoz, hogy plántáltak-e OS újratelepítést túlélő malware-t a gépedbe. Ja, nem. Itt nem az otthoni egy szem szarodról van szó. Szerverek százezrei, milliói lehetnek érintettek. A részletek meg homályosak. Az AMD advisory-ja meg hiányos, a javítási hajlandósága meg elégtelen.

trey @ gépház

aki rootig tori a geped, semmi nem akadalyozza meg, h pl egy laza ipmitool-lal olyan usert csinaljon maganak, a managementhez amilyet akar. vagy efibootmgr-rel olyan sajat vackot bootoljon, amit nem szegyell. (hint: az a bejegyzes sem vesz el egy OS wipe-tol)
az nem gaz, ugye? :)

szoval, akkor nem kell ring0 hozza? :) mutimeg!

ha rootta tortek a geped, ez lesz a huszadik bajod :) hint: nem azt mondogatom, h nem baj, hanem, hogy mar reg k*ara mindegy... ezzel az erovel az ipmitool meg az efibootmgr a sechole :) janem.
szoval kell hozza ring0 vagy sem?
igen/nem megy-e meg? :)

Ezt majd a főnöködnek, amikor meg kell csinálnod a szakvéleményt arra nézve, hogy mekkora a rizikó. Majd megválaszolja neked.

Bár, meglepődnék, ha ott is így adnád elő, amikor a felfedezők éppen az ilyen magatartás kerülésére hívták fel a figyelmet :D

trey @ gépház

milyen magatartas? kapasbol bedobtam neked ket peldat miert nem csak az os-t ellenorizzuk ha rootta volt torve a gep... pedig azok nem is sechole-nak szamitanak, csak standard toolok. ez meg lesz a huszadrangu kerdes a tobbi kozott. :)
te meg terelsz igen/nem helyett.
na ez magatartas! :)
szoval kell hozza ring0 vagy sem?
igen/nem megy-e meg? :)

Nézd, itt kétfajta magatartás van:

  1. az enyém, amelyik elhiszi a felfedezők által állítottakat és betartja* az ajánlásukat
  2. meg a tiéd, amelyik megpróbálja a problémát bagatellizálni (erre a felfedezők fel is hívták a figyelmet, hogy ez kerülendő)

Nem érdekelnek a kérdéseid, ezeket mondtam, hogy hol tedd fel. Az információk hiányosak, az exploitokat az AMD könyörgésére nem hozták nyilvánosságra. Azok a részletek állnak rendelkezésre, amit a felfedezők mondtak (1. pont).

(* illetve tartaná, mert hála istennek egy darab AMD processzoros rendszer nem sok, annyihoz sincs közöm :D :D :D)

trey @ gépház

nem bagatellizaltam lofasztse. van a te hozzaallasod, miszerint le van szarva ha rootta torik a rendszert es azon aggodsz, hogy ezek utan meg a biost/efi-t/bootloadert le tudjak-e cserelni, meg van az enyem, aki abbol indul ki, hogy amit rootta tortek, azt tuzzel-vassal kell 0-ra wipeolni minden szinten is.
Azok a részletek állnak rendelkezésre, amit a felfedezők mondtak > tehat kell ring0 full root kernel access?
kurvara nem egy liga egy remote CVE meg egy local ring0 CVE. ennyi.

a hazudozast te kezdted. hint: bagetellizalas. fogadjisten! :) szar amikor visszanyal? :)

hint: nem azt mondogatom, h nem baj, hanem, hogy mar reg k*ara mindegy... ezzel az erovel az ipmitool meg az efibootmgr a sechole :) janem.

ha fullba tolod az ovodat, ne vard, hogy felnottkent legy kezelve! :)

nem vagyok. ar/teljesitmeny-szolgaltatas alapjan valasztok hardvert, adott use case-re. ha intel a jobb, akkor azt. veled ellentetben, aki default szarozza a gyarto termekeit, annak tulajdonsagait mellozve :) azt sem tudod mi az agesa... xD

szerencsere nem mindenki olyan hulye, mint te es kepzeli azt, hogy csakaZinteeltudcepejutgyaaartaniiii!
"In servers, AMD accounted for 23.1 percent of market sales in Q4, up from 17.6 percent a year earlier, although server CPU shipments were up across the board."
"nem élek AMD szarokkal" by Trey. szivesen, mr. fanboy ur.

Én megpróbálom elmondani, kötekedésmentesen.

Disclaimer: nem olvastam a rendes cikket a sebezhetőségről, mert szerintem még nincs is publikálva. Tehát megvan az elvi lehetőség, hogy valami nagyon váratlan dolog van benne, de szerintem nem lesz.

A CVE alapján a system management interrupt (SMI) lock-ot lehet megkerülni. Az SMI egy egyszerű interrupt kezelő rutin, amit a rendszer firmware (BIOS, UEFI) állít be, majd immutable-é teszi, így az OS kernel már nem tud változtatni rajta. Az SMI futási kontextusának egy nagyon szűk kis memóriája van (vagyis nem fér hozzá a kernel teljes memóriájához). Viszont van néhány különleges jogosultsága, pl system management bus-on szabadon végezhet műveleteket.

Ez azért cinkes, mert ha a támadó hozzáfér, akkor pl a firmware eeprom-ba irhat. Vagyis, ha az SMI lock nem hatásos, akkor ez szolgálhat egy lehetséges útvonalként UEFI rootkit-ek telepítésére. Hogy a manpság mindennek alfája és omegája secureboot-ot (ami elvileg védene a megfelelően alá nem írt payloadoktól az eepromban is) ez a hiba hogy teszi megkerülhetővé, ahhoz meg kell várni a teljes cikket.

Az UEFI rootkit egy külön szakág, ami eddig is létezett. A cikkekben idézett horrorisztikus következmények már az UEFI rootkitekkel elvileg megvalósítható károkozásokról szólnak. Ennek a hibának felhasználása nélkül is voltak módszerek, amivel a rootkitek UEFI-be települni tudtak. Nyilván ezeket a lyukakat a vendorok - ha lassan és foghíjasan is - de csukdossák befele. Most lényegében annyi történt, találtak egy yet-another újabb lyukat.

Régóta vágyok én, az androidok mezonkincsére már!

jo de kihozta a szavazas hogy ez minden amds erint!! raadasul ha telepul a rootkit akkor mindenki IS ki-be jarkal a gepeden. bezzeg az intel csak megfozi a procit, de az meg amugy a kutyat se erinti. meg kulonben is az intel nem hibas, csak a csunya tuningolok kenyszeritettek oket hogy odakozmalo cput csinaljanak!! :DD

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

( kleinie | 2024. 08. 14., sze – 17:57 )

Hajrá RISC-V! Lassan beérik. Bár mire hétköznapi felhasználásra alkalmas lesz, addigra az implementációkat úgy elcseszik, hogy az sem lesz jobb.

Már megtörtént: https://www.phoronix.com/news/GhostWrite-Vulnerability-RISC-V :)

Pont ráillik amit írtál. Egy konkrét implementációban egy nem szabványos extension-t sikerült maximálisan elcsesznie egy kínai gyártónak.

Régóta vágyok én, az androidok mezonkincsére már!

Egy konkrét implementációban egy nem szabványos extension-t sikerült maximálisan elcsesznie egy kínai gyártónak.

Ha jol ertem, pont nem a nem szabvanyos hanem a meg ratifikalas alatt allo egyik extension-t (V) csesztek el, de azt tenyleg elegge combosan :] Lasd doksi, Sec. V. B. a) pont (8. oldal alja). De lehet hogy valamit felreertek. 

Mindenesetre ez valojaban jo kerdes hogy egy nem ratifikalt kiterjesztest milyen cimszo alatt implementalnak - dehat ugye kockazat nelkul nincs vereseg. Mondjuk amig az IMAC-on kivuli kiterjesztesek a `misa`-n keresztul hardveresen tilthatoak akkor talan nincs nagy baj. Sot, talan az M meg A is tilthato lehet mert M-mode trap-ekkel azok is emulalhatoak vegszukseg eseten egy jol iranyzott SBI frissitessel.