[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <5467D237.1090604@mccme.ru>
Date: Sun, 16 Nov 2014 01:22:47 +0300
From: Alexander Cherepanov <cherepan@...me.ru>
To: oss-security@...ts.openwall.com
Subject: Re: Re: strings / libbfd crasher
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
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.
