Feeds

back to article Tiny-traffic DoS attack spotlights Apache flaw

Security guru Robert "RSnake" Hansen has released a novel DoS attack tool that points to a significant flaw in Apache and other webservers. Hansen calls his creation "Slowloris - the low bandwidth yet greedy and poisonous HTTP client." Unlike an old school Denial of Service attack, which ties up a website by bombarding the thing …

COMMENTS

This topic is closed for new posts.
Happy

IIS

"Webservers like IIS uses a "worker pool," allowing as many open connections as its resources will allow."

But it can't have more 'resources' (aka threads) that a machine of the same spec. So we're talking again 1 to 1, or at max 2 to 1 to defeat them as well.

Apache simply allows you to configure the number of threads, so if the value is not low enough, there are no problems either. Experienced/savvy admins use stress testing tools before deployment.

Others get what they deserve.

1
0
Tel
Pirate

Nasty...

But... if it's not really going to affect the popular sites out there, then there'd be very little point in hitting the rest: after all, why bother DOSing a web server that hosts sites very few people actually look at anyway?

0
0
Bronze badge
Thumb Down

Breaking news for the last decade

As Hansen recently discovered, this is an ancient attack. It was actually a common side effect of buggy dialup modems in the 90s. These modems would switch protocols, re-calibrate, and corrupt data constantly so that the connection degraded to very tiny packets coming in very slowly. It was just fast enough to evade socket timeouts but so slow that the server would eventually become overwhelmed serving many broken modems concurrently.

Death by slow requests was more troublesome when enterprise servers had 64MB of RAM and no firewall. There are workarounds today.

0
0
Thumb Down

This is news?

This 'vuln' has been known about for a long, long time. I was of the impression that this was how the vast majority of HTTP DOS based attacks were carried out...? Clearly, I'm in the wrong job and that Captain Obvious cap belongs to me.

0
0

Not really new

The idea of DOS'ing a server by flooding it with SYN packets and no ACKs has been around for at least a decade. This is essentially the same thing, using HTTP rather than TCP.

0
0
Gates Halo

Wait, Wait, Wait....What?

<quote>but his attack doesn't affect IIS6.0, IIS7.0</quote>

A flaw that doesn't affect MS? The world as I know it is upside-down.

0
0
Paris Hilton

Forgive my ignorance...

but doesnt this sound an awful lot like that happened to the shields up guy (google says his name is steve gibson)

ah RTFA tells me this attack is a http one, not a SYN flood like Gibsons problem was, and "NOT a GET request flooder"

How many people will not have RTFA?

either a) everyone is cleverer than me and will not have made that initial mistake,

or b) fortunately this is the internet and ill bet (1p) at least one person will have done it as well.

take a cheque?

0
0
Silver badge

Solid Gold or Vapourware.

"take a cheque?" A bank's guarantee to pay and transfer credit? Why ever not? Are they not Personal Gilts, System Guaranteed?

0
0
Pirate

It may be old...

But it still works (well), very often old vulnerabilities do work (like the humble Ping-Of-Death), far too many system admins ignore the older vulnerabilities and concentrate on the latest (arn't we clever) exploits.

0
0
Silver badge
Heart

@ FirstPosting AC

That would be all fine and good, *IF* the other web servers mentioned used apache's model of dedicating a heavy thread or (worse) process to each connection. I don't know about IIS, but lighttpd does not do this. It uses a light-weight thread to handle multiple connections (easily into the hundreds). An idle thread causes almost NO load on a lighttpd server.

The only resouce to be worried about on Lighttpd would be file-discriptors, and that likely has gotten better (I last ran it on a 32-bit machine)

In fairness, I'm told Apache 2 can be configured similerly, but it is not the default, and nowhere near as well documented as it's "prefork-mode"

0
0
Stop

Disingenuous

"Apache did not respond to our request for comment on the bug."

Did you give us time to respond? The date stamp on your email is just over an hour (72 minutes, to be precise) before that of this article.

This is not new, and a trawl through Apache mailinglists will find a few mentions of it over the years. For example, the Event MPM effectively nullifies this attack, and was first included in a production release of Apache in 2005.

0
0
Bronze badge

asymmetric resource requirements

Are the hallmark (or even definition) of any DOS attack, no? So this "new-skool" attack isn't really anything of the sort. It is kind of interesting that Apache is vulnerable to this slow starvation attack but I don't see why IIS shouldn't also be vulnerable(*). So long as the web server keeps all valid connections alive, and the client can drag out telling the server what it wants done for long enough, sooner or later it's going to run into some sort of limit on the number of open sockets/running threads, whether that's a limit built into the server or the OS it's running If the server has a high number of these resources, relative to the attacker, then obviously multiple attack machines are needed, but once the tipping point has been reached, it's only a matter of time before the server is starved out.

(*) At least I can't see anything in the article that says that IIS expires connections in the request phase if they're dawdling too much, which seems to be the obvious defence. AC at 00:56 makes the same point.

0
0

@Tel

There actually are small companies depending on web presence ;)

