New Denial-of-Service Attack Is a Killer 341
ancientribe writes "Hacker RSnake blogs about a newly discovered and deadly denial-of-service attack that could well be the next big threat to the Internet as a whole. It goes after a broadband Internet connection and KOs machines on the other end such that they stay offline even after the attack is over. It spans various systems, too: the pair of Swedish researchers who found it have already contacted firewall, operating system, and Web-enabled device vendors whose products are vulnerable to this attack." Listen to the interview (MP3) — English starts a few minutes in — and you might find yourself convinced that we have a problem. The researchers claim that they have been able to take down every system with a TCP/IP stack that they have attempted; and they know of no fix or workaround.
I cant believe this is the first comment, (Score:5, Funny)
Some DOS attack on Slashdot in progress?
Re:I cant believe this is the first comment, (Score:5, Funny)
Yeah, some stupid user deltree'd the whole site!
Re: (Score:2, Funny)
Ah, there's your problem, you're runnning your website on MS-DOS 6.22!
This is a bit unorthodox, but might I suggest...linux?
Re:I cant believe this is the first comment, (Score:5, Funny)
No, it's my fault. I linked to slashdot from slashdot, slashdotting slashdot. So slashdot's slashdotted.
Sorry.
Re:I cant believe this is the first comment, (Score:5, Funny)
AHAHAHAHAHA! You left your system open to hacking! HAHAHAHA! Look at all this animal porn you have! HAHAHA I'm deleting your OS's Kernel right n
fearmongering (Score:5, Insightful)
Re:fearmongering (Score:5, Insightful)
Sorry, but your entire argument is shot down by TFA. For those of you too lazy to read it, this gem "Robert and Jack are smart dudes. I've known them for years," clearly shows that your argument is moot. The author has known them for years from (presumably) T-Ball league. How can you argue with that?
(this having to wait 5 minutes between posts is a pain in the ass. Anyone else stuck with this restriction?)
Re:fearmongering (Score:5, Insightful)
Sorry, but your entire argument is shot down by TFA. For those of you too lazy to read it, this gem "Robert and Jack are smart dudes. I've known them for years," clearly shows that your argument is moot.
Seriously....just saying "Yeah, these two dudes I know can break the whole Internet. Trust me. I've known them a long time." is just completely lame and useless.
The article is nothing more than fear mongering and fudfudfud (please tag appropriately). Unless there's something to the interview beyond "I know how to break the Interwebs!!!", I'm from Missouri on this one.
Re: (Score:3, Informative)
The interview does actually have a lot of detail.
Skip to ~ 5m10s for the English.
Re:fearmongering (Score:5, Funny)
My sig answers your question. :)
Re:fearmongering (Score:5, Insightful)
(this having to wait 5 minutes between posts is a pain in the ass. Anyone else stuck with this restriction?)
Yes, limiting the possibilities to comment is clearly a bad idea. /. summaries have always been quite bad for as long I can remember it, but all the informational value is in the comments. Where else can you see a fearmongering article, people making some obvious remarks, getting insightful retorts to finally end on a +5 comment coming from a guy working in the lab TFA mentions ?
Slashdot, don't fear posters. Your moderation system filters spam (and as*holeness) with enough efficiency, don't add nagging features !
Re:fearmongering (Score:4, Insightful)
That kind of restriction does pretty much nothing at all to stop any kind of crapflood.
See, crapflooders are not limited to using one IP or one account, unlike legitimate users.
Re: (Score:3, Funny)
Yeah, it would be nice if nobody crapflooded /. ever, so they didn't have to come up with such restrictions...
they'd also have to fire some of the editors to get rid of all the crap that gets posted here, though...
Re: (Score:3, Informative)
It wasn't our intention to fear monger. In fact if you listen to the whole podcast we actually comment on the "Chicken Little" phenomenon in security research.
For those wanting to stay abreast of these issues as more information is shared publicly, keep an eye on my blog [robertlee.name].
I'm trying to keep a link to most news articles there. I've also been able to answer a few questions in the comments through that medium.
--Robert
Re: (Score:3, Insightful)
Re:fearmongering (Score:5, Informative)
Weird.
Re: (Score:2)
"fixes are not available," /me inserts non-multisession live CDs into all my machines...
"Bring it on!" :)
Re: (Score:3, Insightful)
Please correct me if I am wrong, but I don't see how this cannot be fixed. Another super-scary (and warrantless) slashdot headline and summary IMHO.
Pfffft (Score:5, Funny)
Doesn't affect me. I haven't used DOS in YEARS. Some folks need to move up to Windows 3.1. That is where it is at.
Re:Pfffft (Score:4, Funny)
Uhh, you know that's still based on DOS right? You should update to Windows 95 like me to be safe.
Re:Pfffft (Score:5, Informative)
Re: (Score:2)
WinME is even worse. It tries to achieve NT on Windows 98. You have to boot to it and use it for a week. You will see the amount of insanity in the idea. I can't express it even. Just think system restore running on FAT32 instead of NTFS which has legendary shadow copy. Problem begins exactly at that point.
It is more like Rhapsody on Mac land. I mean the strangeness Very interesting for IT history :)
Re: (Score:2, Interesting)
built by David Cutler, on a VMS foundation
What piffle. He took ideas from VMS, that's all.
Cutler was one of the core authors of VMS
More piffle. He was part of a technical design committee that worked on the FIFTH iteration of the OS/hardware combo, and left the project before v1.0.
Re:Pfffft (Score:5, Informative)
Piffle yourself. The memory management, as an example, was definitely theft from DEC.
David was one of the three team leads on Starlet, which became VMS. And yes, according to DEC personnel of that era, he was very much a technical lead, if not the technical lead.
Re: (Score:3, Informative)
The memory management, as an example, was definitely theft from DEC.
Should surprise no one. He did, after all, work on Starlet, in the 1980s there were many books written on VMS internals, and the source code isn't even that difficult to get.
(As an aside: at a VMS tech conference in 2002, we were told by a VMS engineer that Itanium's memory management was purposefully designed to be like that of the VAX.)
according to DEC personnel of that era, he was very much a technical lead, if not the technical lead.
I
Re: (Score:2)
Vista is an attempt to get back to the glory days of Win98.
Re:Pfffft (Score:5, Funny)
Re:Pfffft (Score:4, Interesting)
Haha!
Pentium? Microsoft advertised that 3.1 would run on a 386 with 16 meg of RAM, so that's what we installed it on to evaluate against our lovely Netware 3.11 fileservers.
Guess what?
It sucked ass - 10 minutes to boot, and funny looks were a definite no-no.
I have a lawn you could get off, if you like...
Re: (Score:2, Interesting)
No lie, I once had Windows 3.1 running on a 286. Not sure how much RAM I had. Oh, and the monitor was monochrome orange and black (or may have just been broken). The keyboard connected with something resembling a phone jack. I probably still have that machine in the attic. Note that I said it was running. I can't comment on if it was running *well* or not because I just booted it for curiosity's sake, then shut it down and promptly forgot about it until just now. This was well into the days of the Pentium 2
Re: (Score:3, Insightful)
Could it be that you're talking about MS Windows 3.1 instead of Windows NT 3.1 that the parent seems to be talking about? Because NT 3.x was a completely different beast from regular Win 3.1.
/Mikael
Lose (Score:3, Funny)
I renamed the win.com file in Windows 3.x to be lose.com instead. Then you got the esthetically satisfying possibility:
C>win
Bad command or file name
C>lose
Starting Microsoft Windows
Then again, I was already sick of Windows at 3.0, having tried Windows 1, Windows 2, Windows 286, and Windows 386, and hated them all for being so stupid and unreliable. The first version of Windows that I almost liked was the one in OS/2 2.0, because you could run several instances of them and kill them if they didn't a
Re: (Score:2)
Thing would BSOD if you more than looked at it funny.
Modded informative. Love it.
Re: (Score:3, Funny)
Bah. I use Dr. Dos. It's a doctor so it fixes itself and I don't have to worry about these issues!
Re: (Score:2)
Re: (Score:2)
Do you know where I can get Windows 3.1 for my Apple ][?
Transcript (Score:5, Insightful)
Do people really have time to listen to podcasts unless they are commuting?
Is there a transcript???
Re: (Score:3, Insightful)
Do people really have time to listen to podcasts unless they are commuting?
Is there a transcript???
To answer your question before I start my tirade: From the blog in question, "The podcast is still the most complete public source of information for these findings." http://blog.robertlee.name/ [robertlee.name]
I know what you mean. Audio or video are pretty poor for the rate of information disseminated compared to text. This is doubly true when the creators aren't formally trained (presenters aren't actors, or the script is not professionally written). Then you wind up with unskilled individuals all over the internet bl
Re: (Score:3, Informative)
Or if you prefer normal pitch, install http://www.breakfastquay.com/rubberband/ [breakfastquay.com] , an excellent Free pitch shifter, and use:
mplayer -speed 1.6 -af ladspa=ladspa-rubberband.so:rubberband-pitchshifter-stereo:0:-8.1:0:2:0:0 [file]
Not much information (Score:5, Informative)
Neither interview nor Link provides much information about the kind of attack. Between the lines they seem to be doing something with the ressource usage by manipulating tcp session parameters. But that's idle speculation for now.
CU, Martin
Re: (Score:3, Informative)
Looks like you may be onto something; found this writeup with a bit more detail: New attacks reveal fundamental problems with TCP [techtarget.com]
Don't know enough about TCP/IP to comment, but maybe someone else here could elucidate or elaborate?
How it works (Score:5, Interesting)
Many TCP servers use a technique known as a SYN cookie in order to prevent attackers using spoofed IP addresses from launching SYN flood denial-of-service attacks against them. The cookie is essentially a chosen TCP initial sequence number that is calculated using some specific hashed metadata that reflects the details of the specific TCP connection. Once the client returns a correct packet to the server, the server knows that the client isn't using a forged IP address.
Sockstress computes and stores so-called client-side SYN cookies and enables Lee and Louis to specify a destination port and IP address. The method allows them to complete the TCP handshake without having to store any values, which takes time and resources. "We can then say that we want to establish X number of TCP connections on that address and that we want to use this attack type, and it does it," Lee said.
In summary, it works by establishing tons and tons of connections using carefully-forged SYN cookies [wikipedia.org]. The irony? "SYN Cookies are the key element of a technique used to guard against SYN flood attacks". ROFLMAO.
And then it gets scarier:
From the wikipedia article:
The use of SYN Cookies does not break any protocol specifications, and therefore should be compatible with all TCP implementations.
Now, are you ready to scream?
the 2.6.26 Linux kernel added limited support of TCP options.
Scream.
More scares, AND A TEMPORARY FIX! (Score:2, Informative)
The technique was created by Daniel J. Bernstein and Eric Schenk in September 1996. The first implementation for SunOS was released by Jeff Weisberg a month later, and Eric Schenk released his Linux implementation in February 1997 (the current implementation uses e.g. net.ipv4.tcp_syncookies).
From an old 2001 syn cookies vulnerability report: [linuxdevcenter.com]
syncookies can be disabled on a running system by executing the command:
echo 0 > /proc/sys/net/ipv4/tcp_syncookies
(To the editors: Mind adding the above line to the summary? Thanks!)
Patch your systems. NOW! (note that this makes them vulnerable to syn flood attacks, but at least those won't leave your system unusable until reboot!)
Re: (Score:2)
I just added the above line to /etc/rc.d/rc.local, but I really don't know if that leaves a window of time during boot where the vulnerability can be exploited.
Any GNU/Linux expert who can inform us how to correctly patch our systems (until the official patch is released, of course)?
Re: (Score:3, Insightful)
Simple: put that line before your network cards are initialised. That's rc.inet1 in Slackware, YMMV elsewhere.
Re: (Score:3, Informative)
Unless the kernel was patched, or the rc files in your distro explicitly enable them, the default is 0 (off).
From the kernel config help under IP: TCP syncookie support (disabled per default)
"
If you say Y here, note that SYN cookies aren't enabled by default;
you can enable them by saying Y to "/proc file system support" and
"Sysctl support" below and executing the command
echo 1 >/proc/sys/net/ipv4/tcp_syncookies
at boot time after the /proc file system has been mounted.
"
DON'T PANIC! (Score:4, Informative)
If you are running Ubuntu 8.04, you probably aren't vulnerable (or at least I am not). See if you get what I got in the terminal:
collin@collin:~$ cat /proc/sys/net/ipv4/tcp_syncookies
0
collin@collin:~$
Re:DON'T PANIC! (Score:4, Funny)
Apparently, I should panic:
I CAN'T TURN IT OFF!
(Manually-built kernels FTW!:
)
Re:DON'T PANIC! (Score:5, Funny)
Oh no, me too!!
C:\Documents and Settings\Adam>cat /proc/sys/net/ipv4/tcp_syncookies
'cat' is not recognized as an internal or external command, operable program or batch file.
Setting system parameters (Score:3, Informative)
On RedHat distros, and probably others, there is a utility called 'sysctl' and a config file called '/etc/sysctl.conf'. In Redhat, the following appears in /etc/sysctl.conf:
# Controls the use of TCP syncookies
net.ipv4.tcp_syncookies = 1
Just change the 1 to a 0
Re: (Score:3, Informative)
YaST2 -> System ->
I don't remember messing with this setting, so my bet is that openSUSE defaults to on.
Re:More scares, AND A TEMPORARY FIX! (Score:4, Informative)
WHY ARE YOU TAKING THE ADVICE OF RANDOM FOOLS OFF SLASHDOT? Go find out what syncookies first. Find out why syncookies were put in. Then find out what this attack is supposed to do. Then think for your self - do I want to protect against a known attack that has successfully brought down large sites, or do I want to turn that protection off because some fool suggested it on slashdot because I heard about a new scary attack?
If you are truly worried, there are other things you can do - look at your routers, firewalls, etc. Also, look at other OS'es. OpenBSD doesn't have syncookies - why not?
Re: (Score:3, Interesting)
Mod Parent Dow; Not a fix! (Score:5, Informative)
Now we see that a little bit of knowledge can be a dangerous thing.
The point that's in the grandparent's post is not that your own syn-cookies can be used against you. Syn cookies on your server are doing the right thing and are protecting you against normal syn floods.
What's happening in this attack is that the client side (the attacker) is using their own syn cookies to store information about connections on your server (instead of in their own memory). This allows them to handle more connections than otherwise. Unfortunately there is nothing you can do to stop this. They are using required behavior of the TCP stack for their information storage.
Some mitigation strategies that I can think of
The parents "fix" will make things slightly worse during this attack since turning off syn-cookies will mean that your server will have to track even more TCP connections. Not just those that are active, but also those that have just started. Of course, it will also make the new attack pointless since they can just do a normal syn-flood instead.
The best current full fix I can think of is to use IPSEC and ensure that all incoming connections are authorised. Your own users will still be able to DOS you, but at least you can hunt them down.
Re: (Score:2)
There's not fery much new detailother than stating that it's about "TCP state table manipulation". I'd guess they're keeping details to themselves until a fix can be found. My guess is that others will discover it just based on the broad area described.
Re:Not much information (Score:5, Informative)
Go for it, take on my machine! (Score:3, Interesting)
My IPv4 address is 127.0.0.1 ...
More seriously, I wonder if this actually affects *nix machines, and how the various environments in that area affect the attack.
After all, they may find a single attack against all MS Windows XP machines, but they need a lot more then one to attack all Linux based systems (and then you throw in BSD based ones as well...).
Meh, the article doesn't give much detail.
Re:Go for it, take on my machine! (Score:5, Insightful)
Re:Go for it, take on my machine! (Score:5, Insightful)
Of course Linux is not a magical shield. But having a diverse eco-system is known to protect against many attacks.
One of the reasons stories about how the banana is going extinct come up every few years is because the "modern" banana that most people in the over developed world can buy, are all clones! One disease can attack all the plants in the same manner.
In the same way, computers that have the same OS tend to be vulnerable to the same attack. Because there are a lot more OSs based around Linux (and BSD), people running these OSs are less vulnerable, because they are in a diverse eco-system. Especially when these kernels and the user-land tools are FLOSS.
As such, yes, it maybe a generic vulnerability in the TCP spec. (though how likely is that?), however, it is not specified, which is why I asked if it did affect *nix.
If nothing else, due to the nature of FLOSS, the attack could quickly be coded around as soon as it is known, and then pushed out to many many people running auto-update systems (such as Debian, Ubuntu and similar). (Even if that breaks the spec.)
Re: (Score:2)
One of the reasons stories about how the banana is going extinct come up every few years is because the "modern" banana that most people in the over developed world can buy, are all clones! One disease can attack all the plants in the same manner.
I wondered how long it would be before someone dragged out a banana analogy.
Re: (Score:2)
Re: (Score:3, Insightful)
Of course Linux is not a magical shield. But having a diverse eco-system is known to protect against many attacks.
Amen! Even so, I would expect to see patches coming from David Miller shortly if Linux is truly vulnerable. Similar to how Linux was the first system to be protected against the F00F Intel Pentium hardware bug.
Re:Go for it, take on my machine! (Score:5, Funny)
Thief! That's MY address!
Re: (Score:2)
researchers claim that they have been able to take down every system with a TCP/IP stack that they have attempted
Last time I checked, that includes Unix and BSD. Not only does it include BSD, but since the XP TCP stack literally is the BSD stack, I think youre point is pretty irrelevant.
Re: (Score:2)
(and then you throw in BSD based ones as well...)
You do know that MS didn't write Windows' TCP stack on their own, right?
Coral cache link (Score:2, Informative)
Things that make you go 'Hmmm...' (Score:4, Interesting)
The simple fact that I'm posting this reply makes me doubt the "ZOMG UNSTOPPABLEZ" aspect of this claim, is all.
Nah (Score:4, Funny)
Ignore the story, there's very little chance that a single virus can take down all systems, especially if the user is not running Windows.
I for instance have multiple rock solid software and hardware firewalls, and most ports blocked - I'd like to see it try taking dow
For those who can't listen to the interview (Score:5, Informative)
Here's a link to an article in English:
http://searchsecurity.techtarget.com/news/article/0,289142,sid14_gci1332898,00.html [techtarget.com]
From the article:
Many TCP servers use a technique known as a SYN cookie in order to prevent attackers using spoofed IP addresses from launching SYN flood denial-of-service attacks against them. The cookie is essentially a chosen TCP initial sequence number that is calculated using some specific hashed metadata that reflects the details of the specific TCP connection. Once the client returns a correct packet to the server, the server knows that the client isn't using a forged IP address.
Sockstress computes and stores so-called client-side SYN cookies and enables Lee and Louis to specify a destination port and IP address. The method allows them to complete the TCP handshake without having to store any values, which takes time and resources. "We can then say that we want to establish X number of TCP connections on that address and that we want to use this attack type, and it does it," Lee said.
So it's a DoS abusing SYN cookies? (Score:2)
So.. setting up a SYN cookie handshake takes up memory on the server. And by calculating the correct response to a SYN cookie challange they defeat the handshake, opening the port on the server, and then they set a new connection from a new forged IP address. This takes up memory and connections on the server machine, leaving connections to time out.
Do I have this correct?
Re:So it's a DoS abusing SYN cookies? (Score:4, Interesting)
I don't think so. From the techtarget article, it seems that they are using a technique invented for the server side, but on the client side.
It's a way of calculating the syncookies, so that the server doesn't need to store anything, until it receives the third packet (ACK) of the three way handshake, thus being able to handle syncookie'd connections just as fast as normal connections. My understanding is that these guys use the same technique on the client, so that they don't need to store anything either.
They send the first packet (SYN), and forget about it.
When the server responds (SYNACK) several thousand packets later - this is a flood, remember - they know the server cookie, and can recalculate their own cookie. Thus they can send the third packet (ACK) and complete the handshake, establishing the connection. The server now inserts the connection into its connection table. The client does not, it's doing a DOS attack, not trying to communicate.
When the client doesn't need to keep track of its connections, it can start new connections as fast as bandwidth allows. Basically syn-cookies just became useless, and we're back at square one.
However, for servers that don't have this no-memory implementation of syncookies, but still store the syncookie itself, it gets even worse. Not only are you using up all available connections, but you also fill up the syncookie table. This may be where the "does not recover after the attack" comes in. Previously syncookies would prevent the flooding in the first place, and thus you would never fill up the syncookie table. So that part of the code never got tested.
Of course this is just how *I* understand it.
Computing SYN cookies? (Score:5, Informative)
Sockstress computes and stores so-called client-side SYN cookies
This isn't supposed to be possible. SYN cookies [cr.yp.to] are supposed to contain at least 24 bits worth of entropy, produced by running a server-side secret through a one-way hashing function. You can easily obtain a SYN cookie by performing the initial SYN with the server. A SYN+ACK comes back which contains the SYN cookie (as the initial sequence number). The cookie so received is unique per TCP connection (IP address and port numbers at both ends), and valid only for a limited time. The server side does not maintain any state information until the cookie is returned in the client's ACK.
If they are actually computing SYN cookies on the client side, it's evidence of a weak SYN cookie implementation. Computation of the cookie should be infeasible without access to the server-side secret. Of course, this may be a case of sloppy reporting. As usual, we aren't given all the details of this earth-shattering vulnerability. We are simply left to guess whether these folks (and those that report on them) know what they're talking about or not.
They could be guessing cookies, and that would explain the "it will hurt intermediate systems" excuse they used for not demonstrating it, since they'd need to flood the peer TCP with millions of randomly-guessed initial sequence numbers. Incidentally, if this is a TCP SYN-flood attack of this sort, the "after effects" they mention have to do with the fact that all the TCP connections must time out naturally -- a process which might take several minutes per connection, depending on the configuration of the listening server application. The process is naturally limited by bandwidth and the size of the TCP state table: you have to be able to send successful fake ACKs fast enough to fill the TCP state table. All the usual mitigations for TCP SYN floods apply, such as increasing the state table size and reducing the timeout for open but idle connections.
It's not at all clear that this is any worse than the kind of DDoS attack that a typical botnet can unleash. In that case, you get thousands of perfectly real TCP connections from multiple addresses almost simultaneously. So maybe this attack doesn't require a botnet, but I don't see that it's a big new threat (as I've described it).
Re: (Score:3, Informative)
Sockstress computes and stores so-called client-side SYN cookies
This isn't supposed to be possible.
I took it to mean that the client is doing something equivalent to the "normal" SYN cookies that servers use, so that it doesn't have to remember what connections it's in the middle of trying to open.
Re: (Score:2)
Power grids? (Score:3, Insightful)
pff (Score:5, Funny)
Typical /. reaction to potential danger:
"Hah. Until I don't taste nuclear winter snow I don't believe that's gonna happen'"
Give the man his nuke. He earned it.
Comment removed (Score:4, Interesting)
The sky is falling! (Score:4, Interesting)
I don't understand... (Score:2)
Why didn't they publish a detailed description of their exploit? If they don't supply enough information to let any script kiddie with "toolz" create havoc and end Western Civilization, they must be just blowing smoke and sowing FUD, right?
Re: (Score:2)
Factual Inaccuracy (Score:2, Informative)
The sky is falling! (Score:4, Insightful)
Quickly, go yank the cable/dsl connection right out of the wall before its too late!
Come on... I'm not going to listen to mp3, but the /. summary and the article both are dangerously low on details. This effects every machine with a TCP/IP stack? IPv4 and IPv6? Leaves the machines in a permanent state of DOS? There's no prevention? No fix? And you can't even test it because it might take down "other devices between here and there"?
Pardon me, I'm off to find myself a huge grain of salt.
Re: (Score:3, Funny)
Re: (Score:3, Funny)
Let's give them the benifit of the doubt (Score:2, Insightful)
Let's assume that they have actually discovered this industry sweeping exploit.
So they went and contacted the vendors like good white hats. Now, if their intent was in being contributers to the greater good of security they would stop at this level of correspondence and work with the companies until the problem is fixed.
However, they released this article to inform the public. Normally when someone does this it is with the intension of providing the public with the knowledge, tools, or rallying them activis
Missed part (Score:2)
I read TFA, but somehow I missed the part about the nth complexity binary loop [tamu.edu].
I'm safe (Score:5, Funny)
Everybody turn off syncookies.... (Score:2)
Because in a week I'm going to be auto-DOSing every frigging zombie which connects to my servers and tries to send spam or crack SSH.
(No, not really. Besides, the botnet people would probably turn off syncookies on their zombies)
Something strange... (Score:4, Insightful)
It sounds like a blind resource consumption attack against SYN-cookie implementations, no? (Without SYN-cookies, the attack is trivial, just spoof SYNs).
http://searchsecurity.techtarget.com/news/article/0,289142,sid14_gci1332898,00.html [techtarget.com]
SYN-cookies are a simple idea. Upon receiving a SYN, rather than creating all the state, the server returns a SYN/ACK with the SEQ value = H(IP,ACK value). Thus when it sees the ACK packet it can check that the value is returned, and then create all the state.
If this is the case, it seems to require that a SYN-cookie be predictible, that the attacker can probe a client to predict what H(IP,ACK value) is. IF that is the case then there is an easy fix: simply use more and better random data as salt in a better hash function.
Simply because ANY blind resource consumption attack against a SYN-cookie server requires knowing what the SEQ value from the server for the SYN/ACK in order to establish a connection by sending the proper ACK (and then some data to load the server further).
If the attacker can't predict the SYN/ACK's SEQ value, it can't construct a proper ACK and cause the server to consume resources.
OOPS, I was wrong... (Score:2)
Its simply using the SYN-cookie style trick on the client side to reduce the state-holding requirements on the client to near-zero.
SNEAKY!
Off-topic, I know... but... (Score:3, Interesting)
...something about this article made me think of something else.
With these caps and limits being placed on customers of Comcast and others, I have to wonder if the customer is being protected or endemnified against people attacking their accounts with massive data packets in order to fill up their limits? This wouldn't be a [D]DoS exactly, but potentially, it could be an [E]DoS in effect -- E meaning "Expensive."
I know personally, after having realized this, if I knew any Comcast customers I didn't particularly like, I might be tempted to set up a dyndns entry for their IP address and mention them on slashdot...
Outpost24 (Score:4, Informative)
How this really SEEMS to work... (Score:5, Informative)
The observation: You can use a SYN-cookie like trick on the client side as well for an attacker:
You send SYNs where the initial seq # = H(sip, dip, sport, dport).
Now when you get a SYN/ACK back, you can send the ACK to complete the handshake. You can use the ACK field back from the server to know where you are in what data to send (just subtract the value from the initial sequence # to know what the next piece of data to send is), and you can know where you are in the received data (if necessary) by storing just the server's initial sequence #.
As a result, you can now interact with the server without having to maintain ANY TCP session state, or just a single word (the server's initial seq #), allowing the attacker to use vastly fewer resources to tie up server resources.
On one hand, this is a cool trick, and potentially useful for an attacker: if you have only a couple of machines and really want to tie up server resources, you can use this quite quickly.
But OTOH, attackers already have so many zombie resources that this really doesn't necessarily buy the attacker all that much: If you have 10K machines banging on a server, the 10K machines have a good 2000x more state than the servers. So who cares about stateholding requirements on the zombie side? Thus I think its only really relevant if you wanted to DOS google, akamai, or some similar very-high-resource infrastructure.
And as the attacker can't SPOOF packets with this (it needs to see the SYN/ACK), the zombies can be filtered if the DOS is detected and the attacker's identified as well.
WOOT! Narrowband (tm) rules! (Score:3, Funny)
Ha, ha, laugh at my dial-up connection now!
Re: (Score:2)
I think you wanted a "signal terminated" to show your machine had been taken off-line in a 'hilarious' "I'm in the middle of typing something that isn't on /. until I submit" post. Error 404 means a suitable response was not found, which means you got some contact ;)
Re: (Score:2, Insightful)
It reaches you in that no one else can see you on the Internet. If all routes are down, you can't communicate. Done, denial of service at its best, even if no packet ever reaches your interface.
That, still assuming that all of this is true.
Re: (Score:2)
You're also assuming that the devices that go down affect most other people trying to connect to the target. If the devices on your routes to the target that go down first are the ones closer to the attacker (an assumption, but not a crazy one) then this is kind of a non-issue. The attacker and people "near" him may not be able to access the site, but it completely depends on what fails first as to whether the target site is offline to the world as a whole.
Re: (Score:2)
> Say they launched the DOS from Sweden and took out all the devices in the first hop,
> that doesn't mean, everyone else in the world will not be able to reach me.
In fact all it means is that they've DOSed themselves and maybe a couple of neighbors.
(Note: I am commenting on SL1200MKII's comment, not on the subject of the purported attact.)
Re: (Score:2)
A virus that takes the host offline is not a very effective virus.
But a DOS that does is very effective.
Re: (Score:3, Insightful)
Because if we don't discuss it, vendors will think that it doesn't need to be fixed, and won't fix it. I'm all for giving vendors some lead time to come up with solutions to discovered attacks, but history has plainly shown that the only way to compel vendors to fix security problems is to publicize them.
And keep in mind: The fact that we're not discussing it doesn't mean it's not getting discussed in other circles who look to use it for less noble things than correcting defects.
Re: (Score:3, Informative)