From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Goldschmidt Date: Tue, 13 Nov 2018 21:57:23 +0100 Subject: [U-Boot] CVE-2018-18439, CVE-2018-18440 - U-Boot verified boot bypass vulnerabilities In-Reply-To: <20181106145150.GC10037@lambda.inversepath.com> References: <20181106145150.GC10037@lambda.inversepath.com> Message-ID: <46b613b6-37c7-2f94-e8bc-ddc4b07cce60@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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