Skip site navigation (1)Skip section navigation (2)
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>