[34664] in bugtraq
Re: Apache - all versions vulnerability in OLD procesors.
daemon@ATHENA.MIT.EDU (Peter J. Holzer)
Mon Apr 26 13:50:25 2004
Date: Mon, 26 Apr 2004 09:54:32 +0200
From: "Peter J. Holzer" <hjp@wsr.ac.at>
To: bugtraq@securityfocus.com
Message-ID: <20040426075432.GA24495@wsr.ac.at>
Mail-Followup-To: bugtraq@securityfocus.com
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-md5;
protocol="application/pgp-signature"; boundary="fdj2RfSjLxBAspz7"
Content-Disposition: inline
In-Reply-To: <20040424155303.24514.qmail@www.securityfocus.com>
--fdj2RfSjLxBAspz7
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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:
>=20
> "src/ap/ap_sha1.c"
> ...
> ...
> #define SHA_BLOCKSIZE 64
> ...
> ...
>=20
> Hm... ok, this get's evaluated further more in ebcdic2ascii() ?
>=20
> "src/ap/ap_ebcdi.c"
> API_EXPORT(void *)
> ebcdic2ascii(void *dest, const void *srce, size_t count)
> {
> unsigned char *udest =3D dest;
> const unsigned char *usrce =3D srce;
>=20
> while (count-- !=3D 0) {
> *udest++ =3D os_toascii[*usrce++];
> }
>=20
> return dest;
> }
>=20
> Above function copies 64 bytes, structre AP_SHA1_CTX is an array of 16 el=
ements.
> Take a look at structure element declaration :
>=20
> "src/include/ap_sha1.h"
> typedef unsigned long AP_LONG; /* a 32-bit quantity */
>=20
> This is fine, assuming that we have 32 bits CPU, and sizeof(unsigned long=
) equals 4. So 4*16=3D64.
> There is no guarantee that on some archs unsigned long is going to stay 3=
2 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.=
=20
Correct.
> When sizeof( unsigned long )!=3D4 it can lead to memory corruption in fun=
ction ebcdic2ascii(),
> which will either copy too much, copyied in this example 32 bytes more th=
an 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 =3D 128 bytes long. So half of the buffer will be wasted, but no
overflow will occur.=20
hp
--=20
_ | Peter J. Holzer | Shooting the users in the foot is bad.=20
|_|_) | Sysadmin WSR / LUGA | Giving them a gun isn't.
| | | hjp@wsr.ac.at | -- Gordon Schumacher,
__/ | http://www.hjp.at/ | mozilla bug #84128
--fdj2RfSjLxBAspz7
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iQDQAwUBQIzAOFLjemazOuKpAQEbPwXUCNUJBs/ZvAs0fw9od2x2SCqexoutolNU
l9gIGuwHMJsu+u6MznzkoXIeIt1lIlX83bt4t/UldrFAEYpFUn7yN/e5IaeB1BC/
wQcQeS8i+3n5i53+Jnn69qCuNrOOtcoiBVGsqa71fpepjCMMV+c6n+dtfV1s22XZ
MbI/8LuoMBhUqlycQz9wYnOKRiN2j8EJsZmsE+571NZ3ct/OOA+KYYbWt+6smHw3
KabG5oPoRvBMwPjr/o3c/6aLDw==
=fvq/
-----END PGP SIGNATURE-----
--fdj2RfSjLxBAspz7--
