Slashdot Mirror

That's right.

What many linux affectionados do not realize is there are many much more advanced power user control systems then sudo. My favorite example is RBAC which has, unlike sudo, some corporate/security professional appeal. See there. It is mostly used on Solaris where the integration level is impressive. For example we can make a requirement that some operations can be only performed by two admins (a "two men rule" ).

Sure, sudo can also can be taken to a much higher level when properly configured, but still ;-)

At this point, browsers warn people, operating systems warn people, firewalls warn people and virus scanners worm people, and they still just have to run that trojan software for whatever pointless whizz-bang effect it adds to their mouse cursor or emails.

Was "virus scanners worm people" a reference to the recent McAfee problem or just a typo? :)

Er, anyway, my actual point was that people are now so used to be warned about installing just about everything that they just click "yes" without thinking. When you go to Windows Update or Microsoft Update for the first time, Microsoft has a nice little picture explaining how to say "yes" to the warning dialogs that come up when it tries to install the update ActiveX control.

People are just so used to be annoyed by their computer that they mindlessly click through all the warnings anyway. The warnings don't really help, people don't bother understanding what they mean, and websites frequently include instructions on how to bypass them without explaining what the warning means. (I'll fix that someday. No, really...)

The only real solution is user education. Failing that, the clue-stick (also known as a "clue-by-four") is a fun, but ultimately useless, alternative.

What's the stop the person running the open access point from logging all your activity? Even with SSL, there's possibile MITM attacks that can be done. Are you really willing to trust a random individual with your privacy. I know that ISPs are capable of the same, but at least you have a contract with them.

SANS Internet Storm Center says it's fixed. Seems pretty silly.

SANS says it's an automatic download in Safari though it should still need the administrator password. I can't get the Mac away from my wife long enough to run the demo with an inert payload,

I see Apple's mistake as being to offer the "Open Safe Files After Download" feature. Do that, and you commit yourself to identifying safe files. It's not enough to have a robust algorithm. It's not enough to be foolproof. Not on a huge network full of clever and hostile people.

Are you sure phishing is so easy to recognize?

http://isc.sans.org/diary.php?date=2006-02-13

While you can assume everything is a phishing attempt, that will be about as useful as assuming all email is spam. You won't suffer from the bad emails, but you might as well not have a computer.

Sorting out phishing attacks is getting much harder. See for example.

I'm sure someone has already posted this before, but this is a pretty good scenario of techniques used today:

http://isc.sans.org/diary.php?storyid=1118

Snippets of your credit card info (the first part of the card number is usually the same for a issuer's customer base)
Non-obfuscated links (not a link to a .ru domain)
Valid SSL certificate
Valid links to other credentialing organizations

Most of us are aware of the typical phishing attempt. Message from your bank, paypal, ebay, etc asking you to log in to "verify" your info. Old hat.

How about this: You get an email newsletter from Newegg or Amazon. Look, a brand new HP Laserjet printer for only $3.99. Whoa, those guys screwed up! You click the link, and sure enough, the price is valid, though they undervalued the printer by a factor of 100. You're lucky, there's only three left in stock (but don't worry, there's more on the way!) You log into your account; heart pounding, racing to get your order submitted and shipped before the price is corrected.

Congratulations, you've just been hit by a targeted phishing scheme.

... http://isc.sans.org/diary.php?storyid=1113

> There's plenty of similarly named legit businesses that all have certs issued to them.

The issue here is that the "business" was not legit, and GeoTrust did not detect that before issuing the cert. They (officially) require you to provide copies of business licenses, articles of incorporation, etc. They are supposed to check with the Secretary of State's Office in the state of incorporation, a requirement that the business be in good standing, etc. But they didn't do either in this particular case.

More details here: http://isc.sans.org/

"A commercial CA will protect you against anyone from whom they won't take money." -- Matt Blaze

SSL certs are great for end-to-end encryption. They are not good for authentication, because people don't usually check on the certificate - however, here even a check wouldn't have done any good. I only buy SSL certs because people don't like the extra confirmation dialogue that comes with self-signed ones.

See also this ISC piece.

Tom Liston, a handler at SANS ISC well known for his various takes on Malware problems has a good take on this entitled Phollow the Phlopping Phish on the ISC Handler diary. Covers what it looks like to a user, and why it all falls down.

Tom Liston, a handler at SANS ISC well known for his various takes on Malware problems has a good take on this entitled Phollow the Phlopping Phish on the ISC Handler diary. Covers what it looks like to a user, and why it all falls down.

Tom Liston, a handler at SANS ISC well known for his various takes on Malware problems has a good take on this entitled Phollow the Phlopping Phish on the ISC Handler diary. Covers what it looks like to a user, and why it all falls down.

Tom Liston, a handler at SANS ISC well known for his various takes on Malware problems has a good take on this entitled Phollow the Phlopping Phish on the ISC Handler diary. Covers what it looks like to a user, and why it all falls down.

Tom Liston, a handler at SANS ISC well known for his various takes on Malware problems has a good take on this entitled Phollow the Phlopping Phish on the ISC Handler diary. Covers what it looks like to a user, and why it all falls down.

Tom Liston, a handler at SANS ISC well known for his various takes on Malware problems has a good take on this entitled Phollow the Phlopping Phish on the ISC Handler diary. Covers what it looks like to a user, and why it all falls down.

Tom Liston, a handler at SANS ISC well known for his various takes on Malware problems has a good take on this entitled Phollow the Phlopping Phish on the ISC Handler diary. Covers what it looks like to a user, and why it all falls down.

The perception that PHP is insecure is based on the fact that it was in the past incredibly insecure, not just because of bad programmers, but by design as a language/deployment environment. Perhaps it was too long ago for you top recall, but it used to be that register_globals was on by default. register_globals was inherently insecure, and including it in the language at all was a huge security compromise, and pathetically enough since there are still PHP packages out there that depend on it, it has not been removed from PHP.

Also letting include() take a URL is batshit crazy. While handy (like most security compromises), it means that if anyone can figure out a way to sneak a string in to that include call, then they can import any malicious code they want. register_globals was often a handy way to do that in the past...

There are a few other things that I think are a sign of poor security design, but most would likely just cause language wars, so I will leave it to those above to illustrate that PHP, especially in its earlier incarnations had a poor design with respect to security.

PHP itself has had its fair share of security vulns, for instance:

http://www.hardened-php.net/advisory_202005.79.htm l
http://www.hardened-php.net/advisory_152005.67.htm l
http://www.hardened-php.net/advisory_142005.66.htm l
http://www.sans.org/newsletters/risk/display.php?v =3&i=50#widely4
http://www.sans.org/newsletters/risk/display.php?v =3&i=23#other1
http://www.sans.org/newsletters/risk/display.php?v =3&i=28#widely4
http://www.sans.org/newsletters/risk/display.php?v =3&i=48#exploit1

There are more, but I am too lazy to find a more complete list, and that is enough to illustrate the point.

So while it's true that there are a lot of bad security habits that many PHP programmers have used, PHP's bad reputation is something they have earned all by themselves.

The perception that PHP is insecure is based on the fact that it was in the past incredibly insecure, not just because of bad programmers, but by design as a language/deployment environment. Perhaps it was too long ago for you top recall, but it used to be that register_globals was on by default. register_globals was inherently insecure, and including it in the language at all was a huge security compromise, and pathetically enough since there are still PHP packages out there that depend on it, it has not been removed from PHP.

Also letting include() take a URL is batshit crazy. While handy (like most security compromises), it means that if anyone can figure out a way to sneak a string in to that include call, then they can import any malicious code they want. register_globals was often a handy way to do that in the past...

There are a few other things that I think are a sign of poor security design, but most would likely just cause language wars, so I will leave it to those above to illustrate that PHP, especially in its earlier incarnations had a poor design with respect to security.

PHP itself has had its fair share of security vulns, for instance:

http://www.hardened-php.net/advisory_202005.79.htm l
http://www.hardened-php.net/advisory_152005.67.htm l
http://www.hardened-php.net/advisory_142005.66.htm l
http://www.sans.org/newsletters/risk/display.php?v =3&i=50#widely4
http://www.sans.org/newsletters/risk/display.php?v =3&i=23#other1
http://www.sans.org/newsletters/risk/display.php?v =3&i=28#widely4
http://www.sans.org/newsletters/risk/display.php?v =3&i=48#exploit1

There are more, but I am too lazy to find a more complete list, and that is enough to illustrate the point.

So while it's true that there are a lot of bad security habits that many PHP programmers have used, PHP's bad reputation is something they have earned all by themselves.

The perception that PHP is insecure is based on the fact that it was in the past incredibly insecure, not just because of bad programmers, but by design as a language/deployment environment. Perhaps it was too long ago for you top recall, but it used to be that register_globals was on by default. register_globals was inherently insecure, and including it in the language at all was a huge security compromise, and pathetically enough since there are still PHP packages out there that depend on it, it has not been removed from PHP.

Also letting include() take a URL is batshit crazy. While handy (like most security compromises), it means that if anyone can figure out a way to sneak a string in to that include call, then they can import any malicious code they want. register_globals was often a handy way to do that in the past...

There are a few other things that I think are a sign of poor security design, but most would likely just cause language wars, so I will leave it to those above to illustrate that PHP, especially in its earlier incarnations had a poor design with respect to security.

PHP itself has had its fair share of security vulns, for instance:

http://www.hardened-php.net/advisory_202005.79.htm l
http://www.hardened-php.net/advisory_152005.67.htm l
http://www.hardened-php.net/advisory_142005.66.htm l
http://www.sans.org/newsletters/risk/display.php?v =3&i=50#widely4
http://www.sans.org/newsletters/risk/display.php?v =3&i=23#other1
http://www.sans.org/newsletters/risk/display.php?v =3&i=28#widely4
http://www.sans.org/newsletters/risk/display.php?v =3&i=48#exploit1

There are more, but I am too lazy to find a more complete list, and that is enough to illustrate the point.

So while it's true that there are a lot of bad security habits that many PHP programmers have used, PHP's bad reputation is something they have earned all by themselves.

The perception that PHP is insecure is based on the fact that it was in the past incredibly insecure, not just because of bad programmers, but by design as a language/deployment environment. Perhaps it was too long ago for you top recall, but it used to be that register_globals was on by default. register_globals was inherently insecure, and including it in the language at all was a huge security compromise, and pathetically enough since there are still PHP packages out there that depend on it, it has not been removed from PHP.

Also letting include() take a URL is batshit crazy. While handy (like most security compromises), it means that if anyone can figure out a way to sneak a string in to that include call, then they can import any malicious code they want. register_globals was often a handy way to do that in the past...

There are a few other things that I think are a sign of poor security design, but most would likely just cause language wars, so I will leave it to those above to illustrate that PHP, especially in its earlier incarnations had a poor design with respect to security.

PHP itself has had its fair share of security vulns, for instance:

http://www.hardened-php.net/advisory_202005.79.htm l
http://www.hardened-php.net/advisory_152005.67.htm l
http://www.hardened-php.net/advisory_142005.66.htm l
http://www.sans.org/newsletters/risk/display.php?v =3&i=50#widely4
http://www.sans.org/newsletters/risk/display.php?v =3&i=23#other1
http://www.sans.org/newsletters/risk/display.php?v =3&i=28#widely4
http://www.sans.org/newsletters/risk/display.php?v =3&i=48#exploit1

There are more, but I am too lazy to find a more complete list, and that is enough to illustrate the point.

So while it's true that there are a lot of bad security habits that many PHP programmers have used, PHP's bad reputation is something they have earned all by themselves.

The Internet Storm Center did a write-up on this case inclusing a hypothetical tale of Joe Sixpack trying to verify the phish, doing (almost) everything right -- typing in the address instead of clicking on the link, checking for an SSL certificate, checking who the cert is registered to, etc, and still getting caught.

The fatal flaw in the hypothetical course of action is trusting the non-standard domain name...but you can hardly blame Joe Sixpack for that one when so many financial institutions actually use one-off domains or partner sites. I was working on some phishing rules last year and counted something like 5 domains that Citibank used alone.

A better link, with more screenshots:

Phollow the Phlopping Phish

Ok, in some parts of the world it is already Feb 3rd and some damage is already probably done.
If you know any story related to this event, please share with us .

Samir Datt wrote to tell us about "unconfirmed reports" of damage in Bangalore, Ludhiana and Delhi. (email arrived 1am EST, 6am GMT).

For references, these are the enumeration names and where to go to make sure you have the latest anti-virus signature. Remember, this variant will uninstall and delete most anti-virus software so it's important to recognize it before it goes active tomorrow. Most virus definition software refers to it as CME-24. This is important since this worm has many different names including Nyxem.E, BlackWorm, Grew and Mywife.E.

More on the worm and its permutations and statistics on spreading.

A very detailed analysis with all types of files that may be affected.

And, if it's worth anything to you, the Microsoft advisory which seems to tout that Windows Live Safety Center Beta can protect against it. If you're in charge of computer security at your workplace, I would send out an e-mail instructing everyone to verify that they have the correct anti-virus definitions and to scan their computers before leaving tonight. Luckily, that's not my job where I work.

many people seem to think that the patch/virus definition should be made available prior to its announced release date. with so many anti-virus sites already indicating that they have had an update since Jan 18th(!) and additional updates from MS, then where's the problem? to release this type of update earlier may require resources, increasing cost, thereby lessening the chance that MS would want to focus on these patches prior to systems being compromised(not they're on top of the ball, but at least they are in the ring). i would say it would be bad if MS was the only one who knew how to prevent the worm and caused some sort of failure which could then be indicated as negligence,but this isn't the case... however... some sites are reporting that the worm will attempt to remove/prevent anti-virus software and will try to do so every hour, in that case, good luck! http://isc.sans.org/diary.php?storyid=1067

This virus is very likely a POC and an advance guard to hold doors open for future infection or botnets.
As stated by others already, LURHQ has distribution stats. http://www.lurhq.com/blackworm.html US infections only number about 5% of total. Peru and India have most of the worldwide population of this. (this is ip-based, and may not be reliable.)
I haven't seen another mention, but SANS Storm Center has been following this - and actually has made an offer to sysadmins to share info. They limit the info they will give; if you can reasonably establish that you are the RP for a network or subnet - they will send you a list of known infections in your IP range. They have already sent out notice messages to admins of record (whomever the abuse or tech contact is currently on the whois lookup) using a script. [Check the ISC pages if you really want to know - I don't want to flood them by posting a direct email link here.]
Referred to in the SANS/ISC history on this http://isc.sans.org/blackworm and previous pages - Fortinet has done extensive analysis. This virus has several actions. Most folks already know it deletes files, breaks AV software, and spreads over Windows shares. What hasn't seen much daylight is that it drops a bunch registry entries that grant "trusted" status to the virus. http://www.fortinet.com/VirusEncyclopedia/search/e ncyclopediaSearch.do?method=viewVirusDetailsInfoDi rectly&fid=119856 I'm not an expert on this mechanism - but I'd assume that any machine with these "bad" trusts in place could easily be compromised later using code that is authenticated against these bad keys.
I read M$' page on this virus, http://www.microsoft.com/security/encyclopedia/det ails.aspx?name=Win32%2FMywife.E%40mm as well as a few AV pages. None mention these keys, so I would assume they don't fix this problem.
Any system that has been infected and then cleaned will probably retain these falsified certificates. This leaves a big hole in place, while some users (even the " all your AV is updated hourly folks.. return to your seats" IT guy) - will have a false sense of security on this.
Thankfully, many AV programs discovered this virus Heuristically. (see links to LURHQ & others) McAfee, Panda, NOD32, and several others identified blocked this virus without needing a signature update. This may be why we don't have 2 million AOL/Comcast sheep spreading the virus.
This should serve as a strong reminder to backup religiously, use defense-in-depth, and enforce strong registry policies when Windows systems are implemented.

