httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Purl Gurl <purlg...@purlgurl.net>
Subject Re: [users@httpd] Re: Bug Versions 1.3.28/29 Fixed In 1.3.31 OrNot?
Date Tue, 18 May 2004 02:59:07 GMT
Ben Chabot wrote:
 
> > It is not a matter of preventing logging. This is a matter of
> > logical "clean" logging.
 
> Logical logging is to log all connection attempts.

I did not state to not log connections nor hinted at this.

Please pay attention or resist this temptation to twist
my words into something I did not write.

I very clearly state, "...logical clean logging." Your
twisting of my words into what they are not, is deceit.

 
> > Check your internet resources for
> > an actual transcript of a WebDav exploit. It is thirty-thousand
> > to fifty-thousand bytes of repeating "binary" like code. That
> > garbage is of no value for later analysis. That garbage only
> > serves to bloat logfiles, to break log parsers, to annoy
> > and to lead me to rants.
 
> It _is_ of value for later analysis.  It's called NOPs and shellcode.
> And I assure you it is not just garbage.  Like I said, today it doesn't
> affect apache.  But something might at some point and you won't be
> logging it.  That will be amusing, trying to figure out what happened
> with no logs.
 
I did not state to not log connection requests. This is twice
now you have written this. This prompts me to hold an opinion
you are deliberately practicing deceit. That is inappropriate.

You are not thinking clearly. If a request method exceeds the
set URI length limit, Apache will return a 414 error and there
is absolutely nothing you can do about this. So, if a 414 error
is generated, no hack will be successful. However, your log file
is slobbered with kilobytes of garbage.

Yes, it is garbage. With a 414 response their is no need for
analysis, the data is useless; garbage. It may be of some
entertainment value, might disclose a new exploit but you
will never be able to address whatever is found; 414.
Once Apache cops a 414 error, you are out of the loop.

Doesn't matter if someone sends an extremely long secret
code to the location of Long John Silver's hidden treasure,
you are out of the loop; you cannot respond. Apache will not
allow you to respond.

So you discover a new exploit which turns your Linux
box into a Commodore. What are you going to do? Nada,
zippo, zero, nothing because Apache cops a 414.

Give thought to your words before writing.

With SNORT, this WebDav exploit is fingerprinted using
a depth setting of eight characters and can actually be
fingerprinted in seven characters. Your SNORT reacts,
if you have your rule set for  react:block  and you never
see the exploit at all; the connection is dropped, this
is, you won't see it in an Apache log.

Using your logic, now SNORT is useless as are firmware
appliances which employ SNORT as an IDS.

So which is it? Am I the blithering idiot for wanting
to capture WebDav, truncate the data and form a response
to deal with it or are high end technogeeks, like those
who developed SNORT or those who manufacture expensive
firewall appliances, are they idiots for not allowing
a capture of exploit data? SNORT and firmware do have
configuration settings for, no log, fast log, packet
log and many other options. You can choose to not log
at all or discard data. A serious blunder, you think?

Apache allows lots of nice parsing of incoming data
which does make it in. You can select to record all
data, disregard host name lookup, record or not record
referer [sic] data, almost anything you like.

So now Apache developers are the idiots for allowing
a user to discard data rather than log every bit of
it for analysis. Your logic is not good.

Your logic is not good because you are performing
a critique of me while deliberately ignoring what
I suggest and would like to do, is very popular
and incorporated by almost all professionals.

Why is this not ok for me but ok all others?

You are not thinking clearly. Not only are you resorting
to a tiresome tactic of word twisting, you are also making
an attempt to critique me for suggesting methods which
are precisely what well known commericial software writers
use most routinely.

So, if I am to be the idiot according to your logic,
then SNORT writers and high end software writers are
the idiots, as well.

What you are really doing is twisting my words around,
employing deceit, concealing known methods, using very
poor logic, to afford yourself a chance to critique.

I am here to share information, to learn, to make suggestions
which might help Apache become a better server.

Why are you here? A rhetorical question begging no answer.

I am very dismayed by this lack of professionalism displayed
by a select few here. I am dismayed because you select few
tend to ruin this mailing list, just as others ruin newsgroups
by engaging in the same or similar inappropriate behavior.

Some readers have shared valuable thoughts and input.
Consider not discouraging those few gentle and polite
participants from joining in, by personal attacks.

I do hope, you the reader, plural, will give thought
to my writings and assess if ad hominem behavior is
beneficial for this mailing list.

Moving back on topic, for those actually interested,
last night I looked at source code for 1.3.29 which is
significantly different than 1.3.27 version.

Within protocol.c for 1.3.27 version, I have discovered
potential for crafting a custom Apache server which
handles a 414 error quite differently. Version 1.3.27
affords a lot of code entry points for white hat hacks.

Changing the wording of a 414 response takes only a
minute, not counting compilation time and copying
in new compiled files.

There is also potential for changing the precedence
order of a 414 error, moving it into an allowed status
enabling an ability to capture WebDav, then work with
it and craft a custom response. A word of caution.
There is a need to defeat URI length to allow this.
Doesn't matter, the data is already in a buffer, it
is there so defeating URI length has no effect on
system resource usage.

A reader might find entertainment is looking at
http_protocol.c from line 2868 downward, or
"CHARSET_EBCDIC" downward, version 1.3.27 tarball.

There is lot of potential there for hooking using
Apache's core export feature. I do find a number
of entry points for direct module hooking, as well.


Kira

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org


Mime
View raw message