[U-Boot] CVE-2018-18439, CVE-2018-18440 - U-Boot verified boot bypass vulnerabilities
Simon Goldschmidt
simon.k.r.goldschmidt at gmail.com
Tue Nov 13 20:57:23 UTC 2018
On 06.11.2018 15:51, Andrea Barisani wrote:
> [..]
> The issue can be exploited by several means:
>
> - An excessively large crafted boot image file is parsed by the
> `tftp_handler` function which lacks any size checks, allowing the memory
> overwrite.
>
> - A malicious server can manipulate TFTP packet sequence numbers to store
> downloaded file chunks at arbitrary memory locations, given that the
> sequence number is directly used by the `tftp_handler` function to calculate
> the destination address for downloaded file chunks.
>
> Additionally the `store_block` function, used to store downloaded file
> chunks in memory, when invoked by `tftp_handler` with a `tftp_cur_block`
> value of 0, triggers an unchecked integer underflow.
>
> This allows to potentially erase memory located before the `loadAddr` when
> a packet is sent with a null, following at least one valid packet.
Do you happen to have more details on this suggested integer underflow?
I have tried to reproduce it, but I failed to get a memory write address
before 'load_addr'. This is because the 'store_block' function does not
directly use the underflowed integer as a block counter, but adds
'tcp_block_wrap_offset' to this offset.
To me it seems like alternating between '0' and 'not 0' for the block
counter could increase memory overwrites, but I fail to see how you can
use this to store chunks at arbitrary memory locations. All you can do
is subtract one block size from 'tftp_block_wrap_offset'...
Simon
More information about the U-Boot
mailing list