Bug 200219

Mark Dowd of McAfee Avert Labs reported an off-by-one security problem in
the ldap scheme handling of the mod_rewrite module. Where RewriteEngine is
enabled, and for certain RewriteRules, this could lead to a pointer being
written out of bounds. (CVE-2006-3747)

The ability to exploit this issue is dependent on the stack layout for a
particular compiled version of mod_rewrite. If the compiler has added
padding to the stack immediately after the buffer being overwritten, it
will not be possible to exploit this issue, and Apache httpd will continue
operating normally.

The Red Hat Security Response Team has analyzed Red Hat Enterprise Linux 3
i386 and x86_64, Red Hat Enterprise Linux 4 i386 and x86_64 binaries as
shipped by Red Hat and determined that these versions can not be exploited.
Customers on other architectures, or those not using our supplied binary
versions, may be vulnerable to this issue. We have therefore rated the
severity of this issue as important.

This issue does not affect the upstream version of Apache httpd as shipped
with Red Hat Enterprise Linux 2.1. 

EMBARGO IN EFFECT

On RHEL3 x86, the stack frame looks like this (note that your offsets will vary
based on randomization)

...
                0xb72fbed1 [b4] tempvar
0xbfffd820:     0x08253eb0 [b8] tempvar
                0xb7097e47 [bc] tempvar
                0xb709261b [C0] tempvar
                0xb709a934 [C4] c
0xbfffd830:     0x08160198 [C8] token[0]
                0x00000000 [CC] token[1]
                0xb712aaec [D0] token[2]
                0xb709a934 [D4] token[3]
0xbfffd840:     0x08255791 [D8] token[4]
                0xb7097e53 [DC] ** unused ** <--- Overwritten 
                0xbfffd868 [E0] ** unused **
                0xb709419d [E4] ** unused **
0xbfffd850:     0x08255791 [E8] ** unused **
                0xb7098010 [EC] ** unused **
                0x00000000 [F0] ** unused **
                0xb709a934 [F4] callee-saved bx
0xbfffd860:     0x00000007 [F8] callee-saved si
                0xb7097e53 [FC] callee-saved edi
                0xbfffdcd8 [00] ****** ebp points here
                0xb709154c [04] ****** the return address
0xbfffd870:     0x08253a80 [08] this is where p is
                0x08255790 [0C] this is where uri is
                0x00000007 [10] this is the value of scheme

(Some local variable such as cp are stored in registers). The memory marked **
unused ** can be verified as being unused by disassembling the function and
going through the assembler (which we did to verify this).  An exploit for this
issue can only write to the 4 bytes immediately following token[4], and in this
case it's pointing to unused memory, and therefore the exploit has no effect.

Therefore Red Hat Enterprise Linux 3 on i386 using our httpd binaries is not
vulnerable to this issue.

On RHEL3 x86_64, the situation is similar:

....
0x7fbfffa230 &token[4]
0x7fbfffa238 ** unused **  <----- Overwritten
0x7fbfffa240 ** unused **
0x7fbfffa248 start of callee-saved registers
....
0x7fbfffa278 return address

On x86_64 there are more saved registers, and more of the local variables are
stored in registers.  However the memory that gets overwritten is the 8 buyes
immediately following token[4] and in this case it's into unused memory, and
therefore the exploit has no effect.

Therefore Red Hat Enterprise Linux 3 on x86_64 using our httpd binaries is not
vulnerable to this issue.

On RHEL4 x86_64:

...
0x7fbfffe7c0 &token[4]
0x7fbfffe7c8 ** unused ** <-------- Overwritten
0x7fbfffe7d0 ** unused **
0x7fbfffe7d8 start of callee-saved registers
...
0x7fbfffe808 return address

Therefore Red Hat Enterprise Linux 4 on x86_64 using our httpd binaries are not
vulnerable to this issue.

On RHEL4 x86, the stack frame looks like this (note that your offsets will vary
based on randomization)

0xbff57bd0:     0x09b03469      &token[4]
                0x09b034af      ** unused ** <---- Overwritten
                0xbff57bf8      ** unused **
                0x00233fbd      ** unused **
