Cheap Hack

How Quickly Should Microsoft Rush Out Critical Updates?

Fri, 26 Dec 2008 15:07:39 +0000

When Microsoft release a patch recently for a major zero-day IE bug it was noteworthy for how quickly they turned it around. 8 days is really fast for Microsoft, probably a record, but would 7 days have been better? That's not as easy a question as it may seem. I'm sure that within a day or two Microsoft knew what code was being exploited and had a prototype patch out. A number of things can go wrong if you hurry up at this stage. First, and this is the main reason it takes Microsoft so long to come out with some patches, is the vast number of configurations that must be tested. Consider this particular bug: every supported version of Windows, every supported version of Internet Explorer on them, every language. Then a whole lot of IE application code undoubtedly needed to be tested. I've done some test automation programming and I'm sure Microsoft has put extensive resources into scaling up their test automation exactly for this situation: Needing to test a large number of configurations as quickly as possible and to capture and analyze results from them. It's task that can be highly parallelized, so if you design your test harness and tests well you can throw hardware at the problem. I'm sure that's what happened here, and even so I'm sure it takes a while to test a patch thoroughly. But there's more that needs to be considered. Often when a vulnerability, and subsequently a patch, comes out on some projects it can come out quickly, but we find out soon afterwards that the patch wasn't as comprehensive as it ought to have been. A Firefox/SeaMonkey patch from earlier this year introduced a stability problem that had to be fixed in a subsequent patch. And in what they claim was just an administrative error, the last big batch of Firefox updates mistakenly omitted one patch for Firefox 2. We've all heard of Microsoft patches that introduce instability; I can't find a well-documented example off-hand, but I'm sure there are plenty. Another problem, if you hurry up and patch, is losing the forest for the trees: Are you patching a narrow issue when that issue is an aspect of a larger problem in the surrounding code? There are some programs, like the WMF code in Windows GDI, that have had multiple patches of the same basic type over the years. In the case of WMF the format may be such that the parsing code simply can't be simple, and there's no systemic solution. But it's certainly something to be careful about. And then there are times when Microsoft seems to take far too much time to address a problem, as may be the case with the new SQL vulnerability just revealed a few days ago. The bug had been revealed to them, and they acknowledged it, in April of this year, but they still haven't done anything about it. This particular bug has all the earmarks of a simple one to fix; first, the problem only exists in some versions, generally newer ones, of their SQL products, so clearly it has been addressed in some way. My sense of this one is that Microsoft was waiting for some SQL Service Pack to put it in, but it took too long. Now events have overtaken them and they may be forced to separate out a patch, if only on the next Patch Tuesday, just because of the embarrassment of this. Some companies routinely take a long time to issue updates to publicly-disclosed vulnerabilities, Apple being the biggest offender. Are they making sure the patch is thoroughly cooked, or are they just not in a hurry? I suspect the latter is more of the case, and that they figure there is no hurry because Macs are still largely not on hacker radar. Sometimes even with a dramatically important update it makes sense to wait. Consider the famous Kaminsky DNS bug updates of earlier this year, which were coordinated with all the significant DNS vendors. Almost all patched the same time (a few, like Apple, waited even longer) so that everyone would have the best chance to install the update before the attacks commenced. There are many factors that feed into the prioritization formula for security updates. Microsoft has the hardest decisions not because their software is any less secure than anyone else's, but because it's so widely depended on and so widely attacked. It was obvious that the latest IE bug would be a severe one if left unpatched for very long, but perhaps not so for the SQL bug. And nothing, no matter how critical, ever seems urgent for Macs. Windows is the big city and the Mac is a small town, but even on Windows sometimes it makes sense for them to take their time.

Microsoft Supplies Script to Apply SQL Bug Workaround

Wed, 24 Dec 2008 04:33:03 +0000

If you are thinking of implementing the workaround supplied by Microsoft for the SQL vulnerability the company announced this week and you're worrying about the time it will take, things may have just gotten easier. Microsoft released a Windows Script Host VBScript that implements the workaround on all affected SQL products on the computer on which the script runs. Specifically, it denies Execute permission to the Public role on the sp_replwritetovarbin extended stored procedure in those copies. You need sufficient permissions to run the script, specifically the sysadmin role for each instance of SQL Server. If you don't have one account that runs as sysadmin, then you may have to run the script under multiple accounts. On Vista and Windows Server 2008 you probably have to run it from an elevated command prompt. They don't recommend using it if you've implemented a patch, so if you want to gamble that a patch will be out soon, don't bother with this. How much harder would it have been for Microsoft to put a /UNDO switch on this script to reverse the workaround, as users will want to do once a patch is out? Actually it's a little more complicated than that, as it's possible some users had changed that permission for other reasons and you'd only want to reverse the effects of changes made with this script. So they'd want to store the old permissions somewhere and restore them. Whatever, it's a small lost opportunity.

