netdev - Re: ip_nonlocal_bind and sendto (fwd)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <alpine.DEB.1.10.0902271405180.26625@asgard.lang.hm>
Date:	Fri, 27 Feb 2009 14:07:27 -0800 (PST)
From:	david@...g.hm
To:	Arnaldo Carvalho de Melo <acme@...hat.com>
cc:	netdev@...r.kernel.org
Subject: Re: ip_nonlocal_bind and sendto (fwd)

On Fri, 27 Feb 2009, david@...g.hm wrote:

> On Fri, 27 Feb 2009, Arnaldo Carvalho de Melo wrote:
>
>> Em Fri, Feb 27, 2009 at 01:20:07AM -0800, david@...g.hm escreveu:
>>> I've got a need to forge the source IP of UDP packets (a stupid syslog
>>> receiver app that I need to deal with)
>>> 
>>> I know that this can be done with raw sockets, but with the
>>> IP_nonlocal_bind option I thought that it may be possible to do this
>>> without dealing with raw sockets
>>> 
>>> so I have an app that does the socket call, followed by the bind call
>>> without any errors, but when I issue the sendto call it generates error
>>> 22 (invalid parameter) if the source IP doesn't exist on the local box
>>> somewhere.
>>> 
>>> is this the kernel that is doing whatever check is failing? or is glibc
>>> wrapping the kernel syscall and doing some additional checking?
>>> 
>>> if it is the kernel that's throwing the error, is there some way of
>>> disabling this check? or do I have to go to raw sockets?

Ok, I tried seperating out the connect from the send, and an strace is 
giving me the following sequence

socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 3
setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
fcntl(3, F_GETFL)                       = 0x2 (flags O_RDWR)
fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK)    = 0
bind(3, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("10.201.7.174")}, 16) = 0
connect(3, {sa_family=AF_INET, sin_port=htons(514), sin_addr=inet_addr("10.201.7.101")}, 16) = -1 EINVAL (Invalid argument)
sendto(3, "<13>Feb 27 14:04:16 secdev5 dlang"..., 39, 0, NULL, 0) = -1 EDESTADDRREQ (Destination address required)

so this seems to clearly be saying that it's not willing to accept that IP 
source/destination combination.

why not?

David Lang


>> Follow:
>> 
>> udp_sendmsg
>>    ip_route_output_flow
>>        __ip_route_output_key
>> 
>> And then look at this line:
>>
>> 	rth->fl.fl4_src == flp->fl4_src &&
>> 
>> It'll fail and so another function will be called:
>>
>> 	    ip_route_output_slow
>> 
>> Many, many details later, this comment:
>>
>>                           Because we are allowed to send to iface
>>                           even if it has NO routes and NO assigned
>>                           addresses. When oif is specified, routing
>>                           tables are looked up with only one purpose:
>>                           to catch if destination is gatewayed, rather than
>>                           direct. Moreover, if MSG_DONTROUTE is set,
>>                           we send packet, ignoring both routing tables
>>                           and ifaddr state. --ANK
>> 
>> So try using:
>> 
>> setsockopt(udp_sock, SOL_SOCKET, SO_BINDTODEVICE, "eth0", 5);
>> 
>> Replacing "eth0" with the interface you want your forged packets to fly by.
>> 
>> The device name will be transformed into an index and stored in
>> sk->sk_bound_dev_if, that later, at udp_sendmsg time, will get stashed into
>> that oif field and then that comment will hold.
>> 
>> Caveat emptor: I never tried this, this is just after 5 minutes code 
>> inspection 8)
>
> this did not work.
>
> I didn't really expect it to because routing should only look at the 
> destination address in the packet, so the source address shouldn't matter.
>
> to clarify
>
> the syslog server I am sending to is on my local subnet, I can send messages 
> to it normally.
>
> I am needing to relay syslog messages I have received from another machine to 
> this syslog server, but forge the source IP address to make it look to the 
> syslog server like the packet initiated from the remote machine instead of 
> the syslog relay.
>
> David Lang
>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html