[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALx_OUCG9nbwZJcdAzSyL=_JQhEiv045Vjo-2d+=AZTOqB41_w@mail.gmail.com>
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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