Are you sure? ISC has been sending out notifications about "Blackworm" (Nyxem) infected PCs for a few days, so the list is definitely available to to the security community. It would be fairly logical that Spamhaus' XBL list and other similar DNSBLs of compromised PCs would be able to acquire a copy of list as well, although they might be better with a sanitised version with hosts known to have been cleansed as a result of the ISC mailings being removed.

Was it patched and up to date and left with the default of firewall on? What did the attacker use to gain access or turn it into a bot? If it was not patched then your results are useless.
I am no MS fanboi but my company does support about 500 XP laptop users. Other then the rampant spyware they get on or off our internal firewalled network from browsing the internet, I don't think I've ever seen one owned as a direct result of just being plugged in outside our network. I've read about quite a few honeypots and I know flaws exist but these are almost always pre SP2. Heck, SANS has there own advisory for XP called Surviving the first day (direct pdf link), but it too is pre XP2. I personally would never put any computer directly up against the internet without some type of firewall, XP SP2 included.
Again, I am not saying it does not happen but your dicounting one persons claim with your one claim seems a little odd as well.

SANS keeps a measurement of the 'survival time' of various platforms: http://isc.sans.org/survivalhistory.php

The average life expectancy of the Windows platform is currently 88 minutes. Keep in mind that this estimate is really a count of port attacks by worms, not active systems compromised. W32.Welchia's port scan (DCOM vuln; TCP 135) would have little effect on a XP Service Pack 2 machine.

