[U-Boot] [PATCH v5 0/9] Fix CVE-2018-18440 and CVE-2018-18439

Fri Dec 14 13:27:26 UTC 2018

On Fri, Dec 14, 2018 at 02:06:38PM +0100, Simon Goldschmidt wrote:
> On Tue, Dec 11, 2018 at 10:05 PM Simon Goldschmidt
> <simon.k.r.goldschmidt at gmail.com> wrote:
> >
> > Am 11.12.2018 um 21:10 schrieb Tom Rini:
> > > On Tue, Dec 11, 2018 at 04:19:44PM +0100, Simon Goldschmidt wrote:
> > >> Hi Tom,
> > >>
> > >> [truncated the CC list a bit since I got "too many recipients" errors last
> > >> time]
> > >>
> > >> Am 11.12.2018 um 14:31 schrieb Tom Rini:
> > >>> On Sun, Dec 09, 2018 at 09:45:13PM +0100, Simon Goldschmidt wrote:
> > >>>
> > >>>> This series fixes CVE-2018-18440 ("insufficient boundary checks in
> > >>>> filesystem image load") by adding restrictions to the 'load'
> > >>>> command and fixes CVE-2018-18439 ("insufficient boundary checks in
> > >>>> network image boot") by adding restrictions to the tftp code.
> > >>>> The functions from lmb.c are used to setup regions of allowed and
> > >>>> reserved memory. Then, the file size to load is checked against these
> > >>>> addresses and loading the file is aborted if it would overwrite
> > >>>> reserved memory.
> > >>>>
> > >>>> The memory reservation code is reused from bootm/image.
> > >>>
> > >>> So, thanks for doing all of this.  I'm sorry to dump a few problems on
> > >>> you now however.  First, we have a lot of fail to builds:
> > >>> https://travis-ci.org/trini/u-boot/builds/466333708
> > >>
> > >> Ok, I'll check those. At first sight, the build errors seem to be identical
> > >> in that 'fdt_get_resource' is missing. I'll check that config option.
> >
> > The function 'fdt_get_resource' was the only match that I could find to
> > decode register address + size from fdt. However, it resides in
> > 'lib/fdtdec.c' which is only linked for OF_CONTROL. This seems strange
> > as it is a read-access function to a dts and it can be used when
> > booting, too. What would be the way to go here, move this to a different
> > file or compile 'lib/fdtdec.c' depending on CONFIG_FIT or something?
> >
> > 2nd fail seems to be in 'test/py' tests. I'll dig into that, too.
> >
> > >>
> > >>> Second, giving this a run-time test on Raspberry Pi 3 (aarch64 mode) and
> > >>> trying to boot a regular Linux distro (this example is OpenEmbedded
> > >>> based but generic issue, boot.scr just loads Image to $loadaddr and
> > >>> booti's):
> > >>> U-Boot> run bootcmd
> > >>> switch to partitions #0, OK
> > >>> mmc0 is current device
> > >>> Scanning mmc 0:1...
> > >>> Found U-Boot script /boot.scr
> > >>> 389 bytes read in 2 ms (189.5 KiB/s)
> > >>> ## Executing script at 02000000
> > >>> 13298176 bytes read in 701 ms (18.1 MiB/s)
> > >>> ## Flattened Device Tree blob at 2effb500
> > >>>     Booting using the fdt blob at 0x2effb500
> > >>> ERROR: Failed to allocate 0x7ab5 bytes below 0xffffffff.
> > >>> Failed using fdt_high value for Device TreeFDT creation failed! hanging...### ERROR ### Please RESET the board ###
> > >>>
> > >>> Switching the board to using bootm_size rather than
> > >>> initrd_high/fdt_high=0xffffffff does resolve the issue and I can boot,
> > >>> but it's still a case we need to fix.  Thanks!
> > >>
> > >> Thanks for testing! Of course it's a case we need to fix! Would it be
> > >> possible for you to do this run-time test again with the attached patch that
> > >> enables DEBUG in lmb.c and dumps 'lmb' contents in the error case shown
> > >> above?
> > >
> > > Here.  Note that I'm sure you can replicate this anywhere by setting
> > > initrd_high / fdt_high to 0xffffffff.
> >
> > OK, thanks for this additional output. I cannot reproduce this in the
> > tests though. I'll have to check this with my hardware probably, but I
> > hope it's not related to 64 bit...
> >
> > Regards,
> > Simon
> >
> > > U-Boot> run bootcmd
> > > switch to partitions #0, OK
> > > mmc0 is current device
> > > Scanning mmc 0:1...
> > > Found U-Boot script /boot.scr
> > > lmb_dump_all:
> > >      memory.cnt                  = 0x1
> > >      memory.size                 = 0x0
> > >      memory.reg[0x0].base   = 0x0
> > >                  .size   = 0x3b400000
> > >
> > >      reserved.cnt        = 0x2
> > >      reserved.size       = 0x0
> > >      reserved.reg[0x0].base = 0x0
> > >                    .size = 0x1000
> > >      reserved.reg[0x1].base = 0x3af46e50
> > >                    .size = 0x4b91b0
> > > 389 bytes read in 28 ms (12.7 KiB/s)
> > > ## Executing script at 02000000
> > > lmb_dump_all:
> > >      memory.cnt                  = 0x1
> > >      memory.size                 = 0x0
> > >      memory.reg[0x0].base   = 0x0
> > >                  .size   = 0x3b400000
> > >
> > >      reserved.cnt        = 0x2
> > >      reserved.size       = 0x0
> > >      reserved.reg[0x0].base = 0x0
> > >                    .size = 0x1000
> > >      reserved.reg[0x1].base = 0x3af46a20
> > >                    .size = 0x4b95e0
> > > 13298176 bytes read in 746 ms (17 MiB/s)
> > > ## Flattened Device Tree blob at 2effb500
> > >     Booting using the fdt blob at 0x2effb500
> > > ERROR: Failed to allocate 0x7ab5 bytes below 0xffffffff.
> 
> Tom, this looks strange. You said you're running this in 64-bit mode
> but here, fdt_high seems to be all ones in the lower 32 bit only.
> That's probably because you're running both 32bit and 64bit on the
> same target and that 'fdt_high' value got loaded with the environment?

Yes, that's right.  I run this Pi in both 32 and 64bit mode and the
saved environment is from the 32bit side and fdt_high/initrd_high are,
hah, oops, wrong.

> Anyway, this was the reason I haven't found it. I did find it now and
> it's a bug that's been in lmb.c like forever. I'll send a v6 soon.

Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20181214/9c297b22/attachment.sig>