This Old Vulnerability: UMUL/UDIV

Matasano Team | March 23rd, 2006 | Filed Under: This Old Vulnerability

Vulnerability researchers have been increasingly focused on kernel level vulnerabilities. While a lot of progress has been made in the past couple of years, I thought it would be cool to dig up some really old kernel vulnerabilities. Oh look, here’s one now!

On this installment of This Old Vulnerability, we are going to examine a kernel vulnerability that affected SunOS 4.1 and 4.1.1 (as opposed to a new vulnerability in SunOS 4.1.x). Let’s see what CERT had to say about the Integer Division vulnerability we are going to examine today.

I.   Description
A security vulnerability exists in the integer
division on the SPARC architecture that can be
used to gain root privileges.

II.  Impact

Any user logged into the system can gain root
access.

Helpful as ever! Let’s ask Spaf via the Core mailing list. Spaf, I having a difficult time comprehending this CERT advisory, can you help?

Regarding the integer division problem. It’s not that difficult to comprehend. Just set up a divide instruction, and set it so the remainder is to be stored in any arbitrary address you want (you have to do this in assembler, although the % operator in C may let you do this…I dunno). Then divide appropriately chosen numbers. The instruction traps, the divide is emulated, the results are stored *in privileged mode* and control is passed back to the user. No problems! However, the address specified for the remainder may not be in the user’s memory space. Appropriate choice of values to be stored and locations to be stored into result in all sorts of fun results.

Thanks Spaf!

Finally, lets track this back to the source:

printf("enter address in hexn");
gets(buf);
sscanf(buf, "%x", &addr);
addr -= 32;

pp = (unsigned long *) addr;
printf("address is 0x%0.8xn", addr);

if (fork() == 0) {
asm("   sethi   %hi(_addr), %i4");
asm("   ld      [%i4+%lo(_addr)], %i4");
asm("   nop");
asm("   mov     %i4, %sp");
asm("   udiv    %i2, %i7, %i2");
asm("   nop");
exit(0);
}

Looks like the use of umul/udiv causes an attacker controllable value to be written into the address stored in %sp. Since umul/udiv were emulated instructions on the affected systems, I wonder how umul/udiv is handled on the sun4c ports of linux/*BSD. I suppose if you are still using a sun4c, you will stop attackers simply by boring them to death.