Post by Jim JagielskiPost by Purl GurlPost by Joshua SliveTRACE cannot be restricted with <Limit>
That is precisely what I indicated.
There was also MUCH discussion on whether we needed to
even provide some sort of mechanism to disable TRACE.
Our opinion was that the vulnerability was not in
TRACE at all, but in the other (required) mechanisms
to exploit that particular path. Without TRACE, there
are still very similar exploitable paths.
This is why I commented TRACE is not a problem for Apache.
Reading of source files yields some mechanisms to protect
against cross site scripting. If I recall correctly, these
are mechanisms which use lookup features, I believe
double reverse lookups to ensure host validity.
TRACE is used as example of this problem of not being
able to hook into Apache's frontend, just as I used
HEAD, SEARCH, whatever. TRACE is still an issue under
debate and it is still unclear if this is a major threat.
Although debated, a person would be exceptionally foolish
to completely dismiss TRACE as a possible exploit, just
as Microsoft dismissed many "things" as non-issues only
to be very surprised, such as the Code Red Worm which
slammed all of us with garbage in our log files. This
one, Red Worm, can be captured and dealt with, however.
Most will cuss when reminded of the SWEN32 virus. If like
us, others experienced tens of thousands of email server
hits because of that spamming virus.
Both of those are classic examples of how we can be
caught with our "pants down" just as WebDav has done.
I am directing my efforts at convincing Apache developers
to not be caught with their pants down, in the future.
Apache is not Microsoft. Apache is much better.
As you know, Jim, there will always be exploits. Variations
on old exploits, new exploits, surprises, this we expect
and does make for a strong market for security devices,
both firmware and software, and makes for us having to
pull our pants back up. That is embarrassing.
This WebDav exploit is a classic example of a surprise
and has brought to our attention a bug in Apache which
previously was not known. Many hold a mistaken notion
a bug is not such unless it is immediately apparent.
This is rarely the case. Murphy's Law has it a bug will
not be discovered until the worst possible time, usually
after software has been marketed to millions of customers.
Microsoft well supports Murphy and bugs.
A bug isn't such until it is discovered. Some may elect
to dogmatically claim a bug is not. Nonetheless, the
problem still exists, bug or not. Claiming a bug is
not will not make a problem vanish.
My personal opinion is Apache needs a hook method to
allow administrators to control results of request
methods. This is a serious need and it is a serious
problem which needs to be resolved. I am not suggesting
dropping a connection, although that would be nice, nor
am I suggesting not responding with a correct http
error message. I am suggesting we need control over
the process to customize responses and to customize
what is logged; get rid of the eight-thousand bytes
of useless garbage. Microsoft does this. So should
an Apache server.
In the case of this annoying WebDav exploit, we only
need an ability to accomplish two things. First is
an ability to instruct Apache to limit the length
of the request URI for logging. We can do this with
other request methods, but not WebDav. Second "thing"
is an ability to block ip addresses BEFORE Apache
responds with an error message and logs, as is the
case with WebDav. Use of ip blocking should be global,
should take precedence over all other functions.
For WebDav, we cannot block the offending ip address
and we cannot parse log data before being written.
Those using Apache are completely defenseless against
this WebDav exploit. That really concerns me. What
other exploits will appear? Being defenseless is
exceptionally illogical and not an accepted practice.
Those are very clear bugs recently forced to surface
because of the WebDav exploit.
I am intensely reading and learning about Apache core
files. This is quite the task! For my personal needs,
a stop-gap measure, I plan to mess around with "r"
in the protocol.c file (1.3.x), with a hope of parsing
out the URI garbage, at that point. Later, as I learn
more about Apache core, I will work on a module to
hook into Apache somewhere in the connect and protocol
phases of processing.
A problem I anticipate already, is a need to write
custom include files, then compile Apache. This would
preclude a widespread fix for all Apache users. Many
want a solution, but few have nor can afford Microsoft
C++ software, specifically version 6 which is now down
to $150 to $180 on Ebay. After purchase, you still have
to spend a lot of time simply learning how to use that
compiler, which is very complicated.
Before someone jumps in about Borland, gcc and others,
for portability, Apache, like Perl, must be compiled
on Microsoft C++ version 5 or version 6.
Bought a lot of Apache books, recently, to supplement
what books I already have and to supplement documentation.
Unfortunately, I have not found any books which discuss
a step-by-step walk through of Apache processing. Best
I have found, so far, is "Maximum Apache Security" by
Anonymous and published under Sams. There is some written
material on core processing and some explanations of
module hooking. However, all of this is AFTER the
connection and protocol phases. I am looking at an
O'Reilly book on writing Apache modules to determine
if the contained information will lead to an ability
to hook into Apache's frontend.
I am looking at Apache::Module to determine if it
will allow "peeking" at frontend processing. Being
an XMS based module, compilation is required for
Win32 systems, presenting some challenges.
An author who writes a technical walk through of Apache
core files, will have a best seller, least in the
Apache community. Trying to trace various headers and
c language include files, is extremely difficult. Took
me several nights to finally find where transaction
data is injected just before logging; protocol.c file.
Mentioned before, my hope is a reader will have addressed
this problem already and be able to offer information, if
not a solution, for all readers. This WebDave exploit is
frequently a hot topic for discussion, and there are many
looking for a solution.
If a viable solution can be found for this WebDav exploit,
should a module appear allowing hooking into the frontend,
this will be very proactive by allowing a facility to deal
with future exploits of this nature. This is dire need.
Microsoft IIS, which I will never use, does have this
feature. Apache needs this as well.
Jim, thanks for your positive responses. I don't participate
here often, but will share any information developed for
the benefit of all readers.
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-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org