ANN: DNS resolver changes in yakkety

Stéphane Graber stgraber at ubuntu.com
Tue May 31 21:59:52 UTC 2016


On Tue, May 31, 2016 at 11:33:43PM +0200, Martin Pitt wrote:
> Martin Pitt [2016-05-31 22:45 +0200]:
> > Can you please give a sketch how to look up the source port that the
> > resolver uses? That'd be a good piece of information for the upstream
> > bug report too, as it's not at all obvious.
> 
> Look up, and also how to forge it -- as creating a RAW_SOCKET requires
> root privileges, so I suppose it can be done with a normal UDP socket
> somehow?

You can forge the source port very easily by just calling bind() with
the wanted source port.

The difficulty is with forging the source address. You can use any IP
which the machine already has, but you can't typically use anything
else.


That's why such attacks usually involve a second computer (or container
or VM) on which you have root access and which is attached to the same
subnet as the first. It doesn't need to be in the path (so no MITM),
just to be closed to the target and have a route to it.

As you have root access to that second computer, you can write a tiny
bit of code that runs on it and will send any raw packet that you need.


So if I was to perform such an attack, I'd have a tiny service on my
laptop which listens on a port for a string containing the IP address of
the DNS server to impersonate and its port.

Then I'd have another piece of software on the machine I want to poison
which does the DNS query for the record I want to poison, immediately
looks up the source port and DNS server IP which was used and send those
to my laptop. My laptop then immediately replaces those two in a
pre-generated PCAP containing 32768 UDP packets (one for each of the
transaction IDs) and dumps the generated pcap onto the wire.


This entirely avoids having to go through the whole kernel stack to
generate a real UDP connection. You just dump all 32768 packets into the
network card in one shot.

Then even if it takes a while for the target to process them all, you
are almost guaranteed to have them all ahead of the real reply in the
queue and so have a pretty good chance to indeed poison the cache.


> 
> Thanks!
> 
> Martin

-- 
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20160531/69fe4768/attachment-0001.pgp>


More information about the ubuntu-devel mailing list