Search...

nt.token.ring.DoS.txt

1999-08-17T00:00:00

ID PACKETSTORM:15254
Type packetstorm
Reporter Packet Storm
Modified 1999-08-17T00:00:00

Description

                                            `Date: Fri, 2 Oct 1998 01:04:20 -0500  
From: Simple Nomad &lt;thegnome@NMRC.ORG&gt;  
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM  
Subject: NMRC Advisory - Lame NT Token Ring DoS  

_______________________________________________________________________________  

Nomad Mobile Research Centre  
A D V I S O R Y  
www.nmrc.org  
Simple Nomad [thegnome@nmrc.org]  
30Sep1998  
_______________________________________________________________________________  

Platform : Windows NT  
Application : TCP/IP  
Severity : Medium  

Synopsis  
--------  

On Token Ring networks a packet with bad data in the RIF fields will cause  
all Windows NT workstations and servers on the ring to crash with a blue  
screen of death.  

Tested configuration  
--------------------  

The default settings were tested with the following configuration :  

Microsoft Windows NT Server and Workstation v4.0  
Service Pack 3  
Most SP3 Hot Fixes  

Bug(s) report  
-------------  

When a Token Ring frame passes through a bridge, the bridge will update  
the Routing Information Field (RIF) with its ID number, among other little  
bits of information (including info that limits the size of the data  
field). This information is used to help route traffic back and forth  
between rings connected by bridges.  

On Token Ring if you have a hop count greater than 7 defined in the RIF  
fields this will cause Windows NT's TCP/IP stack to "blue screen", forcing  
the user to reboot. Also if there are duplicate Token Ring IDs listed in  
the hops this will also "blue screen" NT. The bad news is that the packet  
does not have to be addressed to the NT target to blue screen it. It will  
blue screen every NT workstation or server on the ring. The good news is  
that properly configured and functioning network equipment will not pass  
this type of illegal packet across a hop to a different ring, so the  
Denial of Service will be limited to one ring.  

It is possible that some routers will allow RIF fields to have more than 7  
hops, but unless they have been configured to handle this it will not pass  
the packet across a hop as it is considered a bad frame. It should be  
noted that in all related RFCs it is clearly stated that &gt;7 is a no-no and  
should not be done.  

Malfunctioning network equipment could cause this to happen, as this is  
how the information was originally discovered.  

There was no related/discovered Netbios flaws, in particular if  
encapsulation was being used to cross WAN links.  

Solution/Workaround  
-------------------  

Move to Ethernet, or contact Microsoft for the RIF Hot Fix, which was not  
posted last time I looked. I'll assume the latter would be easier.  

Comments  
--------  

This is rather lame, but since I personally know of 2 Token Ring sites  
that this affected in my town alone, I thought I might pass it on.  

When Microsoft was contacted 4 weeks ago they reported that more than one  
corporate customer had reported the problem, and they had a hot fix they  
were testing. Most sites are on Ethernet, and most elite sploit code talks  
Ethernet frames anyway, so my guess is you'll have to ask for it. On a  
personal note, it is a lot of fun to watch a row of NT machines all die  
one after another, making for a very visual test of packet speed.  

Thanks to Mike for letting me know about this, and thanks to a small  
unnamed Dallas accounting firm that graciously let me test this on their  
networks after hours. They were convinced they were under outside attack,  
but a malfunctioning bridge was the culprit.  

_______________________________________________________________________________  

`

JSON Vulners Source

Initial Source