Unless the individual keeps a 24/7 dialup connection, it is unlikely that the user will be up to date against current threats. You can try to download updates before you get infected, but often times people don't get that lucky. Worm/virus port scans are seemingly random, so it's really a tossup as to whether a dialup or broadband connection would be infected first. Broadband access allows Windows to more easily patch itself, and a common router with NAT could shield you from most worm attacks. On the other hand, once you free yourself from the confines of dialup, one's surfing begins to stray elsewhere. Rest assured, that warez/pr0n site is up to date with the latest IE/Java scripting vulnurability. :)

the Internet Security Center at sans.org had an interesting article about getting ready for defcon.. (in order to protect your privacy) While it does not go into very detailed how-to's, it does give a hell of a parnoid BOFH type mindset for defcon. There are some basic guidlines for secure connections using tunneling over SSL in that discussion..

Well this is a timely article for me... This weekend I remembered the listing of Mac OSX in http://www.sans.org/top20/SANS Top 20 Vulnerabilities and as I newbie to Mac OSX I decided to check it out. After being extremely dissappointed that all they did was say "it has vulnerabilites" (all of which I was already patched against...) and that I should "run software update" (which is set by default to run weekly, I had already changed it to check daily...), I decided to run through the CIS Benchmark on securing OSX. 50 pages and several hours later, I came to the conclusion that its based on an older version of OSX and almost everything they mentioned fell into one of three categories:
1/ Default behaviour already.
2/ Instructions out of date so I couldn't verify it needed changing (eg change an xml file that is now a binary file)
3/ Unneccessary for a home user (eg warning banner on login)

But at least now that I've spent more time that 99.99% of windows users ensuring my machine is secure, I can tell everybody that comes up with the "Mac isn't that secure" debate to go jump.

Sophos is one commercial vendor who distributes an anti-virus client package for the Mac. They also offer their server component for Mac, providing update and remote install/upgrade services. Sophos For OS X. While there are only a few viruses/worms/trojans in the wild at this time that can infect OS X, anti-virus software, for instance on a Mac based file server, can help protect machines running other operating systems.

In this geeks opinion, any OS that defaults the primary user on the system with super user access is going to be at least somewhat more prone to attack. Nasty critters enter systems quite often via way of email attachments, and the common users attraction to shiny things. No scripted-auto-execute-attachment-on-view hack to poorly written email clients is needed, nor is any privilege escalation exploit. The human behind the keyboard will perform that task for us. This is something that is very reasonably taken advantage of with OS X (as with Windows). In a business environment one would hope this has been addressed properly.

As for other remote exploits, SANS top 10 list for Mac OS X.

Mac OS X is far from un-exploitable. It's just not the biggest target on the battlefield... but getting bigger every day

I'm a daily Linux user. I also have a G4 under my desk running OS X, and have quite a bit of respect for the work Apple has done with Darwin (not so much with Aqua).

Mac OS X also includes the Safari web browser. Multiple vulnerabilities have been found in this browser and in certain cases exploit code has also been posted publicly.

Apple frequently issues Mac OS X cumulative security updates that tend to include fixes for a large number of vulnerabilities with risk ratings ranging from critical to low. This complicates the tracking of vulnerabilities for this OS, and the best way to ensure security is to apply the latest cumulative patch

From SANs top20.

"It's good to see that this vulnerability is getting some exposure, but this article's synopsis is misleading. It is well known that the WMF vulnerability stems from an intentional feature in the design of WMF that allows code to be embedded into WMF images; this code is executed when the image is viewed. The original purpose of this was mainly to handle the cancellation of print jobs during spooling. This is a feature that has extreme security implications in the context of the Internet, but is from another time (Windows 95), when MS had very little interest in networking beyond trusted internal corporate environments. Over the years this code has lived on in Windows without being reviewed in the current context of Internet connectivity. Never ascribe to malice that which can be explained by incompetence. See http://en.wikipedia.org/wiki/2005_WMF_vulnerabilit y for a lot more detail.

I don't mean to make an ad hominem attack (this podcast is actually fairly accurate), but Steve isn't exactly known for being a respected researcher in the security industry - he's a bit of a poser. He frequently hypes issues to crazy levels and tries to make himself look like a hero/expert. In fact, he usually offers little insight and often tries to pass off regurgitation (often inaccurate) as original research. Just listen to him in this recording talking about "rolling up his sleeves" and "wrote all my own code", etc - trying to sound like he substantially contributed to the security industry. Look up his stuff on nano-probes (http://grc.com/np/np.htm) for some really ridiculous stuff. I am a security professional and can tell you that it's mostly BS and/or hyped/obfuscated wording for technologies and techniques that have been in common usage for years and years before he wrote this crap.

