Slashdot Mirror
New Windows Vulnerability in Help System
wesleyt writes "CERT announced today a significant Microsoft Windows vulnerability related to IE and its handling of the Windows help subsystem. There are currently no patches available and no virus definitions for the major scanners. As well, exploits have been reported in the wild. Because the vulnerability is in the help subsystem, even users who avoid Outlook and IE are vulnerable, since IE is the default handler for help files. It seems that this is going to be an ugly one."
Although there's no specific patch, the Windows XP SP2 release candidate mitigates this problem.
They announced this TODAY? It has been discussed on Bugtraq for weeks - and due to a few comments I made in their discussion forum the Swedish IDG.se reported this last Friday. I've also linked to one of the PoC-exploits here on Slashdot for people check for themselves. ... what took them so long?
Jelmer's PoC is good: link
(That page is the info page, you won't get hit by clicking on the link directly)
it's in my head
Use the runas service to do administrative stuff. You can either use it in command line form or hold down shift and right click on an executable. It works on most control panel applets as well.
This is a much broader problem than merely stupid/lazy users.
Remember to backup your registry (or at least this portion of it)
a nd ler\{ms-its,ms-itss,its,mk}
From the CERT article:
Currently, there is no complete solution for this vulnerability. Until a patch is available, consider the workarounds listed below.
Disable ITS protocol handlers
Disabling ITS protocol handlers appears to prevent exploitation of this vulnerability. Delete or rename the following registry keys:
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\PROTOCOLS\H
Disabling these protocol handlers will significantly reduce the functionality of the Windows Help system and may have other unintended consequences. Plan to undo these changes after patches have been tested and installed.
Follow good Internet security practices
These recommended security practices will help to reduce exposure to attacks and mitigate the impact of cross-domain vulnerabilities.
Disable Active scripting and ActiveX controls
NOTE: Disabling Active scripting and ActiveX controls will not prevent the exploitation of this vulnerability.
Disabling Active scripting and ActiveX controls in the Internet and Local Machine Zones may stop certain types of attacks and will prevent exploitation of different cross-domain vulnerabilities. Disable Active scripting and ActiveX controls in any zones used to read HTML email.
Disabling Active scripting and ActiveX controls in the Local Machine Zone will prevent malicious code that requires Active scripting and ActiveX controls from running. Changing these settings may reduce the functionality of scripts, applets, Windows components, or other applications. See Microsoft Knowledge Base Article 833633 for detailed information about security settings for the Local Machine Zone. Note that Service Pack 2 for Windows XP includes these changes.
Do not follow unsolicited links
Do not click on unsolicited URLs received in email, instant messages, web forums, or Internet relay chat (IRC) channels.
Maintain updated anti-virus software
Anti-virus software with updated virus definitions may identify and prevent some exploit attempts. Variations of exploits or attack vectors may not be detected. Do not rely solely on anti-virus software to defend against this vulnerability. More information about viruses and anti-virus vendors is available on the US-CERT Computer Virus Resources page.
The RUNAS service will allow you to run an executable with elevated privileges. And shortcuts have the option to run as a different user by clicking the check box that says,"Run as different user." To use the RUNAS service, just hold down shift and right-click and you'll see an option that says "Run As".
Save it as chm-disable.reg
Put a line like this in your logon script:
regedit
Use the same trick to restore the values when a patch is available (that means that you must save the HANDLER keys first).
Note: If you're still using batch files: KiXtart is your friend!
...but Mr MS-Security himself said that there were NO exploits prior to the security patches !
Maybe we deserve this world ?
I played with fire and tested the PoC found here
In IE, it copied itself over wmplayer.exe, SFP copied the original back, but that was enough for me. Firefox 0.8, OTOH, didn't budge and nothing happened to wmplayer.exe. Same thing with Netscape 7.1 and Opera 7.23.
At least in this case, IE seems to be the only one.
I ran a few quick tests on a couple of different Windows XP systems using the proof of concept exploit code here.
s peed.planet.nl/security/newone/modified//EXPLOIT.C HM::/exploit.htm
.chm) in any directories except for the ProgramFilesDir and System directories, but, as you can see, it did not stop the sample code from executing when IE was run with administrator privileges.
---------
Windows XP Professional Service Pack 1
Mozilla Firebird 0.8 run as limited user: no apparent effect
Mozilla Firebird 0.8 run as administrator: no apparent effect
Internet Explorer 6 run as limited user causes an Internet Explorer Script Error:
Line 47, Char: 5, Error: Write to file failed, Code: 0
URL: ms-its:mhtml:file://C:\foo.mht!http://ip3e83566f.
Internet Explorer 6 run as administrator: demo exploit runs as expected
A software restriction policy is in place on this machine, forbidding the execution of any executable files (including
------------
Windows XP Professional Service Pack 2 RC 1
Internet Explorer 6 run as administrator: no apparent effect
Fixed in SP2?
---------------
One thing that concerns me about using this particular sample code as a test, is that it seems to rely on having write permission to \Program Files, thus requiring administrator privileges (usually) and thus making limited user accounts appear to be invuelnerable -- but are they? Can a version of this exploit be written that runs even if the user does not have write privileges to the program files and system directories? (Thus giving access to all of the limited user's files.) In such a case, would software restriction policies prevent the execution of the exploit exe even if not stopping the script itself?