It might not be useful if you're after headlines, but still a mean little trick if your goal is to lock up your competitior's website/shop for some time (or whoeverelse's you might want to damage).

0
0

mod_cband

mod_cband would seem to mitigate this problem for now, using CbandRemoteSpeed to limit simultaneous connections to a reasonable level. Be careful with the setting, especially on web2.0rrhoea sites and do note that mod_cband's restrictions need to be applied to vhosts, not globally.

Also, the Slowloris code seems to hint at a global Timeout setting <166 seconds being problematic:

if ( $delay < 166 ) {

print <<EOSUCKS2BU;

Since the timeout ended up being so small ($delay seconds) and it generally takes between 200-500 threads for most servers and assuming any latency at all... you might have trouble using Slowloris against this target. You can tweak the -tcpto flag down to 1 second but it still may not build the sockets in time.

EOSUCKS2BU

}

I generally have mine set to 45 and broken modems and slowpokes be damned. The default is assumed to be 300 seconds or five minutes but we wouldn't go shoving an httpd up with the defaults, would we?

0
0
IT Angle

Dear Reg

I would like to submit a proposal for (2) new icons:

"Where is the GTA angle?"

"Where is the sailing angle?"

GTA seems to the source of all society's ills and so it quite often comes up in articles.

Sailing angle can refer to a new age of exploration.

0
0

A 'fraction'?

"We're really only talking about a fraction of the Apache sites out there," he says.

Apache 2x is quite common, no? And the web is mostly comprised of sites that aren't big news and retail sites. Seems like quite a big fraction to me.

Here's hoping most of the web's sysadmins are using workarounds for it, really.

0
0
Thumb Down

@Nick Kew

"For example, the Event MPM effectively nullifies this attack, and was first included in a production release of Apache in 2005."

It may well be included in production releases of Apache, but the documentation for the latest release says:

"This MPM is experimental, so it may or may not work as expected." (http://httpd.apache.org/docs/2.2/mod/event.html).

0
0

Apache trying to spin this a bit, methinks

They are quite correct that this sort of thing isn't new, but:

" For example, the Event MPM effectively nullifies this attack, and was first included in a production release of Apache in 2005."

So I go to the apache website:

http://httpd.apache.org/docs/2.2/mod/event.html

"This MPM is experimental, so it may or may not work as expected."

"Production" and "experimental" are mutually exclusive, no?

0
0

blow me

"epic amounts of traffic"

epic? EPIC? wtf. Bad register, bad.

0
0
Stop

Response from Apache

Please don't take my comment as an official response from Apache. It was merely intended as a reaction to your publication at 12:15 GMT having emailed an hour earlier.

I think it's unlikely to represent the whole story, and I've neither done enough testing to give an informed response, nor consulted with my colleagues on the subject. If and when I do, it's unlikely to be in a comment posted on someone else's article!

0
0
Anonymous Coward

Tarpitting

Frankly it just sounds like a form of tar pitting to me, and that is neither new or novel.

So nothing new here at all, there is nothing to see, please move along.

0
0
Gold badge
Alert

So this is a generic attack

IE its a feature of any protocol which has a negotiation type structure.

From old modem DOS attacks to new HTTP. Same protocol structure -> Same protocol attack.

So the same countermeasures should be feasible.

But I doubt these are the only protocols on the Web that work in this fashion.

Time to check the RFC's

0
0
Heart

Glad I use IIS

and the only LInux box I use has lighttpd installed instead of Apache.

0
0

To all those "not affected" people ...

As I read it, IIS and lighthttp ARE vulnerable - but in a different way. OK, they need to hold a connection until it times out or the client closes it, but they don't use huge amounts of resource to do so.

So you've got oodles of partial requests held, and then suddenly the client completes them all ? This needs very little traffic from the client (MUCH less than opening the original request connection), and suddenly your sever is expected to handle many, many times it's normal peak load.

I hope these servers have some form of protection against a flood of requests that complete at once - there's a good chance this technique could bypass connection rate limiting if it is applied to connections as they are opened.

0
0
Flame

@Nick Kew

Most serious organisations I have worked for will commit to reply to e-mails inside the hour.

All others either do not treat e-mail seriously as a modern communications medium, or do not know how to handle time-sensitive e-mails so that another member of the team can respond to these messages when they arrive (honestly, the idea that an important person is not covered by someone else in the event of their unavailability at any point in time is, quite frankly, laughable.)

You were caught napping. Just because e-mail is a non-interactive communications medium, does not mean you can safely ignore messages until you get around to dealing with them. Whining about the fact that 72 minutes passed before anyone in your organisation checked their inbox is, to be honest, more of a statement of the Apache Foundation's own business standards than The Register's.

0
0
Flame

Your message will be ignored

@AC Monday 22nd June 2009 11:54

"""

Just because e-mail is a non-interactive communications medium, does not mean you can safely ignore messages until you get around to dealing with them.

"""

Err, it does mean precisely that. Deal with it!

The only redeeming feature of email is that one absolutely *can* ignore the mailbox until the appropriate time to deal with the whole lot arrives - instead of being rudely interrupted all the time.

Those "serious organisations" you like so much will, IMO, be the same ones where you "improve" "the email response time"-KPI by routing all communication through several layers of useless twits causing only the most determined (or desperate) people to actually reach someone that can deal with whatever the problem was!

PS: I have nothing to do with Apache whatsoever.

0
0
Thumb Down

MPM "Solution"

I'm reading at http://httpd.apache.org/docs/2.2/mod/event.html that:

"At present, this MPM is incompatible with mod_ssl, and other input filters."

I'd call that a non-solution if ever I heard one.

0
0
Flame

@AC Monday 22nd June 2009 11:54

Email is not meant to have instantaneous response. If you can deal with every email that comes in on the second it comes in, good for you. Nik wasn't able to respond to El Reg's email in less than 72 minutes, so what? Doesn't mean he's evil or the product is evil or the company is evil. MS probably would of waited days then sent a generic non-answer.

Bottom line - email gets answered when I want, if I want. I'm sure other people feel the same way.

No I don't work for Apache either - I'm an email admin for a large retail chain store.

0
0
Silver badge

FreeBSD is not affected

FreeBSD has kernel http_accept filters that hold all requests that aren't completed. This functionality is about 10 years old.

I tried this program on my modest server, first setting all the timeouts to the default, and the program had no effect.

Only when I disabled accept filters did the program do as it is suppose to:

http://www.freebsd.org/cgi/man.cgi?query=accf_http

http://httpd.apache.org/docs/1.3/mod/core.html#acceptfilter

http://httpd.apache.org/docs/2.2/mod/core.html#acceptfilter

One in the eye for the Linux fanboys.

0
0
Silver badge

oh bugger

please ignore my last message

0
0
Unhappy

Fix the bug!

I can see why they don't want Event MPM as an official comment.

http://httpd.apache.org/docs/2.2/mod/event.html

Because of:

"Warning

This MPM is experimental, so it may or may not work as expected."

and

"Issues

At present, this MPM is incompatible with mod_ssl, and other input filters."

So, it may nullify the problem, but it doesn't fix it and it is a sloppy piece of crap. They should just do a bug fix on apache instead!!!

0
0

The Event MPM is not a solution.

I know it has already been mentioned that the Event MPM is not a solution because a) it's experimental and b) it doesn't support SSL, but you are forgetting the most important point:

The Event MPM is just as vulnerable as the Pre-Fork and Worker MPMs.

0
0
This topic is closed for new posts.