Code Red, SirCam, important Windows and Media Player patches

Beware Parrots bearing screensavers; SirCam leaks more official documents; It's funny, but only because it wasn't your network; Code Red rides again...; plus more patches

Sorry -- today's introduction will be very rushed as I am writing it as I run for a plane in Chicago. All Windows NT and/or 2000 administrators should pay special attention to the Windows updates this week, especially the Windows Media Player one. The virus news is mainly 'more of the same' from last week, with Code Red and SirCam dominating the headlines. Allaire and ZoneAlarm Pro users should check the appropriate items in the security section too. See you all again -- and hopefully less rushed -- next week (probably from Dallas).

Virus News

Beware Parrots bearing screensavers

A new virus that also mass-mails itself has been reporetd from a few sites in the wild. Officially known as Win32/Crackly, but likely to be referred to as Parrot, this virus will typically arrive via e-mail as an attachment called PARROT.SCR and if run it creates and plays an MP3 file with a coarse message referring to a well-known figure in the antivirus industry. It also displays Windows dialog boxes with the text of the audio message and can spread via IRC if the popular mIRC IRC client is installed on a victim's machine.

Various antivirus vendor descriptions: ca.com, vil.nai.com, sophos.com

SirCam leaks more official documents

Last week we reporetd the FBI unintentionally 'leaking' documents marked as 'official use only' due to a NIPC staffer running the SirCam e-mail worm on an office machine, rather than on an isolated test machine. Reuters is now reporting a similar incident is claimed to have seen secret documents from the administration of Ukraine's President Leonid Kuchma being distributed to people outside the administration.

Website Says Virus Leaked Ukrainian Secret Documents - Reuters.com

It's funny, but only because it wasn't your network

An amusing to behold, retold, story about hapless system administration, curious (albeit 'typical') users and a mass mailing virus is recounted at the link below. Your newsletter compiler is sure something can be learned from this...

It's baaaaaack.... - Computerworld.com

Code Red rides again...

Despite predictions of imminent Internet meltdown, Code Red has not ended the Internet as we know it. In fact, on balance, Code Red looks like just another 'virus hype', but please note that it was not the antivirus companies doing the hyping this time. Of course, some will say that the fact the rebirth of Code Red has such relatively minor impact is indicative of the effectiveness of the warnings raised by the media and related coverage of the story.

Some of the experts making such soothing sounds seem to be speaking with forked tongues and/or to protect their own vested interests. For example, many of them are also the 'experts' who, just a few short days ago, were incorrectly warning us that come 1 August, all the instances of Code Red laying dormant in machines that had not yet been cleared of the initial 300,000-plus infestations of the worm from its initial bloom (ending midnight 19/20 July when the worm switched from its 'spread like crazy' mode to its 'DoS www1.whitehouse.org' mode) would spontaneously re-awaken and all revert to 'spread like crazy' mode. All the technical experts known to your newsletter compiler agreed that Code Red simply did not work that way. They could imagine laboratory test scenarios where that could happen, but these scenarios just did not map onto the real-world Internet environment where Code Red was actually of concern.

With the advantage of hindsight, we can easily see from the statistics claiming to monitor the 're-emergence' of Code Red that there was not a huge, initial outburst of Code Red activity come midnight on 1 August UTC. What that means is that either virtually all of those 300,000-plus IIS servers infested with Code Red during the initial outbreak around 12-19 July were cleared of the worm, or those 'experts' were wrong about it being able to spontaneously re-awaken.

This healthy cynicism does not mean that Code Red is not something to be concerned about. As this is being written the ongoing monitoring of Code Red suggests that in the first day of its 're-awakening' it compromised about 85-90% of the number of machines that it compromised on the last day of its initial spread before switching into its 'DoS www1.whitehouse.org' mode. That also is not good news. Worse, it raises valid questions about whether the optimism expressed in the 'we seem to have got the word out to reduce the scale of the problem' message is at all well-founded. Spreading at 85-90% of what it did ten days ago may well be within the natural spread for such a worm, meaning that virtually nothing has changed. If that really is the case, it seems a lot of self-congratulatory words have been expended by and on 'experts' who effectively achieved little, if anything.

Code Red statistics/comment/analysis/hype:

http://www.digitalisland.net/codered/

http://www.incidents.org/

Security News

Patches for multiple Windows services

Errors handling Remote Procedure Call (RPC) requests in many system services in NT 4.0 and Windows 2000, and in Exchange and SQL server products have been discovered and patches released to remedy them. If exploited in an attack against a vulnerable machine, these errors have varying effects, from temporarily slowing or blocking access to an affected service through total service failure requiring a system restart.

