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 ..." |
