The latest Windows malware, Duqu is getting a lot of attention.
Duqu exploits a previously unknown TrueType font parsing bug in the Windows kernel. The bug exists in all the supported versions of Windows: XP, Vista, 7, Server 2003 and Server 2008. It's a big-time bug too, as it lets bad guys do pretty much anything they want to do on the victims' computer.
While it works on a fix, Microsoft has offered a workaround that prevents access to the buggy component, file t2embed.dll. But Microsoft seems to have been particularly sloppy in explaining their workaround.
I am referring to Microsoft Security Advisory (2639658) Vulnerability in TrueType Font Parsing Could Allow Elevation of Privilege.
To begin with, the Suggested Actions section of the advisory offers commands that a Windows user can issue to deny access to T2EMBED.DLL.
Someone running a 64-bit version of Windows XP or Windows Server 2003, is instructed to "enter the following command" after which there are two commands. Likewise, anyone running a 32 bit version of Windows Vista, 7 or Server 2008 is also instructed to "enter the following command" and then given two commands to run.
Should you issue just the first one as instructed, or, assume the instructions are wrong and issue both commands?
And, someone running a 64 bit version of Vista, 7 or Server 2008 is given four commands to enter after the instructions to "enter the following command".
And, it goes without saying that before making sytem modifications, you should always make a restore point. I mean this literally, Microsoft omits this important Defensive Computing step from their instructions. All their "Fix it" solutions make a restore point before changing anything, so it should be in the manual instructions too.
Also missing are instructions for determining if a given copy of Windows is 32 or 64 bit. My favorite method is the free and portable SecurAble utility from Steve Gibson.
More importantly, the advisory appears to conflict with itself.
In the Mitigating Factors section it says "The vulnerability cannot be exploited automatically through e-mail. For an attack to be successful, a user must open an attachment that is sent in an e-mail message."
In the FAQ section it says "There are multiple means that could allow an attacker to exploit this vulnerability, including ... convincing users to visit a Web page that embeds TrueType."
Many, if not most, email messages are formatted with HTML, the underlying language of web pages. So, can viewing an HTML formatted email message result in an infection? I would think so.
Or, is the point about web pages wrong? I've read my share of articles on Duqu in the technical press and none of them mentioned that infection was possible by viewing a web page.
And, if web pages are a means of infection, Microsoft should say if this is true for all web browsers or only theirs.
I asked Microsoft for clarification, we'll see if I get an answer.
Microsoft has also failed to provide a tester, that is, something that a Windows user can do to verify that the workaround is, in fact, working.
If Word is the only means of infection, they should offer a test Word document. If you can get infected via a web page, Microsoft should create a page with an embedded TrueType font that does something trivial, like running the calculator, on a vulnerable machine.
They also don't say if running as limited/restricted/standard user offers any protection. My guess is that it does not, but considering this is a common defensive tactic against malware, it should be mentioned in the advisory.
Finally, Microsoft is virtually silent on the issue of what breaks when you install the workaround, be it manually with commands or with their dedicated Fix it tool.
A person commenting on a ZDNet story said the workaround "kills the ability to export to PDF in Office 2010". Another person, commenting on the same story, said that Windows Update on Windows XP gets confused by the workaround and tries to install a pair of old patches. I can't vouch for either observation.
EMAIL ATTACHMENT DEFENSE
Taking a step back, its worth noting that infected email attachments are a tried and true attack vector. And, it's a shame, because there is much that Windows users can do to protect against this, for free, that rarely gets discussed.
My first defensive computing tact for email attachments is to open them with unpopular software. For example, use Writer in LibreOffice rather than Word or SumatraPDF rather than the Adobe Reader.
An excellent second line of defense can be provided by running the unpopular software in a Sandboxie sandbox.
Finally, all email attachments need to be treated as dangerous. Just because they appear to come from someone you know means nothing.
Duqu exploits a previously unknown TrueType font parsing bug in the Windows kernel. The bug exists in all the supported versions of Windows: XP, Vista, 7, Server 2003 and Server 2008. It's a big-time bug too, as it lets bad guys do pretty much anything they want to do on the victims' computer.
While it works on a fix, Microsoft has offered a workaround that prevents access to the buggy component, file t2embed.dll. But Microsoft seems to have been particularly sloppy in explaining their workaround.
Michael Horowitz on Duqu
- Microsoft sloppy on Duqu workaround
- Why Duqu is more dangerous than most people think
- A simple test insures the Duqu workaround is working
To begin with, the Suggested Actions section of the advisory offers commands that a Windows user can issue to deny access to T2EMBED.DLL.
Someone running a 64-bit version of Windows XP or Windows Server 2003, is instructed to "enter the following command" after which there are two commands. Likewise, anyone running a 32 bit version of Windows Vista, 7 or Server 2008 is also instructed to "enter the following command" and then given two commands to run.
Should you issue just the first one as instructed, or, assume the instructions are wrong and issue both commands?
And, someone running a 64 bit version of Vista, 7 or Server 2008 is given four commands to enter after the instructions to "enter the following command".
And, it goes without saying that before making sytem modifications, you should always make a restore point. I mean this literally, Microsoft omits this important Defensive Computing step from their instructions. All their "Fix it" solutions make a restore point before changing anything, so it should be in the manual instructions too.
Also missing are instructions for determining if a given copy of Windows is 32 or 64 bit. My favorite method is the free and portable SecurAble utility from Steve Gibson.
More importantly, the advisory appears to conflict with itself.
In the Mitigating Factors section it says "The vulnerability cannot be exploited automatically through e-mail. For an attack to be successful, a user must open an attachment that is sent in an e-mail message."
In the FAQ section it says "There are multiple means that could allow an attacker to exploit this vulnerability, including ... convincing users to visit a Web page that embeds TrueType."
Many, if not most, email messages are formatted with HTML, the underlying language of web pages. So, can viewing an HTML formatted email message result in an infection? I would think so.
Or, is the point about web pages wrong? I've read my share of articles on Duqu in the technical press and none of them mentioned that infection was possible by viewing a web page.
And, if web pages are a means of infection, Microsoft should say if this is true for all web browsers or only theirs.
I asked Microsoft for clarification, we'll see if I get an answer.
Microsoft has also failed to provide a tester, that is, something that a Windows user can do to verify that the workaround is, in fact, working.
If Word is the only means of infection, they should offer a test Word document. If you can get infected via a web page, Microsoft should create a page with an embedded TrueType font that does something trivial, like running the calculator, on a vulnerable machine.
They also don't say if running as limited/restricted/standard user offers any protection. My guess is that it does not, but considering this is a common defensive tactic against malware, it should be mentioned in the advisory.
Finally, Microsoft is virtually silent on the issue of what breaks when you install the workaround, be it manually with commands or with their dedicated Fix it tool.
A person commenting on a ZDNet story said the workaround "kills the ability to export to PDF in Office 2010". Another person, commenting on the same story, said that Windows Update on Windows XP gets confused by the workaround and tries to install a pair of old patches. I can't vouch for either observation.
EMAIL ATTACHMENT DEFENSE
Taking a step back, its worth noting that infected email attachments are a tried and true attack vector. And, it's a shame, because there is much that Windows users can do to protect against this, for free, that rarely gets discussed.
My first defensive computing tact for email attachments is to open them with unpopular software. For example, use Writer in LibreOffice rather than Word or SumatraPDF rather than the Adobe Reader.
An excellent second line of defense can be provided by running the unpopular software in a Sandboxie sandbox.
Finally, all email attachments need to be treated as dangerous. Just because they appear to come from someone you know means nothing.
No comments:
Post a Comment