On 2014-12-04 17:27, Mark Wielaard wrote:
[skip]
> BTW. It is helpful to know which architecture you are running on. Some
> issues only show on a 32bit architecture trying to parse a 64bit ELF file,
> or on little/big endian systems parsing a different endian ELF file.

Yes, sorry, I'm using amd64 now. Maybe will switch to x86 later.

>> I'm not very familiar with elfutils. Which commands give the most code
>> coverage (and shortest run time)? I've used two commands so far:
>>
>>     objdump -rs
>>     readelf -aAdehIlnrsSVcp -w
>>
>> and crashes seem to differ for them.
>
> That does give a biggest coverage. For eu-readelf -w you might want to use
> -N, --numeric-addresses Do not find symbol names for addresses in DWARF data
> which can increase the runtime a lot (we really need to not do a linear
> search to lookup the addresses...).

Thanks for the tip!

> But I found that using such broad coverage makes the search space for the
> fuzzer really, really big. It can take days for the fuzzer to generate a
> somewhat valid data for some of the section types. It is imho better to
> not use -a or -w, or a combination of flags for different headers or data
> sections, but to create a minimal valid ELF file with just one kind of
> section or segment and then let the fuzzer run on that with just one
> specific flag (or --debug-dump=xxx).

I think this is specific to AFL which you seem to use. For it, I agree 
with your approach. But I'm not sure how useful such an advanced fuzzer 
at this stage. I'm still using zzuf. Right now it gives more crashes 
than I can pipe through valgrind. You can get similar behavior with AFL 
if you specify -dn options (or perhaps you can use just -d).

>> BTW does indended use of elfutils include the use against untrusted
>> files and do you track corresponding security issues?
>
> I guess it isn't specifically intended for use against completely untrusted
> files. But it happens of course. Also some of the elfutils libraries (libelf,
> libdw) are used by tools that might process untrusted data. For example
> systemd might use libdw to extract backtraces from core files - which should
> normally be "trusted" because generated by the kernel, but there might be
> bugs in the generation or they might refer to ELF or debug files that a
> hostile user might have prepared. So we are actively working to make it
> work robustly against anything thrown at it.

Nice to hear it!

> We don't specificly track any security issues, we just treat them as bugs
> to be fixed and do a new release when enough/important bugs have been fixed.
> There have been people who have filed CVEs against elfutil bugs though.
> I don't have any experience with filing CVEs though.

I see. For now, I've added 'Security' keyword to the bug in the 
bugzilla. This should get attention of the security team. Otherwise I 
can ask for CVEs later in oss-security mailing list.

[skip]
> I might be good to have a central place to store these results.
> The mailinglist seems a little problematic and we might miss/overlook
> some issues just posted to the list.

Sure, and mailing several megs of attachments to all the list is not 
nice too. It's just there is no info about bug reporting on the project 
page at https://fedorahosted.org/elfutils/ .

> Do you have some location where you
> can store them and any future files? Or could you open a bugzilla report
> against elfutils and attach them there?
> https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora

I think the bugzilla is exactly fine for this. Filed here:

https://bugzilla.redhat.com/show_bug.cgi?id=1170810

-- 
Alexander Cherepanov