Slashdot Mirror
New Denial-of-Service Attack Is a Killer
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.
Some DOS attack on Slashdot in progress?
While it is pretty interesting, and disturbing, we are once again faced with a "The Internet Will Cease To Exist And Your Brain Will Explode" vulnerability. We dont know exactly how it works, we dont know exactly what to do to stop it, fixes are not available, and we are all doomed. The podcast goes into enough detail about how they discovered it to be replicated by skilled evildoers without too much trouble, but nobody knows how long, easy or invasive a fix is going to be.
People who think they know everything are a great annoyance to those of us who do.
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.
See my journal for slashdot ID's by year. Mine created in 2005. http://slashdot.org/journal/289875/slashdot-ids-by-year
Do people really have time to listen to podcasts unless they are commuting?
Is there a transcript???
http://blog.grcm.net/
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
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.
I wank in the shower.
FTFA... "Robert and Jack are smart dudes"
yep ... and i'm scared now cuz the smart dudes told us the sky is falling, but don't ask why, they are working with the "vendors" in secret. which must be a lot since this affects every tcp/ip stack in existence.
who is jacking off who here?
Coral Cache (just in case): http://debeveiligingsupdate.nl.nyud.net/audio/bevupd_0003.mp3
Forget world peace, bring on -1 pointless
TCP/IP stacks are telling my operating system not to work any more.
The simple fact that I'm posting this reply makes me doubt the "ZOMG UNSTOPPABLEZ" aspect of this claim, is all.
when exactly are they going to explain how it is done? I would be interested to know...and I'm sure if they release the details, someone somewhere in the world will have a fix up within hours.
Then again, once it is posted, I predict that all the major internet sites will go down within hou
(error 404)
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
Why OpalCalc is the best Windows calc
http://blog.robertlee.name
Here's a link to an article in English:
http://searchsecurity.techtarget.com/news/article/0,289142,sid14_gci1332898,00.html
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.
Why do I constantly find stories about how our power grids, nuclear energy sites, military bases, Federal government, etc., etc., will be taken down by Internet hackers? Please don't tell me that all of those resouces are accessible over the Internet. Why in God's name would put such resources on the Interet?
Fata viam invenient.
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.
mov ax,4c00h
int 21h
someones mom needs to check the basement more often...
TFA starts off with "things are a brewin' in sweden"
"Robert and Jack are smart dudes."
"I feel winter slowly coming, and it would be a shame if entire power grids could be taken offline with a few keystrokes, or if supply chains could be interrupted. I hear it gets awfully cold in Scandinavia. "
Good people go to bed earlier.
Another security researcher claims the sky is falling. There are no details, no proof of concept, nothing to prove the alleged vulnerability even exists. Here's something those researchers should learn: if you can't back up your claims with proof it doesn't exist!
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?
I've calculated my velocity with such exquisite precision that I have no idea where I am.
The interview is in Dutch, not Swedish. And since the researchers' names are Robert E. Lee and Jack C. Lewis, I don't believe they are Swedish either.
"Cock Up Your Beaver" does not mean what you think. This sig is intended to clog filters and annoy do-gooders
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. 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.
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.
According to the article:
... I asked him if he'd be willing to DOS us, and he flatly said, "Unfortunately, it may affect other devices between here and there so it's not really a good idea."
So if they tried to launch a DOS against me and inadvertently take out all the devices a few hops before they get to me, how is this attack going to reach me?
They will have no way of knowing if the attack even worked, since all routes to me are down.
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:
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!)
Oh great, another article on Slashdot about how a new, horribly scary security hole in the internet has been found, and now we're all going to go back to the 1930's and relearn how to use slide-rules, and the popularity of vacuum tubes will take off again. Supposing the internet is still working in a few hours, you'll all be jabbering on about how the LHC is going to Bosenova the Earth to smitherenes or something. I can't believe how many times these "OUR TECHNOLOGY IS DOOMED!!!" articles show up. You'd think that eventu
Conscience is the inner voice which warns us that someone may be looking.
Virii is only the plural form of virus if you are an idiot and not familiar with the roots of the word virus.
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?
A virus that takes the host offline is not a very effective virus. The virus needs keep the host alive to reproduce and spread, otherwise it won't let itself run wild.
Every time there's a story about a connection dying or a machine crashing we see a flood of posts that end lik
It was funny _once_. Maybe. Be more creative. I'm trying to waste my day at work reading /. so could you people make up some new ones? And I'm not going to even delve into the fact that thanks to the ways posting content to a website works the failure wouldn't look remotely like this... we're not all on modems connecting to a BBS.
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 activism towards the end of making the upstream change things. This article does not constructively inform in this way and does not give the end user something to throw upstream. Then what is this article accomplishing?
The fact that we are discussing this and that we have, theoretically, RTFA implies that we have exposed ourselves to their names, tools, and services. It also, loosely implies a need for their services and their "skill." Quotations are entered around "skill" as I the reader have no way of actually confirming their skill because of the lack of real material to observe. From this perspective, I am tempted to conclude that this article serves as little more then an advertisement for their services and a cry for attention.
What then, you may ask. Do I suggest that they leak "dangerous" information and risk their horror story becoming reality? No; rather I propose that if their intentions were really to protect the Internet, they should have stopped the discussion of their research from the immediate parties involved.
I do not necessarily advocate any of these stances as this analysis is meant to be normative.
These are not RESEARCHERS but wicked WITCHES. Burn them!! Burn the wicked witches!!
I read TFA, but somehow I missed the part about the nth complexity binary loop.
This doesn't me since use I UDP all communications communications for.
This
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:~$
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)
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
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.
Test your net with Netalyzr
...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...
Reminds me of the Win95 invalid datagram attack that caused a buffer overflow. For it to be platform agnostic, it would need to a specification problem, rather than implementation.
This sounds bogus.
Yes, this new attack is so effective that just attacking ONE host on the Internet effectively rendered the whole Internet inaccessible! The boys had to reboot their computer for the Internet to become operational again.
Server generates a random number every restart.
Server adds random number to the "secure" hash generator.
No one can produce a correct hash without knowing the random number, the "secure" hash generation stops calculation of the random number.
The random number may need to be regenerated every few minutes (If it is 2x the syn timeout, then just check with current and last one)
Yes?
"Of course Linux is not a magical shield. But having a diverse eco-system is known to protect against many attacks."
Well except slashdot's the one always going on how there are a limited number of ways to do something every time software patents come up for discussion. Let alone standards constrain that diversity to a certain degree.
"As such, yes, it maybe a generic vulnerability in the TCP spec. (though how likely is that?)"
More likely than you think.
"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.)"
It may break more than just the spec. That's why patches take time, floss or no floss.
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!
Test your net with Netalyzr
You can find more information at my friends blog http://blog.robertlee.name/ he is one of the researchers at http://www.outpost24.com/ that discovered this vulnerability together with Jack Louis. This is probably the best place to find links for intervies, other articles and keep yourself updated with this issue. They will among other things present this at T2 in Finland this friday http://www.t2.fi/schedule/2008/#speech8
/sbin/iptables -A INPUT -i eth0 -p tcp --tcp-flags SYN -j DROP
Aye captain!
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.
Test your net with Netalyzr
Sockstress computes and stores so-called client-side SYN cookies
This isn't supposed to be possible. SYN cookies 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).
proof, n. A demonstration that a conclusion is implied by certain premises and axioms.
I believe this may not affect NetBSD since they use a different approach to fend off SYN flood attacks.
Sometimes a little extra disclosure may be necessary to like fires under asses.
Extra Bonus: I've corrected your spelling error in the subject.
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
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.
=~ s,(.*),<sarcasm>$1</sarcasm>,g if any_point_you_wish();
It has never been demonstrated that very many of these systems are on the Internet. Let's see some evidence that they are before we panic.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
Ha, ha, laugh at my dial-up connection now!
Disclaimer:IANAL/MD/PhD-Just the local yokel PC "doc" ~If you're not having fun, then you are probably doing it wrong.
TFA> I asked him if he'd be willing to DoS us, and he flatly said, "Unfortunately, it may affect other devices between here and there
So, if it takes out other devices before reaching it's target, isn't there a reasonable chance that the attacker will just isolate himself from the net ?
What a depressingly stupid machine.
It's an alarmist tag, yes, but...
Someday someone in a life-threatening situation with a VOIP phone is going to try to make a 911 call and not get through due to high bandwidth utilization on their IP connection. The person might die. If this is caused by zombification or DOS attack wouldn't that make the perpetrators responsible for manslaughter? Then wouldn't the FBI have to get involved?
This looks like a replay of the naptha DoS from late 2000.
On the assumption that some of these "bad-boy L33T" virus, script and netbot writers read Slashdot, aren't we just playing into their hands by having any discussion about this subject?
Would we not be better off just not making any mention of it?
I mean, what's the worst that can happen? My Internet connection goes down for 48 hours until someone fixes the problem, during which time I can:
- Start actually *looking through* my pr0n collection rather than just spending my time finding more of it to download
- With the 2 hours I save daily not doing an "emerge world" on Gentoo, I'll be able to listen to some nice music
Hell, I may even dollop on some Factor 50 suntan on my pallid flash and venture out into the scorching UK Autumn sunlight for a couple of minutes...
Gentoo Linux - another day, another USE flag.
I believe this new attack is called a PDOS attack. It specifically targets router firmware.
More can be found at
http://hackaday.com/2008/05/20/phlashing-denial-of-service-attack-the-new-hype/
Comment removed based on user account deletion
Comment removed based on user account deletion
Comment removed based on user account deletion
Comment removed based on user account deletion
If you set up a state-based firewall that limits the number of SYN requests in a given second and drops the rest, I believe that will greatly reduce if not eliminate the threat.
The best workaround are the friends,enemies,acquaintances and relatives of whoever invented/uses the attack. Once the whereabouts of said evildoer is disclosed they can be sanctioned and purged from the gene pool by any interested party.
Feel free to name-drop in any reply posts along with relevant personal information.
*Repent!Quit Your Job!Slack Off!The World Ends Tomorrow and You May Die!
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 actually kill themselves.
Incidentally, the shareware graphical shell Aporia gave a sort of Windows 95 look to Windows 386 in the late 1980s (before Windows 3.0). It had icons for tools, drag+drop worked, there was a trashcan, and so forth. I wonder what happened to it...
Those who can make you believe absurdities can make you commit atrocities. - Voltaire
Listening through the whole podcast after reading many comments here, I found most people here did not get the point.
Their stateless SYN-Handshake just makes the described types of attacks even more resource-efficient for the attacker, but I assume that it is even feasible when using "normal" SYN-ACK connection estabishing.
The point is, that the attack starts *after* a connection is set up, using all types of other flow-control mechanisms in order to exhaust specific resources of the tcp-stack.
As an example I just made up, after the connection is open, you could use a flood of ACKs combined with a particular order of out-of-sequence packets or fragmented packets to make the system use up a lot of timers until the whole tcp-stack or the kernel goes down the drain. But as mentioned in the podcast, Timers are just one of a large number of different resources involved in housekeeping after a connection is established, and you can craft attacks to exhaust a specific set of these.
This opens up a complete new can of worms and may turn out not to be easily thwarted because you have to guard *all* of your resources, not just those involved in establishing a connection like in a SYN-attack.
Noone currently has an idea how serious this will turn out to be in the wild, but to me it sounds serious enough not to be ignored, and it has at least the potential to kill the open internet as we know it. In some distant future, you might need an authorization to even send a packet to a particular host, or the whole internet will be so closely monitored that anyone interfering will be visited by black helicopters immediately.
Btw, there is a cool protocol called FLIP (Fast Local Internet Protocol), designed by Tanenbaum in the early 90s for the Amoeba operating system, that would kill many of the problems we have today on the Internet, and it seems to be immune against many types of attacks, including eavesdropping, but FLIP, as the term "Local" in the name says, works just on one local Ethernet, using TCP-Tunnels to connect to other Ethernets, so it is not a viable replacement in its current form and might not scale and has probably a number of issues on its own. What is however remarkable that in FLIP even the source and destination address and port are encrypted, so you can not get even a single packet through if you don't have the permission, and you don't know who is talking to whom even when you sniff the traffic. Although it won't be able to replace TCP/IP, the concepts are an interesting starting point when thinking about a future secure internet. Just imagine every router on the internet would be a kind of TOR-Node, and you could transparently adress every running process on the internet in a secure fashion, no matter where is physically resides, and you could even multicast and have group communication on the network level, reaching millions of host with just sending one packet, but it will arrive only with their prior permission, which you give by just joining a communication group. Imagine a kind of PGP on the network level. This is what a future internet could possibly provide.
For now, we are stuck with TCP/IP, and maybe for a very long time, unless this kind of problems will finally bring the Internet down, which I think is totally possible because TCP/IP is designed for a network of hosts requiring at least some trust and playing fair on the TCP level.
p.
Without order, nothing can exist. Without chaos, nothing can be created.
Wouldn't share technical details? They explained how to do it quite well. Which is a little scary.
both funny and insightful. Your choice. It is ok to take a day off once it awhile.
All your database are belong to U.S.
"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."
If I don't RTFA then what hope is there of me plugging a headset in and listening?
An SQL query goes to a bar, walks up to a table and asks, "Mind if I join you?"
I've never had 2 good points in a matter of 5 minutes.
... doesn't make sense here. The interviewee states that they don't want to reproduce the DOS attack because other systems along the way will become affected as well (I'm assuming he is talking about routers). Well if those systems get affected (and stop being responsive), then how in the heck can they forward any traffic to the intended system?
TOP DSLR Cameras Reviews of the top DSLRs
My refractory period is at least 15 minutes. Which unsolicited e-mail did YOU respond to?
TCP is a stateful protocol. Each connection consumes resources (memory, timers, etc.) for keeping track of the connection state. Denial of service attacks used to attack the handshake phase by starting the handshake without ever finishing it. That's called SYN-flooding. SYN cookies were invented to defend against that. A lot of work has been done to make sure that computers which don't complete the handshake can't bog down a server. The rationale behind this bias is that those types of attacks can be performed with spoofed packets, which makes the attackers hard to catch, so you must defend against these attacks.
The new attack completes the handshake and then does things which consume an extraordinary amount of resources in the TCP stack of the victim. Apparently all TCP stacks are much too trusting in one way or another if the remote computer completes the TCP handshake.
The researchers have written a port scanner which tracks connections with very little overhead. While researching that application, they came across odd behavior in target machines and even found comments in TCP stack source code which hinted at possible resource problems in certain situations. They proceeded to craft attacks to trigger exactly these problems and found that they could easily bring down machines. Some of the consumed resources are so critical that their exhaustion causes other parts of the OS to fail in ways which can only be corrected by a reboot.
Mod my original post down. Thanks for fixing my mistake.
Comment removed based on user account deletion
A man was found dead in his home today, after a deadly denial-of-service attack.
In lieu of flowers, please send firewalls to your local school.
I hold it, that a little rebellion, now and then, is a good thing. -- Thomas Jefferson
Fyodor of nmap fame writes an article on his site following up on this: http://insecure.org/stf/tcp-dos-attack-explained.html
...quicker, easier, more seductive the darkside is...but more powerful, it is not.
...but wouldn't an obvious way to defeat this attack be to modify the attributes used by the attacker in the SYN packets before sending a SYN ACK, so that exctracting the original information becomes impossible?
duh what's new? TCP/IP was designed without security in mind and during the times of ARPAnet. stop picking the wound. nothing to see here.