Bug 200219 - CVE-2006-3747 mod_rewrite off-by-one
CVE-2006-3747 mod_rewrite off-by-one
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: httpd (Show other bugs)
4.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Joe Orton
reported=20060724,impact=none,public=...
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-07-26 06:38 EDT by Mark J. Cox (Product Security)
Modified: 2009-06-23 16:49 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-05-29 11:18:03 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Comment 1 Mark J. Cox (Product Security) 2006-07-26 06:54:24 EDT
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
Comment 2 Mark J. Cox (Product Security) 2006-07-26 07:01:31 EDT
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.
Comment 3 Mark J. Cox (Product Security) 2006-07-26 07:06:18 EDT
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.
Comment 4 Mark J. Cox (Product Security) 2006-07-26 07:08:33 EDT
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.
Comment 5 Mark J. Cox (Product Security) 2006-07-26 07:10:42 EDT
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.

Comment 6 Mark J. Cox (Product Security) 2006-07-26 08:39:00 EDT
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.

Comment 9 Mark J. Cox (Product Security) 2006-07-26 17:31:13 EDT
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.
Comment 10 Mark J. Cox (Product Security) 2006-07-26 17:34:03 EDT
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.
Comment 11 Mark J. Cox (Product Security) 2006-07-28 01:59:54 EDT
now public, removing embargo
Comment 13 Roger Pena-Escobio 2007-03-04 10:30:35 EST
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)
Comment 14 Joe Orton 2007-05-29 11:18:03 EDT
An official statement is carried in the NVD database here:

http://nvd.nist.gov/nvd.cfm?cvename=CVE-2006-3747
Comment 15 Joe Orton 2007-05-29 12:13:10 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.