oss-sec mailing list archives
Re: Re: strings / libbfd crasher
From: Alexander Cherepanov <cherepan () mccme ru>
Date: Wed, 05 Nov 2014 03:09:34 +0300
On 2014-11-03 03:57, Michal Zalewski wrote:
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.
What a pity!:-)
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.
Thanks a lot for your explanation! The data for most things that you describe seems to be available from valgrind so it could be scripted.
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.
That's after deduping by a call stack as available in valgrind output:-(That is, for those thousands of samples which were run through it. Unfortunately valgrind is not very fast and millions of other crashes were not analyzed.
Well, after the first bunch of crashes will be fixed I can simply rerun zzuf and see which crashes are left.
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.
Indeed. And both things are easy to get with gdb. And it's much faster than valgrind.
But some memory corruption issues will have latent effects. With these, ASAN / Valgrind / debugging allocator can help.
Indeed. Thanks again. -- Alexander Cherepanov
Current thread:
- Re: strings / libbfd crasher, (continued)
- Re: strings / libbfd crasher Michal Zalewski (Oct 24)
- Re: strings / libbfd crasher Tavis Ormandy (Oct 24)
- Re: strings / libbfd crasher mancha (Oct 24)
- Re: strings / libbfd crasher cve-assign (Oct 26)
- Re: Re: strings / libbfd crasher Hanno Böck (Oct 26)
- Re: strings / libbfd crasher cve-assign (Oct 30)
- Re: Re: strings / libbfd crasher Alexander Cherepanov (Nov 02)
- Re: Re: strings / libbfd crasher Hanno Böck (Nov 02)
- Re: Re: strings / libbfd crasher Michal Zalewski (Nov 02)
- Re: Re: strings / libbfd crasher Jann Horn (Nov 02)
- Re: Re: strings / libbfd crasher Alexander Cherepanov (Nov 04)
- Re: Re: strings / libbfd crasher Michal Zalewski (Nov 04)
- Re: Re: strings / libbfd crasher Alexander Cherepanov (Nov 11)
- Re: Re: strings / libbfd crasher Michal Zalewski (Nov 11)
- Re: Re: strings / libbfd crasher Michal Zalewski (Nov 11)
- Re: Re: strings / libbfd crasher Alexander Cherepanov (Nov 15)
- Re: Re: strings / libbfd crasher Michal Zalewski (Nov 15)
- Re: Re: strings / libbfd crasher Alexander Cherepanov (Nov 15)
- Re: Re: strings / libbfd crasher Hanno Böck (Oct 26)
- Re: Re: strings / libbfd crasher mancha (Nov 03)
- Re: Re: strings / libbfd crasher Michal Zalewski (Nov 03)
- Re: Re: strings / libbfd crasher mancha (Nov 03)