Re: Apache - all versions vulnerability in OLD procesors.

From: Peter J. Holzer (hjp_at_wsr.ac.at)
Date: 04/26/04

  • Next message: Kyle Duren: "Samsung SmartEther SS6215S Switch" 
    Date: Mon, 26 Apr 2004 09:54:32 +0200
To: bugtraq@securityfocus.com

    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@wsr.ac.at        |	-- Gordon Schumacher,
__/   | http://www.hjp.at/   |     mozilla bug #84128

  • Next message: Kyle Duren: "Samsung SmartEther SS6215S Switch"