"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
| https://twitter.com/fdfalcon |
@fdfalcon
- 71 Followers
- 79 Following
- 7 Posts
Reverse engineer and vulnerability researcher at Quarkslab.
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.
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.
