[16977] in bugtraq

home help back first fref pref prev next nref lref last post

Re: Very interesting traceroute flaw

daemon@ATHENA.MIT.EDU (Daniel Jacobowitz)
Sat Sep 30 17:39:43 2000

Mail-Followup-To: BUGTRAQ@SECURITYFOCUS.COM
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
              protocol="application/pgp-signature"; boundary="mP3DRpeJDSE+ciuQ"
Content-Disposition: inline
Message-Id:  <20000930171842.A7464@drow.them.org>
Date:         Sat, 30 Sep 2000 17:18:42 -0400
Reply-To: Daniel Jacobowitz <dmj+@ANDREW.CMU.EDU>
From: Daniel Jacobowitz <dmj+@ANDREW.CMU.EDU>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To:  <200009291651.JAA24056@eris>; from pedward@WEBCOM.COM on Fri,
              Sep 29, 2000 at 09:51:02AM -0700

--mP3DRpeJDSE+ciuQ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Sep 29, 2000 at 09:51:02AM -0700, pedward@WEBCOM.COM wrote:
> What is causing the segmentation fault is freeing of unallocated memory, =
not
> the fact that you are calling free in the middle of a chunk of malloced
> memory.  This code will produce SIGBUS on solaris and other hardware that
> supports a misaligned access exceptions.

No... this is not a misaligned access if the data saved is of the
proper size.

> I have downloaded the sources and done the work:
>=20
> The second -g 1 causes a free() on an unallocated pointer.  The problem
> is that the second 'savestr' doesn't actually allocate a chunk of memory
> for hi->name, so when free is called against the bogus pointer it segfaul=
ts
> in chunk_free.  The hi->name is actually written to an unallocated, but u=
nused
> portion of the heap.

Not necessarily unused, depending on the sequence of options passed.=20
You can corrupt resolver datastructures this way.

> If this is possibly exploitable (rh6.2 rev 18), then I would be REALLY
> surprised.  savestr is only used in gethostinfo, totally innocuous.

Passing user-controlled data to free is sufficient.  I'm thoroughly
convinced that this would be exploitable, at least on big-endian
architectures (the trailing 0 of the saved string can be problematic).

For more information, see the discussion in the security-audit mail
archives when the issue was first noticed (well, second - I had a private
conversation with Chris Evans about it after he first mentioned it, if
I recall correctly):
  http://www.geocrawler.com/archives/3/302/2000/8/0/

Also see the discussion of heap overflows by Solar Designer that Chris
mentioned in the original post in this thread.

Dan

/--------------------------------\  /--------------------------------\
|       Daniel Jacobowitz        |__|        SCS Class of 2002       |
|   Debian GNU/Linux Developer    __    Carnegie Mellon University   |
|         dan@debian.org         |  |       dmj+@andrew.cmu.edu      |
\--------------------------------/  \--------------------------------/

--mP3DRpeJDSE+ciuQ
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE51liybgOPXuCjg3cRAkfyAKC/u2SxxDmFau/jmg7ZqSUygqpa5gCfTfkR
pYyQ8WlVYMNaNju1li3MCkk=
=YVKV
-----END PGP SIGNATURE-----

--mP3DRpeJDSE+ciuQ--

home help back first fref pref prev next nref lref last post