[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Apache - all versions vulnerability in OLD procesors.



On 2004-04-24 15:53:03 -0000, Adam Zabrocki wrote:
> Apache - all versions vulnerability in OLD procesors.

Hmm, 64 bit processors are old?

[...]

> Aha... good, while count is bigger or equal following constant:
> 
> "src/ap/ap_sha1.c"
> ...
> ...
> #define SHA_BLOCKSIZE           64
> ...
> ...
> 
> Hm... ok, this get's evaluated further more in ebcdic2ascii() ?
> 
> "src/ap/ap_ebcdi.c"
> API_EXPORT(void *)
> ebcdic2ascii(void *dest, const void *srce, size_t count)
> {
>     unsigned char *udest = dest;
>     const unsigned char *usrce = srce;
> 
>     while (count-- != 0) {
>         *udest++ = os_toascii[*usrce++];
>     }
> 
>     return dest;
> }
> 
> Above function copies 64 bytes, structre AP_SHA1_CTX is an array of 16 
> elements.
> Take a look at structure element declaration :
> 
> "src/include/ap_sha1.h"
> typedef unsigned long AP_LONG;     /* a 32-bit quantity */
> 
> This is fine, assuming that we have 32 bits CPU, and sizeof(unsigned long) 
> equals 4. So 4*16=64.
> There is no guarantee that on some archs unsigned long is going to stay 32 
> bit width. When it's
> either longer or shorter (I am not sure if long can be 16 bits long, but 
> possibly ANSI C standart
> doesn't say anythin about it's length in bits).

How about looking it up? The C standard defines long as having at least
32 bits (and int and short as having at least 16 bits, and char as
having at least 8 bits, just for completeness).

> Ie. on 64bit platforms, depending on compiler
> options, and compiler it self long can be either 64 (default) or 32 bits. 

Correct.

> When sizeof( unsigned long )!=4 it can lead to memory corruption in function 
> ebcdic2ascii(),
> which will either copy too much, copyied in this example 32 bytes more than 
> he should and
> that situaction do this bug!

No. It will still copy 64 (SHA_BLOCKSIZE) bytes, but the buffer will now
be 16*8 = 128 bytes long. So half of the buffer will be wasted, but no
overflow will occur. 

        hp

-- 
   _  | Peter J. Holzer      | Shooting the users in the foot is bad. 
|_|_) | Sysadmin WSR / LUGA  | Giving them a gun isn't.
| |   | hjp@xxxxxxxxx        |  -- Gordon Schumacher,
__/   | http://www.hjp.at/   |     mozilla bug #84128

Attachment: pgp00024.pgp
Description: PGP signature