[Png-mng-security] Order of building gamma_16_table and png_do_chop

Glenn Randers-Pehrson glennrp at gmail.com
Wed Feb 18 12:47:59 UTC 2009


In pngrtran.c we have this:

#if defined(PNG_READ_GAMMA_SUPPORTED)
   if ((png_ptr->transformations & PNG_GAMMA) &&
#if defined(PNG_READ_BACKGROUND_SUPPORTED)
      !((png_ptr->transformations & PNG_BACKGROUND) &&
      ((png_ptr->num_trans != 0) ||
      (png_ptr->color_type & PNG_COLOR_MASK_ALPHA))) &&
#endif
      (png_ptr->color_type != PNG_COLOR_TYPE_PALETTE))
      png_do_gamma(&(png_ptr->row_info), png_ptr->row_buf + 1,
         png_ptr->gamma_table, png_ptr->gamma_16_table,
         png_ptr->gamma_shift);
#endif

#if defined(PNG_READ_16_TO_8_SUPPORTED)
   if (png_ptr->transformations & PNG_16_TO_8)
      png_do_chop(&(png_ptr->row_info), png_ptr->row_buf + 1);
#endif

Later on, when building gamma tables, we use png_info->depth
to decide whether to build the 16-bit gamma tables or the 8-bit
table.  png_info->depth gets set in png_do_chop().  This means
that the 16-bit gamma tables get built even if the user has
called png_set_strip_16().  That seems to me to be a waste,
and it unnecessarily exposes applications to the current
memory allocation vulnerability.  For example, it makes
mozilla/firefox vulnerable, even though it uses png_set_strip_16(().

Is there any reason not to swap these two blocks of code
in libpng-1.4.0beta, to avoid unnecessarily building the
16-bit gamma tables?

Glenn



More information about the png-mng-security-archive mailing list