CVE-2004-0598
CVSS5.0
发布时间 :2004-11-23 00:00:00
修订时间 :2016-10-17 22:46:33
NMCOP    

[原文]The png_handle_iCCP function in libpng 1.2.5 and earlier allows remote attackers to cause a denial of service (application crash) via a certain PNG image that triggers a null dereference.


[CNNVD]libpng png_handle_iCCP NULL指针远程拒绝服务漏洞(CNNVD-200411-144)

        
        libpng是多种应用程序使用的解析PNG图象格式的库。
        libpng png_handle_iCCP()在内存分配时存在问题,远程攻击者可以利用这个漏洞对应用程序进行拒绝服务攻击。
        构建恶意的PNG图象,当png_handle_iCCP()处理内存分配时会由于NULL指针废弃而造成拒绝服务攻击。
        攻击者可以构建恶意PNG文件,诱使用户解析,可能导致应用程序崩溃。
        

- CVSS (基础分值)

CVSS分值: 5 [中等(MEDIUM)]
机密性影响: [--]
完整性影响: [--]
可用性影响: [--]
攻击复杂度: [--]
攻击向量: [--]
身份认证: [--]

- CPE (受影响的平台与产品)

产品及版本信息(CPE)暂不可用

- OVAL (用于检测的技术细节)

oval:org.mitre.oval:def:2572DoS Vulnerability in libpng function png_handle_iCCP()
oval:org.mitre.oval:def:10203The png_handle_iCCP function in libpng 1.2.5 and earlier allows remote attackers to cause a denial of service (application crash) via a cert...
*OVAL详细的描述了检测该漏洞的方法,你可以从相关的OVAL定义中找到更多检测该漏洞的技术细节。

- 官方数据库链接

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0598
(官方数据源) MITRE
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2004-0598
(官方数据源) NVD
http://www.cnnvd.org.cn/vulnerability/show/cv_cnnvdid/CNNVD-200411-144
(官方数据源) CNNVD

- 其它链接及资源

http://distro.conectiva.com.br/atualizacoes/?id=a&anuncio=000856
(UNKNOWN)  CONECTIVA  CLA-2004:856
http://marc.info/?l=bugtraq&m=109163866717909&w=2
(UNKNOWN)  BUGTRAQ  20040804 [OpenPKG-SA-2004.035] OpenPKG Security Advisory (png)
http://marc.info/?l=bugtraq&m=109181639602978&w=2
(UNKNOWN)  HP  SSRT4778
http://marc.info/?l=bugtraq&m=109761239318458&w=2
(UNKNOWN)  SCO  SCOSA-2004.16
http://scary.beasts.org/security/CESA-2004-001.txt
(VENDOR_ADVISORY)  MISC  http://scary.beasts.org/security/CESA-2004-001.txt
http://sunsolve.sun.com/search/document.do?assetkey=1-66-200663-1
(UNKNOWN)  SUNALERT  200663
http://www.debian.org/security/2004/dsa-536
(VENDOR_ADVISORY)  DEBIAN  DSA-536
http://www.gentoo.org/security/en/glsa/glsa-200408-03.xml
(VENDOR_ADVISORY)  GENTOO  GLSA-200408-03
http://www.gentoo.org/security/en/glsa/glsa-200408-22.xml
(VENDOR_ADVISORY)  GENTOO  GLSA-200408-22
http://www.kb.cert.org/vuls/id/236656
(VENDOR_ADVISORY)  CERT-VN  VU#236656
http://www.mandriva.com/security/advisories?name=MDKSA-2004:079
(UNKNOWN)  MANDRAKE  MDKSA-2004:079
http://www.mandriva.com/security/advisories?name=MDKSA-2006:212
(UNKNOWN)  MANDRIVA  MDKSA-2006:212
http://www.mandriva.com/security/advisories?name=MDKSA-2006:213
(UNKNOWN)  MANDRIVA  MDKSA-2006:213
http://www.mozilla.org/projects/security/known-vulnerabilities.html
(UNKNOWN)  CONFIRM  http://www.mozilla.org/projects/security/known-vulnerabilities.html
http://www.novell.com/linux/security/advisories/2004_23_libpng.html
(VENDOR_ADVISORY)  SUSE  SUSE-SA:2004:023
http://www.redhat.com/support/errata/RHSA-2004-402.html
(VENDOR_ADVISORY)  REDHAT  RHSA-2004:402
http://www.redhat.com/support/errata/RHSA-2004-429.html
(VENDOR_ADVISORY)  REDHAT  RHSA-2004:429
http://www.securityfocus.com/bid/10857
(VENDOR_ADVISORY)  BID  10857
http://www.trustix.net/errata/2004/0040/
(VENDOR_ADVISORY)  TRUSTIX  2004-0040
http://www.us-cert.gov/cas/techalerts/TA04-217A.html
(VENDOR_ADVISORY)  CERT  TA04-217A
http://xforce.iss.net/xforce/xfdb/16895
(VENDOR_ADVISORY)  XF  libpng-pnghandleiccp-dos(16895)
https://bugzilla.fedora.us/show_bug.cgi?id=1943
(PATCH)  FEDORA  FLSA:1943