0xbff57be0:     0x09b03469      ** unused **
                0x0023c334      ** unused **
                0x0023405e      ** unused **
                0x0023db84      push ebx (callee saved bx)
0xbff57bf0:     0x00000007      push esi (callee saved si)
                0x09b01b00      push edi (callee saved di)
                0xbff588d8      <---- ebp (return address)

(Some local variable such as cp are stored in registers). The memory marked **
unused ** can be verified as being unused by disassembling the function and
going through the assembler (which we did to verify this).  An exploit for this
issue can only write to the 4 bytes immediately following token[4], and in this
case it's pointing to unused memory, and therefore the exploit has no effect.

Therefore Red Hat Enterprise Linux 4 on i386 using our httpd binaries is not
vulnerable to this issue.

On RHEL3 ppc and RHEL4 ppc we also get padding. RHEL3:

0xffffd4f8:     0x00000000 &token[0]
                0x00000000 &token[1]
                0x03000000 &token[2]
                0xffffd558 &token[3]
0xffffd508:     0xffffce78 &token[4]
                0x100a7b90 ** unused ** <--- overwritten
                0xffffd530 ** unused **
                0x00000000 ** unused **
0xffffd518:     0x0df72318 ** unused **
                0x100a7ba8 ** unused **
                0xffffd550 ** unused **
                0x28002448 (r1+68) register save area
0xffffd528:     0x00000000 (r1+72) register save
                0x00000000 (r1+76) register save
                0x100640a0 (r1+80) register save
....

RHEL4 is similar, 

0xffffd770:     0xffffd7b0 &token[4]
                0x07d67a88 ** unused **             <---- overwritten
                0x0833df98 ** unused **
                0x05f009bc ** unused **
0xffffd780:     0xffffd790 ** unused **
                0x0833e0bc ** unused **
                0x48008482 r1+72 register save

Therefore Red Hat Enterprise Linux 3 and 4 on ppc architecture using our httpd
binaries are not vulnerable to this issue.

Alexandre Oliva analysed our ia64, s390, and s390x packages for Red Hat
Enterprise Linux 3 and 4.

On ia64, the overwrite would happen into the end of a 16-byte scratch area. 
This memory is unused.

On s390, the overwrite happens into padding.  This memory is unused.

On s390x, the overwrite happens into the space of a temporary variable.  The
temporary variable is used later in the subroutine to hold the output of the
call to ap_escape_uri.  Therefore the overwrite into this space has no effect.

Therefore Red Hat Enterprise Linux 3 and 4 on ia64, s390, and s390x
architectures using our httpd binaries are not vulnerable to this issue.

The conclusion is that the Red Hat binary versions of httpd supplied in Red Hat
Enterprise Linux 3 and 4 on all architectures are not vulnerable to this issue.
 In all cases the exploit will overwrite memory that is unused or the overwrite
has no effect.  Therefore attempts to exploit this issue will fail, and the
Apache server will continue to service requests normally.  This is based on our
analysis of the generated assembler code and stack frame on each architecture
and platform.

I therefore downgrade this issue to having no security impact.

now public, removing embargo

I would like to recommend to make an "official" statement, at least in the KB
page associated to this CVE number, that the httpd package is already patched
again this bug so it not rely in compilation to not be vulnerable.   I don't
know why the changelog of the package httpd-2.0.52-28.ent say "add mod_rewrite
ldap scheme handling fix" but it do not say it is in fact fixing this CVE, as
other entries in the same changelog do, although the name of the patch clearly
show this fact (httpd-2.0.46-CVE-2006-3747.patch)

An official statement is carried in the NVD database here:

http://nvd.nist.gov/nvd.cfm?cvename=CVE-2006-3747

In response to comment 13: the patch to fix the mod_rewrite bug was included in
the httpd package only to mitigate against future compiler changes which might
invalidate the analysis above.  Since the security issue CVE-2006-3747 did not
affect the package as shipped in Red Hat Enterprise Linux, the CVE name was not
referenced in the change to the package.