libpng exploit.. possible interim fix?

  • Thread starter Thread starter Mark Miller
  • Start date Start date
M

Mark Miller

Seeing as MS has yet to release a fix for the libpng
exploit, I was wondering if removing pngfilt.dll will
solve the problem by preventing IE from even attempting to
decode .png files.

Thx,
Mark Miller
 
Not sure, sounds like a good guess.

Maybe I'm out of the loop, but I haven't seen or been able to find any
trustworthy information confirming that Windows or IE are definitely
vulnerable to the libpng vulnerability, which of the libpng
vulnerabilities affect it, and/or that anything more serious than
"just" a browser crash is possible. Do you have a link or such
information?
 
If you go to this website, the owner has several
sample .png files which demonstrate the exploit. It
crashed my IE which was enough for me to believe that if
it can crash the browser, it could do more damage if
the .png files were maliciously designed to take advantage
of the vulnerability:

http://zcrayfish.augurtech.com/bad.htm

For what it's worth, going into the recovery console and
manually renaming pngfilt.dll to, e.g., pngfilt_.dll
bypasses the problem at the cost of not being able to
view .png files in IE. Since .png graphics are not nearly
as popular as .gif and .jpg, until Microsoft bothers to
advise US-CERT with something more than "unknown" (see
link below), I'll assume the browser is vulnerable and
just live without .png file viewing from within IE.

http://www.kb.cert.org/vuls/id/388984

-Mark
 
For what it's worth, going into the recovery console and
manually renaming pngfilt.dll to, e.g., pngfilt_.dll
bypasses the problem at the cost of not being able to
view .png files in IE. Since .png graphics are not nearly
as popular as .gif and .jpg, until Microsoft bothers to
advise US-CERT with something more than "unknown" (see
link below), I'll assume the browser is vulnerable and
just live without .png file viewing from within IE.
Click to expand...

FWIW, Microsoft appears to have a policy that they avoid discussing
vulnerabilities in most cases until a patch is available. I would guess
they feel that acknowledging a vulnerability before there is a fix puts you
the user at additional risk. There is some merit to that. Also, this is a
relatively new vulnerability, and I can't blame Microsoft for not releasing
a patch yet.

Part of the blame lies on security investigators who announce a
vulnerability to the world without first contacting the vendor privately to
give them a reasonable amount of time to fix the problem without impact to
the customer. Security investigators that don't do that are endangering
Internet users like you and me. Microsoft can code a fix for things in
minutes or hours in some cases, but if they released that patch and it broke
something on your system, you and millions of other people would be pretty
upset. When there are serious vulnerabilities, work can happen round the
clock at Microsoft as needed. But most of the delay on making patches is
probably usually beta testing the patches, and if a problem is found, then a
new beta would probably have to be started.
 
Well, thank you Karl. I greatly appreciate your prompt
responses and all the info. I'll keep an eye out for the
patch. Have a great weekend.

-Mark
 
Although MS uses libpng in some of its products, it doesn't use it in
Internet Explorer. You can demonstrate this to yourself, by running
"strings -a pngfilt.dll". This reveals a bunch of strings found in
zlib version 1.1.4 but nothing from libpng.

Some of the libpng test cases do crash non-libpng applications because
they are so huge (one has a billion rows) that it isn't surprising that
they run out of memory and such. That doesn't necessarily mean that a
malicious png file could actually take over the browser, the way it
supposedly can with libpng-based applications.
 
Hmm... and yet IE has the ability to render PNG images. Could it be that
the call to pngfilt or another dll is actually contained in the MS HTML
rendering subsytem, e.g. MSHTML.DLL or another related library, and that you
didn't run strings on the necessary file?
 
Karl Levinson [x y] mvp said:
Hmm... and yet IE has the ability to render PNG images.
Click to expand...

As Mark said earlier in this thread, it doesn't if you remove or rename
pngfilt.dll.
Could it be that
the call to pngfilt or another dll is actually contained in the MS HTML
rendering subsytem, e.g. MSHTML.DLL or another related library, and that you
didn't run strings on the necessary file?
Click to expand...

"strings" does output IDAT PLTE IHDR and IEND which indicates that the
file is indeed a (somewhat limited, because tRNS, gAMA, and others are
missing) PNG decoder.

Glenn
 
Glenn Randers-Pehrson said:
"Karl Levinson [x y] mvp" <[email protected]> wrote in message
Hmm... and yet IE has the ability to render PNG images.
Click to expand...

As Mark said earlier in this thread, it doesn't if you remove or rename
pngfilt.dll.
Click to expand...

I know. What I'm saying is, I am wondering if it is wise to assume that IE
doesn't use vulnerable PNG code because the file or files you checked with
strings [I'm not sure which files you checked] didn't turn up libpng. My
understanding is that HTML rendering isn't done by IE but by Windows via the
MS HTML rendering subsystem contained in different files and folders from
IE. Given that Windows, especially Windows HTML rendering, is all about
re-using common library code, and that the number one Windows application
that typically uses PNG files is IE, it seems strange that MS would have a
..dll for handling PNG files but not use it in IE.

I agree this might not be a remote code execution vulnerability. As you
know, several vulnerabilities were found, most of which "just" crashed the
browser as far as we know at this point.
 
Back
Top