- 漏洞信息

libpng png_handle_iCCP NULL指针远程拒绝服务漏洞
中危 未知
2004-11-23 00:00:00 2010-04-02 00:00:00
远程  
        
        libpng是多种应用程序使用的解析PNG图象格式的库。
        libpng png_handle_iCCP()在内存分配时存在问题,远程攻击者可以利用这个漏洞对应用程序进行拒绝服务攻击。
        构建恶意的PNG图象,当png_handle_iCCP()处理内存分配时会由于NULL指针废弃而造成拒绝服务攻击。
        攻击者可以构建恶意PNG文件,诱使用户解析,可能导致应用程序崩溃。
        

- 公告与补丁

        厂商补丁:
        libpng
        ------
        使用如下补丁程序:
        diff -ru libpng-1.2.5/png.h libpng-1.2.5.fix/png.h
        --- libpng-1.2.5/png.h 2002-10-03 12:32:26.000000000 +0100
        +++ libpng-1.2.5.fix/png.h 2004-07-13 23:18:10.000000000 +0100
        @@ -835,6 +835,9 @@
         /* Maximum positive integer used in PNG is (2^31)-1 */
         #define PNG_MAX_UINT ((png_uint_32)0x7fffffffL)
        +/* Constraints on width, height, (2 ^ 24) - 1*/
        +#define PNG_MAX_DIMENSION 16777215
        +
         /* These describe the color_type field in png_info. */
         /* color type masks */
         #define PNG_COLOR_MASK_PALETTE 1
        diff -ru libpng-1.2.5/pngpread.c libpng-1.2.5.fix/pngpread.c
        --- libpng-1.2.5/pngpread.c 2002-10-03 12:32:28.000000000 +0100
        +++ libpng-1.2.5.fix/pngpread.c 2004-07-13 23:03:58.000000000 +0100
        @@ -209,6 +209,8 @@
         png_push_fill_buffer(png_ptr, chunk_length, 4);
         png_ptr->push_length = png_get_uint_32(chunk_length);
        + if (png_ptr->push_length > PNG_MAX_UINT)
        + png_error(png_ptr, "Invalid chunk length.");
         png_reset_crc(png_ptr);
         png_crc_read(png_ptr, png_ptr->chunk_name, 4);
         png_ptr->mode |= PNG_HAVE_CHUNK_HEADER;
        @@ -638,6 +640,8 @@
         png_push_fill_buffer(png_ptr, chunk_length, 4);
         png_ptr->push_length = png_get_uint_32(chunk_length);
        + if (png_ptr->push_length > PNG_MAX_UINT)
        + png_error(png_ptr, "Invalid chunk length.");
         png_reset_crc(png_ptr);
         png_crc_read(png_ptr, png_ptr->chunk_name, 4);
        diff -ru libpng-1.2.5/pngrutil.c libpng-1.2.5.fix/pngrutil.c
        --- libpng-1.2.5/pngrutil.c 2004-07-13 13:36:37.000000000 +0100
        +++ libpng-1.2.5.fix/pngrutil.c 2004-07-13 23:43:02.000000000 +0100
        @@ -350,7 +350,11 @@
         png_crc_finish(png_ptr, 0);
         width = png_get_uint_32(buf);
        + if (width > PNG_MAX_DIMENSION)
        + png_error(png_ptr, "Width is too large");
         height = png_get_uint_32(buf + 4);
        + if (height > PNG_MAX_DIMENSION)
        + png_error(png_ptr, "Height is too large");
         bit_depth = buf[8];
         color_type = buf[9];
         compression_type = buf[10];
        @@ -675,7 +679,7 @@
         else
         truelen = (png_size_t)png_ptr->channels;
        - if (length != truelen)
        + if (length != truelen || length > 4)
         {
         png_warning(png_ptr, "Incorrect sBIT chunk length");
         png_crc_finish(png_ptr, length);
        @@ -1244,7 +1248,8 @@
         /* Should be an error, but we can cope with it */
         png_warning(png_ptr, "Missing PLTE before tRNS");
         }
        - else if (length > (png_uint_32)png_ptr->num_palette)
        + if (length > (png_uint_32)png_ptr->num_palette ||
        + length > PNG_MAX_PALETTE_LENGTH)
         {
         png_warning(png_ptr, "Incorrect tRNS chunk length");
         png_crc_finish(png_ptr, length);
        @@ -1400,7 +1405,7 @@
         void /* PRIVATE */
         png_handle_hIST(png_structp png_ptr, png_infop info_ptr, png_uint_32 length)
         {
        - int num, i;
        + unsigned int num, i;
         png_uint_16 readbuf[PNG_MAX_PALETTE_LENGTH];
         png_debug(1, "in png_handle_hIST\n");
        @@ -1426,8 +1431,8 @@
         return;
         }
        - num = (int)length / 2 ;
        - if (num != png_ptr->num_palette)
        + num = length / 2 ;
        + if (num != png_ptr->num_palette || num > PNG_MAX_PALETTE_LENGTH)
         {
         png_warning(png_ptr, "Incorrect hIST chunk length");
         png_crc_finish(png_ptr, length);
        @@ -2868,6 +2873,9 @@
         png_read_data(png_ptr, chunk_length, 4);
         png_ptr->idat_size = png_get_uint_32(chunk_length);
        + if (png_ptr->idat_size > PNG_MAX_UINT)
        + png_error(png_ptr, "Invalid chunk length.");
        +
         png_reset_crc(png_ptr);
         png_crc_read(png_ptr, png_ptr->chunk_name, 4);
         if (png_memcmp(png_ptr->chunk_name, (png_bytep)png_IDAT, 4))

- 漏洞信息 (F33973)

Chris Evans Security Advisory 2004.1 (PacketStormID:F33973)
2004-08-05 00:00:00
Chris Evans  
advisory,overflow
CVE-2004-0597,CVE-2004-0598,CVE-2004-0599
[点击下载]

libpng version 1.2.5 is susceptible to stack-based buffer overflows and various other code concerns.

CESA-2004-001 - rev 3

libPNG 1.2.5 stack-based buffer overflow and other code concerns
================================================================

Programs         : libpng users including mozilla, konqueror, various e-mail
                   clients, generally lots. Also reports that some versions of
                   IE are vulnerable to some of the problems.
Severity         : - A malicious website serving a malicious PNG file could
                     compromise the browsers of visitors.
                   - A malicious PNG could be sent via e-mail and compromise
                     the e-mail viewer of the recipient.
                   - For systems with user-providable images for "face
                     browsers", a local system compromise could be possible via
                     a malicious PNG.
CAN identifier(s): CAN-2004-0597 (the serious one), CAN-2004-0598,
                   CAN-2004-0599
CERT VU#s        : VU#388984 (the serious one), VU#236656, VU#160448,
                   VU#477512, VU#817368, VU#286464

This advisory lists code flaws discovered by inspection of the libpng-1.2.5
code. Only the first one has been examined in practice to confirm
exploitability. The other flaws certainly warrant fixing.

A patch which should plug all these issues is appended beneath the advisory.
NOTE! This patch serves as demo purposes for the flaws only. An official
v1.2.6 libpng with an official, slightly different fix will be released by
the libpng team in parallel with this advisory.

1) Remotely exploitable stack-based buffer overrun in png_handle_tRNS
(pngrutil.c)

If a PNG file is of the correct format, a length check on PNG data is missed
prior to filling a buffer on the stack from the PNG data. The exact flaw would
seem to be a logic error; failure to bail out of a function after a warning
condition is hit, here:

      if (!(png_ptr->mode & PNG_HAVE_PLTE))
      {
         /* Should be an error, but we can cope with it */
         png_warning(png_ptr, "Missing PLTE before tRNS");
      }
      else if (length > (png_uint_32)png_ptr->num_palette)
      {
         png_warning(png_ptr, "Incorrect tRNS chunk length");
         png_crc_finish(png_ptr, length);
         return;
      }

We can see, if the first warning condition is hit, the length check is missed
due to the use of an "else if".

A PNG crafted to trip this is available at
http://scary.beasts.org/misc/pngtest_bad.png

It crashes both mozilla and konqueror.
A scarier possibility is targetted exploitation by e-mailing a nasty PNG to
someone who uses a graphical e-mail client to decode PNGs with a vulnerable
libpng.


2) Dangerous code in png_handle_sBIT (pngrutil.c) (Similar code in
png_handle_hIST).

Although seemingly not exploitable, there is dangerous code in this function.
It relies on checks scattered elsewhere in the code in order to not overflow
a 4-byte stack buffer. This line here should upper-bound the read onto the
stack to 4 bytes:

   png_crc_read(png_ptr, buf, truelen);


3) Possible NULL-pointer crash in png_handle_iCCP (pngrutil.c) (this flaw is
duplicated in multiple other locations).

There are lots of lines such as these in the code:

   chunkdata = (png_charp)png_malloc(png_ptr, length + 1);

Where "length" comes from the PNG. If length is set to UINT_MAX then length + 1 will equate to zero, leading to the PNG malloc routines to return NULL and
subsequent access to crash. These lengths are sometimes checked to ensure
they are smaller that INT_MAX, but it is not clear that all code paths perform
this check, i.e. png_push_read_chunk in pngpread.c does not do this check
(this is progressive reading mode as used by browsers).


4) Theoretical integer overflow in allocation in png_handle_sPLT (pngrutil.c)

This isn't likely to cause problems in practice, but there's the possibility
of an integer overflow during this allocation:

   new_palette.entries = (png_sPLT_entryp)png_malloc(
       png_ptr, new_palette.nentries * sizeof(png_sPLT_entry));


5) Integer overflow in png_read_png (pngread.c)

