Új hozzászólás Aktív témák
-
M107
addikt
Magyar It emberke, gratulálunk s köszönjük.
Hiába vannak még kiváló munkájukat magas szinten végző magyar szakemberek.
A fórumon, bármit leírhatsz, én csak az igazat írom le. :) Utálom ha hülyének néznek ! - Addikt - vissza az őstag címet :) )
-
PC-rev-RM
tag
Akkor kezdem.
6 éve. A konkurencia híres TLB-hibája előtt. Mégsem csináltak vele semmit. Látszik, ami látszik, na.Szerk: akkor ez most szoftverhiba, vagy hardverhiba, vagy mindkettő kell hozzá? Csak mint laikus érdeklődő kérdeném.
[ Szerkesztve ]
"My GPU maker took more money from me than yours did from you! My GPU maker is #1!"
-
félisten
Az említett szoftverek nem készültek fel arra, hogy az intel procikban máshogy műxik, mint az AMD proci. Eddig szoftveres hibának tűnik.
Viszont, azt nem tudom, hogy az intel procik miért működnek máshogy... véletlenül, vagy direkt, illetve, ha szándékosan, akkor volt-e dokumentálva, és ha igen, akkor miért nem készültek rá fel az OS fejlesztők...Eladó régi hardverek: https://hardverapro.hu/apro/sok_regi_kutyu/friss.html
-
PC-rev-RM
tag
Tudásomhoz képest rossz helyen vagyok, mert feltűnt, hogy semmit sem értek az egészből.
Elnézést kérek!Bici, (#8)Abu85: Köszönöm! Így már érthető idelent az egysejtű létformák szintjén is.
[ Szerkesztve ]
"My GPU maker took more money from me than yours did from you! My GPU maker is #1!"
-
Angel1981
veterán
Őőő - most akkor ez mit is jelent a hétköznapok szintjén?
-
Abu85
HÁZIGAZDA
Inkább is-is. Hardver és szoftver is. De javítható szoftveresen, szóval mindenképpen megoldható.
Nyilván teljesen feleslegesen törte magát az Intel az eltérő működésen, pont az egységesség lenne a lényeg. De mivel az AMD64 az AMD ISA-ja és a dokumentációt is ők írták rá, így világos, hogy nem az Intel megoldására építették a szoftvereket. A kérdés inkább az, hogy miért nem javították már ezt a gondot, hiszen évek óta létezik. Azért bőven volt idő a reagálásra.(#7) Angel1981: Ha írnak egy exploitot erre a hibára, akkor pillanatokon belül root jogot lehet szerezni a foltozatlan 64 bites OS-t futtató Intel procis gépeken.
Ez a US-CERT leírása a hiba kiaknázására. Azóta ez eltűnt, mert viszonylag egyszerűnek hangzik, és nem akarnak segíteni a támadóknak:
Attack steps (done by ring3 attacker)
- Map a frame at virtual address (1<<47)-4096
- Any method to set the target of sysret to a non-canonical address can potentially be used. This includes ptrace, sys_sigreturn, sigaction, execve, possibly others. The best solution is to add a check for the address being non-canonical close before executing sysret. Note if the syscall handler ends with iret, then even if iret throws #GP, rsp is not controlled by the attacker, and such the situation can be handled safely.
- Place a syscall instruction at address (1<<47)-2
- Place SOMETHING_MALICIOUS in general purpose registers
- Set rsp to AROUND_SOME_IMPORTANT_RING0_STRUCTURE
- Other scenarios are possible. Whenever the #GP handler runs with usermode rsp, or does not do swapgs correctly, code execution may be possible.
- Jump to syscall instruction at (1<<47)-2At the syscall handler entry, rcx will be set to (1<<47)-2+instruction_len(syscall) = 1<<47, which is non-canonical. Therefore, when the syscallhandler terminates with sysret, #GP will be raised. This fault will be handled without a stack switch (assuming #GP entry in IDT does not include a nonzero IST index), as the faulting instruction is in ring0. Only Intel CPUs are affected. On AMD CPUs, sysret completes the switch to ring3 before throwing #GP, so the stack switch occurs. Also, immediately before sysret, the syscall handler must restore rsp to the value set by ring3 (because syscall/sysret do not set rsp). Therefore, the #GP handler will execute with rsp chosen by the attacker, so when GPRs are pushed on the stack in the #GP handler prologue, SOMETHING_MALICIOUS will be placed at AROUND_SOME_IMPORTANT_RING0_STRUCTURE. This write-anything-anywhere primitive could be enough to hijack execution in ring0. Additionally, in many cases, gs base is not swapped in the #GP prologue (as the fault originates in ring0), which may make the exploitation quite reliable and stable - overwrite #PF IDT entry via stack push, trigger #PF by gs access, repair IDT (from IDT table of other cpu) in the shellcode, return to usermode.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
sztanozs
veterán
Ez a US-CERT leírása a hiba kiaknázására. Azóta ez eltűnt, mert viszonylag egyszerűnek hangzik, és nem akarnak segíteni a támadóknak:
És nyilván te is azért írtad le ide...JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
Abu85
HÁZIGAZDA
Már kismillió helyen fent van. Ami egyszer felkerül a netre az onnan nem távolítható el. Innentől kezdve mindegy, hogy még hova kerül fel. Aki ki akarja aknázni a hibát, már rég megszerezte ezeket az adatokat, sőt, szerintem már írt is rá exploitot. Szóval innentől a javítással kell törődni.
Az persze világos, hogy hivatalos helyen ne legyen fent a leírás, de ez egy fórum.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Orton96
aktív tag
Bocs de én még mindig nem értem...
Akk ez valami végzetes egész rendszert megbontó / felbontó hiba vagy csak vmi kis semmiség -
rt06
veterán
letezik publikus, mukodo exploit ehhez a hibahoz?
megneznem, mit szol hozza a hardened gentoo kernel-t hasznalo xen hypervisor-om (eddig, amiket probaltam (marmint nem ehhez a hibahoz, hanem egyebekhez), mindent fogott a hardening)[ Szerkesztve ]
Politikailag korrekt, valamint munkahely- és gyermekbarát aláírás, amiben egyáltalán nincsen p*na.
-
Abu85
HÁZIGAZDA
Annyi, hogy rendszergazda jogokhoz juthat a felhasználó. Az, hogy ez mennyire súlyos a felhasználó szándékától függ. Ha gonosz a user, akkor nagy szívás. Szóval igen. Eléggé súlyos.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
wetomi
aktív tag
Akkor most nem olyan jó buli az Intel tetemes részesedése a szerver piacon is?
-
bteebi
veterán
"Viszont, azt nem tudom, hogy az intel procik miért működnek máshogy... véletlenül, vagy direkt, illetve, ha szándékosan, akkor volt-e dokumentálva, és ha igen, akkor miért nem készültek rá fel az OS fejlesztők... "
A kérdés erősen jogos... Mondjuk én eléggé valószínűnek tartom, hogy ez (csak) az OS fejlesztők hibája. Az, hogy a Linux-ban már 6 éve kijavították ezt a hibát, azért elég kemény . Remek lehetőség a flémelésre .
#15: Attól függ. Azért szerintem - pontosabban a hírtől függetlenül remélem - a legtöbb szerveren valamilyen Linux-disztrib fut, bár pontos számokat nem tudok.
[ Szerkesztve ]
Cancel all my meetings. Someone is wrong on the Internet.
-
-
rt06
veterán
igen, ez benne van a hirben is, viszont nekem valami kiprobalhato formaban kellene, mert annyira nem ertek ehhez, hogy az itt-ott (akar itt, a topic-ban is) elofordulo leirasok alapjan magam irjak egyet
Politikailag korrekt, valamint munkahely- és gyermekbarát aláírás, amiben egyáltalán nincsen p*na.
-
F34R
nagyúr
vajon majd ez engem mennyiben érint a közeljövőben ?
intel + linux ...... -
#40553216
törölt tag
Csak nekem tűnt fel az ellentmondás?
Red Hat, SUSE Linux affected vs "Linux nem érintett". Mert jó, hogy a Red Hat nem rolling, na de ennyire azért talán mégis.
Vagy csak nem értek hozzá? (Utóbbi tény, számomra mégis erős ellentmondásnak tűnik. ) -
vanhalen
senior tag
3 dolog:
"Viszont, azt nem tudom, hogy az intel procik miért működnek máshogy..."
Az AMD64 "kiterjesztés" emlékeim szerint 2003-ban debütált. Az Intel ezt a technológiát vette át AMD-től, mert ugyan ők is dolgoztak egy ideje a saját megoldásukon, de ez tűnt mégis legkézenfekvőbbnek, főleg, hogy az MS. azonnal az SMD64 mellé állt, mivelhogy "visszafelé kompatibilis" volt meg stb. Ha jól értelmezem a cikk alapján, akkor az Intel nem "egy az egyben" építette bele az AMD féle 64 bites techet (gondolom technikailag nem is volt lehetséges) hanem az akkori Pentiumokra szabva módosításokkal, így lett belőle EMT64 (ha jól emlékszem)
"véletlenül, vagy direkt, illetve, ha szándékosan, akkor volt-e dokumentálva, és ha igen, akkor miért nem készültek rá fel az OS fejlesztők... "
És ott követték el szándékosan, vagy szándéktalanul ezt a hibát, ha jól értem. Ami elgondolkodtató, hogy 2003 óta nem javítottak egy ilyen brutál sebezhetőséget, ami ráadásul hardveres elsősorban.. És ha jól értem, az OS fejlesztők sem.. very very érdekes
"A Linux kernelben 6 éve szépen csendben javították a problémát…"
Ez very blyúfifúl, csakhát ugye 2012-őt írunk, ebből-6 év az ugye 2006 tehát akkor ők is "csak" 3 évet késtek (igaz, akkoriban a 64bites OS-ek programok még otthoni felhasználói szinten elég "egzotikusnak" számítottak (a Windows Cisztáig legalábbis mindenképp)
Felvetődik a kérdés, hogy a hőn szeretett és MS-t előszeretettel, lépten-nyomon, a legkisebb "kiderülő" sebezhetőségért is bőszen támadó szabad szoftveres-linuxos közösség, illetve a hibát javító fejlesztőik miért nem hívták fel látványosan a többi OS és program fejlesztőinek/kiadóinak a figyelmét, még a BSD-sekét sem, ahogy a userekét sem
Nem vagyok az összeesküvés elméletek híve, de azért ez enyhén szólva is felvet pár kérdést.
Ha esetleg mégis szóltak MS-nek, csak lesz@**ták, akkor ezúton is piejesudomine [link] a linuxosok felé
[ Szerkesztve ]
-
#40553216
törölt tag