Netscape Communicator 4.x JPEG-Comment Heap Overwrite Vulnerability

                                                source: http://www.securityfocus.com/bid/1503/info

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.

http://www.exploit-db.com/sploits/20098.jpg