From: Daniel Axtens <dja@axtens.net>
To: Vladimir 'phcoder' Serbinenko <phcoder@gmail.com>,
The development of GNU GRUB <grub-devel@gnu.org>
Subject: Re: [PATCH] Remove HFS support
Date: Fri, 02 Sep 2022 00:01:42 +1000 [thread overview]
Message-ID: <87h71rnqgp.fsf@dja-thinkpad.axtens.net> (raw)
In-Reply-To: <CAEaD8JMPR9qrnVueUY=WQGpPP1Y_wOkYF4mTQ9+iQpPdMww-3A@mail.gmail.com>
"Vladimir 'phcoder' Serbinenko" <phcoder@gmail.com> writes:
> Le ven. 26 août 2022, 15:47, Daniel Axtens <dja@axtens.net> a écrit :
>
>> Let me answer this out of order.
>>
>> > I understand the need to sometimes get rid of old code, but since the HFS
>> > module can be blacklisted as Vladimir explains, I don't really understand
>> > the reasoning in this particular case.
>>
>> I want _all_ grub code to reach a minimum standard of not crashing or
>> corrupting memory in the presence of malicious input. HFS does not reach
>> that standard.
>>
> That is a very high standard. Products with a huge security team like
> Chrome don't reach this standard. It's reasonable that you submit the
> improvements. Also it's reasonable for you to blacklist code that gets in
> the way of security. E.g. all compressors that are not used should be
> blacklisted.
ext and fat file systems (and several other more obsure file systems)
and all our image parsers reach this standard, best as I can tell. As
far as I can tell the grub IPv4 networking stack does too, although I am
not as certain that my coverage was very thorough.
Several of us are actively working to get all of grub to this
standard. grub is a lot simpler than Chrome, so I am optimistic.
>> If you or someone else (someone from Gentoo, perhaps?) want make it fuzz
>> clean, then that'd be great. If no-one is able to bring it up to what is
>> *not* an especially high standard, then it should be considered
>> abandoned by developers and therefore removed.
>>
> Show me the fuzzes that create problems and I'll improve the code
The following two files cause crashes on stock grub-fstest
stack overflow (unbounded recursion): files.intermittent.network/grub/hfs.stack-overflow
stack buffer overflow -> eventual segv: files.intermittent.network/grub/hfs.stack-buffer-overflow
There are an additional set of files that cause crashes when grub is
compiled with ASAN:
files.intermittent.network/grub/hfs.tar.xz (18MB, 210MB uncompressed)
There are 222 files. The corpus is not de-duplicated (there are not
222 unique bugs) and includes the two files called out above, plus
other some different heap buffer overflows.
I compile grub with ASAN using:
ASAN_OPTIONS=detect_leaks=0 make CFLAGS="-fsanitize=address" -j8
Modern gcc works fine. grub-emu will fail to link, but grub-fstest
should build fine.
In all cases, the crashes reproduce with:
./grub-fstest <file> ls '(loop0)/'
Good luck, the stack-overflow one in particular looks especially
painful.
I will leave your other points for others to address.
Kind regards,
Daniel
next prev parent reply other threads:[~2022-09-01 14:01 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-19 13:38 [PATCH] Remove HFS support Daniel Axtens
2022-08-19 13:57 ` Daniel Kiper
2022-08-19 14:03 ` John Paul Adrian Glaubitz
2022-08-19 17:57 ` Vladimir 'phcoder' Serbinenko
2022-08-20 14:23 ` Daniel Axtens
2022-08-19 18:09 ` Steve McIntyre
2022-08-19 18:38 ` John Paul Adrian Glaubitz
2022-08-19 19:04 ` Dimitri John Ledkov
2022-08-19 19:45 ` Vladimir 'phcoder' Serbinenko
2022-08-20 14:05 ` Daniel Axtens
2022-08-24 7:17 ` John Paul Adrian Glaubitz
2022-08-24 7:16 ` John Paul Adrian Glaubitz
2022-08-20 14:13 ` Daniel Axtens
2022-08-19 19:01 ` Vladimir 'phcoder' Serbinenko
2022-08-26 15:46 ` John Paul Adrian Glaubitz
2022-08-26 17:02 ` Vladimir 'phcoder' Serbinenko
2022-08-20 13:53 ` Daniel Axtens
2022-08-24 7:21 ` John Paul Adrian Glaubitz
2022-08-26 13:31 ` Daniel Axtens
2022-08-26 15:17 ` Vladimir 'phcoder' Serbinenko
2022-08-30 18:28 ` Robbie Harwood
2022-09-01 14:01 ` Daniel Axtens [this message]
2022-08-26 15:27 ` John Paul Adrian Glaubitz
2022-08-30 16:37 ` Robbie Harwood
2022-08-30 17:21 ` John Paul Adrian Glaubitz
2022-08-30 18:43 ` Robbie Harwood
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87h71rnqgp.fsf@dja-thinkpad.axtens.net \
--to=dja@axtens.net \
--cc=grub-devel@gnu.org \
--cc=phcoder@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.