Security Audit Records Might Be Lost
A recently discovered bug in the Event Log service has potentially serious consequences for sites that implement security auditing. According to Microsoft, the service incorrectly reports that the event log is full before the maximum log file size is reached; the system simply stops writing new records when you enable the "Do not overwrite events" option, and the event log reaches a size of 200MB to 600MB (even when you define a log file size greater than this range). If you also enable the option to shut down the system when the event log is full, this bug causes a system to shut down sooner than expected. Although missing events in the application log might not pose a serious problem, lost events in the security log mean you might not immediately learn about logon failures, account management changes, and other crucial security events.
You can install a new version of the Event Log service that automatically creates a backup of each event log when the log is full and the service can't overwrite existing records. You implement the automatic backup feature by manually adding registry values for each log file. When the service determines the log is full, it copies the log contents to a backup file named for the type of log (e.g., system, security, application) plus the time and date and clears the primary file to allow posting of new events. You’ll find directions for the registry keys and values you need to add in the Microsoft article "The Event Log Stops Logging Events Before Reaching the Maximum Log Size" at http://support.microsoft.com/default.aspx?scid=kb;en-us;q312571. Because of the potential consequences of lost security audit records, I recommend you call Microsoft Product Support Services (PSS) and ask for the new version of eventlog.dll with a file release date of May 2. Windows 2000 Service Pack 3 (SP3) won't include this patch.
Security Hotfix Closes Privilege Elevation Vulnerability
A recent security hotfix addresses a serious vulnerability in how the Windows debugger authenticates access on Windows NT, Windows NT Terminal Server Edition, and Win2K systems. The debugger provides services that programs can access for diagnostic information when they encounter unexpected conditions. One of these services lets a program connect to and take full control of any running program, opening the door for a malicious user to run other code in the security context of the program that this user now controls.
The vulnerability lets an interactive user gain unrestricted access to any valid user account, including administrator and system accounts. You can read a complete description of the risk factors associated with this vulnerability in the Security Bulletin MS02-024 "Authentication Flaw in Windows Debugger Can Lead to Elevated Privileges" at http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/bulletin/MS02-024.asp. The hotfix Q320206 contains a new version of smss.exe with a file release date of April 29. To eliminate the exposure, you need to install the hotfix on every system in your enterprise.
You must reboot after you install the hotfix to ensure the system starts with the patched files. This hotfix emerged after the SP3 cutoff, so you’ll need to keep it on the regular reinstall list. Sigh.
Download for Windows 2000:
http://www.microsoft.com/windows2000/downloads/security/q320206/default.asp
Download for Windows NT:
http://www.microsoft.com/ntserver/terminalserver/downloads/security/q320206/default.asp
Password Complexity Loophole
Many sites enable the Group Policy password option "Password must meet complexity requirements" to force users to choose more secure passwords. When you enable this policy, passwords must be at least six characters long, must not contain part of the account or user’s proper name, and must contain a combination of numeric, alphabetic, and punctuation or non-printing characters.
However, a loophole in this policy shows up when you use the Add User Wizard to create a new user. The wizard will generate a password for the new user but doesn't enforce the password complexity Group Policy. To ensure all passwords conform to the complexity requirements, you must check the Add User Wizard option "I will specify user’s password," and enter a password that meets the above criteria. The same loophole exists when an Administrator changes a user’s password manually. In both situations, the system accepts the password even when it doesn't follow the complexity rules. See the Microsoft article "Password Is Not Compliant with the System Password Complexity Policy" at http://support.microsoft.com/default.aspx?scid=kb;en-us;q279890.
Bogus Disk Defrag Error
When the Windows 2000 defrag utility can't move a cluster of data during it’s disk optimization procedure, the utility logs an error in the System Event log with event ID 55, a source of NTFS, and the message "The file system structure on the disk is corrupt and unusable. Please run the chkdsk utility ...." The defrag utility then schedules Chkdsk to run at the next opportunity. When Chkdsk runs, it uncovers no errors, so you think the volume is fine, but the next time you run the defrag utility, you’ll see the same error in the System Event log.
The Microsoft article "Chkdsk.exe Is Scheduled After You Run Disk Defragmenter on Your NTFS Partition" at http://support.microsoft.com/default.aspx?scid=kb;en-us;q320866 states that the defrag errors are a false positive for corrupt data and that you can safely ignore these event ID 55 messages. Because this bug produces an endless cycle of defrag errors and clean chkdsk runs, it can be quite annoying. The reference article offers several workarounds. I take exception to Microsoft’s first recommendation, which is to upgrade to Windows XP. If you’re not interested in upgrading to XP, you might be able to eliminate the problem if you backup the disk where the error occurs, reformat the disk, and restore the backup.
