rtl8139 Network Card Driver Out-of-bounds Read #348
Assignees
Comments
Merged
bors bot
added a commit
that referenced
this issue
Feb 7, 2022
356: RTL: RAII buffers r=stlankes a=mkroening This addresses #348. I replaced the manual pointer arithmetic with boxed slices which contain bounds checks (no unsafe code accessing the buffers in the driver now). Now reading outside the buffers through manipulated lengths should be impossible. It is still possible to access the other network packages in the buffers. I am not sure about the architecture of the network driver and where to get the corresponding lengths from, which might or might not require a bigger rework. `@lrapp-x41-pub,` would you consider this enough for closing #348 or would that require to properly avoid accessing all of the buffer? While working on this I found #355. Co-authored-by: Martin Kröning <mkroening@posteo.net>
|
Closed by #356 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The rtl8139 network card driver contains an out-of-bounds read vulnerability inside the
receive_rx_buffer()function which parses the packet coming from the network card firmware.The problem is that the length value read from the packet length field is blindly trusted without any further checks.
https://github.com/hermitcore/libhermit-rs/blob/f5408c23771eb37f0be57986db19ca9d0d290cf7/src/drivers/net/rtl8139.rs#L274-L275
A corrupted (the CRC is never checked!) or actively manipulated length value would cause the function to return a slice which contains bytes that do not belong to the packet payload anymore. As the length is not restricted to the ring buffer size this does not only affect the other network packages inside the ring buffer, but also the bytes placed in the memory behind the ring buffer.
https://github.com/hermitcore/libhermit-rs/blob/f5408c23771eb37f0be57986db19ca9d0d290cf7/src/drivers/net/rtl8139.rs#L278-L284
In order to exploit the vulnerability, an attacker would have to control the package’s length field and thus the (emulated) rtl8139 on-chip firmware, which is relatively unlikely (if the attacker controls the host, we are lost anyway). Nevertheless an exploit for this vulnerability could be chained with other potential exploits and should be fixed for an in-depth security approach.
The text was updated successfully, but these errors were encountered: