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.

(more…)

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).

(more…)

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…)

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.

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.

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.

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.

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.

We’ve been hearing a lot about software distributors downplaying vulnerabilities in their code. It seems like a familiar tune. Gadi’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.

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 1.5.0.1 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.

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.

• Timeliness

  All 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.

• Approach

  Microsoft’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.

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.

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:

\\127.0.0.1\C$\WINDOWS

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.