After upgrade Apache from 2.0.48 to 2.0.49, I received large amount of WebDA
V exploit requests
(like "SEARCH  \x90\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02
\xb1\x02\xb1\x02......
")
(>500 entries in 3 days).

Then i degrade to 2.0.48, the requests disappeared.

So, only Apache 2.0.49/1.3.29 log these requests, is that true? And why?

[ Post a follow-up to this message ]

jason.gao wrote:

> WebDAV exploit requests

> So, only Apache 2.0.49/1.3.29 log these requests, is that true?

No, this is not true. Any version which drops a connection
based on a 414 error, contains this bug. It might be 2.0.49
accepts a SEARCH request method. However, I would expect
this same bug to appear if that version drops a connection
based on a 414 error; URI length over eight kilobytes.


> why?

Visually examine your Apache httpd.h header file
for c++ compilation, found in your include directory,
about half way through,

define ap_status_drops_connection

There and subsequent lines and sections you
will discover why Webdav exploits are able
to make use of this bug in Apache.

Most direct cure is to rewrite the httpd.h header file
and associated header files to remove a 414 from the
drop connection array, then allow SEARCH as a recognized
method, then recompile Apache.

There is an inherent problem, this defeats the URI length
filter allowing the entire Webdav exploit to enter.
Better approach would be to write code which scans
a request for "SEARCH" and immediately drops a connection
with no further processing.

Apache should drop a connection based on an unrecognized
request method, but does not. This is a bug which leads
to a series of subsequent bugs.

I would suggest a reader not try this unless you
are quite experienced in C language and equally
experienced at compiling Apache.


Purl Gurl

[ Post a follow-up to this message ]

Purl Gurl, thank you very much, but i am still some confused.


.. Any version which drops a connection
based on a 414 error, contains this bug. It might be 2.0.49
accepts a SEARCH request method...


2.0.48 _accepts_ SEARCH method too. I searched its access 
log and found SEARCH entries, but no webdav SEARCH entry
(and no 414 error in error log). Strange?


define ap_status_drops_connection


I took a look at the source code distributions of 2.0.48 
& 2.0.49. They are same (both include 414 error):

#define ap_status_drops_connection(x) \
                                   (((x) == HTTP_BAD_REQUEST)           || \
                                    ((x) == HTTP_REQUEST_TIME_OUT)      || \
                                    ((x) == HTTP_LENGTH_REQUIRED)       || \
                                    ((x) == HTTP_REQUEST_ENTITY_TOO_LARGE) |
| \
                                    ((x) == HTTP_REQUEST_URI_TOO_LARGE) || \
                                    ((x) == HTTP_INTERNAL_SERVER_ERROR) || \
                                    ((x) == HTTP_SERVICE_UNAVAILABLE) || \
				    ((x) == HTTP_NOT_IMPLEMENTED))

Does it mean there is no this bug for 2.0.48? 
or 2.0.48 is better than 2.0.49 at this point?
Where did the webdav exploit requests go for 2.0.48??


Apache should drop a connection based on an unrecognized
request method, but does not..


Agree. 

I tried to reject SEARCH method using LimitExcept directive for 2.0.49.
It worked with normal SEARCH requests, shown in error log as
"Invalid method in request SEARCH..."
(BTW, but for webdav exploit requests, it still reported as
"request too long").
But still logged them into access & error logs.


Jason Gao

[ Post a follow-up to this message ]

jason.gao <jason.gao.14nd1l@mail.webservertalk.com> wrote in message news:<jason.gao.14nd1l
@mail.webservertalk.com>...
>
> Does it mean there is no this bug for 2.0.48?
> or 2.0.48 is better than 2.0.49 at this point?
> Where did the webdav exploit requests go for 2.0.48??

I am fairly certain that there is no difference between 2.0.48 and
2.0.49.  You probably just upgraded before this worm hit.

> Apache should drop a connection based on an unrecognized
> request method, but does not..
>
>
> Agree.

Ah, so Apache should violate the HTTP standard?  (RFC 2616 section
5.1.1)
This is a bad idea for a bunch of different reasons.

>
> I tried to reject SEARCH method using LimitExcept directive for
> 2.0.49.
> It worked with normal SEARCH requests, shown in error log as
> "Invalid method in request SEARCH..."
> (BTW, but for webdav exploit requests, it still reported as
> "request too long").
> But still logged them into access & error logs.

If you don't want them logged, you can probably do it with the patch
included below for server/protocol.c (you'll need to fix it up for
line-wraps).  But this is a *really* bad idea.  The logs are there to
let you monitor your server for bad things.  If you don't log those
bad things, you have no way of knowing what is going on with your
server.

Why don't you instead invest a couple minutes in learning how to use
"grep" to remove things from your log.

Joshua.

Index: protocol.c
 ========================================
===========================
RCS file: /home/cvs/httpd-2.0/server/protocol.c,v
retrieving revision 1.121.2.16
diff -u -d -b -r1.121.2.16 protocol.c
--- protocol.c  8 Mar 2004 22:54:20 -0000       1.121.2.16
+++ protocol.c  13 Apr 2004 14:19:38 -0000
@@ -857,11 +857,15 @@
/* Get the request... */
if (!read_request_line(r, tmp_bb)) {
if (r->status == HTTP_REQUEST_URI_TOO_LARGE) {
+#if 0
ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r,
"request failed: URI too long (longer than
%d)", r->server->limit_req_line);
+#endif
ap_send_error_response(r, 0);
ap_update_child_status(conn->sbh, SERVER_BUSY_LOG, r);
+#if 0
ap_run_log_transaction(r);
+#endif
apr_brigade_destroy(tmp_bb);
return r;
}

[ Post a follow-up to this message ]

Joshua Slive wrote:

> jason.gao wrote:

(Purl Gurl wrote
 

(Jason wrote
 

> Ah, so Apache should violate the HTTP standard?  (RFC 2616 section
> 5.1.1)
> This is a bad idea for a bunch of different reasons.

HTTP protocol standards are a joke. Not that there is anything
wrong with trying to standardized, this is good. However, companies
such as Microsoft and most others ignore RFC suggestions.

Microsoft Internet Explorer, today the most widely used browser,
ignores almost all http protocols ironically leading to the worst
and the most popular browser.

There is a significant difference between correcting bugs
and not obeying all http protocol. No server recognizes
all http protocols for a good reason; efficiency.

Amongst the best written programs are those which do
not comply with suggested standards. If you want Apache
to comply with all http protocol, you will have to
bloat its size by a factor of ten, resulting in
classic bloatware.

Currently Apache does not comply with all http protocol
and this actually is a benefit.

(Jason wrote
 

> If you don't want them logged, you can probably do it with the patch
> included below for server/protocol.c

You can accomplish this more efficiently, much quicker and
with greater flexibility using a dozen lines of PERL code.

Concept is not to prevent logging but rather to repair this bug.

> Why don't you instead invest a couple minutes in learning how to use
> "grep" to remove things from your log.

What leads you to believe readers do not know how
to use grep or other methods? There are those who
would rather fix this bug in Apache than to place
a band-aid upon it.

> Index: protocol.c

Interesting approach. Perhaps you are motivated
to consider fixing this bug in Apache. Clearly
there are many readers here and elsewhere, who
would like this bug repaired.

I have copied out your code and, in the future,
will compile your code into Apache and note results.


Purl Gurl

[ Post a follow-up to this message ]

[I know I shouldn't respond to this, but...]

Purl Gurl <purlgurl@purlgurl.net> wrote in message news:<407C03AD.EE1C69D4@purlgurl.net>...
 
>
> HTTP protocol standards are a joke.

Wrong.

1. The web was and is built on standards.

2. The Apache HTTP Server project has as one of its primary goals the
implimentation of the standards.  It is not perfect, but it is very
close a fully compliant HTTP/1.1 origin server.  See the first
paragraph of this page:
http://httpd.apache.org/

3. MS-IIS doesn't just drop requests for unknown methods either.

4. The standard says what is says for good reasons.  For example, if
you simply drop a request, how is a browser supposed to know if you
don't support the method, if there was a network problem, or if there
was some other error.  It would make debugging and inter-operation
practically impossible.

HTTP servers respond to requests with HTTP responses, with proper
error handling.  They do not simply drop requests when they find an
error.

> There are those who
> would rather fix this bug in Apache than to place
> a band-aid upon it.

I have seen absolutely no evidence that there is a bug in Apache
handling of these requests, with one exception: there may be a bug in
how the request is logged.  There is also a feature missing that some
people want: being able to skip logging of these requests.
Personally, I think this feature is not a very important one, since
complete logs are a webmaster's best friend.

So, to summarize:
- The fact that Apache doesn't drop connections on errors is most
certainly not a bug.  It is an important feature of its design.
- I have seen no evidence at all that Apache's response to the client
in this case is in any way incorrect.

Joshua.

[ Post a follow-up to this message ]

quote:
Originally posted by Joshua Slive 

I am fairly certain that there is no difference between 2.0.48 and
2.0.49.  You probably just upgraded before this worm hit.
 

The difference just happened! I am using 2.0.48 now (degraded from 2.0.49).
The strange thing can be repeatedly observed. I can use AWK or PERL to 
remove the logs easily, but cannot stop surprising and confusing.

BTW, I used the default binary releases for Windows (2000), and a exact same
config file.

Jason Gao

[ Post a follow-up to this message ]

jason.gao <jason.gao.14qg5l@mail.webservertalk.com> wrote in message news:<jason.gao.14qg5l@
mail.webservertalk.com>...
> Joshua Slive wrote: 
>
> The difference just happened! I am using 2.0.48 now (degraded from
> 2.0.49).
> The strange thing can be repeatedly observed. I can use AWK or PERL to
>
> remove the logs easily, but cannot stop surprising and confusing.
>
> BTW, I used the default binary releases for Windows (2000), and a exact
> same
> config file.

Sorry, but I can't understand what you are saying.  What does "The
difference just happened!" mean?  Be specific about exactly what you
do and exactly what you observe.

What does "cannot stop surprising and confusing" mean?

Joshua.

[ Post a follow-up to this message ]

Originally posted by Joshua Slive 


> Sorry, but I can't understand what you are saying.  What does "The
> difference just happened!" mean?  Be specific about exactly what you
> do and exactly what you observe.


OK.

More clearly, the server is my home computer, ADSL, Windows 2000.

1. 
I upgraded from Apache 2.0.48 to 2.0.49 at 10:46 Apr. 9. Then 
I saw first webdav exploit request in the access log at 11:10.

2.
Then the webdav requests appeared almost evenly. Up to 20:00, 
Apr. 11, I received more than 500 hits. The hits came from 
many IP addresses.

3.
If I redial to internet (change IP address), the requests then 
appeared again after about 20 minites.

4.
Finally, I degraded back to 2.0.48 at 20:08, Apr. 11. The requests
disappeared. And I never saw one of them from then on!

How I upgrade/degrade Apache:
First remove old version (httpd.conf not removed),
Then install new version to the same location as old one
(use the old httpd.conf).


> What does "cannot stop surprising and confusing" mean?


I am surprised and confused on this. (My English is poor)


> You probably just upgraded before this worm hit.


I thought so at first. But now, should I think that 
I just degraded after this worm stop hitting? :D


Jason Gao

[ Post a follow-up to this message ]