It has been another very slow week. There have been many, small Unix-related patches, but few major ones and a fix for serious LDAP over SSL permissions escalation bug in Windows 2000. There has been nothing of real newsworthiness on the virus front at all, as the only virus-related item I have included indicates...
Not so 'Jolin' virus
Several antivirus vendors have posted alerts/warnings/descriptions of a virus variously being called VBS/Jolin and VBS/Niloj ('Jolin' in reverse). This reputed mass-mailing, mIRC script-spreading virus is, in fact, so buggy that it cannot evenb run -- it throws fatal VBS compiler errors when attempting invocation and bombs unceremoniously. As this is completely obvious from less than ten seconds 'testing' of the 'suspect' VBS file, your newsletter compiler is left wondering why some of the giants of the antivirus development world missed this rather significant factor. Perhaps they were feeling the pinch of the slow week too?
Patch for LDAP over SSL on Windows 2000 server
Microsoft has released an important patch for any Windows 2000 servers that run LDAP over SSL, or that may enable LDAP over SSL in the future. The function that allows password changing via LDAP services is only available to LDAP over SSL connections. This is not the default LDAP configuration. However, that function has a flaw, such that it does not check that the connected user is authorized to change the password of the user the password change is requested for. An attacker with access to an LDAP over SSL server would thus be able to alter domain passwords of any user, including the domain administrator.
Links to patches for this vulnerability for Windows 2000 Server and Advanced Server are available from the Microsoft security bulletin linked below.
Several popular Linux/Unix packages updated
samba, xinetd, fetchmail, webmin, ispell, xvt and other packages commonly shipped with or installed atop popular Linux/Unix systems have been found to have various exploitable format string or buffer overflow vulnerabilities recently. Several of these allow remote and/or local root compromises -- as always, you should be checking with your vendors or package developers to keep up with such security issues.
Is a screen saver a security component?
Many Windows system admininstrators are pressured to allow their users to install new screen savers. Presumably partially because it allows employees to express their individuality through personal tastes, and perhaps because it also allows an 'acceptable' deviation from the tedium of the 'everything is the same grey' aspects of large corporate LAN installations, this pressure is often bowed to. Ignoring the darker side of deliberately malicious screen savers, which are, afterall, just standard Windows executable programs, whose installation and execution carry all the same risks of potential virus and Trojan infection, a recent incident shows a more 'benign' cause for concern in allowing staff who are not security professionals to install and configure their own choice of software.
It has been reported that installing the popular 'Living Waterfalls' screen saver, made by Rhode Island Soft Systems but distributed through many click- through links around the web, opens a serious security hole on your PC. The 'free' version of the screen saver pops open a web browser when the spacebar is pressed, opening a page on Rhode Island Soft's web site allowing you to register the screen saver and download the full version (which has more animations and scenes). This occurs
independently of the screen saver 'password protection' option and thus bypasses the security offerred by the 'locked screen saver' option. With the web browser window open the user (who could be anyone -- not just the authorized user of the machine) can easily browse the contents of the local hard drive and if on an NT/Windows 2000 system, they do so with the permissions of the currently logged in user.
Hopefully a security aware system administrator would notice such a grievous security hole in testing a new screen saver, but it is unlikely that 'typical users' (and that includes most of your corporate 'power user' type under NT/Windows 2000!) would notice, ao at least would care.