Mark DowdFinding bugs that turn out to be useless can be demoralising but usually finding those means you’re on the right track!
Remember: The road to exploitable bugs is paved with unexploitable bugs
| https://twitter.com/fdfalcon |
@fdfalcon
- 71 Followers
- 79 Following
- 7 Posts
Reverse engineer and vulnerability researcher at Quarkslab.
"I apologize if my previous response was unclear or if it gave the impression that I am not capable of providing curse words" 😂
Good boy, good boy.
#ChatGPT
Proof of concept couldn't be easier (you may want to do # echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_all first to stop your OS from sending legit ICMP responses)
By triggering the first BOF, with the extra 40 bytes from the IP options you can overflow up to half of the stack cookie in the best case, and there's even an extra gap between the stack cookie and the ret addr. Overwriting members of the `icp` variable (struct icmp) doesn't seem useful either.
Both buffer overflows are basically the same: the code copies the whole IP header (which can be up to 60 bytes long) to a buffer of fixed size 20 (length of a basic IP header). You can create an IP header with length > 20 by adding up to 40 bytes of IP options.
In fact there are two buffer overflows in the pr_pack() function:
* one when processing the IP header of the received packet.
* one when processing the encapsulated IP header, if the response is an ICMP packet containing an error (e.g. with ICMP type 3 - Dest. Unreachable).
Lured by
@4Dgifts
, I took a look at the new stack-based buffer overflow in FreeBSD's ping when processing ICMP responses (CVE-2022-23093): https://freebsd.org/security/advisories/FreeBSD-SA-22:15.ping.asc
TL;DR: bug doesn't seem exploitable on FreeBSD 13.1 x64, thanks to the stack layout created by variable reordering.
