---------------------------------------------------------------------------

Section 08

Netware and Windows 95

---------------------------------------------------------------------------

08-1. Will Windows 95 cause server problems for Netware?

By default Windows 95 shipped with long file names (LFN) and Packet Burst
enabled, which created a unique problem -- if the server didn't have long
name space loaded (OS/2 name space) it caused problems with files and
occassionally crashed the server. But the worse one was Packet Burst. 
Unless you had at least a 3.11 server with the PBURST.NLM up and running,
along with drivers for the server's network capable of handling Packet
Burst, the buffer space used for network connections and/or the buffer
space on the network card created problems ranging from lockups to
timeouts to abends.

There were a couple of different fixes you could do, like updating the
server for long name space and Packet Burst (sorry Netware 2.x users), or
you could update the clients' SYSTEM.INI file with the following entries:

        [nwredir]
        SupportBurst=0
        SupportLFN=0

Alternately, a frame type (802.3) that doesn't support Packet Burst could
be used, and you could enforce no LFNs via system policies. 

---------------------------------------------------------------------------

08-2. Will Windows 95 cause network problems for Netware?

If File & Print Sharing for Netware is configured and you have non-Windows
95 users, there could be serious network problems. How does this happen? 
Here is a very simplified explanation -

The way Netware advertises its file and print services is via Netware's
proprietary (but widely documented) Service Advertising Protocol (SAP).
How to get to these resources is communicated via Routing Information
Protocol (RIP) packets. Both SAP and RIP info are transmitted broadcast
style. Netware servers and even intelligent networking equipment that
conform to the SAP and RIP protocol scheme (like routers) share this info
dynamically between each other.

The problem is when Windows 95 is set up with File & Print Sharing for
Netware, because the Windows 95 workstation does a lousy job of
implementing and interacting with the SAP and RIP info. As any LAN/WAN
specialist will tell you, extra SAPs can quickly waste bandwidth, 
causing timeouts and broadcast storms. And that is exactly what Windows 
95 does. Netware 3.x and 4.x have released patches, but the easiest thing
to do is simply NOT use File & Print Sharing under Windows 95 -- use
Netware's file and print services like they're supposed to be used, or 
use Client/FPS for Microsoft networks instead.

Can hackers take advantage of this? Here's the theory how -

- Turn on File & Print Sharing for Netware in Windows 95.

- On an SLIST the Windows 95 workstation will show up.

- In a Netware 3.x and 4.x environment, there is an internal network 
number and an external number. Windows 95 will only show an external
number, and since these numbers help determine how many hops away the
service is, not having an internal one means (depending on your network
layout) your Windows 95 workstation is one hop closer.

- When a regular user boots up, the user needs to get to the nearest
server to find his prefered server's location from the nearest server's
SAP and RIP tables. Routers typically will simply pass on the name and 
address of the closest server attached to it. This with the hop counts
will lead to a lot of attachments to the Winodws 95 server. Therfore even
a PREFERED SERVER variable in the NET.CFG would not help.

- To keep clients from timing out with an error, Microsoft passes the
user onto the prefered server IF the Windows 95 server is set up with the
same name.

- In theory could create a \LOGIN directory and run your own LOGIN.EXE 
that grabbed the password and then send the client onto it's real server.

What could prevent this? Well, in a WAN environment a router could be
configured to only allow SAPs to come from certain segments, or every one
of the workstations are running Windows 95 (which is probably Microsoft's
solution). And even though I have heard from a dozen people stating that
this could be done, no one has said they've done it (the alternate LOGIN
directory and trojan LOGIN.EXE).

---------------------------------------------------------------------------

08-3. What's with Windows 95 and Netware passwords?

Windows 95 has its own password file, and uses this file to store
passwords to Windows 95 itself as well as Netware and NT servers. The 
problem here is that the PWL file is easily cracked by brute force, by
using exploit code readily available on the Internet. To keep this from
happening either Service Pack 1 should be applied (see Microsoft) or 
disable password caching.

---------------------------------------------------------------------------

08-4. Can Windows 95 bypass NetWare user security?

I am unsure as to the conditions (if anyone knows, please forward me the
info) but if your .PWL file is around 900 bytes versus 600 bytes, your
workstation will log in without prompting you for a password. This bug was
working as of December 1995, and I would think at this point patched via
the latest service pack.

Two ways this can be abused -- on some systems generating the longer file
you can simply make sure you generate a .PWL file with the target account
name and reboot using that .PWL file.

The other way is to simply collect the .PWL file from an unattended
workstation and boot using it (or attack it using the exploit code
referenced in Section 08-3.

---------------------------------------------------------------------------
