mjhjmtu

To add another contrived but based on real example:

Many (many) moons ago, my high school was running Novell Netware and had it configured so that students couldn't directly run an dos prompt (which was annoying if you e.g. needed to format a floppy disk). However, it was discovered that if you entered in a password more than X characters (i.e. just held down a key for a while), this would crash netware and drop the system back to ... a dos prompt. Most likely this was a buffer overrun, but the principle is the same: if you're dealing with a system (especially an embedded one) which handles at least some unexpected crashes by dropping you into a maintenance mode, then there is a security concern.

As the other answers are suggesting, it entirely depends on the whole system. That is not just the code, but the platform, language and compiler too.

For example in c++, division by zero on integers is undefined behaviour. One of the rules about that particular language is the compiler may assume that undefined behaviour will never occur, and is allowed to do anything if it does.

Anything includes crash with an error message and clean up, crash without an error message and leave everything in a weird state, or most terrifying try to keep going as if nothing has happened.

Now in practice most good modern compilers try to crash cleanly if they hit something like that, but this should make it clear why the assumption is that it is a vulnerability. If you just build your code with a different compiler or different settings, and don't even change the code, what the program does could go from a clean crash to wiping out your database.

Altogether with a misconfigured webserver, a PHP environment could reveal the physical path to the script when a division by zero is caused (internal path leakage):

<?php
$denominator = $_GET['number'];
echo 1/$denominator;

Accessing script.php?number=0, we could see:

Warning: Division by zero in /var/www/html/script.php on line 3.

While I sometimes say in my workshops and lectures that all security issues in software are essentially bugs, the reverse is not automatically true.

I would not, however, go to exploitability as an argument. Just because you and me can't figure out a way to exploit doesn't mean someone more crafty won't one day. We would have to provide a formal proof that it is not exploitable. Good luck with formal proofs in current programming languages.

So to answer your question: A division by zero could be a vulnerability or a part of it. Typically it will lead to an exception and thus termination of the software. This by itself could be important information for an attacker (he now knows that some variable was zero).

It is unlikely that the division by zero alone is a security vulnerability, but in a larger context it can be a part of the problem.