Much better resources and much more insightful experts are accessible. Try http://www.schneier.com/blog/ and http://isc.sans.org/diary.php for FAR more interesting information. No one I know or work with pays any attention to Steve Gibson, except as a source of humor. :)"

"If the impact is huge, testing of more obscure cases can be deferred somewhat. If the impact is small, more time can be taken."

I'm with you so far....

"So if there hadn't been any customer sentiment (i.e. no one cared), it would make no sense to rush the patch and risk breaking something."

Err, that's a non-sequitur. Whether customers care or not has nothing to do with the cost/benefit analysis that decides the timing and scope of an initial patch. A software company should never rely on its customers to perform risk analysis. If it's serious (and the WMF flaw is egregiously so), then you find a way to protect your customers as quickly and effectively as you can. In some cases - though certainly not all - you can even accept shortcomings in the patch itself if significantly reduces the risk.

The third-party patch, for example, causes issues with the Windows printing subsystem. People voiced suspicions that this might be the case right from the start, though confirmation only came through earlier today. To my mind, that was an acceptable risk. A server that can't perform some print tasks and won't show pretty preview icons is worth a heck of a lot more to me than one that's 0wned by some random script kiddy.

And before some astroturfing twit spouts the simplistic, binary logic of 'MS is damned if they do and damned if they don't', I'd like to say from experience that deciding the timing of a security patch is a terribly difficult process. It requires the right amount of analytical skill, deep technical expertise, a healthy dose of horse sense and exactly the right measure of patience. Too much or too little of any of these can result in exactly the wrong kind of response.

