Security Watch

The Day Symantec Couldn't Speak Chinese

It was a case of Symantec Updates not working on Chinese Windows XP, but was it due to pirated XP copies? Also: IETF approves DKIM; rare MOICE problems.

• By Russ Cooper
• 07/09/2007

It was back in May that ComputerWorld reported (here and here) that Symantec had released a signature update that led to two critical Windows system .DLLs -- Netapi32.dll and lsasrv.dll -- being quarantined by the antivirus program on Simplified Chinese language versions of Windows XP SP2 which had been updated as of Microsoft Security Bulletin MS06-070. If such a system received the faulty signature update and was rebooted after the files had been quarantined, the system would no longer boot. Recovery is only possible via the Windows Recovery Console.

Symantec subsequently stated that its automated threat analysis system caused the false positive on the Windows system files, a process which automatically generates signatures to identify malware. A corrected signature update was made available about 13 hours after the faulty version was published.

It’s interesting to note how the articles depict users whose XP version is pirated; "A likely snafu in that scenario (using the Windows Recovery Console), however, is that many Chinese users don't have a restore CD because they're running pirated copies of Windows."

Of course the story's author fails to realize that SP2 required Windows Genuine Advantage, so pirated copies won’t be at XP2, and therefore won’t have been able to install MS06-070 to cause the misdetection. Ergo, only legitimate users will encounter problems, and all should have access to a Windows Recovery Console. Regardless, that an automatic update from Symantec resulted in an inability to use the PC and force the effort involved with recovering with the Windows Recovery Console is a major fault on their part.

A Faster, More Secure VNC Remote Access Trick
Check out this excellent, two-page article on making VNC connections more secure from Howto Forge. The author uses a NoMachine NX Server to provide a faster SSH tunnel and session server (RDP or Remote X) to pass the VNC session through. He also uses a WiKID Server to provide two-factor authentication using certificates.

The article is well worth the read if you use VNC in your environment. The added authentication is of particular interest, as it should ensure that VNC authentication bypass vulnerabilities cannot be exploited by anyone other than a trusted insider. I highly recommend considering this solution or, at the very least, comparing your existing solution to what is proposed here to determine if weaknesses exist in your environment. Also, if you provide remote access to a third party, such as a remote support organization, ensure they are using something similar to what is described in this article.

IETF Gives Nod to DKIM
DomainKeys Identified Mail specification has been approved by the IETF. This means the standard is now finalized and now the only question is how widely it will be adopted. DKIM describes a standard where a system who has a role in submitting a message into the e-mail stream signs the message with a cryptographic signature. Recipient systems can then perform a lookup on the key provided to verify that the message was actually submitted by the entity claiming ownership.

DKIM differs from systems like S/MIME and other cryptographic email signing mechanisms, in that neither the author nor the entire contents are being attested to, merely the fact that the e-mail presented can be attributed in some way to the organization who adds the signature header element. Multiple elements could be present in an e-mail, as each entity involved in the process may sign the e-mail. (SearchSecurity.com also has an interesting article here.)

DKIM has far greater value for very large e-mail providers, such as one of the original developers -- Yahoo! -- and possibly very large companies who are targets of frequent phishing attacks.

A recipient mail system should perform a DNS lookup on the signature provided in an e-mail to determine whether the cryptographic key of the claimed "Signing Identity" was actually used to make the signature included in the headers of the e-mail. From this, the recipient could know whether or not the e-mail forged the header lines. The actions taken by recipients, be they systems or people, are variable. If a signature is present, it should be valid, if it is not valid, then the message might be rejected outright. However, the lack of a DKIM signature may or may not mean a forged message, the recipient would have to determine whether or not a DKIM signature was supposed to be present.

DKIM is similar to SPF in that it provides a recipient with a way to determine if e-mail is legitimate. Like SPF, it is not foolproof. While SPF focuses on whether a mail server is allowed to deliver e-mail from a given domain, DKIM incorporates a portion of the message content in forming the signature placed in the header.

It is unlikely that either method will be chosen over the other, as neither is completely effective. Instead, it is likely that both will be incorporated, in addition to other more traditional methods such as TLS and S/MIME or PGP.

Want More Security? This column was originally published in our weekly Security Watch newsletter. To subscribe, click here.

A Problem with MOICE
There are some very serious limitations with the Microsoft Office Isolated Conversion Environment tool that, we believe, will make it too cumbersome to use in any average environment. (You can read more about it here; registration is required.)

MOICE requires that the OS be configured to invoke it, rather than Microsoft Office applications, when its supported Office document types are invoked. Further, Office applications should be configured to prevent opening of Office documents, requiring either the repeated use of MOICE every time a document is opened, or, the use of an Office 2007 feature called "Trusted Locations" to store Office documents (now with limited support for Office 2003.)

We believe the average enterprise need do nothing regarding the release of MOICE. MOICE may prove to be a rarely used forensic tool, since it's a must-have for a very limited set of users. It is not easily configured for per-document use, but may prove useful occasionally for repository scanning.