Just before Christmas and wouldn't you know it -- two critical security updates for Windows systems and the first Office XP service pack! Unix and Linux admins get off more lightly, though should be checking for a library update to fix a nasty globbing bug that could leave some of their externally exposed services open to remote attack. On the virus front, a couple of mass mailers half-sparked this week, but should not have caused any trouble for those of you in well-maintained corporate LAN environments. Finally, if you must (or just will) use Outlook as your e-mail client and rue its forced rendering of HTML, one or both of two articles below (depending on the version(s) of Outlook you use) may be of interest. Office XP SP1 introduces Microsoft's first attempt at providing a 'no HTML' option, but of course, just for Outlook 2002 users. Those with other versions of Outlook may (or may soon) find the
NoHTML add-in of use.
Seasons greetings to all our readers -- this is the final Virus & Security Watch newsletter of 2001 (which probably means something really serious is coming down the pike as I sign off... 8-) ).
Maldal -- another 'dumb' mass mailer -- takes flight
Somewhat surprisingly, although perhaps not that surprising given events of the last few weeks, Win32/Maldal.C@mm made a minor flurry in the annals of 'successful' e-mail worms late this week. Arriving as an executable attachment its recipients have to decide to run themselves, Maldal.C is actually a variant of Zacker, mentioned in last week's newsletter. The antivirus industry decided neither Zacker nor Keyluc (as a few had named the earlier worm) were good names for this worm and most developers have renamed the whole family to Maldal. Of course, this did not happen until after at least some developers had chosen yet another name and made press releases and the like. Thus, the name Reeezak is also associated with this worm.
Aside from mass mailing itself, Maldal.C tries to download and run further VBS viruses and e-mail worms from a web site. The web pages involved exploit an old Internet Explorer security vulnerability to drop and run the script files, thus starting those viruses. Closely related, those viruses have been named VBS/Dismissed.A and VBS/Dismissed.B@mm -- note the second is also a mass mailer. Neither of the script viruses depend on each other or on Win32/Maldal, hence their inclusion in a separate family.
It seems the virus was caught early in its propagation and the web site administrators were quickly contacted. There prompt removal of the site seems to have occurred early enough in the piece that the script viruses have not become established, although Maldal.C, which works independent of the existence of the web site, is still showing up as moderately active as this newsletter is finalized for posting on Friday morning. Readers may wish to check its 'progress' with MessageLabs' VirusEye.
The day before Maldal.C took off (see previous item), JS/Coolsite.A@mm also caused a brief stir. Like the mechanisms Maldal.C used to drop the VBS/Dismissed variants on victims' machines, Coolsite depended on an old Internet Explorer vulnerability. Exploiting the 'Microsoft VM ActiveX Component' vulnerability, the JS/Coolsite script, embedded in the HTML of a web page, sends a simple message to the addresses of the messages in Outlook's Sent Items e-mail folder. That message exhorts the recipient to visit 'a cool web site'. If the reader of such a message (or anyone else for that matter) visited the web site with a version of IE with the 'Microsoft VM ActiveX Component' vulnerability, the virus would run on their machine, and so, and so on and so on.
Fortunately, this replication scheme means that there is only one 'permanent' copy of the actual virus code, and closing the web site hosting it fairly quickly stopped the virus.
More critical Internet Explorer updates
In the last few weeks we have seen extensive use of old Internet Explorer vulnerabilities that allow 'auto-running' of e-mail attachments and other similarly funky things with web pages. During that time, further 'advances' on some of the earlier vulnerabilities, and discovery of some entirely new ones, have been made. These also allow auto-running of e-mail attachments and the like from web pages.
In tune with its 'current and previous major release' support policy, only Internet Explorer 6.0 and 5.5SP2 have been tested and patched by Microsoft. Users of older IE versions really should now be upgrading or, with the rate of discovery of such horrendous bugs in IE showing no sign of abating, perhaps finally biting the bullet, switching browsers and hacking some of the clearly awful IE DLLs out of their systems. Anyway, you have been warned. If you are not comfortable with ripping IE out of your system (Microsoft technical support, for one, certainly will not be happy with you...) and/or you have to keep using IE and Outlook (but _not_ Outlook Express), read the articles later in this newsletter about the eventual arrival of the ability to disable the rendering of HTML in Outlook, delivered in Office XP SP1, or through the use of the NoHTML COM add-in for earlier versions of Outlook...
The history of these things suggests it typically takes three to six months from the public release of sample exploits of such vulnerabilities before we see their (often successful) use in new e-mail worms and the like. Recent history, however, suggests that the virus and worm writers are paying closer attention to such developments and implementing them in their 'creations' sooner. It would be prudent to install this update (and in IE 5.5's case the service pack this update depends on if it's not already installed) before leaving the office for Christmas, or at least ensuring it is ready to rollout the first day back after the break!
One thing that may make this a more appealing process -- if you have been a bit lax with installing your IE patches of late, this is another 'security rollup' patch, meaning it has all patches that are required on top the current service pack. For IE 5.5 that means you must have already installed SP2 before installing this update, and as there have been no service packs for IE 6.0 yet, this patch can be installed on any IE 6.0 installation, regardless of its current hotfix status.
Critical update for UPnP on Windows XP, ME, 98SE, 98
Further to the MS01-054 security bulletin and patch a couple of months back, further problems in the implementation of the UPnP device discovery protocol have been discovered, requiring a further patch. The effects of these problems vary, depending on the OS. For Windows XP, which has UPnP installed and running by default, remote compromise and execution of arbitrary code with system level privileges is possible, and for all OSes performance degradation and instability are possible outcomes of an attacker exploiting these vulnerabilities.
Microsoft rates the severity of these vulnerabilities as critical on Windows XP and moderate on the other OSes _if_ UPnP support has been installed on them. Windows 98 and 98SE do not have any UPnP support by default, but it is installed with the Internet Connection Sharing client supplied with Windows XP. Although Windows ME has native UPnP support, it is not installed and enabled in Microsoft's default configurations, however some OEMs ship Windows ME with UPnP installed and enabled. If you apply the patch to Windows XP _then_ install the Internet Connection Sharing client on Windows 98 or 98SE machines from the patched XP installation, the Windows 98 machines are not vulnerable.
Office XP service pack 1 released
The first Office XP service pack has been released. Aside from fixing numerous bugs and adding a few 'last minute' features and feature enhancements, it also includes the earlier security hotfixes that handle the file format errors that can allow documents bearing macros to have their macros run despite the macro security options being set to prevent that. If you did not install those hotfixes when they were released (there were only known public exploits of one of the Word format bugs), this service pack may be for you!
Better, however, is that the updated version of Outlook included in the service pack finally adds the ability to configure Outlook so it will not render HTML in e-mail messages. This feature is currently only available by manually adding a registry entry -- there is no radio button somewhere in Tools/Options to configure this -- but at least you now have the choice. The details of disabling HTML are described in a KnowledgeBase article, linked below. Note that disabling HTML does not disable all HTML, as digitally signed and encrypted messages are left unaltered and will display as HTML if they have HTML components.
- Microsoft KnowledgeBase article explaining plain text reading
NoHTML for Outlook
Security and privacy conscious users of Outlook and Outlook Express have long asked for an option to disable the products' behaviour of defaulting to displaying the HTML component of MIME multipart/alternate messages and possibly even to be given an option whereby _no_ HTML content would be rendered. The reasons for this are manifold, but mainly revolve around the fact the only way Outlook and Outlook Express render HTML is by passing it off to Internet Explorer's notoriously buggy and security flaw-ridden HTML parsing code.
None of the auto-running e-mail worms we have seen become large problems of late would have been able to work as they do if IE was not in the e-mail picture. That is because they depend on IE security flaws, _not_ on Outlook or Outlook Express ones. Of course, whether these worms would have become widespread would still partly have depended on how many users were foolish enough to manually run the worm's attachments, but all those hundreds of thousands of copies that were created when people just chose to read the message would have been avoided. If a 'no HTML' option been available from the outset (and people had chosen to use it), things would be a lot better. Further, the use of 'tracking' devices such as web bugs is reputedly on the increase, and even if it is not, people's privacy concerns should be sufficient reason alone to offer the non-use of a web browser for reading ones e-mail.
Anyway, having addressed the attachment issue in recent security packs for Outlook, including building the attachment type limiting features into Outlook 2002 (the version in Office XP), Microsoft has finally eaten a sliver of humble pie by providing an 'almost no HTML' option in Outlook 2002 SP1 (see the previous item in this newsletter). That coincided with the public release of the NoHTML add-in for Outlook 2000 and 2002, stealing some of his thunder, but nonetheless, there is still some use for this add-in.
Microsoft has not released, nor given any indication it will, an equivalent of its 'read as plain text' option for Outlook 2000 or 98, yet many corporate users still run these versions of the product. Currently NoHTML only works with Outlook 2000 and 2002, but there is some hope from the NoHTML web page that Outlook 98 may also be covered in a later version. The Microsoft solution for Outlook 2002 is more comprehensive than NoHTML, being able to burrow deeper into Outlook's innards, so is the better choice for that platform, but NoHTML offers some help for Outlook 2000 users.
NoHTML, from the NTBugtraq mailing list moderator Russ Cooper, is a COM add-in that triggers on a selection change. Unfortunately, if Outlook's preview pane is enabled, a message is rendered in the preview pane _and in HTML_ before the selection change event triggers. Fortunately, from a security perspective, Outlook's preview pane (unlike that in Outlook Express) does not do full HTML rendering -- it does not run embedded scripts or other active content. Unfortunately, from a privacy perspective, rendering in the preview pane will try to get image files, including hidden web bug ones, from Internet URLs. If you think NoHTML may be of use to your Outlook 2000 users, please carefully read the web page below, as NoHTML is not quite a mainstream product with a fancy installer and such, but may just be worth your while.
glibc update for multiple Unixes, Linuxes
Bugs in the standard globbing function in several Unix and Linux distributions has been fixed. This was discovered as a result of similar recent bugs in some popular FTP daemons when some daemons that rely on the system's glob library function, rather than their own globbing routines were also found to have similar problems to the daemons whose internal glob functions had earlier proven exploitable. Check with your vendor(s) in case your distribution is affected.