A PNG with excessive height may cause an integer overflow on a memory
allocation and subsequent crash allocating row pointers. This line is possibly
faulty; I can't see anywhere that enforces a maximum PNG height:

      info_ptr->row_pointers = (png_bytepp)png_malloc(png_ptr,
         info_ptr->height * sizeof(png_bytep));


6) Integer overflows during progressive reading.

There are many lines like the following, which are prone to integer overflow:

      if (png_ptr->push_length + 4 > png_ptr->buffer_size)

It is not clear how dangerous this is.


7) Other flaws.

There is broad potential for other integer overflows which I have not spotted -
the amount of integer arithmetic surrounding buffer handling is large,
unfortunately.


CESA-2004-001 - rev 3
Chris Evans
chris@scary.beasts.org

[Advertisement: I am interested in moving into a security related field
 full-time. E-mail me to discuss.]


diff -ru libpng-1.2.5/png.h libpng-1.2.5.fix/png.h
--- libpng-1.2.5/png.h	2002-10-03 12:32:26.000000000 +0100
+++ libpng-1.2.5.fix/png.h	2004-07-13 23:18:10.000000000 +0100
@@ -835,6 +835,9 @@
 /* Maximum positive integer used in PNG is (2^31)-1 */
 #define PNG_MAX_UINT ((png_uint_32)0x7fffffffL)
 
+/* Constraints on width, height, (2 ^ 24) - 1*/
+#define PNG_MAX_DIMENSION 16777215
+
 /* These describe the color_type field in png_info. */
 /* color type masks */
 #define PNG_COLOR_MASK_PALETTE    1
diff -ru libpng-1.2.5/pngpread.c libpng-1.2.5.fix/pngpread.c
--- libpng-1.2.5/pngpread.c	2002-10-03 12:32:28.000000000 +0100
+++ libpng-1.2.5.fix/pngpread.c	2004-07-13 23:03:58.000000000 +0100
@@ -209,6 +209,8 @@
 
       png_push_fill_buffer(png_ptr, chunk_length, 4);
       png_ptr->push_length = png_get_uint_32(chunk_length);
+      if (png_ptr->push_length > PNG_MAX_UINT)
+         png_error(png_ptr, "Invalid chunk length.");
       png_reset_crc(png_ptr);
       png_crc_read(png_ptr, png_ptr->chunk_name, 4);
       png_ptr->mode |= PNG_HAVE_CHUNK_HEADER;
@@ -638,6 +640,8 @@
 
       png_push_fill_buffer(png_ptr, chunk_length, 4);
       png_ptr->push_length = png_get_uint_32(chunk_length);