So, to close the loop, you should always treat all bugs seriously. If you cannot be sure (e.g. your division uses a variable you don't control) then you need to catch and handle it, security or not. "yeah, it's a bug but I don't see how it could be exploited" is not a security-conscious mindset.

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.

If a program will only receive trustworthy data, and if it would not have to meet any behavioral requirements when given maliciously-crafted data, then it may be possible to generate slightly more efficient code than would be required if there were some behavioral requirements that it had to meet for all data.

Because some tasks only involve processing trustworthy data, while others involve processing data from untrustworthy sources, the C Standard allows implementations that are intended only for the former tasks to make optimizations that would be inappropriate in those intended for the latter, and for those intended to be suitable for the latter tasks to offer guarantees that would unnecessarily impede optimizations that could be useful when processing the former.

Unfortunately, the Standard provides no means by which implementations can indicate what kinds of behavioral guarantees they will offer beyond those mandated by the Standard. When C89 was written, the authors expected that "the marketplace" could do a better job than the authors of the Standard of determining what kinds of implementations should support what "popular extensions" by behaving at least somewhat predictably in cases where the Standard imposed no requirements, and such attitude has not changed even though it no longer fits today's compiler marketplace.

Given something like:

if (x != 0) launch_nuclear_missiles();
... and then, possibly in another function
z=y/x;

some people would view a compiler that replaces the "if" with an unconditional call to launch_nuclear_missiles() as superior to one that only calls launch_nuclear_missiles if x is non-zero, but such behavior would only be appropriate when processing tasks that will never involve untrustworthy input.

If one knows that the compilers one is using will uphold the kinds of weak behavioral guarantees that general-purpose compilers used to offer as a matter of course, and which facilitate writing programs that could meet weak behavioral constraints even when given maliciously-crafted inputs, then division-by-zero might not pose security weaknesses. With aggressively-optimizing compilers that are not designed to be suitable for tasks involving untrustworthy input, however, it will be necessary to add enough safety-checking logic to negate any advantages such "optimizations" could have offered.

but is there any attack method that uses divide-by-zero bugs to achieve something different than DoS, like privilege escalation for example?

Quick search on MITRE's CVE database will reveal that mostly division by zero causes denial of service, but one particular case CVE-2005-0998 allows for something else:

Description
The Web_Links module for PHP-Nuke 7.6 allows remote attackers to obtain sensitive information via an invalid show parameter, which triggers a division by zero PHP error that leaks the full pathname of the server.

This itself doesn't allow for privilege escalation or specific attacks, but generally speaking sensitive information can be useful in crafting other attacks. In other words, by itself division by zero might be only a stepping stone.

I see where you are coming from on this. In it own right its difficult to see how just an arithmetic error could be used to cause anything that required data input (like code execution).

However, depending on the language it could cause flow control issues or selectively crash threads etc. This is the sort of thing that allows you to compound other issues or if you're really (un)lucky, directly lead to triggering a pathway that causes double something exploitable. Remember the data entry and the bug don't necessarily have to be the same.

This is a bit of a contrived, but say for example you moved an object already in a linked list by adding a copy to the head, and then iterating till you find it and remove the copy.
If you do this is in a thread and for some reason (say someone puts a stats print statement in the iteration loop that's wrong), it's possible that will leave the list in a bad state with 2 copies of the same element.
When this gets cleaned up: double free...

If you can control the contents of this new element, and can make the stat result in a divide by zero and still control enough of the contents, this could well be exploitable.

Not likely, but possible.

The question might be better phrased as "Why is Denial of Service considered a security vulnerability?". When running Linux on an x86 processor, if the processor divides an integer by 0 (or the minimum signed integer value divided by -1, thanks supercat) the program receives a SIGFPE signal. In Windows it's an illegal operation. The C/C++ standard considers it undefined behavior which means you can't reliably know what will happen just by looking at the code.

Normally this, as with many but not all Denial of Service vulnerabilities, will result in a "crash". Here's some possibilities of what you can exploit when a program has abnormal termination:

• It could allow another program to use the same resources as the first (like a port) and pretend to be the same program.


• Crashing may circumvent any cleanup operations used by the program which could be exploited.


• If the exit code of the program is being used in another program that isn't checking the signal state of the child process's PID it could think the program returned an error code. For instance on my Linux machine, the following 2 programs both set $? (the variable used in shell scripts to represent return code of the previous command) to 136:
  int main(int argc, char** argv) return 1 / (argc - 1); and int main() return 136;
  


• Crashing may result in things like coredumps which may contain protected memory like security keys, passwords, and the recipe for Coca-Cola.

Additionally, because of optimizations, the compiler may choose to assume that the divisor could never be 0 and potentially optimize away code you might not have considered. This only applies to compiled languages like C and C++ that have undefined behavior (or its equivalent) for division by zero. I couldn't produce optimized code that does that using the examples in some other answers in clang or gcc, but there is nothing preventing them or other compilers from doing that either in the past or future.

Here is an example of where it might make a difference.

It is 100% contrived - but many classes of exploits are identified by theoretical "contrived" examples, until specific examples are found.

It is pseudo-code.

try:
 get the average cpu usage per logged in user
 if this average is too high, tell the person logging on that we're busy.
 get login credentials
 verify login credentials
 if credentials are invalid, tell them to go away
 restrict access for this session to the correct access for this user
if there is an exception:
 do nothing

let the user in

In this case the average cpu per logged in user, might be calculated as "total cpu / number of logged in users" - if there are no logged in users, you get "divide by 0", and it skips directly to the "if there is an exception" clause. This includes restricting access - the new session might have access matching the last user to log in, or unlimited access.

While this example shows all the code together, often your main code will call something, which calls something else, and the two aspects that interact (in this case, division by 0, and the fact that the exception is ignored) may run in parts of the code which are a long way apart.

As many people have mentioned, division by zero (on it's own) is not a security bug, or indeed a bug at all. As far as I'm aware, most (maybe all!) programming languages have clearly documented information as to what happens when division by zero occurs. I think pretty much every language that has exceptions, has an exception for division by zero (I have seen a mechanical calculator get stuck in an endless loop).

There are some very specific answers here. I would agree that a (unhandled) division by zero issue is primarily a functional issue - but that does not mean it cannot be exploited as a security issue. Indeed, there are so many bugs which can be exploited the classification of "functional" vs "security" when applied to bugs seems somewhat pointless.

You dismiss a category of Security issues (DOS) without any discussion of what you consider out of scope here. The most obvious scenario is that tripping the error will cause the instance of the program to stop. But there are more subtle effects - if it causes large amounts of data to be written to the filesystem (such as a core dump) it presents an avenue for a second type of DOS, by filling up the filesystem.

Jefrey mentions disclosure for a PHP application - but error messages, logs and core dumps provide rich picking grounds for people trying to extract information they should not have access to from programs written in any language.

If the premature termination of the program leads to some sort of response, then an attacker has means of triggering a specific program at a time of their choosing - they have some control over what your system is doing which can facilitate an attack / privilege escalation.

Even if the control system is manual, there is still a transition state for the system where security behaviours are less well defined and where assets such as pass-phrases, passwords and private keys are in flight.