AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2013.08.01 09:21 "[Tiff] Vulnerabilities in libtiff 4.0.3", by Pedro Ribeiro
2013.09.20 16:09 "Re: [Tiff] Vulnerabilities in libtiff 4.0.3", by Lee Howard
2013.09.20 16:24 "Re: [Tiff] Vulnerabilities in libtiff 4.0.3", by Bob Friesenhahn
2013.09.20 16:34 "Re: [Tiff] Vulnerabilities in libtiff 4.0.3", by Lee Howard
2013.09.20 16:59 "Re: [Tiff] Vulnerabilities in libtiff 4.0.3", by Olivier Paquet
2013.09.20 17:05 "Re: [Tiff] Vulnerabilities in libtiff 4.0.3", by Bob Friesenhahn
2013.09.20 17:02 "Re: [Tiff] Vulnerabilities in libtiff 4.0.3", by Bob Friesenhahn
2013.09.20 17:21 "Re: [Tiff] Vulnerabilities in libtiff 4.0.3", by Lee Howard
2013.09.24 06:55 "Re: [Tiff] Vulnerabilities in libtiff 4.0.3", by Albert Cahalan

2013.09.20 16:34 "Re: [Tiff] Vulnerabilities in libtiff 4.0.3", by Lee Howard

On 09/20/2013 09:24 AM, Bob Friesenhahn wrote:

Justification:

Use of sprintf to write into a 2048 character buffer. The input is the filename, which might be over 2048 if crafted by a malicious user. However I could not determine this as the code is not easy to navigate.

This appears to be resolved already in CVS since the code now uses snprintf() instead of sprintf():

           snprintf(buf, sizeof(buf), "YCbCr conversion of %s",

Please be aware that snprintf is not assured to null-terminate the destination string. Is this being handled by subsequent statements or is the problem only changed?

The snprintf man page says:

        The functions snprintf() and vsnprintf() write at most size

bytes (including the trailing null byte ('\0')) to str.

        The trailing null byte is added to str, unless size is zero.

Is it wrong? What am I missing?

Thanks,

Lee.