Re: Sun libnsl lameness

approFY.CHALMERS.SE

• Messages sorted by: [ date ][ thread ][ subject ][ author ]
• Next message: Jeff Forristal: "Followup to MetaInfo vulnerabilities"
• Previous message: Aleph One: "ALERT: Microsoft IIS ASP - $DATA issue update"
• Maybe in reply to: George Clooney: "Sun libnsl lameness"
• Next in thread: Matt Conover: "Re: Sun libnsl lameness"

> it should be noted that ssh and sshd make use of insecure functions as
> mentioned below.
>
> [rootsquig ~/work/ssh/ssh-1.2.25] nm sshd | egrep 'getnetname|getsecretkey'
> [428]   |    372268|       0|FUNC |GLOB |0    |UNDEF  |getnetname
> [527]   |    372280|       0|FUNC |GLOB |0    |UNDEF  |getsecretkey
> [rootsquig ~/work/ssh/ssh-1.2.25] nm ssh | grep getnetname
> [416]   |    356736|       0|FUNC |GLOB |0    |UNDEF  |getnetname
>
I'm the one who is responsible for these calls:-) Hello, everybody!

First of all I want to point out that mentioned functions in both ssh
*and* sshd cases are called at least at caller's, a.k.a.  none-root,
effective uid. Observe that when called at none-root euid 'getnetname'
does *not* call 'host2netname', but 'user2netname'. In addition it
should be mentioned that in ssh case call to 'getnetname' is performed
in separate process context at *both* effective & real caller's uid. So
that the way I see it it's *not* possible to exploit 'getnetname' to
gain root privileges in neither ssh nor sshd case.

Now let's look at 'getsecretkey' in sshd... First of all it looks like
the information provided in RSI bulletin is not accurate. 'getkeys_nis'
looks quite innocent to me, but not 'getkeys_nisplus'... I don't
believe buffer overflow in 'getkeys_nisplus' ever takes place in sshd
case, because arguments can not be manipulated by the intruder (as he's
not logged in yet!) by e.g. setting NIS_PATH environment variable. Bad
news is that all 'getkeys_*' call 'extract_secret' which in turn
does look like "come and get me"...  But what would it take to exploit
it? The way I see it intruder would have to have access to or forge
answers from NIS/NIS+ server in order to feed the victim with unusually
long key-pairs. Well, I have to conclude that 'getsecretkey' in sshd is
exploitable. Again! Provided that intruder has access to or capable
of imitating NIS/NIS+ server.

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:-)
>
>
> George Clooney wrote:
> >                Functions we have found vulnerable:
> >
> >                Vulnerable key functions
> >                ---------------------------------------------------
> >                getsecretkey ()         : Calls getkeys_nis ()
> >
> >
> >                Vulnerable RPC functions
> >                ----------------------------------------------------
> >                getnetname ()           : Calls host2netname ()
>
Andy.

• Next message: Jeff Forristal: "Followup to MetaInfo vulnerabilities"
• Previous message: Aleph One: "ALERT: Microsoft IIS ASP - $DATA issue update"
• Maybe in reply to: George Clooney: "Sun libnsl lameness"
• Next in thread: Matt Conover: "Re: Sun libnsl lameness"