Date: Fri, 26 Jun 1998 13:18:29 -0700 (PDT) From: Nate Lawson <nate@almond.elite.net> To: andrewr@slack.net (andrewr) Cc: Pierre.Beyssac@hsc.fr, fenner@parc.xerox.com, nate@elite.net, julian@whistle.com, freebsd-bugs@FreeBSD.ORG, freebsd-net@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: sendto()/raw sockets and now spoofing Message-ID: <199806262018.NAA08152@almond.elite.net> In-Reply-To: <Pine.NEB.3.96.980626131259.3414A-100000@brooklyn.slack.net> from "andrewr" at Jun 26, 98 01:13:39 pm
next in thread | previous in thread | raw e-mail | index | archive | help
>On Fri, 26 Jun 1998, Pierre Beyssac wrote: >> On Fri, Jun 26, 1998 at 09:38:33AM -0400, andrewr wrote: >> > Speaking of IP_HDRINCL, after reading raw_ip.c and noticing the protection >> > against spoofing (can't use IP_HDRINCL in certain situations), I started >> > thinking about actually comparing the user dsupplied ip->ip_src with the >> >> Are you sure you're talking about FreeBSD here ? SunOS 4 has such >> a protection (it checks that the source address belongs to one of >> the interfaces, or so it seems) but I've successfully spoofed >> packets on FreeBSD without any problem using IP_HDRINCL. >> >> Anyway, such a protection can easily bypassed by sending raw >> link-level packets through bpf (or probably /dev/nit in the case >> of SunOS, although I've never tried this). > >I too have spoofed packets under FreeBSD, I am just noting somethings that >might want to be changed. The whole point of IP_HDRINCL is to allow the (privileged) user to supply their own IP header. There should be no code to prevent spoofing because it is quite necessary to be able to write arbitrary parts of the IP header. A DHCP server is a perfect example of a program that must "spoof" its source address. How far do you start to go with this crusade? Do you then go on and verify ip_id is appropriate? What about making sure ip_p isn't equal to ANY of the known protocols since they are accessible through the ordinary sockets interface? If you put the checks in sendto(), I'll be forced to use BPF for my tools. If you put the checks in BPF too, I'll be forced to include an LKM that patches your BPF which ... An operating system provides a layer of abstraction from the hardware that provides protection -- you have this understanding right. But when a properly authenticated and privileged user (root in this case) uses an OS mechanism, IP_HDRINCL, to circumvent these checks, that user takes responsibility for the behavior of his code by explicitly forgoing the normal OS checks. This is the part you were missing. -Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199806262018.NAA08152>