| Message ID | 20181219190009.23265-11-simon.k.r.goldschmidt@gmail.com |
|---|---|
| State | Superseded |
| Delegated to: | Tom Rini |
| Headers | show |
| Series | Fix CVE-2018-18440 and CVE-2018-18439 | expand |
tested now v9 with tftp
U-Boot> bd
arch_number = 0x00000000
boot_params = 0x80000100
DRAM bank = 0x00000000
-> start = 0x80000000
-> size = 0x80000000
baudrate = 115200 bps
TLB addr = 0xFFFF0000
relocaddr = 0xFFF9B000
reloc off = 0x7E19B000
irq_sp = 0xFFB96FF0
sp start = 0xFFB96FE0
Early malloc usage: 318 / 4000
fdt_blob = ffb97000
U-Boot> tftp 0xFFF9B000 ${serverip}:files.lst
Using ethernet@1b100000 device
TFTP from server 192.168.0.10; our IP address is 192.168.0.11
Filename 'files.lst'.
Load address: 0xfff9b000
Loading: #
TFTP error: trying to overwrite reserved memory...
U-Boot> tftp 0xFFB96FE0 ${serverip}:files.lst
Using ethernet@1b100000 device
TFTP from server 192.168.0.10; our IP address is 192.168.0.11
Filename 'files.lst'.
Load address: 0xffb96fe0
Loading: #
TFTP error: trying to overwrite reserved memory...
U-Boot>
works so far
a small remark...i can write with mw data to the "protected areas" and bords resets...maybe this should be added in future :) but so far
Tested-By: "Frank Wunderlich" <frank-w@public-files.de>
regards Frank
Am Fr., 21. Dez. 2018, 13:28 hat Frank Wunderlich <frank-w@public-files.de> geschrieben: > tested now v9 with tftp > > U-Boot> bd > arch_number = 0x00000000 > boot_params = 0x80000100 > DRAM bank = 0x00000000 > -> start = 0x80000000 > -> size = 0x80000000 > baudrate = 115200 bps > TLB addr = 0xFFFF0000 > relocaddr = 0xFFF9B000 > reloc off = 0x7E19B000 > irq_sp = 0xFFB96FF0 > sp start = 0xFFB96FE0 > Early malloc usage: 318 / 4000 > fdt_blob = ffb97000 > U-Boot> tftp 0xFFF9B000 ${serverip}:files.lst > Using ethernet@1b100000 device > TFTP from server 192.168.0.10; our IP address is 192.168.0.11 > Filename 'files.lst'. > Load address: 0xfff9b000 > Loading: # > TFTP error: trying to overwrite reserved memory... > U-Boot> tftp 0xFFB96FE0 ${serverip}:files.lst > Using ethernet@1b100000 device > TFTP from server 192.168.0.10; our IP address is 192.168.0.11 > Filename 'files.lst'. > Load address: 0xffb96fe0 > Loading: # > TFTP error: trying to overwrite reserved memory... > U-Boot> > > works so far > > a small remark...i can write with mw data to the "protected areas" and > bords resets...maybe this should be added in future :) but so far > Well, the idea of the CVE was that you can overwrite U-Boot in RAM without actually having access. You "only" need to control the file system or tftp server. When doing 'mw', you actually need to have access to the U-Boot shell. That's a different level. I'm not sure we need to limit access there... > Tested-By: "Frank Wunderlich" <frank-w@public-files.de> > Thanks for testing! Regards, Simon
just a thought, that someone load a script from tftp (scr) which will be executed locally and imho can also contain mw-commands (like my one adding 0-characters). this can be modified from remote... i will not say that this have to be done, just a thought :) for loading from filesystem/fat with modified address there is also the need for local access right? or do you mean that this can be modified (local uenv.txt) from operation system and applied by next reboot? regards Frank Gesendet: Freitag, 21. Dezember 2018 um 13:56 Uhr Von: "Simon Goldschmidt" <simon.k.r.goldschmidt@gmail.com> Well, the idea of the CVE was that you can overwrite U-Boot in RAM without actually having access. You "only" need to control the file system or tftp server. When doing 'mw', you actually need to have access to the U-Boot shell. That's a different level. I'm not sure we need to limit access there...
Am 21.12.2018 um 14:09 schrieb Frank Wunderlich: > just a thought, that someone load a script from tftp (scr) which will be executed locally and imho can also contain mw-commands (like my one adding 0-characters). this can be modified from remote... Well, from a security point of view, you can't just load a script and execut it. The problem with 'load' and 'tftp' is that these are used in secure boot environments to load the next stage (signed FIT image). This next stage must be authenticated before being used, so you can't just instert wrong 'mw' statements into a signed image (as an attacker, I mean). The CVE reported that you can attack a target without having a valid signature just by loading a file that is too big. To me, that's a big difference to the 'mw' case. > > i will not say that this have to be done, just a thought :) > > for loading from filesystem/fat with modified address there is also the need for local access right? or do you mean that this can be modified (local uenv.txt) from operation system and applied by next reboot? No, you just need a big file. E.g. if you have 1GB of RAM, you "just" need to update the file loaded from disk to be 1GB big and you'll overwrite U-Boot for sure (on the next reboot, that is). Regards, Simon > > regards Frank > > > Gesendet: Freitag, 21. Dezember 2018 um 13:56 Uhr > Von: "Simon Goldschmidt" <simon.k.r.goldschmidt@gmail.com> > > Well, the idea of the CVE was that you can overwrite U-Boot in RAM without actually having access. You "only" need to control the file system or tftp server. > > When doing 'mw', you actually need to have access to the U-Boot shell. That's a different level. I'm not sure we need to limit access there... >
diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c index c3c1d2fdfa..329f20c2bf 100644 --- a/arch/arm/lib/bootm.c +++ b/arch/arm/lib/bootm.c @@ -64,13 +64,15 @@ void arch_lmb_reserve(struct lmb *lmb) /* adjust sp by 4K to be safe */ sp -= 4096; for (bank = 0; bank < CONFIG_NR_DRAM_BANKS; bank++) { - if (sp < gd->bd->bi_dram[bank].start) + if (!gd->bd->bi_dram[bank].size || + sp < gd->bd->bi_dram[bank].start) continue; + /* Watch out for RAM at end of address space! */ bank_end = gd->bd->bi_dram[bank].start + - gd->bd->bi_dram[bank].size; - if (sp >= bank_end) + gd->bd->bi_dram[bank].size - 1; + if (sp > bank_end) continue; - lmb_reserve(lmb, sp, bank_end - sp); + lmb_reserve(lmb, sp, bank_end - sp + 1); break; } }
This fixes 'arch_lmb_reserve()' for ARM that tries to detect in which DRAM bank 'sp' is in. This code failed if a bank was at the end of physical address range (i.e. size + length overflowed to 0). To fix this, calculate 'bank_end' as 'size + length - 1' so that such banks end at 0xffffffff, not 0. Fixes: 15751403b6 ("ARM: bootm: don't assume sp is in DRAM bank 0") Reported-by: Frank Wunderlich <frank-w@public-files.de> Signed-off-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com> Reviewed-by: Stephen Warren <swarren@nvidia.com> --- Changes in v9: - fix compile error in arch/arm/lib/bootm.c Changes in v8: - this patch is new in v8 Changes in v7: None Changes in v6: None Changes in v5: None Changes in v4: None Changes in v2: None arch/arm/lib/bootm.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)