Új hozzászólás Aktív témák
-
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.
-
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 ![;]](//cdn.rios.hu/dl/s/v1.gif)
.#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.
"
. Remek lehetőség a flémelésre ![;]](http://cdn.rios.hu/dl/s/v1.gif)
.Új hozzászólás Aktív témák
it Egy magyar szakember az elsők között foglalkozott a hibával.
