Visit our newest sister site!
Hundreds of free aircraft flight manuals
Civilian • Historical • Military • Declassified • FREE!


TUCoPS :: Web :: Apps :: ikeyman1.htm

IBM HTTPD /usr/bin/ikeyman setuid bug



Vulnerability

    /usr/bin/ikeyman

Affected

    IBM HTTPD

Description

    Rude  Yak  found  following.   /usr/bin/ikeyman  is a shell script
    installed with setuid root permissions by the IBMHSSSB package  on
    Solaris.  The script does not seem to work very well in a  Solaris
    2.6  environment  because  of  dynamic  linker issues; if they are
    resolved, however, an  unprivileged user may  then be able  to use
    ikeyman to run commands of their choice as root.

    /usr/bin/ikeyman is part of the IBMHSSSB package, which is  needed
    to operate  the SSL  module for  the IBM  HTTP server.   This is a
    shell  script  that  is  installed  and  set  to be setuid root by
    default:

        % ls -dl /usr/bin/ikeyman
        -rwsr-sr-x   1 root     other        126 Dec  2 08:54 /usr/bin/ikeyman

    This script merely sets a path and calls another script:

        % cat /usr/bin/ikeyman
        #!/bin/ksh
        export
        CLASSPATH=$CLASSPATH:/opt/IBMHTTPD/ssl/ikeyman/sguide.zip:/opt/IBMHTTPD/ssl/ikeyman:/opt/ibm/gsk/bin/ikmgui

    Note that the user's CLASSPATH environment is inserted first  into
    the list.  This  seems potentially dangerous, but  not necessarily
    exploitable.  Now, we inspect the ikmgui script referenced above:

        % tail /opt/ibm/gsk/bin/ikmgui
        # ----------------------------------------------------------------------
        # Setup LIBPATH environment for ikeyman
        # ----------------------------------------------------------------------
        export LIBPATH=$IKEYMAN_HOME/lib:$LIBPATH
        export LD_LIBRARY_PATH=$IKEYMAN_HOME/lib:$LD_LIBRARY_PATH
        
        # ----------------------------------------------------------------------
        # Run ikeyman
        # ----------------------------------------------------------------------
        $JAVA_HOME/bin/jre ${JRE_FLAGS} -cp $IBMCFWK_CLASSES
        -Dkeyman.verbose=$IKEYMAN_VERBOSE
        -Dkeyman.fix.jfc.mouse.retarget=$IKEYMAN_FIX_JFC_MOUSE_RETARGET
        com.ibm.gsk.ikeyman.Ikeyman ${ARGS}

    This, on  the other  hand, looks  fairly dangerous.   Leaving  the
    specifics of the exploit up  to the user, it should  be relatively
    easy to create a java class that does something like this:

        package com.ibm.gsk.ikeyman;
        import java.io.*;
        public class Ikeyman
        {
        // bunch of code that essentially mimics
        // % cat /etc/shadow
        // or
        // % echo "+" > /.rhosts
        // should do the trick
        }

    Now,       by       compiling       this       program        into
    ./com/ibm/gsk/ikeyman/Ikeyman.class and exporting

        CLASSPATH=.

    it should  be fairly  trivial to  run ikeyman  and have it execute
    the exploit code  from the current  directory.  However,  it's not
    quite that easy - the Solaris linker (at least on the 2.6 machine)
    seems to do a safety check prior to executing setuid programs  and
    resets LD_LIBRARY_PATH  and thus  won't load  IBM's java libraries
    (which  are  required  by  the  ikmgui  script since it explicitly
    references IBM's JVM, which also needs to be installed).

    So, this is an interesting catch-22.   If the product was to  work
    as designed (?) and allow non-root users to run ikeyman (or if  an
    admin fixed it  to do so  by creating the  proper symlinks, etc.),
    the  script  could  then  be  exploited  to  run  arbitrary  code.
    Otherwise, it seems to be somewhat broken at best.

Solution

    Rude  Yak  contacted  IBM  and  they  acknowledge that there is an
    issue.  It is due to be fixed in the upcoming 3.5 release,  slated
    for this summer.  For  the time being, their recommendation  is to
    remove   setuid   bit   off   /usr/bin/ikeyman   and   not   allow
    non-privileged users to run the program.


TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2014 AOH