Is divide-by-zero a security vulnerability?I've found security vulnerability in current linux distribution....
Why do members of Congress in committee hearings ask witnesses the same question multiple times?
Can I retract my name from an already published manuscript?
Avoiding morning and evening handshakes
What happens if a wizard reaches level 20 but has no 3rd-level spells that they can use with the Signature Spells feature?
Why is commutativity optional in multiplication for rings?
Am I a Rude Number?
Do my Windows system binaries contain sensitive information?
Can a hotel cancel a confirmed reservation?
If I delete my router's history can my ISP still provide it to my parents?
It took me a lot of time to make this, pls like. (YouTube Comments #1)
Which aircraft had such a luxurious-looking navigator's station?
Why is working on the same position for more than 15 years not a red flag?
Yeshiva University RIETS Semicha Yorei and Yadin
Where is this triangular-shaped space station from?
Can chords be played on the flute?
How to avoid being sexist when trying to employ someone to function in a very sexist environment?
How Should I Define/Declare String Constants
Meaning of すきっとした
How to define a macro with multiple optional parameters?
Wanted: 5.25 floppy to usb adapter
Finding the number of integers that are a square and a cube at the same time
How can I mix up weapons for large groups of similar monsters/characters?
Eww, those bytes are gross
Why does the DC-9-80 have this cusp in its fuselage?
Is divide-by-zero a security vulnerability?
I've found security vulnerability in current linux distribution. What next?Vulnerability exploitation in Javawhere can I find list of zero day vulnerability?web security testing - vulnerability issueTrusted vulnerability database sourcevulnerability scanning softwareHow to detect Rowhammer vulnerability?Educational Security VulnerabilityIs there an estimation of the amount of zero-days out there?is SSRF attack or vulnerability?
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?
exploit attacks vulnerability
asked 5 hours ago
Gwangmu LeeGwangmu Lee
1063
add a comment |
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?
exploit attacks vulnerability
asked 5 hours ago
Gwangmu LeeGwangmu Lee
1063
I have a vague memory of a CVE from many years ago that was at its core a divide by zero, but was a remote root arbitrary code bug. It was probably something like what John Deters described, but I don't remember enough to risk giving an answer.
– Ed Grimm
12 mins ago
add a comment |
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?
exploit attacks vulnerability
asked 5 hours ago
Gwangmu LeeGwangmu Lee
1063
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?
exploit attacks vulnerability
exploit attacks vulnerability
asked 5 hours ago
Gwangmu LeeGwangmu Lee
1063
asked 5 hours ago
Gwangmu LeeGwangmu Lee
1063
asked 5 hours ago
Gwangmu LeeGwangmu Lee
1063
asked 5 hours ago
Gwangmu LeeGwangmu Lee
1063
asked 5 hours ago
Gwangmu LeeGwangmu Lee
1063
1063
I have a vague memory of a CVE from many years ago that was at its core a divide by zero, but was a remote root arbitrary code bug. It was probably something like what John Deters described, but I don't remember enough to risk giving an answer.
– Ed Grimm
12 mins ago
add a comment |
I have a vague memory of a CVE from many years ago that was at its core a divide by zero, but was a remote root arbitrary code bug. It was probably something like what John Deters described, but I don't remember enough to risk giving an answer.
– Ed Grimm
12 mins ago
I have a vague memory of a CVE from many years ago that was at its core a divide by zero, but was a remote root arbitrary code bug. It was probably something like what John Deters described, but I don't remember enough to risk giving an answer.
– Ed Grimm
12 mins ago
I have a vague memory of a CVE from many years ago that was at its core a divide by zero, but was a remote root arbitrary code bug. It was probably something like what John Deters described, but I don't remember enough to risk giving an answer.
– Ed Grimm
12 mins ago
add a comment |
3 Answers
3
active
oldest
votes
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.
answered 3 hours ago
duskwuffduskwuff
1,211410
add a comment |
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.
answered 5 hours ago
securityOrangesecurityOrange
62215
add a comment |
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.
answered 2 hours ago
John DetersJohn Deters
27.8k24191
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "162"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f204669%2fis-divide-by-zero-a-security-vulnerability%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
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.
answered 3 hours ago
duskwuffduskwuff
1,211410
add a comment |
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.
answered 3 hours ago
duskwuffduskwuff
1,211410
add a comment |
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.
answered 3 hours ago
duskwuffduskwuff
1,211410
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.
answered 3 hours ago
duskwuffduskwuff
1,211410
answered 3 hours ago
duskwuffduskwuff
1,211410
answered 3 hours ago
duskwuffduskwuff
1,211410
answered 3 hours ago
duskwuffduskwuff
1,211410
1,211410
add a comment |
add a comment |
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.
answered 5 hours ago
securityOrangesecurityOrange
62215
add a comment |
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.
answered 5 hours ago
securityOrangesecurityOrange
62215
add a comment |
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.
answered 5 hours ago
securityOrangesecurityOrange
62215
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.
answered 5 hours ago
securityOrangesecurityOrange
62215
answered 5 hours ago
securityOrangesecurityOrange
62215
answered 5 hours ago
securityOrangesecurityOrange
62215
answered 5 hours ago
securityOrangesecurityOrange
62215
62215
add a comment |
add a comment |
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.
answered 2 hours ago
John DetersJohn Deters
27.8k24191
add a comment |
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.
answered 2 hours ago
John DetersJohn Deters
27.8k24191
add a comment |
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.
answered 2 hours ago
John DetersJohn Deters
27.8k24191
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.
answered 2 hours ago
John DetersJohn Deters
27.8k24191
answered 2 hours ago
John DetersJohn Deters
27.8k24191
answered 2 hours ago
John DetersJohn Deters
27.8k24191
answered 2 hours ago
John DetersJohn Deters
27.8k24191
27.8k24191
add a comment |
add a comment |
Thanks for contributing an answer to Information Security Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f204669%2fis-divide-by-zero-a-security-vulnerability%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
I have a vague memory of a CVE from many years ago that was at its core a divide by zero, but was a remote root arbitrary code bug. It was probably something like what John Deters described, but I don't remember enough to risk giving an answer.
– Ed Grimm
12 mins ago