It seems to have been a fairly quiet week again, although the MTX virus has been stirring things up with those unfortunate enough to have been infected. Some observations and important details about the inner workings of your virus scanner are included below as a result of focussing much of my work this week on MTX and its after-effects.
On the security front, of particular note because of its rarity, Sun has just released an announcement that two of its security certficates may have been compromised and that they are withdrawing them. Because of the typical configuration of most web clients, this may require manual intervention on teh users' part to remove these certificates if they have already been accepted by your browser.
More on MTX virus
Two weeks ago we mentioned that MTX, which had been "bubbling under" for a while, had raised its head above the threshold of "totally unintersting". Last week it was mentioned to be holding -- gaining
ground even. This week we are seeing even more MTX infections and many people having trouble cleaning up after it. One of MTX's "tricks" is that when checking for files to infect, it looks at all files,
regardless of their file extensions (well, it ignores files smaller than 8KB and a that don't meet a few other arcane requirements).
When ooking at the files that MTX will infect this week, the newsletter compiler was surprised at how many Windows "portable executable" (PE) style files may be on a "normal" machine but with odd, and in some cases quite unexpected, extensions.
Why does this matter?
Because many virus scanners still have a list of file extensions that designate the "types of files" that will be scanned. Some developments in the last couple of years have seen a move to "scan all files" as the default, where what actually happens is the scanner takes a quick look at each file's contents and decides whether internally the file is of a type that needs to be scanned. However, many scanners still do not do this including some of the more popular ones. As MTX is quite clearly "out there", it may be prudent to check what file types your scanner looks at by default, and if you should be unfortunate enough to be infected with MTX, ensure that you do a thorough (some products call it "deep", others "dumb") scan of ALL files on the infected machine(s).
And don't forget, MTX uses the "trick" of naming the attachments it sends in its Email messages (well, most of them) with a .PIF extension. However, the files in the attachments are actually EXE files. When these renamed EXEs are "opened" on a Windows machine, the OS silently resolves that they are actually program files and it runs them as such -- no fuss, no bother, no warning. Unfortunately, it seems many users treat file extensions they do not recognize as "probably safe" rather than "decidedly dodgy" and happily click on them. As few users other than system administrators are probably aware of the real nature of PIF files, and even fewer would have been aware of the "rename an EXE to a PIF" trick (at least until recently), we may well see MTX get worse before it gets better...
Further comment on MS00-078 "feature" from last week
In the previous newsletter, we reported the claim that installing the MS00-078 update to fix a nasty directory traversal vulnerability could break those parts of sites that depend on directories with dots in their names. Specifically, it seemed that web directories with extensions in their names (e.g. <webroot>/test.dir) will be inaccessible to the server if the directory name "looks like" a file-type that is executable to the server (e.g. <webroot>/test.com).
A Microsoft security spokesperson confirmed that this was, in fact, expected behaviour after installing that patch. This does not seem like a very satisfactory "solution" for sites doing massive virtual hosting,
where using the domain name as the webroot is often a fairly "obvious"choice (to ease administration if nothing else).
The Microsoft response to one public complaint about this unexpected loss of functionality can be read at the link in the bugtraq archive, provided below.
YAMVU -- Yet another Microsoft VM update
How many Microsoft VM updates have we mentioned in recent newsletters?
There seems to be a cottage industry somewhere inside Microsoft that churns out VM sub-system updates at an alarming rate. Although there is sometimes a lag in their appearance, their rate of apprearance closely matches the rate at which independent security researchers find glaring holes in the most-recently released version of the VM.
This update closes another hole whereby an "attacker" can use a Java applet to access files on the machine running the applet. Files accessible across the LAN or an intranet can also be accessed by a
malicious applet exploiting this hole, but this is a little more difficult for an attacker to pull off. An attacker need not know the names of files that are local to the machine running such a malicious
applet, as this hole allows the applet to list files. Attackers wanting access to files accesible from a share that is not mapped to a drive on the machine running the applet would have to know the share names of interest -- once these were available to the attacker an applet would be able to list the files on the shares, just as it could list the files on a local drive.
At newsletter publication time, Microsoft had not released updates for either the 2000-series or 3000-series versions of the VM. A note on the Microsoft security web site said these updates "will be available shortly". Another option is to upgrade your VM to build 3319, regardless of which VM series you currently have installed.
However, there are a few limitations on this, such as the 3319 build of the VM requires that you have v4.01 (or a later version) of Internet Explorer installed, and Windows 2000 users must have SP1 installed. Windows 2000 users considering the 3319 build upgrade should also be aware that they must download a different updater from Win9x, ME and NT users -- it must be installed as part of a "hotfix" or "service pack" process. Regardless of your OS version, if you do install the 3319 update, it cannot be uninstalled. Finally, details of using the JVIEW utility to determine what VM version is currently installed on your machines are contained in the FAQ associated with the Microsoft Security Bulletin covering this issue. Finally, note that this update supercedes the MS00-059 VM update mentioned a month or so back in the newsletter.
Security update for IIS
A patch that eliminates the "Session ID Cookie Marking" vulnerability has been released by Microsoft and is avaiable for download from the first of the URLs below. This vulnerability can allow for the hijacking of a user's secure web session. The fundamental problem is that IIS uses the same Session ID for secure and non-secure pages on a site. The gory technical details can be read in the Microsoft Security Bulletin and FAQ at the links below.
Microsoft recommends this patch be installed on any IIS web server that needs to mark as secure Session ID cookies from ASP pages.
Sun advise of potentially compromised security certificates
Two Sun security certificates, that have only had limited distribution, may have been compromised. Sun recommends that people check whether their web broser has accepted one of these crtificates, and if so, remove it. Instructions for doing so are provided at both Sun's security web site and the CERT Coordination Center.