Microsoft Issues Advisory on SQL Vulnerability

Tue, 23 Dec 2008 04:30:39 +0000

Microsoft has issued a security advisory for a vulnerability in certain versions of SQL Server and other SQL products. The vulnerability, complete with proof-of-concept exploit code, had been disclosed publicly by SEC Consult on Dec. 9. The disclosure says that Microsoft had been notified of it in April, had acknowledged it, but had stopped responding to SEC Consult requests for status. The vulnerability is in a stored procedure named sp_replwritetovarbin. It is possible to cause this stored procedure to invoke a heap buffer overflow in the server and write to a controlled location. You need to be an authenticated user, local or remote, to invoke it, but you can get around that requirement through SQL injection or by compromising a vulnerable Web application. We don't know of any actual exploits yet using this vulnerability. The vulnerability affects some Microsoft SQL products, but not others, and some more seriously than others. All supported versions of SQL Server 2000 appear to be vulnerable. SQL Server 2005 SP2 is vulnerable, but not SP3. SQL Server 2008 and SQL Server 7.0 SP4, the only supported version but a very old one, are not vulnerable. It's an odd combination. Perhaps the most common versions that are technically vulnerable, SQL Server Desktop Engine 2000 (MSDE 2000) and SQL Server 2005 Express, do not allow remote connections by default. This means that an attacker would have to have local access to the system in order to attack it; I think such systems aren't as likely as servers to be vulnerable to SQL injection or other hacks associated with Internet-facing servers. It's a problem on these systems, but not as serious as on others. A Microsoft Security Vulnerability Research & Defense blog entry gives some more analysis on the vulnerability, especially with regard to the implications of a compromise through this flaw. The privileges of the attacker would vary depending on the server version and how the system was configured during installation, but even in the more benign cases, it's possible to use other attacks to escalate privilege once in. The Microsoft advisory and other public Microsoft statements give the usual line about how "... Microsoft will take the appropriate action to help protect our customers" and that this may include a patch. Note that the SEC Consult advisory states that Microsoft told them in September that a fix had been completed, but they said nothing about plans for its distribution. Microsoft also issued a workaround as part of the advisory, to use permissions to deny access to sp_replwritetovarbin. Denying access to it shouldn't affect most systems. Microsoft describes the procedure this way:

It [sp_replwritetovarbin] is called as a trigger for user modifications during transactional replication with updatable subscriptions. So if your SQL installation does not include replication, the workaround will have no effect other than to protect you from this vulnerability. The workaround will also have no impact on your database installation if you use transaction replication with read-only subscriptions, bi-directional, or peer-to-peer settings. It is only transactional replication with updatable subscriptions that is impacted.

It would seem that Microsoft doesn't think too much of this vulnerability. How serious is it? That depends on how many servers, especially Internet-facing servers, are running vulnerable versions of the products. The mix of vulnerable/not-vulnerable products and mitigations baffles me, but I don't understand the company's hesitance to issue a patch, especially one that has been available for three months.

What is TrustedInstaller And Why Won't It Let Me Change My Registry Keys?

Sun, 14 Dec 2008 20:24:08 +0000

In my recent column "Microsoft Gets More Detailed About IE Vulnerability and Workarounds" one of the workarounds I describe is "Disable Row Position functionality of OLEDB32.dll". It involves deleting a specific registry key. I tried this myself on one of my systems and I wasn't able to delete the key. Even though I was logged in as Administrator I got permissions errors when attempting to delete it. I examined the key's permissions and saw that Administrator, SYSTEM and users had only Read permissions. The only user with Full Control was TrustedInstaller. Who is TrustedInstaller? I'm not completely clear on it, but it appears to be a process involved with Windows File Protection, the feature which prevents the modification or deletion of critical Windows files. Vista support forums have lots of messages from people trying to delete or modify files or to which only TrustedInstaller has permissions. The same seems to be true of registry keys. So what do you do? I found the answer in this MSDN thread. Essentially, I had to go into the Advanced Permissions dialog for the key and all subkeys, to the Owner tab and change the Owner to Administrator. Then I had to change the permissions on all these keys to allow Administrator Full Control. THEN I could delete it.

Microsoft Updates Security Advice On IE 0-Day Attack

Fri, 12 Dec 2008 08:16:18 +0000

Microsoft has revised the security advisory issued earlier this week. Initially it appeared that the vulnerability was only in Internet Explorer 7, but after further analysis it seems as if all currently-supported versions of IE are affected, including the betas of IE8. However the attacks that have been observed in the wild so far all target IE7 specifically. The advisory now adds several new proposed workarounds. The complete list:

Set Internet and Local intranet security zone settings to "High"
Disable Active Scripting or set IE to prompt for it
Enable DEP (only hardware DEP will help)
Use ACL to disable OLEDB32.DLL
Unregister OLEDB32.DLL
Disable Data Binding support in Internet Explorer 8

See the advisory itself for details on these workarounds. Secunia points out in their blog that setting your Internet and Local Zone security settings to High won't protect completely against the attack, although it will make attacks more difficult because scripting will be disabled.. The Secunia blog adds that making this change, along with the Microsoft suggestions related to OLEDB32.DLL (see Microsoft's advisory for details), should keep your system safe.

Google's Browser Security Handbook

Thu, 11 Dec 2008 05:58:07 +0000

Google has released a Browser Security Handbook, which the search company describes as "a comprehensive, 60-page document meant to provide Web application developers and information security researchers with a one-stop reference to several hundred key security properties and sometimes counterintuitive quirks in contemporary Web browsers." The document is written and maintained by Michal Zalewski, a famous researcher snapped up by Google. The introduction notes that there are important differences between browsers and lists market share data of browsers on which the document is based. Interestingly, it is Net Applications data, rather than straight Google data, which the company does not release.

The Keys to the Pentagon Are in the Parking Lot

Sun, 07 Dec 2008 13:23:23 +0000

Thanks to Gadi Evron on Twitter for pointing to what is admittedly just a rumor about how the Pentagon got hacked using USB keys. Even if it's completely false it's something you should consider. The story is that the attackers got USB keys into the Pentagon and onto DoD computers by dropping them in the parking lot. Employees picked them up and brought them in to try to see who owned them, but at that point it's already too late. Autoplay runs the attack code, system is 0wned. Maybe it's true, maybe not, but it would be a good enough reason for DoD to ban such devices altogether.

Stolen Domains For Sale

Sun, 07 Dec 2008 07:43:42 +0000

Domainer blogs are warning that a purported domain thief is offering dozens of high-value, but stolen domains for sale. The reports are long on assertion and lack hard evidence, but they certainly seem plausible. Domain theft is not as common as it was before domain locks became standard features of registrars, but it's still possible to lose your domains if a thief gains control over your registrar account or your e-mail address. Attempts to use phishing techniques to steal registrar accounts are an old problem and one can lose control of an e-mail account in any number of ways. Various report place the thief all over the world, from Iran to the Czech Republic. Some think he is this guy banned on dnforum.com. A good summary blog on Domain Name News one of the victims had his domain stolen off GoDaddy because of a compromised e-mail account. GoDaddy was unhelpful, but Name.com, to which the domain was transferred after being stolen, is being more attentive. The way to protect your domains from theft is generally to follow good security practice. Look for signs of phishing, keep updated anti-malware software running on your systems, and use long, secure passwords.

Registry Coalition Backs DNSSEC

Sun, 07 Dec 2008 05:03:39 +0000

Obviously inspired by my recent column calling for the signing of the root zone a consortium of domain registries and industry experts has been formed to facilitate the adoption of DNSSEC. The DNSSEC Industry Coalition includes prominent registries and registry operators PIR, Afilias, EDUCAUSE and, of course, VeriSign. The members work together "...to establish a consistent set of tools and applications, shared best practices, specifications and shared nomenclature." Certainly registries are important in the enabling of DNSSEC because they control the DNS for TLDs (Top-Level Domains), and domains below them need that for full efficacy of the protocol. It's a little early to get specific about what they are going to do.

Windows, Office, Sharepoint, Among Products Getting Updates This Patch Tuesday

Thu, 04 Dec 2008 11:34:54 +0000

Microsoft's Security Bulletin Advance Notification for December 2008 says that there will be 8 bulletins and updates coming next Tuesday for a variety of Microsoft products. 6 of the bulletins have a maximum rating of Critical. One critical update affects all shipping versions of Windows. Another affects only Windows Vista and Windows Server 2008. One update for Internet Explorer is rated Critical for all versions of Windows, indicating that version 7 is affected. Another affecting Windows Media software is rated Important and affects all versions other than the Itanium-based server products. 4 other bulletins affect various Office and server-based products. One for Visual Basic affects only FrontPage and Project in Office, but also Visual Basic 6, Visual Basic.NET and Visual FoxPro. One fix for Microsoft Word is rated Critical for Office 2000 and 2007 (with or without SP1), but Important most everywhere else, including Office 2003. An Excel fix is Critical only on Excel 2000, and Important elsewhere. Lastly, a flaw in Sharepoint Server 2007 and an associated flaw in Search Server 2008 are both rated Important. There will also be the usual assortment of non-security updates: An update to the Junk Mail filter; a new version of the Malicious Software Removal Tool; an update to deal with legal changes in daylight savings time in various unspecified countries; and one which addresses application compatibility problems on Windows Server 2008.