Critical Java Security Hotfix; a Group Policy Editor Problem; and Problems with Win2K Authentication and Kerberos

Critical Java Security Hotfix
Microsoft released a critical hotfix on September 18 that corrects three Java-based security problems. If you disable Java applets in Internet Explorer (IE), you can safely ignore this update. If you let Java applets run (as most users do), you need to install this hotfix on all systems on which you browse Web sites not under your control.

The hotfix eliminates two vulnerabilities that can let a malicious user take control of a machine that browses an attacker’s Web site. In one case, a flaw in how the Virtual Machine (VM) manages Java database functions provides an opportunity for a malicious user to run DLL files of the attackers choice on the local system. To be a target for this type of attack, you must browse a Web site that is under the attacker's control, or read an HTML-based email on a system that doesn't have the Microsoft Outlook Email Security Update installed. The hotfix also eliminates a related database flaw that lets an attacker provide invalid data to IE that can crash the browser and eliminates a vulnerability an attacker can exploit to take control of a local system by leveraging a flaw in how Java loads XML functions.

You need to install the hotfix on all systems for which the VM version number is 3805 or lower. To check the version, open a command prompt and type

jview 

The VM version number appears at the end of the first line of the command's output, which should be similar to "… Command-line Loader for Java Version 5.00.3805." You can install this hotfix from WindowsUpdate (http://v4.windowsupdate.microsoft.com/en/default.asp); the WindowsUpdate reference number is Q329077. See the Microsoft article "MS02-052: Flaw in Microsoft VM JDBC Classes Might Permit Code to Be Run" at http://support.microsoft.com/default.aspx?scid=kb;en-us;q329077.

SP3 Group Policy Editor Deletes Allowed Application List
A bug in Windows 2000 Service Pack 3 (SP3) causes the Group Policy Editor to incorrectly clear the list of allowed Windows applications. To reproduce this problem, open Group Policy in the Microsoft Management Console (MMC), expand Administrative Templates, click System and double-click "Run only allowed Windows Applications" in the right pane. Select the Setting tab, click Enabled, then click Show. If you accidentally enter a blank line in the list of allowed applications and click OK, the editor incorrectly deletes all entries on the list. Microsoft Product Support Services (PSS) has a new version of gptext.dll with a file release date of September 9 that solves this problem by preventing you from entering a blank line on the list. See the Microsoft article "List Is Cleared If You Accidentally Enter a Blank Line in the 'Run Only Allowed Windows Applications' Policy" at http://support.microsoft.com/default.aspx?scid=kb;en-us;q328786.

AD Access Violation
A problem in the Lightweight Directory Access Protocol (LDAP) code that enumerates Active Directory (AD) properties causes all versions of Win2K to generate an access violation when a program or service attempts to update AD. The Microsoft article "An Access Violation Occurs When a Program Tries to Update Active Directory" at http://support.microsoft.com/default.aspx?scid=kb;en-us;q328567 provides one example of an access violation that occurs in the component dsldp.dll, but I think this bug might generate access violations in other modules that programs and services call to update AD fields. Microsoft Product Support Services (PSS) has a fix that corrects the misbehaving code and updates 23 files; most of the updates have a file release date of September 24. This bug is present in all versions of Win2K, including Service Pack 3 (SP3).

Win32k.sys Blue Screen
For reference purposes, you should know that Microsoft admits that an undocumented bug causes Win2K SP3 systems to randomly crash with a stop code of 0x1E in win32k.sys. This bug is specific to SP3 systems and there is no fix available at this time.

Win2K Authentication and Kerberos Packets
If you install and configure firewalls, you need to know about Win2K authentication and Kerberos traffic on UDP port 88. We all encounter situations where a Win2K system unexpectedly logs on with cached credentials because the system can't contact a domain controller (DC). When this situation occurs, Netlogon records a message in the System Event Log with event ID 5719 and the text "No Windows NT or Windows 2000 Domain Controller is available for domain ... There are currently no logon servers available to service the logon request."

You can determine whether a machine logged on locally with cached credentials or authenticated with a DC (i.e., local versus network logon) by examining the value of the environment variable LOGONSERVER. Open a command prompt and type

echo %logonserver%

When a machine logs on locally, the variable is the name of the local system; when a machine logs on to a DC, logonserver is the name of the authenticating DC.

When a system logs on locally, it means the machine couldn't contact a DC. If the DC is online and functioning properly, incorrect or missing TCP/IP settings might be causing the problem. A machine that has no TCP/IP address or a missing or incorrect gateway address can't communicate with other systems on the network. If the machine’s settings are valid, but it still can't log on to the domain, check the firewall. If you configure the firewall to block all traffic until you explicitly grant permission to use a specific protocol/port pair, the firewall might be blocking Kerberos traffic on UDP port 88. You solve this problem by creating a firewall rule that permits UDP traffic on port 88 between all your systems.

For security purposes, you might want to minimize connectionless UDP traffic (i.e., packets not addressed to an established connection). By modifying a Kerberos parameter, you can force Kerberos to use TCP port 88, instead of UDP port 88. The Kerberos Request for Comments (RFC) states that Kerberos must send authentication data using UDP port 88 and can use TCP port 88 when the data in the message exceeds the maximum UDP packet size of 2000 bytes (the default). When you change the Kerberos maximum UDP packet size to a small number such as 1, the data will always exceed the UDP packet size, which forces Kerberos to always send packets using TCP port 88.

To adjust the UDP packet size, open a registry editor and navigate to the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsaKerberosParameters subkey. You'll need to create the Parameters subkey if it isn't already present. Add a value called MaxPacketSize to the Parameters sub key. For example, to force Kerberos to always use TCP port 88, set the maximum packet size to one by adding the value MaxPacketSize: REG_DWORD:1.

To implement this authentication change, you must modify the Kerberos UDP packet size in the registry on all Win2K systems on your network. If you have only a few systems, you can implement the change with a registry script. If you have more than a handful of machines, making the modification is faster and easier with an Administrative Template and a Group Policy Object (GPO). The Microsoft article "Forcing Kerberos to Use TCP Rather Than UDP in Windows 2000," at http://support.microsoft.com/default.aspx?scid=kb;en-us;q244474, contains a sample Administrative Template, with which you can use a GPO to implement this modification.