Hide Forgot
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.