Date: Sun, 2 Nov 2014 16:57:23 -0800 From: Michal Zalewski <lcamtuf@...edump.cx> To: oss-security <oss-security@...ts.openwall.com> Subject: Re: Re: strings / libbfd crasher > BTW is there a method to quickly sort out crashes (or other bad behavior) > into potentially exploitable and presumably non-exploitable, i.e. separate > security issues from non-security ones? Nah, not really. You just sort of need to have a look. For very quick and error-prone triage, it's probably fair to say with out-of-bound writes that are far away from 0x0 *and* are not stack exhaustion, you can presume exploitability. That presumption gets stronger if the address is close to existing memory mappings or if it changes from one test case to another. It's possibly a bit weaker if it's only caught by Valgrind or so, because not all off-by-one issues are necessarily a problem under normal circumstances, due to things such as alignment padding or non-essential variables; when it's bad enough to crash under normal operating conditions, the evidence of exploitability is stronger. For derefs in the fixed vicinity of 0x0, you can probably assume non-exploitability except for certain specific circumstances (e.g., kernel bugs, use of uninitialized memory whose content you feel you could influence). Call stack exhaustion is generally non-exploitable in itself. For read derefs, non-exploitability can be a weak initial assumption, too, but this can change easily (e.g., if the next thing the program would do with the data it tries to read is use it to write to the read address, or something of that sort). Read derefs in places such as free(), malloc(), sprintf(), strcpy(), etc, are probably exploitable. > Simple fuzzing of objdump with zzuf (not even afl) quickly gives out tens > and hundreds of different cases of mentioned errors (mostly from the first > group:-). Now what? Well, deduping is important. If you're running without ASLR, you can get reasonably good results by grouping problems by %eip / %rip where the crash occurred. Looking at the call stack is good, too. But some memory corruption issues will have latent effects. With these, ASAN / Valgrind / debugging allocator can help. /mz
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