Patching is not about being a nice guy. It's not about what your customers think of you. There should be no marketing or sales angle in the creation or timing of a security patch. You determine the scope and severity of the threat, be as thorough as you can reasonably hope to be (and that's never as thorough as you'd like), and deliver it as soon as you reasonably can.

I'm in complete agreement with this handler's diary from isc.sans.org concerning Microsoft's announcement that they would issue the patch at the regularly scheduled time. Given the severity of the flaw, it's unconscionable that they should leave their customers exposed for so long. The fact that they only decided to release the patch out of cycle in response to their users demonstrates that they're far more worried about their image than they are about their software. This does not bode well at all for them. Or for their customers, for that matter.

"If the impact is huge, testing of more obscure cases can be deferred somewhat. If the impact is small, more time can be taken."

I'm with you so far....

"So if there hadn't been any customer sentiment (i.e. no one cared), it would make no sense to rush the patch and risk breaking something."

Err, that's a non-sequitur. Whether customers care or not has nothing to do with the cost/benefit analysis that decides the timing and scope of an initial patch. A software company should never rely on its customers to perform risk analysis. If it's serious (and the WMF flaw is egregiously so), then you find a way to protect your customers as quickly and effectively as you can. In some cases - though certainly not all - you can even accept shortcomings in the patch itself if significantly reduces the risk.

The third-party patch, for example, causes issues with the Windows printing subsystem. People voiced suspicions that this might be the case right from the start, though confirmation only came through earlier today. To my mind, that was an acceptable risk. A server that can't perform some print tasks and won't show pretty preview icons is worth a heck of a lot more to me than one that's 0wned by some random script kiddy.

And before some astroturfing twit spouts the simplistic, binary logic of 'MS is damned if they do and damned if they don't', I'd like to say from experience that deciding the timing of a security patch is a terribly difficult process. It requires the right amount of analytical skill, deep technical expertise, a healthy dose of horse sense and exactly the right measure of patience. Too much or too little of any of these can result in exactly the wrong kind of response.

Patching is not about being a nice guy. It's not about what your customers think of you. There should be no marketing or sales angle in the creation or timing of a security patch. You determine the scope and severity of the threat, be as thorough as you can reasonably hope to be (and that's never as thorough as you'd like), and deliver it as soon as you reasonably can.

I'm in complete agreement with this handler's diary from isc.sans.org concerning Microsoft's announcement that they would issue the patch at the regularly scheduled time. Given the severity of the flaw, it's unconscionable that they should leave their customers exposed for so long. The fact that they only decided to release the patch out of cycle in response to their users demonstrates that they're far more worried about their image than they are about their software. This does not bode well at all for them. Or for their customers, for that matter.

The ISC has clear instructions on how to remove the unofficial patch, although it apparently co-exists ok with Microsoft's patch.

I check isc.sans.org daily and I can't remember the last time I saw a Linux/UNIX vulnerability mentioned (of course they occasionally pop up). On the other hand there are *serious* problems with Windows daily. They've been on Yellow alert for days because of a current VERY serious Windows vulnerability that Microsoft says they'll have a patch for next week:

http://isc.sans.org/

Hello, McFly, is there anybody in there?

Void Main

