CurbRisk.com

Manage Risk With an Effective InfoSec Organization

Outpost24 TCP Denial of Service Vulnerability Interview Transcript

Outpost24: Because there are thirty-two machines that it’s keeping track of. It’s trying to do the work of thirty-two TCP stacks. So if you were to simultaneously attack all these IP addresses at the same time, it would all end up attacking this one machine and the machines in back of it, depending. And so every time you [...] code basically, you increase your exposure. Having an IPS sitting up front of a machine that has a TCP/IP stack, you have two times as much code. And a lot of the times, for whatever reason

Outpost24: It seems like that IPS’s aren’t designed to deal with denial of service. Well, the stack that you have on your computer has been out on the Internet for a while. And people have taken it a lot more seriously to make for example the Windows TCP/IP stack and the BSD TCP/IP stack have been hardened against denial of service because it has been so prevalent. But it seems like a lot of security devices that sit in line don’t really stand up to the same scrutiny over the years. Usually, those are pretty easy to do DoS compared to lets say a kernel stack. It’s just that much easier. I wish I could tell you why, but I think that the security people when develop a security product, especially when it’s a network security product and then they just think, "oh, it’s a security product." But a lot of the times those have security vulnerabilities too. I mean, we see it all the time where the antivirus products have buffer overflows in them and stuff like that. You might be able to get a virus by scanning for viruses because you have a vulnerability in your antivirus scanner. That stuff happens now. But a long time ago people would think you were crazy for saying well what about your antivirus? It could be dangerous running it and people would laugh at you. But now you are starting to see practical attacks of that, too. So it’s just the same thing, it’s the same pattern and it’s just going to happen again.

Interviewer: And don’t even bother moving to IPv6 because that makes it worse, you say. So why is that?

Outpost24: IP version 6 inherently uses more resources than IP version 4 does. The address space is much bigger. There is a lot more features that IP version 6 has. That’s a lot more resources that are exposed. It’s the same reason… just there is so much more functionality inside there now and so much more memory usage that it’s that much easier to do a denial of service attack on. And It’s not like they rewrote TCP for IP version 6.

Interviewer: OK. One technical question that I have left, when I start this attack I don’t need to let the connection stand, do I? I just can show up, do my attack and I basically leave again, right?

Outpost24: It depends on which attack that you are doing. The attacks that we were talking about before that are the lowest bandwidth, lowest resource on the attacker side that simply make the TCP service unavailable. In most cases, not all but in most cases the effects of the attack are only sustained as long as the attack is sustained. But the more exotic attacks will react, so we cause the machine to like let’s say run out of resources like drivers. Those will persist after the attack stops. So it depends on what resource you are attacking basically is the answer to that question.

Interviewer: OK. And you said you are at multiple attack scenarios, how many have you got so far?

Outpost24: I think total I have 5 documented. But certainly it isn’t hard to come up with new ones. You just… you basically have to sit there and search for code and figure out what sorts of…at what stages that you can get to given these constraints would use the most amount of resources. And to figure how complicated the actual stack implementation is on the system that you are targeting. There could be in theory between 5 and maybe even upwards of 30 additional attack types that could be discovered. But Jack has documented 5 so far.

Interviewer: OK. And all of them need a different fix or would one fix it all?

Outpost24: Since we don’t know what the fix is, it’s really hard to answer that question, of course. If we were to come up with a way that we think mitigates this the best. If we apply that philosophy to all that things inside the TCP/IP stack and just kind of go through and review that’s what we would reuse. It’s not like we could just fix this one line of code and the problem would magically go away. We would have to go through a lot of code and just audit all the different resources that can be deployed inside of TCP that you need to protect better and that’s how we would solve the problem. It’s not like we are just going to patch one line of code and fix it.

Interviewer: OK. What would like to see the TCP/IP and security community do with the knowledge that we’re sharing today?

Outpost24: I’d like to get some really smart people to think about what sorts of things are available in TCP and how we could potentially safeguard our kernels a little bit better against people who are malicious. And I really want people to consider just because we’re not spoofing… if we’re not spoofing our source address we certainly can still be malicious. There’s so many features inside TCP and people really don’t consider the implications of using various features, and they really should. That’s what I’d like people to think about. So someone who’s really smart could come up with a really intelligent way to protect your systems.

Interviewer: Yes. Given the book that Dan Kaminsky found in DNS, given the BGP issue, given your issue now, do you see much future for TCP as we know it or is it time to totally rethink the protocol?

Outpost24: It’s funny — we talk about this internally all the time. There’s a lot of researchers out there that’ll go find a major bug and pull a Chicken Little routine about how "we could break the internet in 30 seconds, It’s doomsday all over again." Although we do definitely take this seriously, we do think this is a very highly severe availabilty issue, we think that the community is smart enough and proven robust enough to be able to handle these sorts of things before it becomes too bad of an issue. So no…I think every time that we thought a system was so bad we have to scrap it and throw the baby out with the bathwater I am often surprised at how simple and elegant a solution that we didn’t think about can be. So I’m hoping that’s what happens in this case as well.

Outpost24: Yes. I agree with that. We still use SMTP to send email [interviewer laughs] and the majority of the email on the internet is spam but do we throw out SMTP because it was a broken design? I mean, the community as a whole, I think, likes to find workarounds more than anything else. I mean, if it was a perfect world we probably should reconsider how we do TCP. And we should probably consider that people on the internet aren’t happy and want us to do the best. It’s actually more of a hostile environment than a lot of the people who were designing these protocols thought. So ideally we probably should design something new but chances are pretty slim that that’ll ever happen. I think that someone will just come around with some mitigations that really limit the depth of this problem and something that everyone’s willing to accept. I think that’s probably what will happen.

Interviewer: Okay, well, Jack Louis and Robert Lee, thank you very much for breaking the Internet, I would be inclined to say.

Outpost24: [Laughing] My pleasure. Thank you for taking time with us.

Pages: 1 2 3 4

   

 

If you enjoyed this post, please consider leaving a comment or subscribing to our RSS feed to get future articles delivered to your feed reader. You can also click "Buzz Up" or "ShareThis" above to share this post via email or social networking sites.

Copyright 2008. CurbRisk.com. All rights reserved

• Home
• About
• Contact