[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
- [Chicken-users] [SECURITY] Buffer-overrun in some uses of read-u8vector,
Peter Bex <=