[Toybox] [PATCH] readelf: harden against invalid input.

[Rob Landley]

On 11/18/20 5:19 PM, enh wrote:
> On Wed, Nov 18, 2020 at 1:27 AM Rob Landley <rob at landley.net> wrote:
>>
>> On 11/17/20 6:29 PM, enh via Toybox wrote:
>>> On Thu, Nov 12, 2020 at 4:03 PM enh <enh at google.com> wrote:
>>>>
>>>> I also promised to fix readelf. Where in file(1) I made no attempt to
>>>> say what was bad (or even to change `goto bad` to explicitly say that
>>>> *anything* was bad), I believe that readelf is much more likely to be
>>>> shown invalid ELF files, and that it would be useful to have some clue
>>>> as to what's wrong. Relatedly, this patch removes all existing
>>>> error_exit() calls in case it's being used on multiple files.
>>>>
>>>> Again, this survived ~24hrs of AFL++ trying to blow its house down.
>>>
>>> actually, because i forgot to kill AFL++ and just lost the window in
>>> my stack, this has now survived nearly a week of continuous fuzzing
>>> :-)
>>
>> Your work environment is SO different from mine.
> 
> this is why we always argue about what the units should be in top(1) :-)
> 
> i really tried the whole laptop thing when WFH started, and i lasted a
> couple of weeks before i begged to have a real computer sent to me.
> chrome+gmail is enough of a resource hog that responsiveness of the
> rest of the system is awful just having them chugging away.

