mailing list archives
Re: Remote DoS Attack in Eeye Iris 1.01 and SpyNet CaptureNet v3.12 Vulnerability
From: Dino Amato <slayer67 () APK NET>
Date: Thu, 31 Aug 2000 16:44:52 -0400
just run IRIS and then portscan yourself, this will also cause the same
problem. You dont need and special binary to do a DoS in this case.
I saw this when I first go the beta, but as it says - its Beta.
On Thu, 31 Aug 2000, Ussr Labs wrote:
-----BEGIN PGP SIGNED MESSAGE-----
You forgot say you already know this problem and you write this in a
mail to me the same day Thursday, August 24, 2000 8:47 AM of you
"Send me the advisory if you want, otherwise your wasting my fucking
To anyone of want the mail write to us to see who are rigth or not,
are signed digitaly so no change is posibly.
this is a dos not a remote buffer overlow the dos is caused by one
heap overflow in one of the 13 thread that use the retina 1.01.
anyway i no know ONE. vendors angry with us
u n d e r g r o u n d s e c u r i t y s y s t e m s r e s e a r c
- -----Original Message-----
From: Marc Maiffret [mailto:marc () eeye com]
Sent: Thursday, August 31, 2000 7:58 AM
To: Ussr Labs; win2k
Cc: BUGTRAQ; EEYE; net-security.org; nTBUGTRAQ; Pure-security.net;
packet storm; TECHNOTRONIC
Subject: RE: Remote DoS Attack in Eeye Iris 1.01 and SpyNet
One thing USSR forgot to mention in their advisory is that Iris 1.01
_BETA_. With that out of the way lets proceed...
Our response should hopefully clear up most of the inaccuracies and
technical blunders found within USSR's advisory.
| Remote DoS Attack in Eeye Iris 1.01 and SpyNet CaptureNet v3.12
| USSR Advisory Code: USSR-2000052
| Release Date:
| August 31, 2000
| Systems Affected:
| Eeye Iris 1.01
| SpyNet CaptureNet v3.12
First thing to mention is that SpyNet was purchased by eEye Digital
a few months back. SpyNet is no longer supported and all SpyNet
should contact us for a free upgrade to Iris.
| THE PROBLEM:
| The Ussr Team has found a problem in Eeye IRIS 1.01, There is a
| heap memory buffer o
| verflow in IRIS 1.01 that causes not only this network sniffing
Some might read "buffer overflow" and think that Iris has a remotely
exploitable buffer overflow. This is not true...
| program to crash,
| but also to take system resources up to 100% usage, until it
Indeed the system resources go up to 100% usage. That is because your
program goes into a sendto() loop and sends thousands of packets that
has to redraw on screen. If any program in Windows has to redraw
ammounts of information very quickly then it is going to end up
taking a lot
of processing power. Just as your "exploit" program will consume 100%
attackers system resources when it goes into its sendto() loop.
| The vulnerability arises after sending multiple udp connection to
| random ports
| on the host that IRIS or SpyNet CaptureNet is running.
It does not matter what protocol you use nor what port. It just
you send a massive amount of information across a network that has
running on it. I understand why you used UDP because sendto() loops
easier to create using UDP but that really has no technical bearing
| SPECIAL NOTE:
| That we take no responsibility for this code it is for educational
| purposes only.
| D.O.S Code:
| Binary or source (console win32)
This program, as noted above, is a simple sendto() flooder. The way
is by sending massive amounts of UDP packets destined to a computer
| Vendor Status:
| Send me the advisory if you want, otherwise your wasting my fucking
| Marc Maiffret
| Chief Hacking Officer
| eCompany / eEye
The above "quote" was taken completely out of context. This quote was
numerous eMails between myself and USSR in which I never received ANY
details about the hole. I finally received "technical detailed
in the form of this advisory only 2 hours before USSR posted it today
various mailing lists. I now more than ever can understand why so
vendors have been angry at USSR because of how they handle the
"vulnerabilities" they find. All in all though I definitely did say
"otherwise your wasting my fucking time" because that is exactly what
| Install Free Ethereal for win32, Ethereal is Open Source software
| released under the GNU
| General Public License. and it does the same thing
| http://ethereal.zing.org/ ,or wait untill
| Eeye fix this kind of attack.
We tested USSR's "DoS" program against our test network here. The
Attack Machine: dual 250 Pentium 2 processor NT4 machine with a
100mbit card running the my.exe "DoS" program.
Victim Machine 1: 128megs of ram Single processor AMD 700mhz Win2k
with an Intel 100mbit card running Iris 1.01 _!!BETA!!_
Victim Machine 2: 96megs of ram Single processor Pentium 300mhz NT4
with a Linksys 100mbit card running Iris 1.01 _!!BETA!!_
Attack Test 1:
One hub with all machines connected to it.
my.exe was run against Attack Machine 2 and both Victim
running Iris 1.01 _beta_.
Attack Result 1:
Both machines did not crash after running my.exe against them for
5 minutes. Both machines were using heavy resources as was the
machine which was sitting at 100% cpu processing. However, neither of
two victim machines were left unusable. In fact victim 1 was
Retina in the background with no trouble... and that's not easy on
Attack Test 2:
We figured maybe the hub was limiting the flow of packets due to
So we connected a cross over cable between Attacker and Victim 1 at
We then loaded my.exe on the Attacker machine and made it flood
Attack Result 2:
After about 15 minutes of leaving it flooding Victim 1, which was
Iris, Victim 1 was still running fine. Processor usage was higher but
machine was still responsive. The attacking machine was also using
Attack Test 3:
For the next test we connected the Attacker machine to Victim 2 via a
over cable at 100mbit full duplex. We then loaded my.exe on the
machine and made it flood Victim 2.
Attack Result 3:
Iris used 100% cpu utilization on Victim 2 but did not generate any
errors. The attacking machine's processor also sat at 100% cpu
while running the "DoS" program my.exe.
Analysis of the problem:
USSR kindly left out the fact that their "attack" was done over a
network. This "DoS" is not possible over the Internet unless the
machine and the target machine have better then a DS3.
While we do not discount the fact that Iris might crash when flooded
thousands of packets, we think it will be rare for any modern system
Our recommended hardware configuration, 400mhz, 128megs of ram, or
to be vulnerable to this "bug."
USSR most likely ran across this bug when testing their "DoS" tool
an older, slower, system (One other technical fact their advisory did
cover, was the system they were testing with and against; this is an
important fact in a resource depletion based "DoS" attack.)
The problem triggered by this "DoS" seems to result from filling
buffers faster than Windows can paint them to the screen.
If you are really worried about this, until Iris is out of beta and
the "problem", then we recommend you turn off Iris's Capture packet
feature and use Iris's decode view instead.
| Vendor Url: http://www.eeye.com
| Program Url: http://www.eeye.com/html/Products/Iris/overview.html
| Download Url: http://www.eeye.com/iris/iris101.exe
| SpyNet Url:
SpyNet is no longer supported. If your a registered SpyNet then
contact iris () eeye com to received your free copy of Iris.
If anyone has any questions or problems then feel free to email
iris () eeye com Any new information we learn about this "hole" will be
summarized and posted to Bugtraq.
Chief Hacking Officer
eCompany / eEye
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>
-----END PGP SIGNATURE-----
- Re: Remote DoS Attack in Eeye Iris 1.01 and SpyNet CaptureNet v3.12 Vulnerability Dino Amato (Sep 01)