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

Oracle, under fire, admits to database security holes
By James Niccolai
IDG News Service, 08/03/04
 
Oracle has acknowledged the existence of multiple security holes in its database software and said it plans to issue a security alert shortly. The U.K. security expert who found the holes criticized Oracle's conduct, saying that it has been sitting on patches that would fix the holes for about two months.  
 
David Litchfield, managing director of Next Generation Security Software of Surrey, U.K. claims to have found 34 security vulnerabilities in past and current versions of Oracle's database software, at least one of which could allow a hacker to gain control of a company's database remotely without needing a password.  
 
Litchfield said he notified Oracle of the vulnerabilities in January, and said the company told him two months ago that it had prepared patches to repair them. Oracle has not released the patches, however, because it is in the midst of introducing a new system for distributing security fixes to customers, according to Litchfield, who was critical of the delay.  
 
"The way they should do it is to run the old system (for issuing patches) until the new system is ready for use," he said in a telephone interview from the U.K. Tuesday. "They have not handled this in the best way they could."  
 
Litchfield mentioned the vulnerabilities last week in a presentation at the Black Hat computer security conference in Las Vegas. They were first reported by The Wall Street Journal Tuesday.  
 
Oracle initially would not confirm or deny the vulnerabilities, saying only that it takes security matters seriously. Later Tuesday it appeared to confirm the flaws in a brief statement, but declined any further comment  
 
"Security is a matter we take seriously at Oracle and, while we stand firmly behind the inherent security of our products, we are always working to do better. Oracle has fixed the issues discussed in The Wall Street Journal and will issue a Security Alert soon," the statement read.  
 
Oracle prides itself on the security of its database software. Its advertising campaigns have focused on the idea that its database is "unbreakable," and it often talks of its security certifications awarded by U.S. government agencies.  
 
Litchfield declined to discuss the vulnerabilities in detail for fear of aiding hackers who might seek to exploit them. "In generic terms, the issues are buffer overflow vulnerabilities, PL-SQL injection vulnerabilities, and a couple of minor issues -- well, minor depending on how you do your risk assessment -- things like denial-of-service, passwords in clear text. Basically the whole gamut of vulnerability types."  
 
Until the patches are issued, companies can mitigate risk by following best practices recommended by vendors and consultants, he said, including providing as little access privileges to database users as is practically possible. "One can go a long way to mitigate the risk of these vulnerabilities, but some don't have workarounds," he said.  
 
Litchfield said that about half of the vulnerabilities affect Oracle's newest, 10g database, and that three of them are unique to that database, meaning they don't affect previous versions.  
 
Litchfield is known for releasing the proof-of-concept (or "exploit" ) code two years ago to help explain the threat caused by a vulnerability in Microsoft's SQL Server database. The code was used by hackers as a template to create the Slammer worm, which went on to cause widespread and costly damage.  
 
Litchfield said Tuesday that he has developed similar exploits for the vulnerabilities in Oracle's database, but, after the Slammer experience, he will not be releasing those exploits, he said.  
 
Most industry analysts had not seen the vulnerabilities Tuesday and said it was hard to gauge their severity. Litchfield said he was not aware of any exploits for the security holes circulating among hackers. In general, the analysts praised Oracle for the security of its products and for the way it has handled vulnerabilities in the past.  
 
"They do take these things pretty seriously. They had a security breach a couple of months ago and I think they put out a patch within a day or two," said IDC analyst Carl Olofson.  
 
However, as with any software product that has been on the market for years, "there are naturally going to be some old lines of code that need to be looked at. But you could say the same thing about DB2 and Sybase," he said, referring to two of Oracle's competitors.  
 
Colin White, president of IT consulting company BI Research, in Ashland, Ore., said security is less of a differentiating factor among database vendors now than in the past, because all the leading products are relatively secure.  
 
"However, as the way databases are used changes over time, as you move to a broader audience (of users) and to a Web-based environment, there are more points in the product that people could seek to exploit," he said.  
 