The unofficial "patch" that was released by Ilfak Guilfanov via Sans is not a fix for the problem but a temporary work-around until an official replacement for the shimgvw.dll and, one would desperately hope, the gdi32.dll is released.

Microsoft has already stated that the fix has been completed but that they are testing it. Server patches cannot be distributed willy-nilly and, as difficult as it is to sit around and wait, hoping that nothing incredibly malicious happens, there has to be a certain sense of patient understanding while Microsoft does not give in to the pressure of rushing another code update (and another potential opportunity for exploitation) out the door. Both Microsoft and the Linux community have been bitten in the ass before taking that approach.

For those who are curious about what the unofficial patch does, as well as the exploit in general, here is the link to the Sans FAQ on the WMF vulnerability: http://isc.sans.org/diary.php?storyid=994.

For those too lazy to RTFA:

* How does the unofficial patch work?

The wmfhotfix.dll is injected into any process loading user32.dll. The DLL then patches (in memory) gdi32.dll's Escape() function so that it ignores any call using the SETABORTPROC (ie. 0x09) parameter. This should allow Windows programs to display WMF files normally while still blocking the exploit.

The SETABORTPROC function in the gdi32.dll has been a long-standing point of vulnerability. It was originally intended to be a hook for executable code, invoked when a print operation fails. By introducing a simple buffer overrun, malicious code can be inserted and called from this point.

Some people might want to consider the unofficial patch - personally, I wouldn't let it anywhere near the network of 3000+ machines. If something goes wrong, that a lot of cleaning up to do, and Microsoft will not be interested in helping.

I rolled the MSI-based version of this patch to around 1,500 client PC's this morning. The MSI cleanly uninstalls and has been tested on the US versions of W2K Server SP4, W2K Pro SP4, WXP Pro Gold, WXP Pro SP1, WXP Pro SP2, W2K3 Gold, and W2K3 SP1.

Of course, I'm a bit biased, as I'm the guy that spent most of the weekend writing the Custom Action code for the MSI file that SANS is distributing now. Full source for the MSI is available here.

http://isc.sans.org/diary.php?storyid=1010

Not so important that they intend to release a patch for Win95/98, I hear.

"Note: If you're still running on Win98/ME, this is a watershed moment: we believe (untested) that your system is vulnerable and there will be no patch from MS. Your mitigation options are very limited. You really need to upgrade." http://isc.sans.org/

So finally, Win98 will be hung out to dry - obsolete and dangerous. A pity, since I'd been given to believe that Win98 + appropriate firewalls etc was a reasonable solution until now. Does anyone know if the unofficial patch covers Win 98, even if MS won't?

Also worthy of note is the ISC's latest comments on all this:

And, somehow, as if by magic, all of this work will wind down at precisely the right moment so that the WMF patch doesn't have to be released "out of cycle." How convenient! Especially if you're wanting to avoid all of that nasty "Microsoft Releases Emergency Patch" publicity.

Also worthy of note is the ISC's latest comments on all this:

And, somehow, as if by magic, all of this work will wind down at precisely the right moment so that the WMF patch doesn't have to be released "out of cycle." How convenient! Especially if you're wanting to avoid all of that nasty "Microsoft Releases Emergency Patch" publicity.

If you want the patch itself, try here:
http://isc.sans.org/diary.php?storyid=1010

Second time this story came up with no links to the patch.

How do you intend to block them? Block anything with extension .wmf? Isn't enough as the file will be identified and handled as wmf, no matter what the extension is.

From http://isc.sans.org/diary.php?storyid=994/ you can find that "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."

yeah, works with websites. but not with email, or files that are already stored on your system. even indexing a malicious file on your pc via google desktop or similar programs infect you. for more info see the FAQ at http://isc.sans.org/

Is it just me, or is the Slashdot "unofficial patch" link at the top absolutely useless?

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
http://isc.sans.org/diary.php?storyid=1004