Jump to content
YOUR-AD-HERE
HOSTING
TOOLS

Locked MacOSX 10.11.4 Stack Buffer Overflow in GeForce GPU Driver


dEEpEst

Recommended Posts

/*

 

nvAPIClient::Escape is the sole external method of nvAcclerator userclient type 0x2a0.

It implements its own method and parameter demuxing using the struct-in struct-out

buffers.

 

The second dword in the struct in buffer is another method identifier used in a switch

statement in ::Escape to choose the method to call. Method 24 is ::SetClocksShmoo.

 

On entry to this method rsi points to a buffer in kernel space with completely

user-controlled contents.

 

The uint16_t field at +0xc is used a loop count for the memory copying loop at

+0xff3e with insufficient bounds checking. The destination stack buffer is 0x520 bytes below the saved

frame pointer but the code only checks whether the value we provide (after bit shifting)

is greater than 0xff. Since each iteration of the loop writes 0x14 bytes we can actually

write up to 0x13ec bytes which is well over the size of the stack buffer which is being copied

into.

 

This bug is reachable from the safari renderer sandbox and the chrome gpu process sandbox

on device with the appropriate hardware (eg macbookpro)

*/

 

// ianbeer

 

// build: clang -o nv_shmoo nv_shmoo.c -framework IOKit

// tested on MacBookPro 10,1 w/10.11.3 (15D21)

 

/*

OS X kernel stack buffer overflow in GeForce gpu driver

 

nvAPIClient::Escape is the sole external method of nvAcclerator userclient type 0x2a0.

It implements its own method and parameter demuxing using the struct-in struct-out

buffers.

 

The second dword in the struct in buffer is another method identified used in a switch

statement in ::Escape to choose the method to call. Method 24 is ::SetClocksShmoo.

 

On entry to this method rsi points to a buffer in kernel space with completely

user-controlled contents.

 

The uint16_t field at +0xc is used a loop count for the memory copying loop at

+0xff3e with insufficient bounds checking. The destination stack buffer is 0x520 bytes below the saved

frame pointer but the code only checks whether the value we provide (after bit shifting)

is greater than 0xff. Since each iteration of the loop writes 0x14 bytes we can actually

write up to 0x13ec bytes which is well over the size of the stack buffer which is being copied

into.

 

This bug is reachable from the safari renderer sandbox and the chrome gpu process sandbox

on device with the appropriate hardware (eg macbookpro)

 

[HIDE-THANKS]

This is the hidden content, please

[/HIDE-THANKS]

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.