5 ms·

Did not get root on my test box (OpenSuSE 13.2 64bit) with kernel 3.16.6-2-default uid=10000, euid=10000 Increfing... finished increfing forking... f

Did not get root on my test box (OpenSuSE 13.2 64bit) with kernel 3.16.6-2-default uid=10000, euid=10000 Increfing... finished increfing forking... finished forking caling revoke... uid=10000, euid=10000 sh-4.2$

baghira 11y ago
If you have SMAP, i.e. an Haswell or newer Intel CPU, you should not be vulnerable, so that could be an explanation.
- javanix 11y ago
  Is SMAP required for mitigation, or is SMEP enough? IIUC SMEP is on Sandy Bridge processors too.
  - baghira 11y ago
    According the lwn comments it should be sufficient (and the post by perception-point suggests that it would at least make things more difficult), but I haven't the hardware to test for myself.
    - cmurf 11y ago
      I have Sandy Bridge, i7-2820QM. The exploit code has been running for nearly an hour, still "Increfing..." EDIT: [chris@f23m cve20160728]$ ./cve_2016_0728 PP_KEY uid=1000, euid=1000 Increfing... finished increfing forking... finished forking caling revoke... uid=1000, euid=1000 sh-4.3$
  - benmmurphy 11y ago
    SMEP would stop this particular exploit because it returns into usermode but SMEP is trivial to bypass on linux if there is no KASLR or other mitigation (apparently there are compiler plugins that remove popular stack pivot gadgets).
thefreeman 11y ago
Did you update the addresses of the kernel functions? #define COMMIT_CREDS_ADDR (0xffffffff81094250) #define PREPARE_KERNEL_CREDS_ADDR (0xffffffff81094550)
- vnik 11y ago
  even if you don't update the addresses you would at least get an oops if the exploit is working. I've explained the problem with rcu calls in my post https://cyseclabs.com/page?n=02012016 https://cyseclabs.com/page?n=02012016 reply but did not describe the technique for ordering these calls. The way they do things in the poc, you'd be lucky if it succeeds once out of 100.
  - deleted 11y ago
    [deleted]

baghira 11y ago

If you have SMAP, i.e. an Haswell or newer Intel CPU, you should not be vulnerable, so that could be an explanation.

javanix 11y ago
Is SMAP required for mitigation, or is SMEP enough? IIUC SMEP is on Sandy Bridge processors too.
- baghira 11y ago
  According the lwn comments it should be sufficient (and the post by perception-point suggests that it would at least make things more difficult), but I haven't the hardware to test for myself.
  - cmurf 11y ago
    I have Sandy Bridge, i7-2820QM. The exploit code has been running for nearly an hour, still "Increfing..." EDIT: [chris@f23m cve20160728]$ ./cve_2016_0728 PP_KEY uid=1000, euid=1000 Increfing... finished increfing forking... finished forking caling revoke... uid=1000, euid=1000 sh-4.3$
- benmmurphy 11y ago
  SMEP would stop this particular exploit because it returns into usermode but SMEP is trivial to bypass on linux if there is no KASLR or other mitigation (apparently there are compiler plugins that remove popular stack pivot gadgets).

thefreeman 11y ago

Did you update the addresses of the kernel functions? #define COMMIT_CREDS_ADDR (0xffffffff81094250) #define PREPARE_KERNEL_CREDS_ADDR (0xffffffff81094550)

vnik 11y ago
even if you don't update the addresses you would at least get an oops if the exploit is working. I've explained the problem with rcu calls in my post https://cyseclabs.com/page?n=02012016 https://cyseclabs.com/page?n=02012016 reply but did not describe the technique for ordering these calls. The way they do things in the poc, you'd be lucky if it succeeds once out of 100.
- deleted 11y ago
  [deleted]