Netscape Communicator JPEG-Comment Heap Overwrite Vulnerability
Reading time: 2 – 2 minutes
Antiga vulnerabilitat dels netscape’s, no m’hi havia fixat però tot
llegint la BUGTRAQ m’he trobat aquesta url de securityfocus:
http://www.securityfocus.com/bid/1503 on es descriu el bug i és molt
interessant, més del q sembla a primera vista 😉
Netscape Browsers use the Independent JPEG Group’s decoder library to
process JPEG encoded images. The library functions skip JPEG comments; however,
the browser uses a custom function to process these comments and store them in
memory. The comment includes a 2-byte “length” field which indicates how long
the comment is – this value includes the 2-bytes of the “length” field. To
determine the length of the comment string alone (for memory allocation), the
function reads the value in the “length” field and subtracts two. The function
then allocates the length of the comment + one byte for NULL termination. There
is no error checking to ensure the “length” value is valid. This makes it
possible to cause an overflow by creating an image with a comment “length”
field containing the value 1. The memory allocation call of 0 bytes (1 minus 2
(length field) + 1 (null termination)) will succeed. The calculated comment
size variable is declared unsigned, resulting in a large positive value (from 1
minus 2). The comment handling function goes into a loop to read the comment
into memory, but since the calculated comment size is enormous this causes the
function to read the entire JPEG stream, overwriting the heap. It is
theoretically possible to exploit this to execute arbitrary code. The browser,
mail and news readers are all vulnerable to this.