> >On Friday, 2002-08-30 at 18:33:13 +0000, 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
