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

[enh]

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. (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.)

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].

> My (often battery-powered) laptop has the xfce cpu meter with 4 vertical bar
> graphs and a horizontal line graph and when a chrome tab persistently uses CPU I
> find it with "top" and kill the "renderer" instance. (Which on modern chrome
> will sometimes make the locking unhappy so a tab doesn't acknowledge input even
> to scroll up and down, the fix to which is ctrl-w ctrl-shift-t to kill and
> reopen it...)
>
> I'll leave it doing something cpu intensive (such as an AOSP build or rebuilding
> the musl-cross-make toolchains) overnight, but if it's not done in the morning
> it gets suspended or killed...
>
> (Hey, this laptop is almost twice as expensive as my netbook was. The Dell e6230
> was hot stuff in 2012, and when I got it last year I upgraded the memory as far
> as it would go and broke down and got a 2tb ssd.)
>
> >> 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.)

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.

> 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. if it would just schedule it and do it at
02:30 or whatever i'd probably be better off and happier.