Trustworthy Computing 465
Anonymous Coward writes "This is a first: the Internet Storm Center is recommending trustworthy computing. They want you to trust that the unofficial patch for the Windows Metafile Volunerability that is currently being exploited by an IM worm. No patch from Microsoft at this time, and the exploit is arranged in such a manner that it cannot be detected by most intrusion detection systems (the snort rule will peg the CPU on your router) nor filtered by packet-inspecting firewalls (it spans two or more ethernet frames). Not really a whole lot of choice about this one."
Re:What's wrong with... (Score:3, Informative)
I deployed it (Score:4, Informative)
I've had two; and decided to come in to the office today to make sure we were patched up against the exploit.
Yes, I took the plunge.
The patch is now deployed in our small office (30 windows PCs atm); and so far so good.
Would I have felt safer if the sourcecode was released? Perhaps.
That said, I'd rather take the ISC's word on the fix than have a guaranteed hell within a couple of days.
The dedication of the people involved with ISC, as well as that of Mr. Guilfanov brightened my start of the new year.
Kudos, people.
Re:What's wrong with... (Score:4, Informative)
*Unregister the DLL : some apps may actually reregister the DLL.
*Rename/Delete: make sure XP File Protection is off, otherwise it will be replaced. Also, some apps may behave badly.
So, disabling the DLL is a *good* idea -- but may not be a complete solution by itself.
Re:SPI Aren't meant for this type of filtering... (Score:5, Informative)
* Should I just block all
This may help, but it is not sufficient. WMF files are recognized by a special header and the extension is not needed. The files could arrive using any extension, or embeded in Word or other documents.
Re:"the snort rule will peg the CPU on your router (Score:5, Informative)
A couple of the other comments here seem to miss this very important point:
It's not just files with ".wmf" at the end. Any image file will get unwrapped by Microsoft code and the callback will get executed. Woof.
Re:I deployed it (Score:5, Informative)
Would I have felt safer if the sourcecode was released? Perhaps.
But the source code is released, too . The installation package should have copied it into the "WindowsMetafileFix" folder under the "Program Files" folder.
Get the joke, will travel... (Score:5, Informative)
The title comes from the original note in the Handler's Diary [sans.org]. You see, it creates a mental tension between "Trustworth Computing", the lack of an official patch and ISC's "Please, trust us". It makes some readers smile.
Re:"the snort rule will peg the CPU on your router (Score:2, Informative)
It's not just files with ".wmf" at the end. Any image file will get unwrapped by Microsoft code and the callback will get executed.
Yes. You see, when the HTTP 1.1 protocol was being developed, they made it a solid rule - you MUST NOT GUESS the content-type when it's supplied.
Anybody want to hazard a guess as to what Internet Explorer and everything that uses its rendering engine does? Yep, that's right, it ignores the standard and guesses.
That means that instead of having to check <1% of images going through your firewall/proxy (WMFs and unlabelled content), you have to check 100% of them. Heck of a job, Billy-boy!
Re:Some won't (Score:4, Informative)
I'm a trusting person, and if ISC, and Fsecure's lab both recomend it, I don't mind applying it, I'd trust there code more than MS's
Re:Shame on Hemos (Score:5, Informative)
There is one important note in regards to ALL published signatures including this one. All these signatures will fail to detect the exploits when the http_inspect preprocessor is enabled with default settings. By default, the flow_depth of the preprocessor is 300 which is too short to cover the whole exploit. Should the exploit be transmitted on port 80 and http_inspect is enabled, no alert will occur. Note that it will still alert on any ports (using the all port sig below) that are not configured in http_inspect (ie FTP).
One solution is to add the statement "flow_depth 0" to the http_inspect preprocessor (actually the appropriate http_inspect_server line in the config). This will tell the preprocessor not to truncate the reassembled pseudo-packet, but it will have an adverse impact on performance. On busy networks, this will lead to 100% CPU utilization of the Snort process and major packet drops.
And you should've checked before saying it was all made up.
Re:Some won't (Score:4, Informative)
What is more, re-registering the dll by some bit of software is a possibility, but for this to happen without action from the user, there needs to be another vulnerability that allows running the code to do this (or another way to access this specific vulnerability). If there is another vulnerability then the hotfix won't make you safe, The hotfix does work and provide some extra protection but only for the cases where this specific vulnerability can be exploited through a different path (that does not use shimgvw.dll).
Re:Shame on Hemos (Score:1, Informative)
No flamebait intended, but that's a typical sensationalist misleading Slashdot headline. Noone's advocating "trusted computing" or similar initiatives here;
Who's Noone?
Re:I trust the patch, the source is included (Score:2, Informative)
The patch came as an EXE (InnoSetup), and to get at the source you need to install it... At which point an executable has already been run, *and* a DLL has been dropped to %systemroot%\system32 and schedule to load for any subsequent apps that load user32.dll (according to the description anyway).
I've managed to read the source after installing it... but if it was bad, I'd've already been hosed by that point.
Just plain ignorant post (Score:1, Informative)
Reference: http://www.checkpoint.com/defense/advisories/publ
Re:Trust not the issue... (Score:3, Informative)
Because the flaw isn't in the image previewer used by the shell, it's in GDI32 which is a core OS component and can't be unregistered. Unregestering the image previewer will prevent a lot of attack vectors, sure, but there are probably others.
Re:Over/Under (Score:3, Informative)
This could have been a 0-day fix, quite honestly.
No it's much worse. (Score:3, Informative)
Re:Programmers? (Score:4, Informative)
In the internet age, it's hard to believe, but in fact, yes, there is [f-secure.com]. This isn't a buffer overflow exploit; this is actually the way metafiles were intended to work. AC makes the same point a bit more rudely.
Re:Pushing the patch via Zenworks/SMS/Tivoli??? (Score:5, Informative)
wmffix_hexblog13.exe
These switches do not suppress dialog boxes about installation errors.
The
[from http://www.hexblog.com/2005/12/wmf_vuln.html [hexblog.com] ]
There's a MSI version in the works as well.
Re:WTF... Cannot parse (Score:2, Informative)
fixed.
Re:SPI Aren't meant for this type of filtering... (Score:1, Informative)
So much for that.
Trustworthy Computing != Trusted Computing (Score:5, Informative)
"Trustworthy computing" is Microsoft's bullshit name for their so-called initiative to start taking security seriously. It was under this banner that Bill sent all his coders to secure coding seminars so they could learn what a buffer overflow is. The article is ironic in its title: that Microsoft have failed to find such a glaring issue as a native image format that purposely allows images to execute arbitrary code, and that they have not offered a patch even now when exploits are in the wild since almost a week, shows how trustworthy they really are.
"Trusted computing", on the other hand, is the bullshit name for a nefarious scheme involving hardware and software whereby control over PCs should be taken out of the hands of their owners, and given to the software and hardware vendors. This is sometimes claimed to be about security, but is actually motivated by DRM and DRM only (the name is short for "Trusted Client Computing" and comes from the ability of DRM vendors to trust that your computer, the client, will obey their directions).
The people pushing "trusted computing" are actually not so much Microsoft as Intel and IBM: Microsoft completely support the concept of trying to put the freely programmable computer back in the bottle, but they have had their own ideas about implementation (their version was first called "Palladium", but when they realized that it is bad to have a recognizable name for something customers actually don't want it was renamed "Next Generation Secure Computing Base" and after that it was renamed to nothing at all so they can be snuck into the coming versions of Windows without people noticing.)
can't remove the callback feature (Score:5, Informative)
Guess what else uses this.
There are in-memory and on-disk WMF files. Some are used by apps for repainting the screen. Some are used by apps for printing; Windows printing is based on the WMF. You want error handling with printing, right?
Now, I'm not saying how to fix this unless Microsoft shares some cold hard cash with me, but there are reasonable solutions. It's just not as simple as patching out the feature.
Its not a DLL -its Windows, and its a feature (Score:5, Informative)
Windows Metafiles are a file representation of drawing commands. They are more flexible than bitmaps and get used quite a lot in things like for caching images of every OLE object embedded inside a MS word or powerpoint document. There just happens to be one operation to set a callback when a printing aborts which can be saved to a WMF file, which, when followed by something to abort the rendering, lets you jump to the nominated location.
This back door is built into windows from version 3.0 onwards. Any app that displays WMF images from untrusted sources (lotus notes, maybe msword, even google desktop search) is vulnerable. This is potentially code red for the desktop.
I have the patch on all my systems, the author works for IDA, the debugger tool, and is well respected. I dont care whether IT central will push it out or not; I think they ought to before the back to work/school event causes major worm attacks using it. It will be pretty embarrassing for microsoft though -a third-party emergency fix for windows, in the same year that Vista, "Windows Secured" is due to ship.
I Compiled it myself (Score:3, Informative)
The code is only 200 lines, and is primarily patching logic with a switch in there. The biggest risk is that it patches the wrong place and doesnt provide protection, the next that it doesnt uninstall. Those are hard to test.
Deploying to many machines is hard (Score:5, Informative)
But I won't say that.
First of all deploying any software on a large network is a serious task. It should be carefully planned and performed with the correct (read: responsible) approach.
The hotfix must be tested on as many machines as possible. Possible negative consequences must be determined and decided upon if they are acceptable or not.
In short, more rigorous testing is required.
-------
Ilfak Guilfanov, the author of the hotfix
Re:there is always choice (Score:4, Informative)
Re:Over/Under (Score:3, Informative)
This is yet another example of how you can't retrofit security; the first Windows versions were designed when security wasn't even an issue, when the Internet was barely a twinkle in Al Gore's eye.
Uh, no. The internet was already alive and well and quite mainstream in academe in the early 80s, when Microsoft still thrashing around with early versions of MS-DOS, and networked PCs were well-known by the late 80s. Even before that almost every PC came with a modem.
So, no, sorry, Microsoft does not get a pass for allegedly having developed windows in some misty time of yore when "security wasn't even an issue". Security was an issue on MS-DOS, for modem-using consumers, academic networks of shared PCs, and especially for corporate deployments.
Re:Some won't (Score:2, Informative)
It can be downloaded from http://msdn.microsoft.com/vstudio/express/default
Re:Some won't (Score:1, Informative)
Re:Some won't (Score:3, Informative)
As for me, I test all patches - the ones from MS too - before deployment. I don't blame Microsoft, I take responsibility for what I do.
Re:Over/Under (Score:5, Informative)
As to your contention that microsoft gets a pass because nobody thought of security back "then", I'll take "then" to be the 10 years immediately prior to the release of Windows 3.0. Multi-user PCs were a well-known concept to every student who's done work in the general-population 'computer lab'. Remember Banyan, Appletalk, Netware (you mentioned it)? They may not have been Microsoft products, but they were ubiquitous. Unix workstations (Apollo, Sun, Microvax, etc.) were in very common use among engineers and product designers, and they all were networked. (of course, most unixes and VMS versions were very hackable, but that was part of the fun)
What's more, there were thousands of anti-mal-ware software products for MS-DOS, some samples here. [llnl.gov] The virus vector was BBS downloads and floppy disks rather than open port attacks or browser overruns, but the concept of attacking PCs was already well known. So, no, Microsoft does not "get a pass" for a security problem that nobody could have predicted (sarcasm). They made conscious choices to de-emphasize and ignore security in order to maintain market share at all costs. The economics proved them correct, so far, but they still should carry the blame for those choices.
Re:Over/Under (Score:2, Informative)
It was designed to be easily uninstall-able (listed in Add/Remove Programs, not leave cruft behind, etc). Furthermore, the authors of the patch recommend that you uninstall their patch before installing the official fix (assuming Microsoft ever gets it out the door).
Re:Its not a DLL -its Windows, and its a feature (Score:4, Informative)
After banging around the SANS site for a good 15 minutes, I *finally* found WHERE YOU CAN DOWNLOAD THE PATCH from:
http://isc.sans.org/diary.php?storyid=999 [sans.org]
http://isc.sans.org/diary.php?storyid=1004 [sans.org]