+      if (png_ptr->push_length > PNG_MAX_UINT)
+         png_error(png_ptr, "Invalid chunk length.");
 
       png_reset_crc(png_ptr);
       png_crc_read(png_ptr, png_ptr->chunk_name, 4);
diff -ru libpng-1.2.5/pngrutil.c libpng-1.2.5.fix/pngrutil.c
--- libpng-1.2.5/pngrutil.c	2004-07-13 13:36:37.000000000 +0100
+++ libpng-1.2.5.fix/pngrutil.c	2004-07-13 23:43:02.000000000 +0100
@@ -350,7 +350,11 @@
    png_crc_finish(png_ptr, 0);
 
    width = png_get_uint_32(buf);
+   if (width > PNG_MAX_DIMENSION)
+      png_error(png_ptr, "Width is too large");
    height = png_get_uint_32(buf + 4);
+   if (height > PNG_MAX_DIMENSION)
+      png_error(png_ptr, "Height is too large");
    bit_depth = buf[8];
    color_type = buf[9];
    compression_type = buf[10];
@@ -675,7 +679,7 @@
    else
       truelen = (png_size_t)png_ptr->channels;
 
-   if (length != truelen)
+   if (length != truelen || length > 4)
    {
       png_warning(png_ptr, "Incorrect sBIT chunk length");
       png_crc_finish(png_ptr, length);
@@ -1244,7 +1248,8 @@
          /* Should be an error, but we can cope with it */
          png_warning(png_ptr, "Missing PLTE before tRNS");
       }
-      else if (length > (png_uint_32)png_ptr->num_palette)
+      if (length > (png_uint_32)png_ptr->num_palette ||
+          length > PNG_MAX_PALETTE_LENGTH)
       {
          png_warning(png_ptr, "Incorrect tRNS chunk length");
          png_crc_finish(png_ptr, length);
@@ -1400,7 +1405,7 @@
 void /* PRIVATE */
 png_handle_hIST(png_structp png_ptr, png_infop info_ptr, png_uint_32 length)
 {
-   int num, i;
+   unsigned int num, i;
    png_uint_16 readbuf[PNG_MAX_PALETTE_LENGTH];
 
    png_debug(1, "in png_handle_hIST\n");
@@ -1426,8 +1431,8 @@
       return;
    }
 
-   num = (int)length / 2 ;
-   if (num != png_ptr->num_palette)
+   num = length / 2 ;
+   if (num != png_ptr->num_palette || num > PNG_MAX_PALETTE_LENGTH)
    {
       png_warning(png_ptr, "Incorrect hIST chunk length");
       png_crc_finish(png_ptr, length);
@@ -2868,6 +2873,9 @@
                png_read_data(png_ptr, chunk_length, 4);
                png_ptr->idat_size = png_get_uint_32(chunk_length);
 
+               if (png_ptr->idat_size > PNG_MAX_UINT)
+                  png_error(png_ptr, "Invalid chunk length.");
+            
                png_reset_crc(png_ptr);
                png_crc_read(png_ptr, png_ptr->chunk_name, 4);
                if (png_memcmp(png_ptr->chunk_name, (png_bytep)png_IDAT, 4))
    

- 漏洞信息

8313
libpng png_handle_iCCP() Function NULL Pointer Dereference DoS
Local Access Required Denial of Service, Input Manipulation
Loss of Availability
Exploit Unknown

- 漏洞描述

A local overflow exists in libpng. The library function png_handle_iCCP fails to validate the input length from PNG files resulting in a possible NULL-pointer being referenced. With a specially crafted request, an attacker can cause denial of service which might result in a loss of availability for the application.

- 时间线

2004-08-04 Unknow
Unknow Unknow

- 解决方案

Upgrade to version 1.2.6 release candidate 1 or higher, as it has been reported to fix this vulnerability. An upgrade is required as there are no known workarounds. Users of the older 1.0 series should upgrade to libpng-1.0.16 release candidate 1 or higher.

- 相关参考

- 漏洞作者

 

 

关于SCAP中文社区

SCAP中文社区是国内第一个以SCAP为主题的中文开放社区。了解更多信息,请查阅[关于本站]

版权声明

CVE/CWE/OVAL均为MITRE公司的注册商标,它们的官方数据源均保存在MITRE公司的相关网站