Should we call it Sabotage Pack 5?

Allegedly, Microsoft extensively tests new patches before it ships a service pack. And, new service packs are supposed to improve things, right? If you apply those criteria to Service Pack 5 (SP5), you might wonder whether SP stands for Sabotage Pack. Regarding RAS, RRAS, and DUN, SP5 seems to break as much as it fixes.

Let's quickly recap why, from a RAS perspective, you might decide to install SP5. The following list outlines the major SP4 bugs that SP5 promises to fix:

  • You receive a Dr. Watson visit when you use a shortcut to launch DUN.
  • A handle leak occurs when applications use the RasDial API (i.e., the process token handles open but never close).
  • The RAS Connection Manager causes rasman.exe access-violation errors as a result of long command lines.
  • Unattended RRAS setup fails.
  • You experience access-violation errors when you add demand-dial interfaces in the RRAS administrator tool.
  • RRAS connections time out on slow links.
  • RRAS stops responding to calls under heavy loads and fails to work when you set the number of rings to 0.

Considering this fairly scary-sounding list of bugs, SP5 seems like a good idea to most NT RAS administrators. After all, can SP5 really make things any worse? Unfortunately, SP5 introduces brand-new problems. The following quick tour details the most notable SP5 RAS problems. (You can find most post-SP5 hotfixes at ftp://ftp.microsoft.com/bussys/winnt/ winnt- public/fixes/usa/nt40/hotfixes-postsp5.)

Malformed phonebook entry security problem. Intentionally malformed DUN phonebook entries can cause buffer overruns, which attackers can use to exploit a security vulnerability on RAS clients. This bug exposes a security vulnerability that lets an intruder run applications to gain escalated security privileges and launch Denial of Service (DoS) attacks on a RAS client. To resolve this problem, which Microsoft outlines in "Malformed Phonebook Entry Security Vulnerability in RAS Client" (http://support.microsoft.com/ support/kb/ articles/q230/6/77.asp), install the RAS-fix hotfix.

DUN passwords erroneously cached with RAS. You're probably familiar with the RAS/DUN dialog box that pops up when you establish a connection to a remote system. This dialog box includes a Save password check box that tells the system to cache a password for a connection. However, after you install SP5, the Save password feature functions differently. Regardless of whether you select the Save password check box, RAS caches your password in the Registry. This bug can lead to unauthorized parties discovering your password and making unauthorized connections to remote networks. Microsoft details this problem in "DUN Credentials Cached When Save Password Not Selected with RAS" (http://support.microsoft.com/ support/kb/articles/q230/6/81.asp). To solve this problem, use the RASPassworddialer-fix hotfix.

DUN passwords erroneously cached with RRAS. This bug is identical to the RAS password-caching problem, except that this problem affects RRAS. You can read more about this problem in the Microsoft article "DUN Credentials Cached When Save Password Not Selected with RRAS" (http://support.microsoft.com/ support/kb/articles/q233/3/03.asp), and you can find the RRASPassword-fix hotfix at ftp://ftp.microsoft.com.

The bugs I've listed are only the major bugs that users have unearthed so far. Since Microsoft released SP5, a new bug—followed by a corresponding hotfix—appears almost daily. If you're considering installing the SP5 workarounds or any hotfixes, remember to first test the fixes in a nonproduction environment and remember Microsoft's disclaimer about hotfixes: "A supported fix that corrects this problem is now available but it has not been fully regression tested and should be applied only to systems experiencing this specific problem."

SP6 will be available by the time you read this column. However, don't set your expectations too high—Microsoft has already posted a post-SP6 hotfix to fix a major RAS-related security hole even though SP6 isn't available yet. Given my experiences with SP4 and SP5, I think I'll perform my own regression testing before I deploy SP6 on any of my mission-critical servers.