Litchfield said he expected Oracle to have issued the patches before his presentation last week at Black Hat. However, as happened at the same conference a year earlier, when Litchfield had planned to give a presentation discussing a different set of Oracle database flaws, on the day of his speech the patches still had not been issued, he said.  
 
"I gave them advance warnings last year and they said they would be ready, but on the day of my talk they told me the patches would not be ready. When I set off again this year and they did the same thing again, but for a different set of issues, I thought, 'No, not again,'" he said.  
 
Litchfield said he modified his talk this year and skimmed over his presentation slides describing the vulnerabilities, but he apparently provided enough information at the event for word of the security flaws to spread.  
 
Litchfield said he is aware that he's considered a "troublemaker" by some in the industry. He said he feels that he acts in a responsible way -- by waiting six months to discuss the latest security holes, for example. Even then, he said, he did not intentionally publicize them.  
 
A product such as Oracle's database has enough lines of code that, even with the knowledge that vulnerabilities are present, it would take considerable time and effort for a hacker to find them, he said.  
 
"I think it's fairly safe to talk about these issues. The only place where I can see that I might have been a troublemaker is to Oracle, but if it means that Oracle's customers will get patches that much quicker, then they should be happy about that," he said.  
 
One Oracle database customer said he had contacted Oracle about the security holes Tuesday after seeing The Wall Street Journal report. He was told that patches are not currently available but that they would be issued soon.  
 
"Any time there's this many vulnerabilities, to me it basically mimics the vulnerabilities in Microsoft's products, and I am concerned about it," said Brent Siler, director of IT for EXP Pharmaceutical Services, in Fremont, Calif.  
 
"Luckily for us, we do have intrusion detection systems that we've been able to go out and modify based on what we have been able to read into Mr. Litchfield's comments," he said. "This is definitely something we're going to stay on top of."
 
 
 
 
The IDG News Service is a Network World affiliate.
 
RELATED LINKS
 
   
All contents copyright 1995-2003 Network World, Inc. http://www.nwfusion.com  

Backdoor.Kika.A is a backdoor program that allows unauthorized remote access to a compromised system. It attempts to steal system and user information.  
 
Due to bugs in the code, some functions of this threat may not operate as intended, and the system may crash.
 
 
Also Known As:  BackDoor-CGU [McAfee], Backdoor.Agent.bm [Kaspersky]  
   
Type:  Trojan Horse  
Infection Length:  127,184 bytes (.dll), 7,936 bytes (.exe)  
   
   
   
Systems Affected:  Windows 2000, Windows 95, Windows 98, Windows Me, Windows NT, Windows XP  
Systems Not Affected:  Linux, Macintosh, Macintosh OS X, Novell Netware, OS/2, UNIX  
 

Holding down a special key combination crashes slower Windows XP and 2003 machines
Normally, holding down the WinKey (found between Ctrl and Alt) and pressing "u" launches a special Windows application called the Utility Manager. However, according to Nick Lowe's Full Disclosure mailing-list post, holding down both keys for an extended period of time can significantly slow down or even crash slower Windows XP and 2003 computers. Since you can launch Utility Manager from anywhere in Windows, even at a remote login screen, a remote attacker could even exploit this Denial-of-Service (DoS) flaw through Remote Desktop without having to authenticate to your computer.  
 
Even though Utility Manager was designed so that only one instance of the application will run at a time, holding down this key combination for an extended period of time causes the application start and stop faster than Windows can clean up its memory. Eventually, it sucks so much of your computers resources that it locks-up. You should note that this flaw only seems to affect slower computers. Faster machines with lots of RAM shouldn’t have any problems keeping up with repeated attempts at launching Utility Manager.  
 
Lowe released his advisory either before informing Microsoft or before they released a patch, so you can't fix this vulnerability yet. However, since a remote attacker can only exploit this flaw via Remote Desktop, we recommend you only allow incoming Remote Desktop traffic from IPs and users that you trust. ## -- Corey Nachreiner  
 
 
Copyright© 2004 WatchGuard® Technologies, Inc. You may copy and distribute this article freely in any medium as long as you copy and distribute the entire article without change and preserve this copyright statement and notice.