lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <276004ce0610301100i59db0f17y857f48758473efc5@mail.gmail.com>
Date: Mon, 30 Oct 2006 14:00:58 -0500
From: "Matt Richard" <matt.richard@...il.com>
To: FistFuXXer <FistFuXXer@....de>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: ZDI-06-035: Novell eDirectory NDS Server Host
	Header Buffer Overflow Vulnerability

Manuel,

> the vulnerability details have been submitted by me on June 1, 2006
> CST/CDT (June 2, 2006 GMT+1). So I've found the vulnerability before
> Michael Ligh and Ryan Smith did it.

Please accept my apologies for the insinuation that you may have
personally tried to steal another researchers work.  As you
demonstrated this is clearly not the case.

> Anyway, it doesn't matter if the IDS signature got released on, before
> or after the patch day,

On October 20th details of the vulnerability and a road map to exploit
it were publicly released.  Every vulnerable version that could not be
patched quickly was at risk of remote root.  It's difficult to accept
that this "doesn't matter" to Novell shops with Tipping Point.

> TippingPoint IPS should detect or filter shellcodes and return addresses
> within the host header without any special IDS signature. For example,
> you can filter all illegal characters from the host header and convert
> everything to lowercase characters. Or better: convert the domain name
> in the host header to a random mixture of lowercase and uppercase
> characters and redirect this to the destination server, this should f***
> up every kind of ASCII shellcode and ASCII return address. ;-)

Your reasoning is very good and would certainly mitigate this
vulnerability.  The unfortunate part of the problem is that this is
not what any of the IPS vendors are doing.  In most cases performance
trumps security and anything as CPU intensive as your suggestion isn't
implemented.

> Maybe should you better take some minutes time and think about the fact
> that we humans aren't perfect and make mistakes, instead of wasting your
> time with trying to destroy the image of a company. The employees of
> such companies have to do a lot of work with all the submissions that
> they receive and I also know other security companies that sometimes
> broke down because of this and did multiple mistakes during payment and
> processing.

So we should just hope that they have the time to live up to their promises?

>>From the ZDI FAQ:

"3Com's goal for the Zero Day Initiative is to provide our customers
with the world's best intrusion prevention systems and secure
converged networking infrastructure. In order to accomplish our goal,
we require access to the best and most timely security intelligence
available. "

3Com had access to this data for over 4 months and failed to produce
protections until 6 days after someone else released the work.  This
shows that their process for taking in new vulnerabilities and using
them to proactively protect has failed in this case.  This may be 1
exception out of hundreds of successes.

BTW it is a bit odd that the CVE posting also cites mnin.org
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5478

Cheers,

Matt

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