Researcher's Death Hampers TCP Flaw Fix 147
linuxwrangler writes "Security researcher Jack Louis, who had discovered several serious security flaws in TCP software was killed in a fire on the ides of March, dealing a blow to efforts to repair the problem. Although he kept good notes and had communicated with a number of vendors, he died before fixes could be created and prior to completing research on a number of additional vulnerabilities. Much of the work has been taken over by Louis' friend and long-time colleague Robert E. Lee. The flaws have been around for a long time and would allow a low-bandwidth 'sockstress' attack to knock large machines off the net."
Dang low bus factors! (Score:5, Interesting)
Re:What the fuck (Score:2, Interesting)
On the utter downside, we all seem to be losing bright minds. We lost Hans Reiser [wired.com], Rick752 [slashdot.org], PCLinuxOS lost N1PTT (Robert Green) [pclinuxos.com] just to name a few more.
It just goes to show you how fragile life really is. Some chose to celebrate it with us other geeks and share some code and what not. I thank you all that do!
Shitty year for us all I guess?
Re:Naptha all over again (Score:4, Interesting)
My fix is on the server side. It does not require changes in the stack code of clients who would connect to it. Reverse-engineering it would gain the attackers nothing. An all-or-nothing fix would not be much of a fix. Neither would one which was successful based upon its obscurity.
I am not telling you what it is because I am hoping that Microsoft will pay me some money to give them access to it. Apple as well (and Sun if they're still around). Once these are secured, I will open the invention to the FOSOSs. (Free Open Source Operating Systems). Call me greedy if you want, but I am tired of researching security and not getting paid for my hard work. That's why you haven't seen me by this handle or my real name posting security advisories for some time.
Re:Naptha all over again (Score:3, Interesting)
Source address level filtering does provide some level of protection against a SYN flood.
My point was that this attack has to use a valid IP, because it needs to create a connection. It is therefore easier to block than a SYN flood, which could spoof any address or groups of addresses.
The problem is, it is not universally implemented.
That's news to me. Which commercial firewall hardware does not have this ability?
Another problem is someone who doesn't care to hide their address. If you are doing more than a SYN flood, but more advanced TCP hijinx, you need to use your read IP address anyhow. So, it's not much of a fix.
That's exactly what this attack entails. The attacker has to use their real address with this, so it's easier to block them at the firewall. You might have a problem with your bandwidth, but you'd have that same exact problem regardless of the fix you choose to implement. You'd also have that same problem during a SYN flood.
Neither is the recommendations which came out back in 2000, which was to increase the resource limits that the operating system imposed upon the IP stack. I could go on and on, on how each measure so far implemented has just raised the bar against these type of attacks, but hasn't really done much to prevent them.
If you read the alert from CERT-FI, it says:
March 23 2009. Discussions have been ongoing with a number of vendors, and several of them are currently in various phases of patch development process. Judging by the current progress, CERT-FI is confident that functional fixes to mitigate the risk can be expected to be released during this year.
(Which, BTW, if you expect to sell your solution to vendors, you'd better hurry up.)
My point was that the collapse of the internet due to this attack has been completely exaggerated. As Fyodor explains, this type of attack has been known about for a long time, and it can be filtered.