For a long time, NetWare administrators have been largely immune to the exploits and attacks that Windows administrators have had to face on a nearly daily basis. As Novell adds more Internet technologies to NetWare, though, new opportunities for attack arise.
A form of the overflow buffer attack, one of the most common attacks that has plagued Windows administrators, can now affect NetWare servers. I’ll explain how the exploit works and what you can do about it.
How buffer overflows affect NetWare
A buffer overflow vulnerability usually occurs due to sloppy programming. When a programmer creates a field to accept data from a user, normally the field is restricted to only accept a certain number of characters. If the programmer fails to include the proper checks in the input buffer for that field, a hacker can use the field as an attack point by flooding the input buffer with characters.
Such buffer flows can have one of two results. Normally, a buffer overflow causes the attacked server to crash. In the worst case, a buffer overflow can allow a hacker to actually execute programs on the attacked server. For more information about buffer overflows and other network attacks, see the Daily Drill Down “Understanding network intrusions and attacks.”
In March 2002, iXsecurity identified a buffer overflow condition in NetWare 5.1 and NetWare 6 that affected the NetWare Remote Manager. Novell posted a patch for the problem, which I’ll cover in detail below, in April 2002.
According to iXsecurity, this buffer overflow doesn’t appear to allow a hacker to run code on your NetWare server. It will cause your NetWare server to abend, which, while not as severe as allowing a hacker to run code, can still wreak havoc on your users.
The buffer overflow condition exists in HTTPSTK.NLM, the program that serves as the Web server for the NetWare 6 Remote Manager and the NetWare 5.1 Management Portal. The buffer will overflow and HTTPSTK.NLM will cause the server to abend when a user tries to log in to the Remote Manager under the following circumstances:
- A user enters 595 As.
- A user uses 626 characters for a username/password combination.
- A user enters more than 1565 characters, in which case the user’s browser will display a Document Contains No Data error message.
Instead of typing several hundred characters into your Web browser, you can see if your server is affected by this vulnerability by checking the file date of HTTPSTK.NLM. From your administration workstation, open the SYS:\System folder and find the HTTPSTK.NLM file. If the file is newer than April 3, 2002, you’re okay. If the file date for the NLM is prior to 4/3/2002, the program is vulnerable to the attack, and you have two choices to make. You can either remove the NetWare Remote Manager from your server, or you can obtain and install a patch to fix the vulnerability.
Removing the NetWare Remote Manager
If you’re not using the NetWare Remote Manager, also known as the NetWare Management Portal in NetWare 5.1, to administer your server, you don’t have to worry about the vulnerability. Be aware, though, that the NetWare Remote Manager might be loaded on your server as part of your server’s startup routine without you knowing it. To see if HTTPSTK.NLM is running on your server, go to the server’s console prompt, type modules httpstk.nlm, and press [Enter]. If the module is loaded, you’ll see the version of HTTPSTK that’s running on your server along with other information about the program. If the server returns another console prompt, the module isn’t loaded and you have nothing to worry about.
If the module is loaded and you don’t use the NetWare Remote Manager, you can unload HTTPSTK.NLM by typing unload httpstk at the server’s console prompt and pressing [Enter]. Doing so will unload the module until the next time you reboot your server. To prevent the module from reloading the next time you start your server, edit the AUTOEXEC.NCF file on your server.
You can edit AUTOEXEC.NCF using any text editor from your administration workstation. You’ll find AUTOEXEC.NCF in the SYS:\System folder. When you load the file into your text editor, search for the load httpstk line. Then, delete the line or place a number sign (#) in front of the line to comment it out. While you’re editing the file, look for the load portal line and comment or delete it out, as well. This command loads the portal, which won’t work unless you’ve also loaded HTTPSTK.NLM.
Obtaining and installing the HTTPSTK.NLM patch
If you do use the NetWare Remote Manager and the file date of HTTPSTK.NLM is prior to 4/3/2002, you should download and install Novell’s HTTPSTK patch. You can get it at Novell’s Support Web site. Click the httpstk1.exe link to download the patch. Download the file to a temporary directory on your administrative workstation. HTTPSTK1.EXE is only 240 KB long, so it won’t take very long to download.
If you’re running NetWare 5.1, Novell also recommends that you download and install Support Pack 3 or later for NetWare 5.1. You can install the patch on NetWare 6 without having previously installed Support Pack 1 for NetWare 6. For more information about the latest support packs for NetWare 5.1 and NetWare 6, see the Daily Drill Downs “Novell releases Support Pack 4 for NetWare 5.1” and “Support Pack 1 for NetWare 6 fixes problems, adds features.” Novell plans to include the HTTPSTK patch with NetWare 6 Support Pack 2 and NetWare 5.1 Support Pack 5, along with any future updates to both operating systems.
After you’ve downloaded HTTPSTK1.EXE, run the file to extract the files it contains. You’ll see two subdirectories appear: NW51 and NW6. As you can guess by the names of the subdirectories, the version of HTTPSTK.NLM you’ll need depends on the version of NetWare you’re running.
Although you can use NWConfig to install the patch, the fastest way to do it is from the command line of your administration workstation. Go to the SYS:\System folder on your server. Change the attributes of the old HTTPSTK.NLM file to Read/Write by typing flag httpstk.nlmrw and pressing [Enter]. Next, copy the appropriate version of HTTPSTK.NLM from your administrative workstation to the SYS:\System folder of your server, overwriting the old version. Reflag the file to Read Only by typing flag httpstk.nlm ro and pressing [Enter].
To make the change take effect, you have two options. The first and easiest is to reboot your server. When it restarts, the new version of HTTPSTK and NetWare Remote Manager will load.
The second method takes a little more work, but it will keep you from interrupting any users on your network because it doesn’t require a reboot. First, check your AUTOEXEC.NCF file for the command your server uses to load HTTPSTK, complete with any switches. For example, on our test server BRAIN, the load line for HTTPSTK reads:
load httpstk.nlm /SSL /keyfile:”SSL CertificateIP”
Make note of this command. Also, check and make note of any switches on the load PORTAL.NLM line.
At the console prompt of your server, unload both HTTPSTK.NLM and PORTAL.NLM. Type unload portal and press [Enter], then typeunload httpstkand press [Enter]. When you attempt to unload these NLMs, your server may complain that you also need to unload additional NLMs. Make note of the referenced NLMs and unload them, as well.
Next, type load httpstk.nlm, including the exact syntax you discovered in AUTOEXEC.NCF. Likewise, type load portal.nlm using the same syntax. Finally, load any of the additional NLMs that you had to unload.
Safe and sound
After all of the NLMs finish loading, you’re finished. You can type modules httpstk.nlm to verify that the NLM has reloaded properly. You’ll notice that the actual version number for the HTTPSTK hasn’t changed, but that the build date has. If the build date is 4/4/2002 or later, you don’t have to worry about the buffer overflow on your NetWare server any longer.