[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Chicken-announce] [SECURITY] Buffer overrun in some uses of read-string
[Chicken-announce] [SECURITY] Buffer overrun in some uses of read-string! procedure from "extras"
Thu, 26 Sep 2013 21:02:16 +0200
Hello CHICKEN users,
A problem was found with the read-string! procedure from the "extras"
unit, when used in a very particular way. The manual says:
[procedure] (read-string! NUM STRING [PORT [START]])
Read or write NUM characters from/to PORT [...]
If NUM is #f or not given, then all data up to the end-of-file
If no more input is available, read-string returns the
empty string. read-string! reads destructively into the given
STRING argument, but never more characters than would fit into
It turned out that there was a missing check for the situation when
NUM was #f and the input size to be read from the port exceeded the
given buffer's (STRING's) size. This will result in a buffer overrun,
which may lead to general corruption of the stack or heap, and
can potentially be used to execute arbitrary code.
The bug was fixed by changeset cd1b9775005ebe220ba11265dbf5396142e65f26
All currently released CHICKENs are vulnerable to this bug: all stable
versions up until 18.104.22.168, and all development snapshots up until 4.8.2.
CHICKEN 4.9.0 and 22.214.171.124 will include the fix, as will all development
snapshots starting with 4.8.3.
There is a simple workaround to be used in code that uses read-string!:
simply convert all (read-string! #f buf ...) invocations to
(read-string! (string-length buf) buf ...) or, if possible, use the
non-destructive read-string procedure from the same unit.
A quick scan of the egg repository pointed out that so far only
http-client seemed to be using read-string! in this manner. This
has been fixed in http-client 0.6.1, so all users are advised to
at least upgrade this egg.
The CHICKEN Team
- [Chicken-announce] [SECURITY] Buffer overrun in some uses of read-string! procedure from "extras",
Peter Bex <=