Bugtraq mailing list archives

Re: Windows95,


From: Gilles.Soulet () cst cnes fr (Gilles Soulet)
Date: Fri, 10 Jan 1997 11:49:32 +0100


The strange observation (observed using both ethload in dos, and
trafshow on linux) is that when the machine being called tries to
"call back" it causes a mini ICMP broadcast storm. Some clients try
to connect back via ICMPs with a return address of the 192.168
network.


I wasn't able to reproduce such behavior on a my 95 box with two network
interfaces (one class C, one subneted class B). Here are a few questions
and tips that could help us to understand why things go wrong :

1) Verifying consistency of class B interface, regarding subneting and
   gateway. If you use two "true" network interfaces, verify that you
   don't have a remaining Ethernet PPP Adapter that could cause pbs.
   IP address and netmask should be 0.0.0.0 (as given by ipconfig).

2) Dumping routing table. Win95 accepts multiple default routes entries
   (0.0.0.0) but uses only ONE entry (the last entry in the table). The
   order in the table seems to be defined by net cards detection
   considerations, and might be modified by dynamic insertion/removal of
   interfaces and Plug-and-Pray. I already noticed that my 95 box sent
   defaults routed IP dgram via the "wrong" interface (but never noticed
   any ICMP storm).


A machine that has an interface  connection on network A (using the
192.168.x.y ron routable range), and a connection on network B
(standard class C address, world routable). Windows 95 NOT set to
route (ie, the registry item not modified).

Regarding IP routing :

Standard Win 95 TCP/IP stack never routes packets, as it's said in the
MSDK (see below). Setting EnableRouting to "1" just crashed my system !
Could anybody confirm this ?

Anyway, this might be not relevant, since the Microsoft concept
of "Routing" on the former MS TCP/IP 32 stack from Windows for Workgroups
was related to RIP (that is, enabling Routing on the advanced TCP/IP
configuration on WfW just activates use of RIP protocol for the interface,
as the Mickeysoft documentation says).

I verified this using two networks (A and B) connected to the 95 box, and
trying to go from one to the other by declaring Win95 A and B interfaces
as default gateways for machines on A and B segments (and defining adapted
routing table).

The only thing you can do is to ping Win 95 A interface from a machine
on B, since the 95 box detects that A is a local interface, and responds
through B, with a correct datagram and frame sent to sender on B. This is
not routing. If you ping both Win95 interfaces from (say) B, with RECORD ROUTE
option on, you'll notice that there is exactly the same records number.

Futher experiments with Loose and Strict Source Routing (trying to define
a route from net A to net B passing through the Win 95 interfaces) never
permited me to obtain any IP trafic between A and B : Win 95 refuses to
forward source routed datagrams (as it refuses to take into account
any ICMP redirect message).

I also tried to act on the MIB, modifying such variables as ip.ipForwarding
and ip.ipForwDatagrams, but it failed. Does anybody knows if the MIB
is really connected to the registry or the kernel ? Does anybody ever
succeeded modifying the Win 95 MIB via SNMP ?

Muti-homed PC are getting more and more important as a true security
problem, especially if one network interface is a Modem connected
to the Internet via an IP provider, and the other interface is connected
to internal (and supposed secure) networks. Direct IP routing is not
possible with standard Win95 TCP/IP stack, but this is not true for
NT or other public domain stacks (like CORE Winsocks). As noticed by
Sami, even if this not a Unix problem, this is an important security
issue that we should discuss there, especially if someone discover
a serious bug !

  ~Gillus

----8<----   Extract from MSDK follows  ----8<----

CAUSE
=====

This error can occur if IP routing is enabled. IP routing is not a
supported feature of Windows 95.

RESOLUTION
==========


NOTE: For information about how to edit the registry, view the Changing
Keys And Values online Help topic in Registry Editor (Regedit.exe). Note
that you should make a backup copy of the registry files (System.dat and
User.dat) before you edit the registry.

WARNING: Using Registry Editor incorrectly can cause serious problems
that may require you to reinstall Windows 95. Microsoft cannot guarantee
that problems resulting from the incorrect use of Registry Editor can be
solved. Use Registry Editor at your own risk.

Use Registry Editor to remove the EnableRouting value from the following
registry key:

   HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP

Also, remove the "EnableRouting=1" entry if it is present in the [MSTCP]
section of the System.ini file.

MORE INFORMATION
================

This problem is likely to occur if you upgraded a Microsoft Windows for
Workgroups-based computer using the Microsoft TCP/IP-32 protocol with IP
routing enabled to Windows 95. In this situation, the "EnableRouting=1"
entry is present in the System.ini file and is copied to the registry
during the upgrade process.

IP routing is not enabled by default in Windows 95, and can be enabled
only by adding the unsupported EnableRouting value to the registry.

KBCategory: kbnetwork kbpolicy kberrmsg
KBSubcategory: win95
Additional reference words: 95
=============================================================================
Copyright Microsoft Corporation 1996.



Current thread: