From: Patrick Wildt <patrick@blueri.se>
To: u-boot@lists.denx.de
Subject: efi_loader: tighten PE verification code?
Date: Sun, 10 May 2020 23:00:35 +0200 [thread overview]
Message-ID: <20200510210035.GA12596@nox.fritz.box> (raw)
In-Reply-To: <CAPnjgZ012UWhpRZ3UA--uGsusVuD1usWyQ5JTEKS5PdYU3psGg@mail.gmail.com>
On Sun, May 10, 2020 at 02:36:51PM -0600, Simon Glass wrote:
> Hi Patrick,
>
> On Fri, 8 May 2020 at 12:56, Patrick Wildt <patrick@blueri.se> wrote:
> >
> > Hi,
> >
> > even though this mail has a diff, it's not supposed to be a patch. I
> > have started adjusting my fuzzer to the upstreamed EFI Secure Boot code
> > and I hit a few issues right away. Two of those I have already sent and
> > were reviewed. I have seen more, but since I needed to reschedule some
> > things I couldn't continue and unfortunately have to postpone fuzzing
> > the code. I can assure you if someone starts fuzzing that code, we will
> > find a few more bugs.
> >
> > Especially since this is "Secure Boot", this part should definitely be
> > air tight.
> >
> > One thing I saw is that the virt_size is smaller then the memcpy below
> > at the "Copy PE headers" line then actually copies.
> >
> > Another thing I saw is SizeOfRawData can be bigger then the VirtualSize,
> > and PointerToRawData + SizeOfRawData bigger then the allocated size.
> >
> > I'm not sure if this is the right place to do the checks. Maybe they
> > need to be at the place where we are adding the image regions. I guess
> > the fields should be properly verified in view of "does it make sense?".
> >
> > Also I'm questioning whether it's a good idea to continue parsing the
> > file if it's already clear that the signature can't be verified against
> > the "db". I can understand that you'd like to finish loading the file
> > into an object, and some other instance decides whether or not it's fine
> > to start that image, but you also open yourself to issues when you're
> > parsing a file that obviously is against the current security policy.
> >
> > If you keep on parsing a file that obviously (because tested against the
> > "db") cannot be allowed to boot anyway, the checks for the headers need
> > to be even tighter.
> >
> > I'd be unhappy to see U-Boot CVEs come up regarding PE parsing issues.
> >
> > Best regards,
> > Patrick
>
> Can I suggest adding some more unit tests?
>
> Regards,
> Simon
Hi,
It's a good suggestion. Now it only needs someone with enough time to
actually do it. :-) I'll come back to this in a few weeks when my
current project becomes quieter. I wish I could right now.
Regards,
Patrick
next prev parent reply other threads:[~2020-05-10 21:00 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-08 18:56 efi_loader: tighten PE verification code? Patrick Wildt
2020-05-10 20:36 ` Simon Glass
2020-05-10 21:00 ` Patrick Wildt [this message]
2020-05-11 2:27 ` AKASHI Takahiro
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=20200510210035.GA12596@nox.fritz.box \
--to=patrick@blueri.se \
--cc=u-boot@lists.denx.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox