A new Windows e-mail worm, Win32/Redesi, that has a damaging payload is reputedly doing the rounds. Perhaps this is being pushed to the media by some antivirus companies because of the shame they feel of their disgraceful handling of the 'Anthrax virus' issue two days earlier in the week??
On the security front, a patch from Microsoft fixes another RDP problem on NT Terminal Servers and Windows 2000 machines running Terminal Services (however, very recent reports suggest to approach the patch with caution). Novell has released an update for a directory traversal bug in GroupWise that allows any file on the same volume as the web server to be read -- this should be applied with some urgency! Mac OS X users have a simple local root privilege elevation problem to deal with -- no patch yet but particularly for 'lab managers' in education settings, it is critical to do whatever is possible now to workaround/prevent this being used against your machines. And, Mac OS X 10.1 users should check their Internet Explorer settings!
Aside from those issues, I've included several 'information' items this week that I hope are of general interest to our readership.
Redesi e-mail worm
A new mass-mailing worm is currently reported to be spreading by e-mail, but there are few confirmed reports of infections. Named Win32/Redesi, two variants have been discovered in the last 24 to 36 hours. The first variant arrives in what looks like typical 'spam' e-mail messages. Redesi.B, however, copies the 'fake Microsoft security patch' approach that was quite successful for Win32/Leave. There are conflicting descriptions of a destructive payload that attempts to reformat the victim's hard drive on 11 November -- some reports imply both variants have this payload, and others suggest that just the 'fake Microsoft security patch' one does.
Few web sites have complete details of these new worms yet, but expect emergency product updates today to add detection of these (and note that Kaspersky Lab has named the variants 'back to front' compared to most vendors). Some very early reports of this e-mail worm referred to it as 'DarkMachine', but that name will not be used by antivirus companies.
Various antivirus developer descriptions:
'Anthrax virus' a non-event
[Although this article contains much factual reporting, it unabashedly portrays some of the newsletter compiler's editorial opinions.]
Currently the world lives with very real concerns about the suspected terrorism-related Anthrax bacteria affecting people in New York, Florida, Washington and possibly elsewhere. It would have been nice to
think that the computer security and antivirus folk would have avoided using the name 'Anthrax', or one easily confused with it, for any security attack or virus discovered recently. Apart from being a rather obvious act of sympathy with the victims of the 'real' Anthrax attacks, you would think that avoiding the potential confusion (and worse) that would arise from using such a name for a piece of computer malware would itself be a motivator.
Unfortunately, this was not to be. Some sick-minded miscreant produced several entirely trivial and uninteresting VBS programs with the buggy VBS Worm Generator (VBSWG) kit that was used by Dutchman Jan de Wit to produce the VBS/VBSWG.J (or 'Anna Kournikova') mass mailing worm. There are several minor variants of this virus. Some of them are so buggy that they do not run at all. In antivirus parlance these are known as 'intendeds' not viruses, because the code is clearly intended to be viral, but as it does not work, it is not a virus. Others are viral, but due to different bugs in their code, they do not mass mail themselves (although they will send masses of e-mail messages without the virus attached if run). The one that was first distributed among antivirus researchers, now known as VBS/VBSWG.AL by most researchers, was distributed as if it worked and it was described as if all its code, including the mass mailing part, worked as it was intended to work. Some antivirus vendors even posted screenshots on their web sites, showing a typical message created by this variant but they included the visual representation of the viral VBS file attachment that cannot be produced because of bugs in the virus. Such screen shots showing the viral attachment were clearly 'faked up', presumably to make the virus seem more realistic and scarier.
Why would a couple of antivirus developers do such a thing?
To sell more product perhaps? Or to 'sell' the story to the media?
It seems the latter is more likely.
As far as your newsletter compiler can tell, this virus was first reported (in Spanish) on 13 October by an Argentinean computer news site as VBS/Antrax (the name intended by the aforementioned miscreant who produced it with the VBSWG kit). That story was picked up by a Spanish antivirus developer who stuck with the virus writer's name despite general industry practice to avoid this if possible and despite a well-established standard for naming kit-generated viruses after the kit (hence the 'accepted' name of VBS/VBSWG.AL). That developer then posted a description of the virus to its client mailing list and sent samples to an antivirus industry 'emergency' sample distribution mailing list. Other members of that list started looking at the code and pointed out that aside from the severe bad taste of using 'VBS/Antrax' as a name, the virus should be named VBS/VBSWG.AL. However, at least one of the antivirus developers on that list 'faked up' the aforementioned false screenshots of the virus' e-mail message and posted them and a description of this terrible new mass mailing threat on their web site despite the fact that the code was known to not be able to mail a copy of itself. The US distributor of this developer's product also ran the incorrect description (translated into English), complete with a further altered version of the bogus 'screenshot' on their web site. This US distributor also fuelled some media reports of this 'new virus' stating it was in the wild and mailing itself around.
NT 4.0, Windows 2000 patch for service failure from malformed RDP data
Improper handling of certain data packets by the Remote Desktop Protocol (RDP) in NT 4.0 Terminal Server Edition and all Windows 2000 Server versions results in failure of the service, requiring a system reboot and consequent loss of any work in progress.
Under Microsoft's new severity ratings for security patches (see item below), the highest rating this vulnerability is assigned is Moderate for Intranet servers. This based on the fact that Terminal Servers are expected to be deployed in intranet settings and not on Internet-exposed machines. Obviously, an Internet-facing server running Terminal Services may be deemed a higher risk, particularly if the server runs other 'critical' services (which would be a poor design anyway...).
Post Script: Just before posting this newsletter issue two reports of this patch severely impacting the usability of the boxes it has been installed on were posted on NTBugtraq. This should remind us to thoroughly test patches on suitable test machines that closely emulate our production systems.
Regression errors in Windows 2000 post-SP2 hotfixes
The Microsoft KnowledgeBase article Q299546 talks of 'loss of some of the fixes that are included in SP2' when installing some post-SP2 hotfixes. The issue is that hotfixes are treated with some urgency and generally only tested in relation to the flaw they are designed to address whereas service packs are more thoroughly tested. This means that the base code for a service pack release is 'frozen' at some point (no new fixes are allowed) and then testing begins. new hotfixes, which are treated more urgently, are then made based on this frozen codebase.
So far, so good, right? Unfortunately, in the more thorough testing service packs receive, bugs in the service pack codebase are sometimes found that are missed in the hotfix testing. Thus hotfixes, whose updated files carry higher revision numbers than the matching files in the service pack (even though they can be released prior to the service pack), can 're-introduce' bugs that are reputedly fixed in the service pack. Because of the file-versioning, the hotfix-applied files will always supersede the service pack ones regardless of the order of installation of the hotfixes and service packs.
KB article Q299546 lists all hotfixes known to 'revert' any fixes that someone who has applied SP2 to Windows 2000 should expect to have corrected after applying SP2. Further, these hotfixes have all been re-built based on applying the hotfix code changes to the 'final' SP2 codebase, and these new 'final' versions of the hotfix patches are available from their respective download locations. That list covers all hotfixes, not just security ones. The second page linked below is a message from the NTBugtraq moderator who has worked through that (rather long!) list and extracted the list of security hotfixes affected by these patching issues. He lists them by Security Bulletin number. Depending on your administration duties, you may have to work through the complete list or just the security hotfix list and arrange to have the new versions of these hotfixes applied to your machines.
Microsoft assures us that no security patches were 'undone' in any of this...
MS to rate severity of security vulnerabilities
In response to customer pressure Microsoft has started assigning a risk rating to vulnerabilities described in its security bulletins. The intent is to help customers decide the urgency of applying each patch and the likelihood of being affected should they delay. Of course, such ratings are fairly subjective at the best of times and must simplify many real-world considerations that apply to individual machines. To understand the assumptions about 'typical systems' behind these risk ratings and the types of exposure that will receive Critical, Moderate and Low ratings, please read the article describing this initiative at Microsoft's security page.
Arbitrary file retrieval in Novell GroupWise
A Java servlet in the WebAccess component of the Novell GroupWise v5.5 Enhancement Pack and in Novell GroupWise v6.0 contains a directory traversal bug. This allows web users to retrieve arbitrary files located on the same volume as the web server, so long as their full name (including the path relative to the web server root) is known or can be guessed (despite Novell's TID downplaying this, finding certain critical files by informed guesswork is fairly easy for an attacker familiar with common system configurations).
Novell has released a replacement njweb.jar file to address this vulnerability and all administrators of GroupWise servers should update this component as soon as practicable. Note that although this is obviously a very pressing fix for Internet-facing web servers, GroupWise configuration files are exposed by this bug so even machines solely serving an intranet should be patched with some urgency. Further, if the web server is on the system volume, several potentially sensitive system configuration files may be exposed.
Local privilege escalation with setuid root apps in OS X
OS X continues to show that balancing system security concerns while retaining the high usability and functionality that the Macintosh experience is predicated on can be challenging. A few days ago a local root privilege escalation that is trivially simple to execute was publicly disclosed on several web sites and Mac mailing lists.
Any setuid root application that takes ownership of the menubar can probably be used for this exploit. The example that is being widely described is the following -- launch the Terminal application, exit it, launch the NetInfo Manager application, leave it in the foreground (so it still owns the menubar) then from the Recent Items entry on the Apple menu select Terminal. This newly started Terminal will be running as root. Aside from the Recent Items menu, at least the Services menu also launches applications under the owner of the menubar.
Apple is reputedly working on a fix. In the meantime a useful (though not complete) workaround has been suggested -- see the link to the archived bugtraq item below.
IE in OS X 10.1 defaults to execute downloaded software
Your newsletter compiler is never entirely astounded by the security stupidities he stumbles across and reports, though some come close. This is one such...
Ignore for a moment the sheer arrogance and contempt for any vaguely sensible design and the faintest of security concerns present in a web browser that would even offer the option of automatically executing downloaded software. Consider, instead, the what must have been going through the head of the product designer, project manager or whoever signed off on allowing OS X 10.1 to ship with that option enabled by default in Internet Explorer. It is mind bogglingly stupid almost beyond words (and certainly beyond words that can reasonably be 'printed' here).
Should you oversee any Macs installed with, or updated to, OS X 10.1 visit the KnowledgeBase article (linked below) for instructions on manually correcting this 'oversight'. (The Apple KnowledgeBase requires free registration.)
More wireless LAN woes...
Further to all the technical problems in WEP and other components of the 802.11b wireless networking standard discussed in the last year or so, another ugly possibility has just been realized. A previously esoteric network attack that was a theoretical possibility but technically very challenging (and often effectively impossible) to execute against an arbitrary target, is made a whole lot easier should that arbitrary target have a typical wireless access point installation
A security consultant at software risk management firm Cigital has announced the results of some of their research into the plausibility of 'old' attacks in light of the availability of some new technologies. ARP cache poisoning and redirection attacks have long been understood, but being 'man-in- the-middle' attacks require levels of network access that are typically difficult for an attacker to obtain. Now that attackers can sit in a vehicle in many corporate car parks and access a building's network through poorly configured wireless access points, such arcane attacks become almost easy.
'Don't publish code' call from Microsoft
Scott Culp, manager of the Microsoft Security Response Center, has voiced a plea to 'hackers' to act responsibly with the finer details of vulnerability exploits. Referring to the so-called practice of 'full disclosure' as 'information anarchy', he makes a case for more responsible handling of such information so 'cookbook cracks' for security holes are not made available for the modestly talented hackers to turn into actual attacks, worms, etc. The article is worth reading.