The Recurity Lablog

... I feel compelled to point at Derek Soeder's VMware Emulation Flaw x64 Guest Privilege Escalation (1/2) post at full disclosure. It seems that it's always the same names that come up with those beautiful exploits. Delighting.

I recently discovered that there seems to be this class of discoveries that is made independently by many people from the same community in roughly the same timeframe. What's interesting about this class of discoveries is that often they are not published. Everyone seems to assume (correctly) that others have discovered the same. One topic that certainly falls in this category is “return oriented programming”, which everyone I know invented on their own once they actually needed it. Finally, at BlackHat USA this year, academia in the names of Erik Buchanan, Shawn Moyer, Ryan Roemer and Stefan Savage took this concept and turned it into solid research. Conceptually no news, it's highly recommended reading for anyone who used this method before, as approach and execution are brilliant.

The second instance of that class this year is TCP connections that don't use the operating system's sockets. If you ever wrote networking attack tools using raw sockets or drivers, you have come across the idea and probably tried it out. The basic idea is that you don't need to keep any state as the TCP client. You can send as many SYN packets as you want and can reply with the final ACK once the SYN/ACK packet comes back. All the information you need is in the answer from the server. You can take this method one packet further and actually send the first payload packet as well, e.g. an HTTP GET request. Check out Dennis' blog post if you need a picture of this.

TCP server software is in most cases written around the accept() call, which blocks until the OS has received the final handshake packet. Once that happens, the accept() call returns and the server software starts handling the connection. If you had sent the first payload packet as well, the server software even goes into the state of processing a request. Many servers are not built to handle the case where they no longer have any communication partner (i.e. they don't time out quickly), and the rate in which they get new ones usually overwhelms the server as well as the OS. On top of it, TCP, being a reliable protocol, tries to keep the connection alive by resending the answers because it assumes lost packets. The attacker can make this worse by playing with some properties of TCP, e.g. the window size, or add other twists to it, like ignoring RST packets or sending out-of-band packets with the PSH flag. Bottom line is, it really depends on the kernel and the server software what happens after the handshake is completed, but the issue is the same all over the place. Side note: things that don't implement a proper common TCP/IP stack fail more miserably, ask people at Cisco.

After I played with this in 2002, I became aware of many earlier implementations, e.g. this one, that one and many others. I recently remembered all that when I met Jack and Robert at the Sec-T conference in Stockholm (side note: great conference, watch for their 2009 edition). We compared notes on what things reacted how when exposed to stateless TCP clients hitting them hard. While it is relatively easy to protect server implementations by limiting the number of concurrent requests served, and operating systems by limiting kernel buffers and number of connections from a single source, so-called security devices and code are entirely different stories. Back in the days, my own Linux kernel gave me problems as ip_contrack, part of the NAT code, kept killing my TCP/IP stack as it tried to keep track of the connections I created, despite the fact that neither firewall nor NAT were actually enabled. I had to remove it from my own kernel before I could perform the attack against other devices.

Today's networks are full of devices whose vendors think it's a good idea to track established TCP/IP connections. IDS and IPS systems are just the tip of the iceberg. Just about every firewall, NAT device, TCP load balancer, transparent proxies and even some network sniffers do it. That's certainly not smart. You should try to avoid tracking state of others you don't control, especially if you don't actually need to. But the ignorance of basic principles and prior work is unfortunately not that uncommon.

It should however be clear that the risk of falling victim to this attack is inherent to offering a service. When you get a phone and publish the phone number, anyone can call you. It is not possible to prevent strangers from calling you every five minutes in the middle of the night when you want to be reachable to people that you have not authorized before. Ask any call center or ask people who run a web server that got slashdoted. If you want others to be able to contact you, they can overwhelm you with contacts. If you open your shop's doors, people can come in and buy stuff, but you could also have a flash mop filling your space. You could post bouncers at your door, but that's neither friendly nor helpful.

It should also be noted that this attack is not stealthy at all. No matter if you use your regular operating system's sockets or a raw and stateless TCP/IP implementation to establish a connection; you cannot spoof your IP address unless you sit on the transit route of the legitimate owner (in which case you can do a lot more). I think the scenario of the low-bandwidth customer at home taking down important servers using full handshakes is less likely. In most cases, his DSL home router would die first. Almost all other scenarios have the same effect to the victim as if he is attacked by a regular DDoS attack today: It's always possible but there are mitigations. The easiest mitigation for stateless TCP clients is to limit the amount of connections from a single source address and get rid of useless connection tracking devices in between.

And if the attacker is located in Germany, he will end up in jail. The much contested change to §303b of the StGB, Germany's criminal law, says: Interference with a data processing system that is of importance to someone else, by committing a crime described in §303a, by entering or sending data with the intention to cause a disadvantage to the system or [...], will be punished with jail up to 3 years or a monetary fine. The jail time can be up to 5 years if the affected system belongs to a company or the government. Therefore, completing too many TCP handshakes is illegal in Germany.

I'm looking forward to Jack and Robert publishing their full findings, as I'm sure it will provide much entertainment to the security community.