Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Fix For Apache DoS Bug In the Pipes

timothy posted more than 2 years ago | from the gurgling-through dept.

Bug 49

Trailrunner7 writes with the report that "The Apache Software Foundation plans to have a fix available in the next day or so [Note: that means today, now. --Ed.] for the denial-of-service problem in Apache that was publicized late last week. The bug, which in some forms has been under discussion for more than four years, involves the way that the Web server handles certain overlapping range headers. The vulnerability is a denial-of-service bug, but it is considered serious because a remote attacker can essentially take a targeted server offline with little effort and resources. The Apache Software Foundation, which maintains the popular open-source Web server, updated its advisory on the vulnerability, saying that it expects to have a full fix available for the vulnerability within the next 24 hours."

cancel ×

49 comments

Apache has an excellent security record. (4, Interesting)

Anonymous Coward | more than 2 years ago | (#37227160)

The one thing that I've found really astounding about this whole ordeal is how despicably some members of the open source community have acted towards Apache and its developers. The pure hatred they have spewed is absurd. For such a large and widely-used piece of software, Apache has a superb record of being secure and reliable. The ridicule it has received lately, especially from the open source community, is disheartening.

Somewhat surprisingly, this criticism has been coming from PHP, Ruby and JavaScript programmers. Many of these people likely don't even know C. Yet they still feel it necessary to belittle the Apache developers for making what is actually a very obscure mistake many years back. Of course, these people delivering the criticism won't admit that their own software is far buggier and insecure than Apache. The developers of PHP would never break a critical security-related function like crypt(), right?

Offensive (2, Interesting)

Anonymous Coward | more than 2 years ago | (#37227394)

From the article:

"This problem is so obvious, my grandmother could identify it."

As a 49 yo grandmother, C programmer of 20+ years, and a feminist this offends me. They wouldn't have said grandfather.

Re:Offensive (1)

Anonymous Coward | more than 2 years ago | (#37227544)

Calm down dear. They were simply taking an example of someone who isn't good with computers, which in most people's cases could equally be the grandfather.

That's not even in the article. (0)

Anonymous Coward | more than 2 years ago | (#37227610)

Nice try. That quotation isn't even in the article.

It's clearly not an obvious flaw, either. That's why Apache 1.3, 2.0, and 2.2 were affected. It went years without being detected, and Apache has had many thousands of eyes look upon its code.

Re:Apache has an excellent security record. (0)

Anonymous Coward | more than 2 years ago | (#37227834)

This problem has existed since 2007, the apache devs pooh-poohed it. Now they have egg on their face. So what? Move on, it hasn't affected anyone other than a tiny number of developers and their credibility.

Go and read the original bug notice, and the shitty developer attitude for a more rounded picture. They were told about it, they were shown how to replicate it, but they chose to belittle the report.

Re:Apache has an excellent security record. (1)

ToasterMonkey (467067) | more than 2 years ago | (#37228206)

Somewhat surprisingly, this criticism has been coming from PHP, Ruby and JavaScript programmers. Many of these people likely don't even know C. Yet they still feel it necessary to belittle the Apache developers for making what is actually a very obscure mistake many years back

Let me ask, is mixing free and non-free software acceptable to you? The FLOSS community promotes using open source above all else, for the sake of more people using open source. If "shut up if you can't program" was their motto, its user base should be a tiny fraction of what it is. Unless you think people like being told to "shut up and use it anyway."

You wouldn't DARE tell me, not-a-programmer, use open source "just because", and do not complain about it, in anything short of suicidal fantasies. UNIX system admins are the reason you exist, so suck my ass.

I stopped recommending open source - just because it was open source - a long time ago, because the reality is, it's run by a whole lot of people with attitudes like this.

Grow up folks, buy software when it works.

Re:Apache has an excellent security record. (0)

Anonymous Coward | more than 2 years ago | (#37228432)

What the hell are you going on about?

The GP is talking about the users and advocates of some of the most flawed software ever written (PHP and RoR) insulting the developers of some of the best, most widely-used software ever (Apache) over what's a very minor bug that's easily remedied.

That's completely orthogonal to whatever the fuck you're strung up on.

Re:Apache has an excellent security record. (1)

bgat (123664) | more than 2 years ago | (#37228484)

Grow up folks, buy software when it works.

You let me know how that works out for you.

In particular, I'd love to know what browser you are using to produce your rant, cause I'm not aware of any browser implementation available today that "works" in the manner you suggest they should.

In the meantime, I'll stick with what "reasonably works, and coincidentally works better than the commercial alternatives". You know, like, Apache.

Re:Apache has an excellent security record. (0)

Anonymous Coward | more than 2 years ago | (#37228584)

While I agree that the hatred is based on their stupidity and ignorance (the PHP ones doubly so), this is not what I want to comment about. I want to comment or your view of C as if it was something to aspire to.
You talk as if writing a serious application in C (or C++ for that matter) would be a good thing.

C has its purposes. Like writing the lower layers of a kernel, drivers, etc.
But for applications, it's deeply wrong. As wrong as writing them in any of the mentioned scripting languages. (Which are the other extreme.)

A application should not have to implement all the low-level meddling like memory management, thread management, etc. That is a (configurable) feature of the OS and build system. If you want to improve that, improve in in there. If you want to adapt it to your needs, configure it that way.
It is implemented once, and done properly. To then be used by the applications.

I, for example, deliberately worked right around C and C++. I started out with Pascal and assembler (after playing with GWBasic as a child), then Java (and a couple of scripting languages for the glue), and then I started to learn C and C++. After a short time (easy to learn for someone having done all the stupid memory juggling in Pascal, and knowing the syntax from Java) I realizeds that it was such a primitive (for C) and poorly designed (for C++) mess, that I couldn't bear looking at that FAIL anymore. So I designed my own language. (With hookers. And black jack! ;) Only to find out that somebody had already done that, and done it better, by designing Haskell. So I switched right over to Haskell for everything (except mobile phones that I can't get GHC to compile for yet).
Now although there are also other good alternatives, of course it doesn't even have to be a functional language. But it should still be high-level and clean. The right tool for the job. Not that outdated mess that C is. (Which, by the way, is a simplistic joke compared to Haskell... just in case you thought it would be a "advanced" or "professional" language. To me, C now feels like a simple scripting language for noobs, but with lots of useless repetitive pains inside it.)

Re:Apache has an excellent security record. (1)

bonch (38532) | more than 2 years ago | (#37229384)

Your entire post is basically that you don't like seeing Apache criticized on message boards. So what? You even end with a pointless remark about programmers you assume don't know C, as if that has anything to do with anything. Apache brought criticism onto themselves. The bug is more than four-and-a-half years old.

Re:Apache has an excellent security record. (1)

Onymous Coward (97719) | more than 2 years ago | (#37232536)

Apache brought criticism onto themselves. The bug is more than four-and-a-half years old.

This memory allocation bug is distinct from Zalewski's bandwidth multiplying bug.

Indeed, both stem from "silly" Range handling, but they are still different bugs. I.e., the bug is not 4+ years old.

LAMP = MOST ATTACKED by (0)

Anonymous Coward | more than 2 years ago | (#37230352)

Spammers & Phishers - To wit:

LAMP is the favored attack for phishers & spammers:

http://www.theregister.co.uk/2011/06/10/domains_lamped/

---

PERTINENT QUOTE:

"Phishers compromise LAMP-based websites for days at a time and hit the same victims over and over again, according to an Anti-Phishing Working Group survey.

Sites built on Linux, Apache, MySQL and PHP are the favoured targets of phishing attackers,"

---

* "Read 'em, & WEEP", Open SORES people...

APK

Re:LAMP = MOST ATTACKED by (1)

Anonymous Coward | more than 2 years ago | (#37231252)

Apache is the #1 server on the Internet. Of course it's the #1 attacked too. Duh! Go back under your bridge, troll.

Calling truth's trolling doesn't make it trolling (0)

Anonymous Coward | more than 2 years ago | (#37234706)

See subject-line above, & it's obvious YOU can't handle the truth!

APK

P.S.=> The ONLY reason Apache is the most used webserver IS ZERO CO$T OF PURCHASE, period (yet another truth), NOT THAT IT IS A SUPERIOR PRODUCT vs. say, IIS7!

... apk

Not just an Apache bug (5, Insightful)

Kickasso (210195) | more than 2 years ago | (#37227164)

It's a protocol bug. Any server that implements the protocol to the letter is vulnerable. And it's not just about overlapping ranges. If the server can send a ten megabyte file, an attacker can ask it for ten million of one-byte ranges. The processing overhead will bring most servers to their knees. If the server can compress the output, an attacker can ask for ten million of compressed one-byte ranges. An attempt to execute such a request will kill just about anything. The protocol should have limited the number of ranges per request to, say, 10.

Re:Not just an Apache bug (1)

Jamu (852752) | more than 2 years ago | (#37227232)

Obviously Apache isn't doing so at the moment, but is there any reason it couldn't just take a long time to fulfil the request?

Re:Not just an Apache bug (2)

perlchild (582235) | more than 2 years ago | (#37227374)

If Apache doesn't return an error code it will have to keep the connection open, and you're back at the "consuming so many resources it's denying legitimate traffic" part of the denial of service.

Re:Not just an Apache bug (1)

tepples (727027) | more than 2 years ago | (#37227608)

If Apache doesn't return an error code it will have to keep the connection open

What part of the HTTP spec bans issuing a 400 Bad Request when something looks like a DoS? And is there a reason why Apache can't hand off thousands of connections to a separate, lightweight "penalty box" server process?

Re:Not just an Apache bug (1)

aztracker1 (702135) | more than 2 years ago | (#37227840)

65535 connections for TCP (minus a few) per server... as long as each connection stays open, poof, no more room at the inn.

How about ten thousand (1)

tepples (727027) | more than 2 years ago | (#37227908)

I was thinking on the order of 10,000 connections handled by the penalty box. A server under attack might randomly choose to use 400 Bad Request, use 503 Service Unavailable, or handle the connection slowly, with the frequency of error-code responses increasing as the penalty box fills up.

Re:Not just an Apache bug (2)

ivoras (455934) | more than 2 years ago | (#37227950)

65535 connections for TCP (minus a few) per server...

To be pedantic, that's 65535 per (client_ip,port) pair...

Re:Not just an Apache bug (2)

raynet (51803) | more than 2 years ago | (#37227256)

It all depends how you implement it but yes, it would have been wiser to let the server discard some of the ranges if needed and ask the client to do another request later.

Re:Not just an Apache bug (2)

amorsen (7485) | more than 2 years ago | (#37227354)

The protocol does not require the server to answer at all. The server can just send an error response if it gets too many ranges in a request. The protocol designers cannot know how many resources a given server has available. The most they could do was add a specific error response for "too many ranges, resubmit as individual requests".

Re:Not just an Apache bug (-1)

Anonymous Coward | more than 2 years ago | (#37227470)

Nice try, apologist. I've already tested this with both Cherokee and nginx and neither were affected. The Apathy Foundation's refusal to do anything about this particular bug is the reason many of us have moved on.

Go ahead though, try and find some "that's because Apache is better" way of justifying it.

Re:Not just an Apache bug (0)

Anonymous Coward | more than 2 years ago | (#37227728)

nginx? Seriously? It can't even run CGI scripts. That's the most basic dynamic web technology around. If it can't run CGI scripts, then it's useless for many people.

Re:Not just an Apache bug (0)

Anonymous Coward | more than 2 years ago | (#37227954)

It can run FastCGI scripts, which is what anyone with half a brain should be using.

Re:Not just an Apache bug (0)

Anonymous Coward | more than 2 years ago | (#37230826)

FastCGI is not the solution. The solution is for nginx to man up and support CGI scripts like every decent web server out there.

Re:Not just an Apache bug (0)

Anonymous Coward | more than 2 years ago | (#37231014)

nginx is made for caching, load balancing, and static files.
Go jump on the node.js boat if you insist on using the wrong tool for the job...

Re:Not just an Apache bug (2)

Kickasso (210195) | more than 2 years ago | (#37228300)

How did you test? nginx does honor Range requests. The Apache killer will report that nginx not vulnerable, so what, it misreports PHP-based Apache installations too. However, this attack can be performed in more than one way. Maybe you should know that nginx maintainers have released a patch today. I wonder why.

I have read that IIS is vulnerable to this too, not sure if this is true, I have no IIS installations that I can check.

I'm not sure what Cherokee does so I can't comment here.

Re:Not just an Apache bug (2)

jevan (104286) | more than 2 years ago | (#37227716)

Apache's implementation problems go beyond the protocol specs. The sample attack codes includes invalid ranges in the request (E.g start at 5, end at 0). So the protocol specs aren't the only thing to blame. Also, the fact that apache is the only server to be crippled by this issue is a strong data point against putting all blame on the protocol.

Re:Not just an Apache bug (1)

Kickasso (210195) | more than 2 years ago | (#37228188)

Apache has its share of its own unique bugs, that's true.

indeed (0)

For a Free Internet (1594621) | more than 2 years ago | (#37227200)

a mitie fine goat tudrd it ise is the todaieee!!!!! fart

I hear... (0)

eexaa (1252378) | more than 2 years ago | (#37227282)

the sound of millions lazy sysadmins compaining!

Re:I hear... (0)

Anonymous Coward | more than 2 years ago | (#37227496)

More like the sound of millions of UNDERSTAFFED sysadmins complaining. How many hundreds of production servers are *YOU* responsible for?

Hundreds? (0)

Anonymous Coward | more than 2 years ago | (#37227688)

More like a dozen.

I do pity you public-school-teacher equivalent sysadmins though, I guess.

Re:I hear... (5, Informative)

digitalchinky (650880) | more than 2 years ago | (#37227746)

I am utterly lazy, but a few moments in google and I added the following to my domains:

RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^(HEAD|GET) [NC]
RewriteCond %{HTTP:Range} ([0-9]*-[0-9]*)(\s*,\s*[0-9]*-[0-9]*)+
RewriteRule .* - [F]

It certainly makes the exploit fail which is good enough for me until Apache gets a fix going.

Re:I hear... (2)

thebjorn (530874) | more than 2 years ago | (#37229740)

Request-Range is also affected, better turn it off: RequestHeader unset Request-Range

Re:I hear... (1)

Onymous Coward (97719) | more than 2 years ago | (#37232570)

Request-Range? I'm not familiar with that request-header field. Searching now, I can't find it in RFC 2616 [ietf.org] either. Could you point to where you heard about it?

I wonder if... (1)

ryanmcdonough (2430374) | more than 2 years ago | (#37227376)

This is the main exploit used by the Jester for attacks on Apache servers?

Pipes? (0)

Anonymous Coward | more than 2 years ago | (#37227480)

I thought we were calling them tubes.

Re:Pipes? (1)

KingMotley (944240) | more than 2 years ago | (#37228096)

Pipes are 1/8 of a tube.

YOU F\AIL IT? (-1)

Anonymous Coward | more than 2 years ago | (#37227512)

How many SysAdmins will be logged in on Sunday? (1)

adosch (1397357) | more than 2 years ago | (#37227682)

Next 24 hours puts this fix release on Sunday. I, myself, can't wait to let my Apache source compiles rip upon release.

All jokes aside, what baffles me is even if you're clueless when it comes to Apache webserver security, there's plenty of best practices out there, especially using mod_security with some tuned SecRule's. The mitigation steps Apache provided (using mod_rewrite) almost identically mirror the out-of-the-box SecRule's provided at gotroot.com [gotroot.com] . This isn't a soapbox plug, I just think that this attack really isn't "new" as I've compensated for it for years on any Apache webserver setup, public or private facing. Might be a good idea for 'whomever' is supporting Apache to spend some time securing it so you don't waste your Sunday evenings.

Re:How many SysAdmins will be logged in on Sunday? (1)

Anonymous Coward | more than 2 years ago | (#37228472)

Yeah, once this hits our change control procedures - gets through an internal review or three, jumps through our unreliable release process (after getting munged by several git merge conflicts) it'll fly right on out to our 2k machines RSN. Oh yeah, did I mention how we wouldn't be bothering to test to make sure it doesn't cause any problems in QA?

bugs and beetles (0)

FalseModesty (166253) | more than 2 years ago | (#37228240)

Slashdot's icon for a bug is a picture of a beetle? I thought this was news for NERDS.

http://en.wikipedia.org/wiki/Hemiptera [wikipedia.org]

What's today? (0)

Anonymous Coward | more than 2 years ago | (#37228360)

The Apache Software Foundation plans to have a fix available in the next day or so [Note: that means today, now. --Ed.

It doesn't take a genius to see that this gets stale in a couple of hours. What is today? Now? You might like when it was submitted to slashdot? Put a numeric date in your posts!

nginx patch here (0)

Anonymous Coward | more than 2 years ago | (#37228478)

patch for nginx

http://mailman.nginx.org/pipermail/nginx/2011-August/028779.html

Unit tests (0)

Anonymous Coward | more than 2 years ago | (#37229976)

Good unit tests would have caught this problem.

Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...