Products tested by Microsoft and confirmed affected are Exchange 5.5 and 2000, SQL Server 7.0 and 2000, NT 4.0 and Windows 2000. Earlier versions of these products are no longer supported my Microsoft, so were not tested, but it seems reasonable to assume they are. Upgrading or judicious firewalling of such machines from public networks seem to be the options available to aministrators of such systems.

- Microsoft security bulletin

Another Windows Media Player update

Windows Media Player 6.4, 7.0 and 7.1 have been found to contain exploitable buffer overflows in their handling of Windows Media Station files. These files are effectively 'playlists' of streaming media content and have the extension .NSC (they were originally called NetShow Channel files in NetShow 2.0). This buffer overflow potentially allows attackers to run any code of their choice on machines whose users are enticed into accepting the attacker's maliciously crafted .NSC files.

In case the garvity of that is not apparent, this is precisely the type of flaw that the recent Code Red worm exploited -- a remote buffer overflow that allows aribitrary code to be run on the victim machine. Having said that, Code Red had a leg up in that the process it overflows normally runs in the local system security context, giving the worm full access to the resources of the victim machine. This Media Player overflow 'only' gives the attacker the privileges of the user running the Media Player application. (Note to system administrators -- consider setting permissions on Windows Media Player so it cannot be run by any users with elevated permissions and audit this is not changed...)

Patches have been released for Media Player 6.4 and 7.1. Users of Media player 7.0 should upgrade to Media player 7.1 then apply the patch for that version.

- Microsoft security bulletin

More on MS01-035 patch

Five weeks back we reported on a patch for Microsoft Visual Studio RAD Support in FrontPage Server Extensions, described in Microsoft security bulletin MS01-035. Microsoft recently removed the patch because of an unspecified 'issue' and is planning on re-issuing the bulletin when a fixed patch is available. In announcing this, Microsoft's Security Program Manager Christopher Budd also felt it necessary to warn users again that they should not be implementing Microsoft Visual Studio RAD Support in FrontPage Server Extensions on production machines. To quote him:

In the meantime, it's worth reiterating a couple of important points from the bulletin. The piece of software that contains the vulnerability, known as the Visual Interdev RAD (Remote Application Deployment) Support sub-component, is not installed by default. Further, if the administrator does select it for installation, a dialogue box is displayed pointing out that the sub-component is not appropriate for use on production systems and should only be installed on development systems.

As the bulletin discusses, Microsoft doesn't recommend applying the patch to production systems. Instead, we recommend that the sub-component, if installed, be removed immediately. The patch should only be applied to development systems, and even then on ones that require Visual Interdev RAD support. Of course, standard best practices call for development to be performed on protected machines; it's never recommended to connect a development machine to the Internet.

- Budd's post in bugtraq archive

- Microsoft security bulletin

NT 4.0 security rollup in lieu of SP7

Microsoft has dropped plans to release Service Pack 7 for NT 4.0, but has released a 'security rollup package' (SRP) instead. The SRP contains all post-SP6a security-related patches and updates, including those for IIS. Details can be found in the Microsoft Security and KnowledgeBase articles linked below:

Microsoft NT security rollup links: support.microsoft.com, Microsoft Technet

ColdFusion and JRun patches from Allaire

Users of these Allaire products should check the recent security bulletins for these products at the Allaire security site, linked below. Several denial of service and other security issues have been noted and patches provided. The Allaire security site not only carries bulletins relating directly to Allaire products, but also has security bulletins and advisories for related products or are likely to be relevant to Allaire users. For Allaire-specific issues, check for bulletins with names starting 'MPSB'.

- Allaire security site

Flaw in ZoneAlarm Pro's MailSafe

ZoneAlarm Pro offers a feature, known as MailSafe, that renames 'dangerous' e-mail attachments by altering their filenames to have 'odd' extensions, associated with the ZoneAlarm application. Thus, if a user attempts to open such an extension,. a warning can be dispalyed by ZoneAlarm, preventing the possible disaster of running an unwanted or unknown program. It has been reported that MailSafe fails to rename attachments with extensions on its 'dangerous' list if the filename of an attachment is very long. This problem is said to affect ZoneAlarm Pro v2.6.84 and earlier.

- SecuriTeam advisory

Join the newsletter!

Error: Please check your email address.

More about AllaireFBIMicrosoftNIPCNSC GroupParrotReuters Australia

Show Comments
[]