Securityficus

The PowerPC architecture doesn’t have a divide by zero exception. When you divide by 0, it returns 0. When you do x % 0, it returns x.

This can lead to subtle errors, especially with the mod operation(%).

Example:

This program creates a buffer of user-specified length filled with ‘A’s, and overwrites one random character in the buffer with a ‘B’. If the user-specified length is 0, then it will write a ‘B’ to a random address, corrupting memory. This would be very unlikely to be exploitable, but it illustrates how memory corruption can occur when div by zero is not trapped, and you’re not expecting it. On Intel, the divide by zero would always result in a crash, with no possibility of anything worse.

$ cat test.c

int main(int argc, char **argv) {
    char * buf;    

    //user-supplied size for buf
    int untrusted_size = atoi(argv[1]);

    buf = malloc(untrusted_size);
    if (!buf) {
        exit(-1);
    }

    srandomdev();
    memset(buf, 'A', untrusted_size);

    //get a random number from 0 to untrusted_size-1
    //or if untrusted_size = 0, return a random number from 0 to RAND_MAX
    int rnd_index = random() % untrusted_size;
    printf("rnd_index = %d\n", rnd_index);
    buf[rnd_index] = 'B';
    printf("%s\n", buf);
    return 0;
}

$ ./a.out 10
rnd_index = 8
AAAAAAAABA

$ ./a.out 0
rnd_index = 2098236498
Segmentation fault

http://dvlabs.tippingpoint.com/blog/2007/12/14/new-leopard-security-features—part-iii-sandboxing

This is an interesting article on sandboxing in Leopard.

It’s a feature which allows a user or administrator to limit the actions that a process can do to only the actions that it needs to do. Then, if there is a security vulnerability such as a buffer overflow in the program, when malicious code is injected into the process, it can only do the actions that the process would normally do, thus limiting the potential damage significantly.

In the paper “Some thoughts on security after ten years of qmail 1.0” by Daniel J Bernstein, djb mentions this type of technology as one of the most promising for mitigating security bugs. Specifically, see section 5.2. Of course, he also claims in section 2.5 that “minimizing privilege” is a fundamentally wrong distraction, and the key is minimizing the amount of trusted code, which isn’t the same thing.

Sandboxing can be used for both, and the key to reducing the trusted code base rather than just reducing privilege in general is to intelligently apply appropriate profiles.

See the manpages sandbox(7), sandbox-exec(1), sandbox_init(3), and sandbox-compilerd(8).

http://wslabi.com/wabisabilabi/showBidInfo.do?code=ZD-00000185

http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-6238

http://wabisabilabi.blogspot.com/2007/11/quicktime-zeroday-vulnerability-still.html

There are a number of other links commenting on this story that you can find if you Google. One notable thing that no one seems to notice is that in the comments section of the wabisabilabi blog post, they acknowledge that the bug only affects QuickTime 7.2. 7.3.1 is the current version, and 7.3 was already out when the bug was first put up for auction. Some 0-day.

 2 comments:

Anonymous said...

    Does your issue affect QT 7.3, which is the current version?
    December 3, 2007 8:07 PM
WabiSabiLabi Staff said...

    No, only vulnerable version is 7.2
    December 10, 2007 2:38 PM

Someone ended up buying it for 500 euro. Which is pretty steep, considering QuickTime’s track record, there are probably more bugs in it that are still unpatched.