Re: antisniff latest ("two times fixed") version still exploitable, l0phtl0phe-kid.c

[mudge () L0PHT COM (Mudge)]

A few comments as I think sebastian is taking things the wrong way (and
that was not our intention)

. We were made aware of a bug in antisniff and decided to do the right
thing to set an example for other companies. We posted an advisory on
ourselves with detailed instructions and even proof of concept code. This
was on a strncat() being improperly used in a particular section. I'd like
to see other vendors give similar detailed descriptions about problems
even in their own code.

. Sebastian pointed out the problem with signed/unsigned in testing for
length in the fix. I looked at the code and said 'doh. Even though it was
a copy of a 1 byte value into a 4byte holder it was able to set the MSB to
convince that it was a negative number. There were no recommendations for
fixes in his advisory nor were there descriptive comments.

. We received e-mail from people asking what they were doing wrong in
testing as they could not get Sebastian's exploit to work. No offense, but
I'm not person to be asking for help on that code so I pointed them
elsewhere but assured them that there was a real problem - whether the
exploit code compiled and worked out of the box or not.

. I feel the web page gave proper credit and did not deride Sebastian at
all. Especially in light that there was little information provided and
there was no vendor advance notice (heck, even we give vendors advanced
notice and time frames to work within. Actually our advisory release
policy is very well defined internally here - we will make it public so
everyone can see the procedure that we follow).

Here is the blurb from the web page - I will briefly describe why I feel
it is responsible:
+=+=+=+=+=+=
05.17.00 A cool bug on not properly ensuring variables were cast correctly
was found by sc. His statement that version 1.02 was affected seems to be
in error. In addition, the sample code he provided to various lists was
reported to us not to work. We have not verified the sample code but see
the problem that he points out and are in agreement on the problem. Only
the free researchers version appeared vulnerable.
+=+=+=+=+=+=

First we mention that sc found a cool bug. We had the NT maintainer look
at the NT source code (which is a completely different tree) and felt it
important to point out that it did not have the same setup and that the
researchers version was the one this applied to. We will look into this
further.

We mention that some people reported to us that the exploit code was not
working. Not that we claimed it does not work. We even point out that the
problem it points to *is* valid.

I don't see how Sebastian took this as a deriding of his work (heck - we
even call it _cool_) and we appologize for any way it could be taken like
that.

It should be pointed out that we are not the maintainers of this code
anymore but will help them with these problems. We'll look into this new
one and update shortly.

thanks,

.mudge

PS - considering source was/is available to the version that Sebastian
found the problem in - posting a proposed solution along with the problem
is usually appropriate.

On Thu, 18 May 2000, Sebastian wrote:

> Hi.
>
> This email includes personal opinions that might touch the feelings of some
> persons, but I cannot post this without some anger in my heart, so read on.
>
> The story about this bug started some days ago, when someone notified l0pht
> of a buffer overflow vulnerability in antisniff. Though this vulnerability
> is unlikely to be exploited in the wild it shows that no vendor, even the
> security conscious are safe from accidently creating overflowable code.
>
> l0pht issued an update, that should fix the problem.
> The advisory of l0pht contained one sentence "The fix is as trivial as".
> Maybe not as trivial as they thought, because not only this fix is broken,
> but also the second one, which was issued yesterday in response to my
> exploit post. The latest version of l0pht Antisniff (at least the unix
> version) is vulnerable to the same buffer overflow even after two fixes.
>
> This shows two things, namely a) that nobody, even the "known experts" are
> safe from creating simple bugs which result in security holes, and b) that
> you shouldn't go for "just add a *n* into those str* functions and every-
> thing will be ok" mentality.
>
> But it's ok, everyone is allowed to make errors. What got me a bit angry
> was the comment I read today on their website regarding my exploit. It
> was "reported not to work", and my supplied information "was invalid".
>
> I made one error in my post, that I admit, and thats I messed up with the
> different version numbering of the unix and the windows version. I haven't
> checked the windows version of antisniff for vulnerability, but the latest
> unix version (which was already "fixed") was vulnerable at the time of post,
> and thats what I meant. I'm sorry if that confused some people.
>
> The other point that the exploit doesn't work is maybe because it requires
> some fiddling with the offset and such. I didn't had the time nor the will
> to make the exploit more foolproof, so even the dumbest script kiddie can
> use it without having to try a couple of times. But in regard to the comment
> on the website I modified the exploit a bit, now it should work against
> all versions of antisniff for unix (up to and including 1-1-1) on a linux/x86
> box. If not you only have to do small mods to the offset and it should be
> ok. But don't claim it doesn't work unless you've checked in the debugger
> and see how the return address isn't overwritten. Thanks.
>
> For all that still don't believe, here is a little snapshot:
> (... == victim ip, removed, against x86/linux 2.2.x box with antisniff 1-1-1)
>
> foo:~ # ./l0phtl0phe 1.1.1.1 ...
> exploitation succeeded.
> try: "telnet ... 17664" now.
> foo:~ # telnet ... 17664
> Trying ... ...
> Connected to ... .
> Escape character is '^]'.
> id;
> uid=0(root) gid=0(root) groups=0(root)
> : command not found
> exit;
> Connection closed by foreign host.
> foo:~ #
>
>
> I feel that l0pht is allowed to make errors too, but they shouldn't be such
> contraproductive against people that point out security holes in their
> products by downsizing the claims and putting the stuff as "not working",
> just because it requires some work.
>
>
> ciao and regards,
> scut / teso
>
> --
> - scut () nb in-berlin de - http://nb.in-berlin.de/scut/ --- you don't need a --
> -- lot of people to be great, you need a few great to be the best ------------
> http://3261000594/scut/pgp - 5453 AC95 1E02 FDA7 50D2 A42D 427E 6DEF 745A 8E07
> -- data in VK/USA Mayfly experienced, awaiting transfer location, hi echelon -