chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Chicken-users] [SECURITY] Buffer-overrun in some uses of read-u8vector


From: Peter Bex
Subject: [Chicken-users] [SECURITY] Buffer-overrun in some uses of read-u8vector
Date: Sun, 18 May 2014 13:27:36 +0200
User-agent: Mutt/1.4.2.3i

Hello CHICKEN users,

A problem was found with the read-u8vector! procedure from the srfi-4
unit, which is almost identical to CVE-2013-4385 (which related to
the read-string! procedure, see 
https://lists.nongnu.org/archive/html/chicken-announce/2013-09/msg00000.html
for details).

If read-u8vector! is called with #f as the "NUM" argument, it didn't
bound the read to the u8vector's size, resulting in a buffer overrun
which may lead to general corruption of the stack or heap, and can
potentially be used to execute arbitrary code.

This has been fixed with changeset 1d06ce7e21c7e903ca5dca11fda6fcf2cc52de5e
http://code.call-cc.org/cgi-bin/gitweb.cgi?p=chicken-core.git;a=commit;h=1d06ce7e21c7e903ca5dca11fda6fcf2cc52de5e

All currently released CHICKENs are vulnerable to this bug: this includes
stable versions up until 4.8.0.6, and all 4.8.x development snapshots.
CHICKEN 4.9.0 and a possible 4.8.0.7 will include the fix, as will all
development snapshots starting with 4.9.1.

Like CVE-2013-4385, only code that uses the destructive read-u8vector!
variant with #f as a length argument is vulnerable.  A similar workaround
helps in this case: Convert all (read-u8vector! #f buf ...) calls to
(read-u8vector! (u8vector-length buf) buf ...), or, if possible, use the
safe, non-destructive read-u8vector version from the srfi-4 unit.

A quick scan of the egg repository indicates that only two eggs use
read-u8vector! in a potentially unsafe way.  The (currently unreleased)
r7rs egg's read-bytevector! procedure maps to read-u8vector!, so any
program using that with #f as the length argument is susceptible to this
vulnerability.  The srfi-27 egg's entropy-source-u8vector procedure also
indirectly exposes the read-u8vector! vulnerability, but it is
undocumented that a LENGTH of #f is allowed.

This means that applications should be safe if they don't call
read-u8vector! directly with a #f size and use only documented
functionality of released eggs.

Kind regards,
The CHICKEN team



reply via email to

[Prev in Thread] Current Thread [Next in Thread]