bugtraq - Re: Apache - all versions vulnerability in OLD procesors.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Mon, 26 Apr 2004 09:54:32 +0200
From: "Peter J. Holzer" <hjp@....ac.at>
To: bugtraq@...urityfocus.com
Subject: 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@....ac.at        |	-- Gordon Schumacher,
__/   | http://www.hjp.at/   |     mozilla bug #84128

Content of type "application/pgp-signature" skipped