Thông tin cho biết đã phát hiện ra điểm yếu của module mod_dav (server WEBDAV) tai. format string. Thong qua lỗi này, remote attacker sẽ có thể tấn công theo kiểu DoS và sẽ chiếm được quyền root. Hiện tại chưa có patch để khắc phục lỗi này cho nên cái server đang xài WEBDAV nên shutdown là tốt nhất.
Sau đây là nội dung thông báo... mọi người tham khảo.
--------
Vulnerability Note VU#849993
Some implementations of mod_dav contain a format string vulnerability in "ap_log_rerror()" function
Overview
A vulnerability in some implementations of mod_dav may permit a remote attacker to gain unauthorized access to a web server running mod_dav.
I. Description
mod_dav is a module designed to provide DAV capabilities for a web server.
David Litchfield (Next Generation Security Software LTD) initially reported a format string vulnerability in mod_dav. However, after considerable investigation by the CERT/CC and communication with various vendors, we now believe mod_dav does not contain a format string vulnerability. However, mod_dav is not coded defensively. In other words, a slight modification in mod_dav (e.g. logging routines) can cause mod_dav to be vulnerable to a format string attack.

We've included a brief primer below for those unfamiliar with format string vulnerabilities.

A format string vulnerability occurs when a call to a function in the printf family is made with a format string under the control of an attacker. The most basic case arises when a programmer uses printf as follows:

printf(s);

where s comes from the attacker's input. There are a variety of attacks based on this flaw, many of which can lead to the ability to execute code with the privileges of the vulnerable program. Most of the attacks leverage the %n conversion character, which has the somewhat unusual effect of writing to memory, as opposed to most conversion characters which only read from memory. If the attacker can cause the above printf statement to be issued as follows (by providing %n as input):

printf("%n");

he can write to the stack, and by carefully choosing his input he can control what gets written, and where it goes.

David Litchfield found some problems in Oracle's 9iAS/9.0.2 implementation of mod_dav. Examination of Greg Stein's open source mod_dav (often used by Apache installations) suggested the problem may be broader than just Oracle's implementation. Specifically, looking at the following code from the function dav_lookup_uri in the module dav_util:

if (strcasecmp(comp.scheme, scheme) != 0




      comp.port != port) {
      result.err.status = HTTP_BAD_GATEWAY;
      result.err.desc = ap_psprintf(r->pool,
                                    "Destination URI refers to different "
                                    "scheme or port (%s://hostname:%d)\n"
                                    "(want: %s://hostname:%d)",
                                    comp.scheme ? comp.scheme : scheme,
                                    comp.port ? comp.port : port,
                                    scheme, port);

You can see that in at least one case, result.err.desc gets filled in with values under the control of the caller. Namely, comp.scheme, comp.port, scheme, and port, can be influenced by an intruder. The result variable is returned to the function dav_method_copymove in the module mod_dav as "lookup":

lookup = dav_lookup_uri(dest, r);
  if (lookup.rnew == NULL) {
2:       if (lookup.err.status == HTTP_BAD_REQUEST) {
          /* This supplies additional information for the default message. */
          ap_log_rerror(APLOG_MARK, APLOG_ERR

APLOG_NOERRNO, r,
1:                           lookup.err.desc);
          return HTTP_BAD_REQUEST;
      }

You can see that on the line labelled "1:" if lookup.err.desc could be influenced by an intruder, a format string vulnerability would exist. However, that section of code only gets executed if lookup.err.status is HTTP_BAD_REQUEST, and the dav_lookup_uri function sets err.status to be HTTP_BAD_GATEWAY, so this code doesn't get executed.

Based on these observations, we concluded that a format string vulnerability does not exist in the open source mod_dav. However, we believe that it would be more "correct" to include an explicit format string specifier in all calls to ap_log_error (and indeed any functions which ultimately use the printf family or other var_args like functions). We recommended that this change be made, though we see no immediate security concern -- just a future problem waiting to happen. It appears that Oracle has committed this error by allowing the user to gain control of the format string through a minor change to their implementation of the mod_dav routines. Other vendors may have made similar changes.

Based on our recommendations, Greg Stein made the following change to revision 1.91 of mod_dav.c:

Code a bit more defensively. If dav_lookup_uri() ever placed user input into lookup.err.desc for the HTTP_BAD_REQUEST case, then we could have problems (via a format string attack). This change frees us from *future* worries.

Until you apply a patch from Oracle, you may consider disabling mod_dav functionality on Oracle 9iAS/9.0.2. If you are making use of another implementation of mod_dav, you may wish to make the changes yourself to the source. We've provided an example below:

-    ap_log_rerror(APLOG_MARK, APLOG_ERR

APLOG_NOERRNO, r,
+    ap_log_rerror(APLOG_MARK, APLOG_ERR

APLOG_NOERRNO, r, "%s",

II. Impact
A remote attacker may be able to gain privileged access to a web server running mod_dav.
III. Solution
Apply a vendor patch.
You may wish to disable mod_dav until a patch can be applied.

Systems Affected
Vendor Status Date Updated
3Com Unknown 25-Sep-2002
Alcatel Unknown 25-Sep-2002
Apple Computer Inc. Unknown 25-Sep-2002
AT&T Unknown 25-Sep-2002
BSDI Unknown 25-Sep-2002
Cisco Systems Inc. Unknown 25-Sep-2002
Computer Associates Unknown 25-Sep-2002
Conectiva Unknown 25-Sep-2002
Cray Inc. Not Vulnerable 25-Sep-2002
Data General Unknown 25-Sep-2002
Debian Unknown 25-Sep-2002
F5 Networks Unknown 25-Sep-2002
FreeBSD Unknown 25-Sep-2002
Fujitsu Unknown 25-Sep-2002
Guardian Digital Inc.  Unknown 25-Sep-2002
Hewlett-Packard Company Unknown 25-Sep-2002
IBM Not Vulnerable 27-Sep-2002
Intel Unknown 25-Sep-2002
Juniper Networks Unknown 25-Sep-2002
Lachman Unknown 25-Sep-2002
Lotus Development Corporation Unknown 25-Sep-2002
Lucent Unknown 25-Sep-2002
MandrakeSoft Unknown 25-Sep-2002
Microsoft Corporation Not Vulnerable 6-Nov-2002
MontaVista Software Unknown 25-Sep-2002
Multinet Unknown 25-Sep-2002
NEC Corporation Unknown 25-Sep-2002
NetBSD Unknown 25-Sep-2002
Network Appliance Unknown 25-Sep-2002
Nortel Networks Unknown 25-Sep-2002
OpenBSD Not Vulnerable 26-Sep-2002
Openwall GNU/*/Linux  Not Vulnerable 6-Nov-2002
Oracle Vulnerable 14-Feb-2003
Red Hat Inc. Not Vulnerable 18-Feb-2003
Sequent Unknown 25-Sep-2002
SGI Unknown 25-Sep-2002
Sony Corporation Unknown 25-Sep-2002
Sun Microsystems Inc. Unknown 25-Sep-2002
SuSE Inc.  Unknown 25-Sep-2002
The SCO Group (SCO Linux)  Unknown 25-Sep-2002
The SCO Group (SCO UnixWare)  Unknown 25-Sep-2002
Unisphere Networks Unknown 25-Sep-2002
Unisys Unknown 25-Sep-2002
Wind River Systems Inc. Unknown 25-Sep-2002
Wirex Unknown 25-Sep-2002
Xerox Unknown 17-Dec-2002