In the urgency of covering VeriSign's issuing of bogus "Microsoft Corporation" certificates last week, your newsletter compiler missed including the PGP secret keyfile format flaw, despite referring to it in
the introduction -- it is included this week! Also. Microsoft has released the promised patch to deal with the lack of a certificate revocation mechanism for VeriSign certificates. Users of Windows 98 and ME password "protection" on compressed folders may be in for a rude shock too, in another Windows update below. And this week's virus news was dominated by a Windows/Linux cross-platform infector and a new Linux worm, similar in some respects to the Ramen worm mentioned a few issues back. Several of these stories actually broke within hours of least week's newsletter being issued -- I wonder what will arrive in my e-mail during the next few hours?
Windows/Linux cross-platform virus
Although referred to as W32.Winux in the initial press coverage, most antivirus researchers and developers know this newly discovered virus as Win32/Lindose. Lindose infects Windows PE and Linux ELF format executable files, and will do so on either platform. Expert opinion is that the prospects of such a virus becoming at all common are very slight. However, with the growing adoption of Linux and many dual installations with both Linnux and some form of Windows on one machine, the odds for such a cross-platform infector are improving. As dual installations often share one or more of the logical drives (or partitions) on the machine's hard disk, there is clearly some scope for a virus like Lindose to find "comfortable lodgings".
Both Lindose's components are simple. When infecting PE format files, it looks for target files with ".reloc" sections (conventionally used to store memory relocation mapping information should an executable not be able to load at its preferred memory address) large enough to hold the virus. Suitable hosts are infected by removing the relocatable code flag in the PE header, inserting the virus' code into the space occupied by the .reloc section and changing the host's entry-point header field to
point to the virus code. ELF format executables are infected by copying a chunk of their code from the beginning of the file to the end and overwriting the head with the virus' code. When either kind of infected executable is run under the approriate operating system, the virus' code runs first, searching for other files to infect then, in the PE case, passing control to the original program entry point, and in the ELF case patching the program's image in memory by copying the "moved" section of the original executable back where it should have been and executing it normally from there.
Of course, just two names would be too few for a virus, so in keeping with the antivirus industry's apparent need to confuse its customers, at least a couple of products will call this virus "PEElf" (including the scanner whose US distributors raised all the fuss and hype in the media, initially calling it Winux!). And, finally, there has been a lot of silly talk about Lindose being the first cross-platform virus. This has, in turn, led some commentators to say they did not think such a thing was possible and a few have even been praising the virus' writer. Such people either have short memories or don't know computer security history well enough to be able to validly comment. The so-called "Morris Worm" clearly showed that cross-platform infestation was possible as it affected Sun SPARC-based and Digital Equipment VAX-based systems -- not only two different operating systems, but two quite different architectures.
New Linux worm spreading via old BIND exploits
The Lion worm has been reported to have been found on several Linux machines and spreads by exploiting the TSIG vulnerabiility in "older" versions of of the BIND DNS server software. Necessary updates to patch against this BIND vulnerability have been available since late January this year (the TSIG vulnerability is one of the four that was referred to in an issue of this newsletter earlier this year).
Dartmouth Institute for Security Technology Studies student William Stearns has written a script that should find "standard" variants of the Lion worm but, as of this writing, Lionfind does not remove the worm. Most antivirus products have also added detection of the known binary forms of the worm. Linux system administrators setting out to test their own systems for the worm's presence are advised to read the description of the worm very carefully as Lion installs the "t0rn" rootkit which does a very effective job of hiding the worm's presence.
Certificate revocation patches available from Microsoft
One of the flaws that became abundantly apparent from last week's discovery that VeriSign had issued fraudulent "Microsoft Corporation" code-signing certificates was that none of Microsoft's operating systems that support its code-signing technology had automatic certificate revocation checking mechanisms for VeriSign certificates. This has now been rectified with a patch that covers all versions and service pack levels of all true Win32 OSes -- that is, Windows 95, 98, ME, NT, 2000 and Windows XP beta releases. Despite the official position on some of these OSes now being "unsupported", this patch is a supported patch for all those OSes and Microsoft technical support should be able to assist
user having difficulty with it.
Patch for Microsoft Visual Studio 6.0 Enterprise Edition
The code handling one of the remotely accessible methods of the VB-TSQL debugger object in Visual Studio 6.0 Enterprise Edition has an exploitable buffer overflow. This flaw can thus be remotely exploited to crash the host machine or have arbitrary code run with the privileges of the interactively logged-in user. There are several mitigating factors that reduce the real risks from this bug, but if this version of the software is installed in a potentially hostile environment it should be patched as an exploit has been published.
Note that the exploitable code is only present in the Enterprise Edition of Visual Studio -- the Professinal Edition is not affected.
Passwords for Win98/ME Compressed Folders are recoverable
Microsoft has released a patch to remove a serious security hole from the Compressed Folders feature in Windows 98, 98SE and ME. The Compressed Folders feature is included in Plus! 98 and is a part of Windows ME. Apart from allowing the user to denote folders whose contents are to be stored in compressed form, it allows passwords to be set for such folders.
Note that Microsoft warns in the security bulletin announcing the release of this patch that this password protection feature was not intended as a strong security feature -- that's what Windows 2000 is for. Despite that, users of Compressed Folders with password protection would probably be surprised to learn that the passwords for their folders are stored in plain text in a file called "dynazip.log" in the Windows installation directory. The patch announced in the security bulletin below fixes this shortcoming of Compressed Folders, but note that after installing the patch you must delete the "dynazip.log" file.
Also note that Microsoft's official position on the "security" offerred by passwords on Compressed Folders is "is only intended to provide protection against casual inspection", to quote the security bulletin.
Eudora scripting hole
Eudora supports the display of HTML e-mail messages in one of two ways. The default method is to use an in-built "simple" HTML parser/viewer. Users wishing to view "complex" HTML-formatted e-mail may not find that very satisfactory though and thus Eudora has what is sometimes referred to as "sponsored mode" -- the ability to use the Microsoft Internet Explorer HTML parser and viewer controls, but displaying the results in a window inside the Eudora program.
By default, sponsored mode (the "use Microsoft viewer" option in the configuration menu) is disabled. Eudora has another security mechanism too. Enabled by default, Eudora has an option that attempts to strip scripting code from HTML before passing it to the HTML viewer it is using (reardless of whether it is the internal Eudora viewer or IE). This is the rather oddly named "allow executables in HTML content" option in the configuration menus.
Unfortunately, there is a flaw in the latter filter which allows some obscure forms of scripting to be passed to the HTML viewer. As the Eudora HTML viewer does not support scripting, it does not matter if that viewer is being used, but if IE is set as the HTML viewer, the scripting will be run. Coupled with some other somewhat undesirable Eudora features (such as the ease with which a malicously created e-mail message can drop a file in a known location on a Eudora user's machine) this raises the possibility of some nasty exploits. The first item in a short, but rather technical discussion thread from the Bugtraq mailing-list is referenced below. There is also a link to the Eudora beta software download site where a copy of the latest beta, which fixes the scripting trick discussed above, is available.
PGP secret key issue flaw
Two security researchers working at the Czech compnay ICZ have found a severe security flaw in the PGP secret key file format. Much has been made of the fact that this flaw allows recovery of a person's secret key with having to break the strong cryptography used to "secure" the key and this, indeed, a serious concern. However, there are several quite problematic issues in taking these researchers findings and implementing a successful attack against someone's secret key.
To implement an attck based on this flaw in the secret key file format, the attacker must have physical access to a target's secret key and must be able to alter the key's content. That is quite stringent requirement, and anyone exercising good physical security over their secret key should not be easily targeted this way. However, it is equally plausible that an attacker could "sniff" an image of the key "off the wire" if they had access to a network connection over which the target's secret key is copied as they encrypt a message. This latter scenario also allows an easy way for the attacker to make the one-off modification to the key that is necesary for the attack (more in a minute). It is, of course, bad practice to hold your secret keys on a network server and access them from a workstation...
As well as being able to access and modify the target's secret key, the attacker must also be able to make a change to its contents based on some special knowledge of the secret key format and the specific weakness the Czech researchers uncovered. The attacker then must also be able to receive (or intercept) a copy of any message signed with the attacker's modified form of the key. The attacker should then alter the target's secret key back to how it was. By applying some fancy, but not terribly complex (in terms of computing time) mathemathics the attacker can then recover the target's secret key. This attack is much quicker than a (currently infeasible) brute-force attack against the crptography
used to encypher the secret key within the secret key file (the Czech researchers claim it takes half a second on a typical modern desktop computer).
The lesson to take from this is that, when the PGP and OpenPGP documentation says that you should take extra special care and precautions with the physical security of your secret key file, they really do mean it!