Date: Fri, 26 Jun 1998 09:38:33 -0400 (EDT) From: andrewr <andrewr@slack.net> To: Bill Fenner <fenner@parc.xerox.com> Cc: Nate Lawson <nate@almond.elite.net>, nate@elite.net, julian@whistle.com, freebsd-bugs@FreeBSD.ORG, freebsd-net@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: Apparent bug in sendto() with raw sockets Message-ID: <Pine.NEB.3.96.980626092922.1974A-100000@brooklyn.slack.net> In-Reply-To: <98Jun25.155535pdt.177515@crevenia.parc.xerox.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
actual IP address defined for the outgoing interface. While looking for a
quick hack to get the interface ip, I was looking through ip_output.c and
saw a neat little algo there. While I have not tested this yet, I will in
the next couple of days, I figure it should be a pretty fail safe block
against spoofing IF AND ONLY IF the user has not created there own data
structure, ie.
struct raw_pkt_hdr {
struct ip ip;
struct udphdr udp;
} raw_pkt_hdr;
This will be an easy work around for the user to spoof packets. In my
opinion, while I don't see how it can be done, I believe there should be a
way to test for a user defined data structure containing the IP header,
etc.. From my speaking with a few FreeBSD kernel developers/hackers this
is not possible, and I fully see why it is not.. but, I am just throwing
the idea out into the open for all of you to digest.
Andrew
*****************************************
AWR XNS, Inc.
<andrewr@slack.net>
"Drink beer, it will save your life."
On Thu, 25 Jun 1998, Bill Fenner wrote:
> In message <199806252220.PAA28609@almond.elite.net> you write:
> >I know that 2.0.5R behaved the way that OpenBSD and Linux behave. Were there
> >any complaints or problems with it back then?
>
> It didn't. The code in FreeBSD is almost exactly the same as when
> IP_HDRINCL was introduced in 4.3-Reno. The change that caused
> more recent versions of FreeBSD to return EINVAL was that it
> started checking the validity of the length field and returns
> EINVAL if the IP length is longer than the length of the buffer
> that was provided.
>
> I had tossed around the idea of a socket option to switch behaviors,
> for both input and output, but decided it would be relatively wasted
> effort; if you can conditionally set a socket option you can also
> conditionally (fail to) byte-swap the appropriate fields.
>
> Bill
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-bugs" in the body of the message
>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96.980626092922.1974A-100000>