{"id": "PACKETSTORM:15254", "type": "packetstorm", "bulletinFamily": "exploit", "title": "nt.token.ring.DoS.txt", "description": "", "published": "1999-08-17T00:00:00", "modified": "1999-08-17T00:00:00", "cvss": {"vector": "NONE", "score": 0.0}, "href": "https://packetstormsecurity.com/files/15254/nt.token.ring.DoS.txt.html", "reporter": "Packet Storm", "references": [], "cvelist": [], "lastseen": "2016-11-03T10:23:07", "viewCount": 1, "enchantments": {"score": {"value": -0.4, "vector": "NONE", "modified": "2016-11-03T10:23:07", "rev": 2}, "dependencies": {"references": [], "modified": "2016-11-03T10:23:07", "rev": 2}, "vulnersScore": -0.4}, "sourceHref": "https://packetstormsecurity.com/files/download/15254/nt.token.ring.DoS.txt", "sourceData": "`Date: Fri, 2 Oct 1998 01:04:20 -0500 \nFrom: Simple Nomad <thegnome@NMRC.ORG> \nTo: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM \nSubject: NMRC Advisory - Lame NT Token Ring DoS \n \n_______________________________________________________________________________ \n \nNomad Mobile Research Centre \nA D V I S O R Y \nwww.nmrc.org \nSimple Nomad [thegnome@nmrc.org] \n30Sep1998 \n_______________________________________________________________________________ \n \nPlatform : Windows NT \nApplication : TCP/IP \nSeverity : Medium \n \n \nSynopsis \n-------- \n \nOn Token Ring networks a packet with bad data in the RIF fields will cause \nall Windows NT workstations and servers on the ring to crash with a blue \nscreen of death. \n \nTested configuration \n-------------------- \n \nThe default settings were tested with the following configuration : \n \nMicrosoft Windows NT Server and Workstation v4.0 \nService Pack 3 \nMost SP3 Hot Fixes \n \nBug(s) report \n------------- \n \nWhen a Token Ring frame passes through a bridge, the bridge will update \nthe Routing Information Field (RIF) with its ID number, among other little \nbits of information (including info that limits the size of the data \nfield). This information is used to help route traffic back and forth \nbetween rings connected by bridges. \n \nOn Token Ring if you have a hop count greater than 7 defined in the RIF \nfields this will cause Windows NT's TCP/IP stack to \"blue screen\", forcing \nthe user to reboot. Also if there are duplicate Token Ring IDs listed in \nthe hops this will also \"blue screen\" NT. The bad news is that the packet \ndoes not have to be addressed to the NT target to blue screen it. It will \nblue screen every NT workstation or server on the ring. The good news is \nthat properly configured and functioning network equipment will not pass \nthis type of illegal packet across a hop to a different ring, so the \nDenial of Service will be limited to one ring. \n \nIt is possible that some routers will allow RIF fields to have more than 7 \nhops, but unless they have been configured to handle this it will not pass \nthe packet across a hop as it is considered a bad frame. It should be \nnoted that in all related RFCs it is clearly stated that >7 is a no-no and \nshould not be done. \n \nMalfunctioning network equipment could cause this to happen, as this is \nhow the information was originally discovered. \n \nThere was no related/discovered Netbios flaws, in particular if \nencapsulation was being used to cross WAN links. \n \nSolution/Workaround \n------------------- \n \nMove to Ethernet, or contact Microsoft for the RIF Hot Fix, which was not \nposted last time I looked. I'll assume the latter would be easier. \n \nComments \n-------- \n \nThis is rather lame, but since I personally know of 2 Token Ring sites \nthat this affected in my town alone, I thought I might pass it on. \n \nWhen Microsoft was contacted 4 weeks ago they reported that more than one \ncorporate customer had reported the problem, and they had a hot fix they \nwere testing. Most sites are on Ethernet, and most elite sploit code talks \nEthernet frames anyway, so my guess is you'll have to ask for it. On a \npersonal note, it is a lot of fun to watch a row of NT machines all die \none after another, making for a very visual test of packet speed. \n \nThanks to Mike for letting me know about this, and thanks to a small \nunnamed Dallas accounting firm that graciously let me test this on their \nnetworks after hours. They were convinced they were under outside attack, \nbut a malfunctioning bridge was the culprit. \n \n_______________________________________________________________________________ \n \n \n`\n"}