Új hozzászólás Aktív témák

• #8 Abu85 HÁZIGAZDA Bici #5

  Új Válasz 2012-06-26 12:04:23 #8

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Abu85

  HÁZIGAZDA

  válasz Bici #5 üzenetére

  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)-2

  At 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.

• #11 Abu85 HÁZIGAZDA sztanozs #10

  Új Válasz 2012-06-26 12:31:41 #11

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Abu85

  HÁZIGAZDA

  válasz sztanozs #10 üzenetére

  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.

• #14 Abu85 HÁZIGAZDA Orton96 #12

  Új Válasz 2012-06-26 12:43:44 #14

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Abu85

  HÁZIGAZDA

  válasz Orton96 #12 üzenetére

  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.

Új hozzászólás Aktív témák