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.
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).
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. Continue reading Internet Explorer VML Zero-Day Mitigation
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.
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.