[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <54596ABE.2000400@mccme.ru>
Date: Wed, 05 Nov 2014 03:09:34 +0300
From: Alexander Cherepanov <cherepan@...me.ru>
To: oss-security@...ts.openwall.com
Subject: Re: Re: strings / libbfd crasher
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
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
