Intel e100/1000 Local Privilege Escalation & PAX

[john_anderson_ii]

I was recently informed of an Intel network driver local privilege escalation and I was curious as to how/if PAX can prevent this attack.

From the description of the attack:

Therefore, supplying a 0x17A-character string (at offset +0x0C within
the output buffer, because NDIS uses the first 8 bytes for its own
purposes) will cause the handler function's return address to be
entirely overwritten, allowing execution to be redirected to an
arbitrary user- or kernel-mode address.

Full text of the exploit description: http://www.securityfocus.com/archive/1/453852

I'm betting that PAX ASLR makes this type of exploit impossible. It seems to me that the user space code would not know which address to supply while overwriting the return address and would therefore segfault. Am I correct in this assumption?

To me this means the difference between making a mad dash to upgrade e1000/e100 drivers on hundreds of servers, or doing it as I get the time in a more controlled manner.

[PaX Team]

I was recently informed of an Intel network driver local privilege escalation and I was curious as to how/if PAX can prevent this attack.

according to http://support.intel.com/support/network/sb/CS-023726.htm only Windows was affected.

I'm betting that PAX ASLR makes this type of exploit impossible. It seems to me that the user space code would not know which address to supply while overwriting the return address and would therefore segfault. Am I correct in this assumption?

no. this is a local attack therefore the exploit code has full knowledge of its own process memory layout. the features that would make it non-trivial (but not impossible) to exploit a kernel bug are KERNEXEC and UDEREF.

[john_anderson_ii]

Removed references to Linux and SCO-UnixWare because the kernel architecture precludes this vulnerability; clarified that vulnerability exists in certain Windows drivers for the networking components and adapters.

Thanks for pointing this out. Looks like SecurityFocus is still reporting that this bug is applicable to Linux.

As always, thanks for help.