Date: Thu, 1 Dec 2022 10:27:44 -0500 From: mike tancsa <mike@sentex.net> To: Brooks Davis <brooks@freebsd.org> Cc: Dev Null <devnull@apt322.org>, freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-22:15.ping Message-ID: <4ce47f73-c48f-22f6-e0c0-0bd03452bcda@sentex.net> In-Reply-To: <20221130223855.GA89753@spindle.one-eyed-alien.net> References: <20221130004601.043CE1C623@freefall.freebsd.org> <3dc86282-165d-8562-5cba-0da9896557b9@sentex.net> <e9a7b2ca-a4a4-5b99-f915-0db46b60d1e8@apt322.org> <2b590fd0-8b02-1344-d501-005c6cd9fb8f@sentex.net> <20221130223855.GA89753@spindle.one-eyed-alien.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 11/30/2022 5:38 PM, Brooks Davis wrote: > It's probably also worth considering it as a local privilege escalation > attack. The attacker will need to control a ping server, but it's often > the case that enough ICMP traffic is allowed out for that to work and in > that case they have unlimited tries to defeat any statistical mitigations > (unless the admin spots all the ping crashes). My concern is the "evil server in the middle" ... Things like route highjacking are not that uncommon. I have a number of IoT devices out there I will need to patch, some still based on RELENG_11. The patch doesnt apply cleanly, but looking at the source code, there are a bunch of spots where #ifdef IP_OPTIONS If I put on the top of sbin/ping.c undef IP_OPTIONS will the code that is problematic get compiled out and avoid the issue ? ping.c:#ifdef IP_OPTIONS ping.c:#ifdef IP_OPTIONS ping.c: if (setsockopt(ssend, IPPROTO_IP, IP_OPTIONS, rspace, ping.c: err(EX_OSERR, "setsockopt IP_OPTIONS"); ping.c:#endif /* IP_OPTIONS */ For now, I would rather push a patched ping which I can do quickly to a few hundred devices ---Mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4ce47f73-c48f-22f6-e0c0-0bd03452bcda>