Kdtyjb

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.

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.

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.

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.

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.

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.

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.

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).