Re: Remote DoS Attack in Eeye Iris 1.01 and SpyNet CaptureNet v3.12 Vulnerability

[Synnergy <dethy () DETHY SYNNERGY NET>]

I took an interest to this thread, since it seems to be gaining much
controversy about the supposed existance of the Iris bug.

I went and downloaded the exploit provided by UssrLabs and eEye's product.
The system I used for the test was a PII 300, 64 RAM running Windows NT4.0
SP6
connected over 10 mb/sec link (D-Link ethernet card) on my local network.
The launch pad used was a PII 400, 64 RAM, running Win98 system.

Now, after 1.5 mins of running the supposed exploit, a window popped
up with an Iris 'Application Error' that caused the program to crash.
Resource usage on the client machine was terribly bloated (96%), on the
server side, likewise. A combinatinon of the Iris crash + UDP packets
would cause this, not the Iris crash alone, however. (anyone got more
results for this?) NT/SP5 is able to deal with excess UDP in a relatively
stable manner without crashing, which is why I am led to believe that the
Iris crash has contributed to the resource usage.

> Some might read "buffer overflow" and think that Iris has a remotely
> exploitable buffer overflow. This is not true...

Unless the reader is wearing some unique pair of magic goggles, the term
buffer overflow does -not- include "exploitable" unless it otherwise
states.
Not all buffer overflow's are exploitable, but can be used to cause some
arbitary problem, such as a DoS. I am sure you are aware of this by now.
However, whether or not the problem is a result of a heap based overflow
remains to be seen. The excess packets sent cause the graphical display
to update quicker than it can handle, resulting in the error, from what I
can tell.

(Could this be due to a bad algorithm in the program? What optimisation
is used in the code for this? Big-Oh notation considered? I can't answer
that.) It still holds true that a bug does exist. Marc seems to have very
subtely acknowledged that, Ussr Labs seem to be more or less correct in
their advisory.

The graphical statistics generated from Iris does suffer from this
trivial problem, but nevertheless, considering a network may be using
this product to monitor network connections (internally OR externally),
the bug immediately  becomes the focus of attention. Needless to say, the
vulnerability could then be used to halt network monitoring, thus making
the program defective for its purpose.

--<cut>--
> This "DoS" is not possible over the Internet unless the
> attacking
> machine and the target machine have better then a DS3.

 ..

> USSR most likely ran across this bug when testing their "DoS" tool
> against
> an older, slower, system
--</end cut>--

Let us not forget this -is- a bug, no matter what the "special" conditions
may be. Acknowledging the bug would be more effective, rather than try to
exclude and obfuscate the factors that make this bug -seem- improbable.
(aka Microsoft-style)

> From where I stand, the problem as described in the USSR advisory were
seemingly correct (although more client/server side test conditions would
have been pleasing). The bug does appear to present itself in the
graphical
p acket display updating function resulting from the excess packet
payload.

Marc was correct in saying that protocol does not matter, theoretically
this is true, USSR Labs seem to have missed this issue.

One last thing to add is that this product, although it is beta,
apparently is commercially available for a sum of money, making it
a legitimate product to be tested (and criticised) for bugs.

Anyone else out there have any test results? Perhaps you could reproduce
the bug using the same set of conditions, and under the same circumstances
as I have. Post your results. Thanks !

Synnergy Networks.

------------------------------------
URL: www.synnergy.net