Re: CVE-2006-2162: Buffer overflow in nagios
Posted: Thu May 11, 2006 9:49 am
--rwEMma7ioTxnRzrJ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
hey ethan (et al),
one of the debian security peeps brought to my attention another
possible issue with the Content-Length that might not be resolved
by the current patch. what if someone sends a packet of size
INT_MAX or greater, causing an integer overflow?
sean
----- Forwarded message from Sean Finney -----
Date: Thu, 11 May 2006 13:46:27 -0400
=46rom: Sean Finney
To: Martin Schulze
Subject: Re: CVE-2006-2162: Buffer overflow in nagios
hey joey,
On Thu, May 11, 2006 at 05:46:16PM +0200, Martin Schulze wrote:
> > - crafting a simple "user-agent" that can illustrate the vulnerability
> > by sending a negative or 0 value for content length to a nagios cgi
> > (it doesn't have to actually inject any shell code or anything, just
> > PoC would be fine by me).
>=20
> Why user-agent? "All" you need to do is add some variables, so that
as a general rule i feel much more comfortable having some kind of PoC
code available that will tell me that my patch works. granted, in this
case it's a rather straightforward patch, but still...
> the Content-Length is either exactly INT_MAX or even larger, both
> cause an integer overrun, which cause a negative malloc() which cause
> a situation in which the attacker may control some memory they shouldn't.
ah yes.. good point about INT_MAX. i'll forward this upstream as well,
since i don't think ethan considered this.
sean
----- End forwarded message -----
--rwEMma7ioTxnRzrJ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFEY3kRynjLPm522B0RAnFLAJ4247NlW1XrncbiKLCyB+fHPj2W8gCdEU+Y
v5Zfm9vw6ggb1wrh6ib9mBA=
=R3HU
-----END PGP SIGNATURE-----
--rwEMma7ioTxnRzrJ--
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
hey ethan (et al),
one of the debian security peeps brought to my attention another
possible issue with the Content-Length that might not be resolved
by the current patch. what if someone sends a packet of size
INT_MAX or greater, causing an integer overflow?
sean
----- Forwarded message from Sean Finney -----
Date: Thu, 11 May 2006 13:46:27 -0400
=46rom: Sean Finney
To: Martin Schulze
Subject: Re: CVE-2006-2162: Buffer overflow in nagios
hey joey,
On Thu, May 11, 2006 at 05:46:16PM +0200, Martin Schulze wrote:
> > - crafting a simple "user-agent" that can illustrate the vulnerability
> > by sending a negative or 0 value for content length to a nagios cgi
> > (it doesn't have to actually inject any shell code or anything, just
> > PoC would be fine by me).
>=20
> Why user-agent? "All" you need to do is add some variables, so that
as a general rule i feel much more comfortable having some kind of PoC
code available that will tell me that my patch works. granted, in this
case it's a rather straightforward patch, but still...
> the Content-Length is either exactly INT_MAX or even larger, both
> cause an integer overrun, which cause a negative malloc() which cause
> a situation in which the attacker may control some memory they shouldn't.
ah yes.. good point about INT_MAX. i'll forward this upstream as well,
since i don't think ethan considered this.
sean
----- End forwarded message -----
--rwEMma7ioTxnRzrJ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFEY3kRynjLPm522B0RAnFLAJ4247NlW1XrncbiKLCyB+fHPj2W8gCdEU+Y
v5Zfm9vw6ggb1wrh6ib9mBA=
=R3HU
-----END PGP SIGNATURE-----
--rwEMma7ioTxnRzrJ--
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]