Re: Sun libnsl lameness

From: Andy Polyakov (approat_private)
Date: Fri Jul 03 1998 - 07:09:42 PDT

  • Next message: Jeff Forristal: "Followup to MetaInfo vulnerabilities"

    > it should be noted that ssh and sshd make use of insecure functions as
    > mentioned below.
    >
    > [root@squig ~/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
    > [root@squig ~/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.
    



    This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:01:55 PDT