[<prev] [next>] [day] [month] [year] [list]
Date: Thu, 30 Sep 2021 23:01:37 +0200
From: Philipp Takacs <philipp+enjoy-digital@...eaucracy.de>
To: oss-security@...ts.openwall.com
Cc: florent@...oy-digital.fr
Subject: security issues in Litex IP stack
Hi
I have found some security issues by a code review of litex[0]. The
issues where reported to Enjoy-Digital on 21.02.2021 but not fixed yet.
I haven't tested, if these issues are exploitable.
1. oob read over IP/UDP length
The IP/UDP implementation only checks if the receive data and declared
sizes are big enough to contain a full UDP header. An attacker can set
this to 0xffff, which leads to an out of bound read. (see rx_callback()
in tftp.c and process_ip() in udp.c)
2. out of bounds write
In boot.c tftp_get() is called with "char json_buffer[1024]" as buffer.
Because of missing bound checks in tftp_get() an attacker can overflow
this buffer (see rx_callback() in tftp.c and netboot_from_json() in bios.c).
3. sender check
The tftp client don't check if the packages are from the sender he
requested data. If an attacker sends faster then the requested tftpd, he
can completely control the data.
4. tftp total_length overflow
May only be a theoretical bug, because the result is checked against <= 0.
But if an attacker uses the missing IP/UDP length check he can overflow
the total_length in rx_callback() (see tftp.c).
5. override already received data
The tftp client don't check if he receives data multiple times. An attacker
can send a block the client has already received and override it.
6. arp cache poisoning
It looks like it's possible to just send an arp reply to override the
mac address of the tftp server (see process_arp() in udp.c).
Philipp Takacs
[0] https://github.com/enjoy-digital/litex
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
