Re: Re: strings / libbfd crasher

[Alexander Cherepanov <cherepan () mccme ru>]

On 2014-11-15 23:17, Michal Zalewski wrote:
> > OTOH the "most" part in "most compression utilities" is somewhat
> > questionable. There are quite a number of them. E.g. File Roller supports
> > arj, lha, zoo...
>
> Sure, I mean, the stuff people normally download and click on without
> hesitation (tar, gz, zip, xz, 7z). There are hundreds of less common
> tools and libraries that are probably awful.

I think many people have arj installed and click .arj files without 
hesitation too. According to Debian popcon ( 
http://popcon.debian.org/by_vote ) arj is at the 2266th place, only 4 
places behind wireshark and 6 places ahead of acroread.

> > > The default operation of
> > > /usr/bin/strings and the way many people ended up using it arguably
> > > violates that assumption in a particularly pronounced way. Tools such
> > > as objdump are a bit of a grey area, too.
> >
> > Why is that? I think using objdump to analyze malware is quite common.
>
> Oh, I meant that it's still a bit sketchy (maybe less than 'strings'
> because the untrusted input use case is a lot more specialized and
> fewer people are at risk).

Sorry, I still don't understand what you mean (perhaps my English is 
just lacking). Both `strings` and `objdump` are using libbfd (unlike 
readelf), both are used against untrusted input.

> > > [...tcpdump...]
> >
> > Not good. Haven't you looked into it -- are these crashes due to malformed
> > pcap format or due to malformed traffic?
>
> Both, IIRC. There are some test cases that come with afl-fuzz.

Oh...

> > BTW any crash in imagemagick during image processing is regarded as a
> > security issue? Probably a grateful target for fuzzing.
>
> Well... probably? For example, some sites use ImageMagick to convert /
> resize user-uploaded images. One would hope that they check file
> headers and only accept JPEG / GIF / PNG or so, but that's probably
> not universally true.

Or they can look at the extension and use something like `convert 
png:input.png ...`

> > > Now, the quality of the *average* OSS project is probably comparable
> > > to libbfd, but the average OSS project is probably less likely to be
> > > exposed to untrusted inputs under normal operating conditions.
> >
> > Sorry, I don't understand your stance. There is a whole world of desktop
> > tools and applications -- from `file` and `strings` to LibreOffice and
> > Blender. And most of them process files received from untrusted sources.
>
> I wouldn't describe LibreOffice as a typical example. It's obviously
> security-critical.

Nevertheless taking one simple .doc and zzuf I get an infinite loop(?) 
at seed 58 (IIUC it's classified as DoS in LO) and SIGSEGV at seed 91. 
Hm, abiword also crashes on this case.

Well, crashing at seed 91 is not that bad -- catdoc crashes right at 
seed 0 :-(

> What I mean is that, across all the packages
> installed on your system, most bugs are fairly irrelevant from the
> security perspective - i.e., it probably doesn't matter if you can
> crash uname or ps by passing AAAAAAA... in the command line.

Sure but there are enough apps which process various files -- at opening 
downloads from browsers, clicking attachments from emails or just 
clicking files in a file manager. And there are many command line tools 
which should be safe to use against untrusted files (like `strings`).

And most such programs are easy to crash. And when I say 'easy to crash' 
it means from instantly to a couple of minutes under zzuf, not a couple 
of days under afl.

Too much low hanging fruits, too little time...

--
Alexander Cherepanov