That's why I use thunderbird downloading with pop3. I only deal with the web
interface every couple weeks to go through the spam filter (by which time the
false positive rate can be up to 80% and I'm doing page after page of "not
spam". Luckily you can do it in batches now.)

(Yes, I should use a different server because gmail's spam filtering stopped
being a net positive ages ago, but I've been busy with other things...)

> (i "only"
> have 30 chrome windows open, and although some of them [like this one]
> definitely have 23 tabs or whatever, a good number of them only have
> one.)

I only have 15 at the moment. I didn't reload tabs when I let my laptop battery
die a couple weeks ago.

But if I open more than... (counts) 83 tabs in a full size window at this screen
resolution, it won't show the ones off the right edge meaning it won't let me
SELECT them until I close some of the first 83. (Firefix used to give me little
left/right scroll buttons, chrome never bothered.) So that's when I open new
windows. (Modulo having a window in 5 of my 8 desktops for different topic
reasons. #2 is toybox stuff, #6 is mkroot and linux stuff, #7 is email stuff, #8
is $DAYJOB stuff, #1 is blog and general browsing...

When the memory gets to much I "pkill -f renderer" and then reload as I go. (It
still shows me the URL when I select, and page title in the hover text over the
tab...)

> tbh, the couple of times this week when i was probably feeling the
> effect of AFL++ taking too many resources in the background, i just
> thought it was chrome getting ready for another crash restart[1].

It MOSTLY doesn't crash for me (I use the distro version, not the nightlies),
but when I use "reload tabs" after the battery dies, chrome will try to reload
everything (from the network, not from cache!) and if I "pkill -f renderer" too
many times while it's (iteratively) doing this, yes chrome will crash. (I used
to load tabs when not connected to the network, but then a chrome "upgrade" made
it try to reload them all as soon as the net connected, so I started sabotaging
/etc/resolv.conf so the reloads would fail with DNS lookup errors and all those
tabs wouldn't use tons of memory and cpu, and then they "upgraded" it to break
THAT...)

*shrug* It's a race between the chrome developers trying to be "helpful" and me
sabotaging it to go back to what it USED to do and stop doing things I don't
want it to. (Which was also my relationship with twitter.)

Anyway, there's a reason when it gets past a certain point I go "screw it,
chrome is too broken to maintain state like this" and periodically do NOT reload
tabs.

>>>> Test: ~/AFLplusplus/afl-fuzz -i tests/files/elf -o fuzz-out -- ./readelf -a @@
>>
>> Uh-huh:
>>
>>   https://github.com/AFLplusplus/AFLplusplus#how-to-fuzz-with-afl
>>
>> Alas, bit too much domain expertise required for me to go down that rathole on
>> any other commands just now. Couple interesting youtube videos on it though...
> 
> yeah, that's why it took me so long to get round to this after
> promising i would at the beginning of the year. (the "what have you
> done for fuzzing week?" nag mails were what finally made me work it
> out.)

You have fuzzing week?

I tend to like tools that Do A Thing I Understand, not "put something into this
black box that will perform 37 steps on it, 4 of which provide different results
each time, and 5 of which have implicit assumptions that are not actually true
of your environment but the failures are silent and harmless for 3 of those and
you don't initially know what success looks like for the other 2 so initially
assume the results you got are correct"...

I break everything. And sadly, development processes that add steps to cope we
me having broken stuff tend not to stay unbroken for long. (Not unless the black
box gets run in a VM on a freshly installed stock distro image set up just for
that, with a fresh vm for each purpose, and those go stale...) Yesterday I was
looking for a link (to see if I saved the URL of the man page explaining the
escape sequence I added to "reset"), and my blog entry at the time was:

  https://landley.net/notes-2019.html#06-02-2019

Which is a writeup about setting up a fresh chroot for a yocto build, looking up
what a "uninative binary shim" was, how I broke things like python 3 and bitbake
along the way, and trying to figure out why something calling itself
"core-image-minimal" would install "gnome-desktop-testing".

That sort of thing is a normal day for me, I just don't usually write it up in
that level of detail.

> which other tools were you thinking of fuzzing? file(1)/readelf(1)
> seemed like the obvious two in terms of fuzzing cost/benefit. blkid
> seemed plausible, but that has a lot of known feature work to worry
> about first.

Sigh, what are the blkid todo items? (Checks: -U and -L need arguments, "more
test_host", mount by uuid should use blkid default output. And those are the
only todo I can for it with a quick search. It's already got /proc/partitions
support?)

I was gonna start with sed because that's one of the more complex ones, and then
go to "toysh" when I get the test suite filled out. I'd love to fuzz ps/top but
am not entirely sure what that would _mean_.

Mostly when I'm designing stuff I think in terms of the input ranges for every
possible piece of data. (I break everything. How will THIS break?) I get the
occasional off by one error and miss the occasional integer overflow, but
letting anything go past the end of a buffer usually means I'm not the one who
wrote it, because no matter how obscure the pathological input combination it is
a rake I will digitally step on.

>> Rob
> 
> _____
> 1. i must have offended chrome by saying this, because it crash
> restarted while i was writing this mail. in its defense, chrome is
> _really_ good at recovering its state when it does that, to the point
> where i almost don't care.

Not so much when I have multiple hundreds of tabs open to dubious sites like
oilprice.com where multiple rootkits are trying to fight to see which windows
version you're running, and it tries to reload/reactivate them all instead of
leaving them in a killed state that doesn't eat memory or CPU. (Heck, THAT site
is scummy enough half the time I'm reading it I "switch off wifi" once I've
loaded a half-dozen tabs, which then crash after about 5 minutes and I have to
reconnect to reload the ones I haven't gotten to yet.)

I regularly read the first 20% of long things like
https://nymag.com/intelligencer/2020/11/inside-the-new-york-times-heated-reckoning-with-itself.html
and if I leave them in the background the ads on the page will do random
festering things in the tab as they periodically reload. I've disabled
javascript on a bunch of sites in the chrome config but when I get linked to a
site I don't usually read I just assume it's rootkit city trying to rowhammer
its way into the kernel. (They're generally confused by devuan, but that's not a
_defense_.)

Chrome restarts well for YOU. Restarting for _me_ is a production that can eat
half an hour until I've clubbed it into a malleable stupor again...

> if it would just schedule it and do it at
> 02:30 or whatever i'd probably be better off and happier.

Cron job?

Rob