OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Bugtraq archives for 3rd quarter (Jul-Sep) 1998: Re: Sun libnsl lameness

Re: Sun libnsl lameness

Matt Conover (mattcrepsec.com)
Fri, 3 Jul 1998 10:38:51 -0700 

On Fri, 3 Jul 1998, Andy Polyakov wrote:

> First of all it looks like information provided in RSI bulletin is not
> accurate. 'getkeys_nis' looks quite innocent to me

Yes and No. You're right that it looks quite innocent. And in reality, I
doubt it will be exploited. However, the potential is there. If it is,
for example, cached information (assuming you can), the possibility
exists. I doubt there is much need for concern. But the advisory listed
all potential(ly) vulnerable function(s), and that is why this was
included.

> Should I think of a patch, people? The only thing one can do is to
> fetch key-pair before calling 'getsecretkey' and make sure it's not
> longer than 1K or something:-)

The vulnerabilities have nothing to do with sshd. In most cases, I don't
think the programs that are calling the vulnerable functions are in
fault for assuming the library functions are safe. All that can really be
done for now is bounds checking where it applies, as you had mentioned. If
you feel obligated to prevent overflows at the library level.. feel free
to.

Just for your information, two of the vulnerable key functions in libnsl,
getsecretkey and getpublickey, are also vulnerable in libc. But still,
it's the libraries that need to be fixed, not ssh or sshd.

Matt

*****************************************************************************
Matt Conover <mattrepsec.com>                  RSI R&D Team
-----------------------------------------------------------------------------
RepSec, Inc. (RSI)                              [http://www.repsec.com]
w00w00 Security Development (WSD)               [http://www.w00w00.org]
*****************************************************************************