Xrhrft

Even though sometimes software bugs and vulnerabilities are deemed as the same concept, there must be at least one distinct aspect between them, and I think the most prominent one is exploitability (the latter one having the property).

What I'm curious about is, even after seeing many cases that divide-by-zero bugs are reported as software problems, I can hardly come up with any attack (other than DoS) using divide-by-zero bugs. I know not all kinds of bugs have the same impact upon a system in terms of security, but is there any attack method that uses divide-by-zero bugs to achieve something different than DoS, like privilege escalation for example?

Division by zero is not inherently a security vulnerability.

However, if you can make an application server crash and stay offline by making it divide by zero, this may constitute a denial of service vulnerability.

I think ultimately your answer’s going to come down to the individual system in play. How does the system handle trying to divide by 0? If it’s elegant, then your attack options are limited or nonexistent. If it does something funky you can probably get in there with something.

Basically, no standard attacks can come out of this - that I’m aware of anyway - but computers can always handle bugs badly, and bad handling of bugs is the source of many vulnerabilities.

At issue is that an exception handler will be invoked to handle the division by zero. In general, attackers know that exception handlers are not as well-tested as regular code flows. Your main logic flow might be sound and thoroughly tested, but an exception handler can be triggered by interrupts occurring anywhere in the code within its scope.

int myFunction(int a, int b, SomeState state) {



    state(UNINITIALIZED);

    try {

        state.something(a/b);

        state(NORMAL);

    }

    catch () {

        state.something(b/a);

        state(INVERTED);

    }

    return retval;

}

This horrible pseudocode sort of illustrates one way the flaw could be exploited. Let's say that an uninitialized state is somehow vulnerable. If this routine is called, the state is first uninitialized. If b is zero, it catches the exception and tries to do some other logic. But if both a and b are zero, it throws again, leaving state uninitialized.

The division by zero itself wasn't the vulnerability, it's the bad code around it that's possible to exploit.