Re: How to limit the size of requests ?
[follow-ups set] PMFJI: Buffer overflow in this case happened because of sub-requests - which are hard to deal with at any rate. The actual GET/POST had nothing to do with the insecure action as far as this issue is concerned, the side effect was caused by the way the sub-request handled the execution/hand-off, so the hack was approximately 50 bytes in size (BTW, I have the BSD C source code for the hack if you want it.) And yes, not to toot any horns, but 'them Apache Groupies' are pretty sharp ! ;) HTH/Sx :] (just another ApacheCon 2000 Orlando Speaker :) On Friday, August 30, 2002, at 02:33 PM, HalbaSus wrote: > than packetstorm and securityfocus ? Buffer owerflow under 500 > characters ???
Re: Re: How to limit the size of requests ?
> >On Friday, 2002-08-30 at 18:33:13 +, HalbaSus wrote: > >> About that stoopid way of preventing buffer owerflows... Well, tell me a >> better one. Of course you can patch known bugs. But... how are you gonna >> prevent new buffer owerflows ? > >Auditing? don't you think that before releasing any version of apache they DID some auditing ? just because you don't find any buffer owerflows it doesn't mean that there are NO buffer owerflows > >> What if the guys with 0-day warez are faster >> than packetstorm and securityfocus ? >Read BUGTRAQ and Full-Disclosure. But as I said, you can't prevent this >from happening. If you could by simply writing a wrapper, how many >protective wrappers would we have now? More than a newly wed couple at >the start of their honeymoon. First of all I'm on securityfocus's and bugtraq mailing list and I'm regularly checking packetstorm. Still I have friends in the underground who did have for example that famous wu 2.6.2 exploit before the vulnerability was =FOUND= officially (and by this I don't mean releasing the exploit on packetstorm or anything). A protective wrapper doesn't always protect you (it would be hard to filter out all the IIS/unicode/msadc/sql bugs) and I know that limiting the input doesn't mean 100% security BUT... 1. I've been looking at these new apache exploits and all of them send huge amounts of data (not mentioning bruteforce options when the sent data can be compared to a a DoS tool :). 2. My site the way it is doesn't require forms 'n stuff... when it will I will change the limitations. > >> Buffer owerflow under 500 characters ??? > >Sure. There are single-byte overflow exploits in circulation. > Really, I don't think an apache exploit will be able to send a buffer owerflow under at least 500 characters... (all exploits in circulation for apache send much more than that). >> (don't forget that it has to be inserted in a valid input field (User Agent, >> or something)). And that 500 char. limit was just like a guessing... it's not >> really something i calculated. > You know what ? Closing telnet, rpc, imap and all unusefull services is not a "cool" way to secure your system. Yet it's workin quite well. I'm not saying that this is the most profesional aproach of security. But it's workin (just for the sake of testing I instaled apache 1.3.24 on my freeBSD and ran the apache-nojob exploit. Successfully! I aplied the limitations and the exploits crashed after a few lines. Simple as that. It's not the best sollution but it's certanly working) > >> If you want to see how does a b0f act start >> /apache-nojob localhost:69 (and fire up a netcat listening on port 69) >> About the posting stuff.. don't worry about that... my site doesn't need to do >> posting... so... everybody's happy :) > >I'm not arguing about what your site needs (actually I expected so much, >but things change, and *presto* you have your first feedback form ;-), >but what to do about Apache (and mod_perl) security in general. You >know, these discussions find their ways into archives, and somebody else >might find this thread looking for advice. > >So I want in no way to prevent you from doing with your webserver >whatever you choose to do (Romania is a free country, too! And I'm glad >about that), just to point out that this gains you little and may in >fact weaken your security. Well as I said before, and really, this should end the discusion, I'm not preaching for limiting the input and not worying about new vulnerabilities, patches, etc... BUT... It's a good way to prevent buffer owerflows and DoS attacks. That's all... It might be a little bit dirty and totally unacceptable for some sites (using forms for example) but adds some extra security to a patched apache... that's all >HTH, >Lupe Christoph >-- >| [EMAIL PROTECTED] | http://www.lupe-christoph.de/ | >| Big Misunderstandings #6398: The Titanic was not supposed to be | >| unsinkable. The designer had a speech impediment. He said: "I have | >| thith great unthinkable conthept ..." | Home, no matter how far... http://www.home.ro
Re: How to limit the size of requests ?
On Friday, 2002-08-30 at 18:33:13 +, HalbaSus wrote: > About that stoopid way of preventing buffer owerflows... Well, tell me a > better one. Of course you can patch known bugs. But... how are you gonna > prevent new buffer owerflows ? Auditing? > What if the guys with 0-day warez are faster > than packetstorm and securityfocus ? Read BUGTRAQ and Full-Disclosure. But as I said, you can't prevent this from happening. If you could by simply writing a wrapper, how many protective wrappers would we have now? More than a newly wed couple at the start of their honeymoon. > Buffer owerflow under 500 characters ??? Sure. There are single-byte overflow exploits in circulation. > (don't forget that it has to be inserted in a valid input field (User Agent, > or something)). And that 500 char. limit was just like a guessing... it's not > really something i calculated. This is no way to approach a security problem. > If you want to see how does a b0f act start > /apache-nojob localhost:69 (and fire up a netcat listening on port 69) > About the posting stuff.. don't worry about that... my site doesn't need to do > posting... so... everybody's happy :) I'm not arguing about what your site needs (actually I expected so much, but things change, and *presto* you have your first feedback form ;-), but what to do about Apache (and mod_perl) security in general. You know, these discussions find their ways into archives, and somebody else might find this thread looking for advice. So I want in no way to prevent you from doing with your webserver whatever you choose to do (Romania is a free country, too! And I'm glad about that), just to point out that this gains you little and may in fact weaken your security. HTH, Lupe Christoph -- | [EMAIL PROTECTED] | http://www.lupe-christoph.de/ | | Big Misunderstandings #6398: The Titanic was not supposed to be| | unsinkable. The designer had a speech impediment. He said: "I have | | thith great unthinkable conthept ..." |
Re: How to limit the size of requests ?
Well first of all I would like to thank Geoffrey's input... you know RTFM... that's all if I would have read about LimitRequest's before would have spared me like 2 days of coding... About that stoopid way of preventing buffer owerflows... Well, tell me a better one. Of course you can patch known bugs. But... how are you gonna prevent new buffer owerflows ? What if the guys with 0-day warez are faster than packetstorm and securityfocus ? Buffer owerflow under 500 characters ??? (don't forget that it has to be inserted in a valid input field (User Agent, or something)). And that 500 char. limit was just like a guessing... it's not really something i calculated. If you want to see how does a b0f act start ./apache-nojob localhost:69 (and fire up a netcat listening on port 69) About the posting stuff.. don't worry about that... my site doesn't need to do posting... so... everybody's happy :)
Re: How to limit the size of requests ?
>>my the time mod_perl enters the request, Apache has already taken care >>of parsing the request, so there's not much you can do about it (in >>1.3, at least). > > > Parsing the request *headers*. So you can't prevent any overflow in the > headers with mod_perl. well, headers and the request line, which includes the query string. that's what I meant :) > You *can* prevent the chunked encoding overflow, > because that happens in the "body". > and I mentioned a few ways to control that, IIRC :) --Geoff
Re: How to limit the size of requests ?
On Friday, 2002-08-30 at 09:22:47 -0400, Geoffrey Young wrote: > >I have written a perl script which prevents browsers (or evil exploits) to > >send buffer owerflows to apache. Basicaly this script is supposed to > >listen on port 80 for incoming connections. The input (from browsers) is > >read up to 500 characters. Excuse me, but that's a Stoopid(tm) way to try to prevent buffer overflows. What if the buffer is smaller than your limit. What about POSTed content? 500 characters is really small for complex forms. IIRC the chunked encoding buffer overflow required less than 50 bytes: > >Some friend of mine told me that apache perl modules should be faster so > >here's my question. How do I limit the webclient's input to a number of > >characters, bytes whatever... > my the time mod_perl enters the request, Apache has already taken care > of parsing the request, so there's not much you can do about it (in > 1.3, at least). Parsing the request *headers*. So you can't prevent any overflow in the headers with mod_perl. You *can* prevent the chunked encoding overflow, because that happens in the "body". AFAICT, this was the first Apache buffer overflow in a long time. Ever? Those folks ssem to be pretty sharp. Can you guarantee you're at least as sharp as they are, or will you introduce new vulnerabilities in your code? Does it really drop all priviledges, etc? Secure programming is hard. That's why so many people fail in it... Lupe Christoph -- | [EMAIL PROTECTED] | http://www.lupe-christoph.de/ | | Big Misunderstandings #6398: The Titanic was not supposed to be| | unsinkable. The designer had a speech impediment. He said: "I have | | thith great unthinkable conthept ..." |
Re: How to limit the size of requests ?
> I have written a perl script which prevents browsers (or evil exploits) to > send buffer owerflows to apache. Basicaly this script is supposed to listen > on port 80 for incoming connections. The input (from browsers) is read up to > 500 characters. don't the apache directives: LimitRequestBody LimitRequestFields LimitRequestFieldsize LimitRequestLine essentially do what you are coding yourself? > Some friend of mine told me that apache perl modules should be faster so > here's my question. How do I limit the webclient's input to a number of > characters, bytes whatever... my the time mod_perl enters the request, Apache has already taken care of parsing the request, so there's not much you can do about it (in 1.3, at least). if you use Apache::Request (part of libapreq) you can limit the message body (POSTed content) via some directives and throw out an informative message. or you can use mod_perl's native read() method to read only so much data from the client. there are lots things to learn in mod_perl, and there is lots of online material and books to help. http://perl.apache.org/help/index.html is a good place to start. --Geoff
How to limit the size of requests ?
Hi list ! I subscribed to this list because I want to learn more about mod_perl and apache. I'm familiar with perl but recently I had to surender using the old fashioned plain perl use IO::Socket; scripts... I have written a perl script which prevents browsers (or evil exploits) to send buffer owerflows to apache. Basicaly this script is supposed to listen on port 80 for incoming connections. The input (from browsers) is read up to 500 characters. Here's a sample from the script: for(;$paddr = accept(CLIENT,SERVER);close CLIENT){ open(STDIN,">&CLIENT");open(STDOUT,">&CLIENT");open(STDERR,">&CLIENT"); recv CLIENT,@input,500,0; After the program reads the browsers input he sends it to an apache webserver sitting on port 3000 (and only accepting connections from localhost), then the script grabs the httpd's reply and sends it back to the client listening on port 80. The problem is that this program slows down the connection creating 30 second lags (YES i removed buffering). Some friend of mine told me that apache perl modules should be faster so here's my question. How do I limit the webclient's input to a number of characters, bytes whatever... Best regards HalbaSus --- Proud member of PentaGuard "Making the net a safer place since 1998"