public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
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

  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