oss-sec mailing list archives

Re: Buffer overrun vulnerability in CHICKEN Scheme


From: Kurt Seifried <kseifried () redhat com>
Date: Fri, 27 Sep 2013 00:14:29 -0600

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/26/2013 03:27 PM, Peter Bex wrote:
Hi all,

I'd like to request a CVE for a recently discovered vulnerability
in CHICKEN Scheme.  It affects a very particular, not very common
use of the read-string! procedure.  If given a buffer and #f (the
Scheme value for "false") as the buffer's size (which should
trigger automatic size detection but doesn't), it will read beyond
the buffer, until the input port (file, socket, etc) is exhausted.
This may result in the typical potential remote code execution or
denial of service; in CHICKEN, these buffers are initially
allocated on the stack and moved to the heap upon GC.

In normal usage, users would usually pass in the buffer's size.
This is also the workaround for this bug.

For the official announcement, see 
http://lists.nongnu.org/archive/html/chicken-announce/2013-09/msg00000.html

 The discussion thread's final accepted patch is at 
http://lists.nongnu.org/archive/html/chicken-hackers/2013-09/msg00009.html


which got applied as
http://code.call-cc.org/cgi-bin/gitweb.cgi?p=chicken-core.git;a=commit;h=cd1b9775005ebe220ba11265dbf5396142e65f26

All versions of CHICKEN prior to 4.8.0.5 and 4.8.3 (not yet
released) are affected.

Cheers, Peter Bex


Please use CVE-2013-4385 for this issue.

- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)

iQIcBAEBAgAGBQJSRSJFAAoJEBYNRVNeJnmTp1EP/0zsOAo2k2c4DnwSk7K0XFiU
uBz9zeIi+y+o2ejZrts0dkc0AFg05V1nbSnAc9Hq/mFNx8kOP+ZB3H+ExFechRLj
PnE+Tl9dD/I8oKR2d8Rn95rY/z2gBZj0GoBla+EkERPwsXnXGwBklJOtjFYa1DFZ
wqOg2WD17E3/P5ZdK8LoBMi86ZBwibXhWgdmNcJWGtpKWbdbO0Z7Tj6CYNLQrJMQ
Nb9LqnBO5Mh2xq0unb8QegxcUdhTWPz23PciUrcml5tyL3SGrMiaBGWzunKN770B
oiSV490xOpGyuoLHOAHuQcBysLYHGZ1wfOExAWvPGmuEJpjnma4KX96SCQW16PLl
nfH0PpQso9D9PyATOq87hoQwtvDwR/Ez2ak0reAXyC6+kDEbpilY7r3TOiSRwrBM
1uYVt5pLFfblo6MbzgotdvdOJfAmD3pUkU4OOGT6n60CoQSb5hH0HrY16uiTatmb
nQvTJNjdPA+eZ1yp1p8x0n7wVkDWcA2C56OBNVHXby/sNUd38vg3za9xRu+UQ9vJ
uKuhX/m5+SkVIXhcwBDc+6kAlV15I4EfDYjBS15PryWyapmFkyimA6APsQmDswCB
a3NH1w28+ToJeIeL6bmrahOp+jnepiquJwD3eJLdkPwcLUMEN5P2+M/9cVCYpXbE
8SCqKFuqKxPBAOVnpOvG
=tO27
-----END PGP SIGNATURE-----


Current thread: