Re: Security Problems in XMCD 2.1

[jimd () starshine org (Jim Dennis)]

> On a side tangent, the standard rule of thumb is:  "If a program doesn't
> really need SUID/GID, don't give it SUID/GID." ...  Doesn't fix the buffer
> overrun, but it doesn't give the user root either...
> Theo Van Dinter                          www: http://www.kluge.net/~felicity/

        Add to that the notion that -- wherever possible --
        any SUID program should be o-rxw (i.e. only
        owner and group executable).  By ensuring that
        only "trusted" users are allowed to execute your
        programs you minimize the number of people who can
        use the exploit (forcing most attackers to compromise
        one of your "wheel" or "staff" or "console" accounts
        before they can use their favorite exploits).

        Specifically all of these modplayer, CD player,
        SVGALib, audio-recorder, CU-See-Me clients and
        similar SUID programs can be configured to be
        owned by a "console" group.  You can then add
        only those users with console access to that
        group.

        Things like chsh and chfn and passwd should be
        owned by a group like 'shell' -- so that only
        shell account holders can execute them (meaning
        that 'nobody' and 'daemon' and 'www' and 'listman'
        and 'postman' (P'gres) -- can't execute these

        I'm considering taking things like chsh and chfn
        and setting them to execute through a sudo/expect
        wrapper.  This wouldn't add much to the security
        on the shell accounts directly -- but it would force
        logging of each execution of these commands --
        and the wrapper script could check arguments or
        other factors.  It might also prevent LD_PATH
        and IFS types of attacks (since sudo seems to
        check it's environment -- and keeping just one
        statically linked sudo binary around beats
        dealing with some number of other binaries that
        might have to be statically linked *and* might
        have a variety of SUID bugs).

        I was looking at SFW (simple file wrapper) off of
        the COAST archive at Purdue recently.  Unfortunately
        it isn't very portable -- Solaris and AIX only so
        far.  I was able to get it to compile under Linux --
        but it didn't work properly (segv on some NIS/YP
        calls or something like that).

        However, what attracted me to this package
        was the optional MD5 check on your binary after
        the ACL is verified and before the su/execution.

        The idea of this package is that it allows the admin
        to configure any number of programs to be run by any
        number of different users or groups 'as' any user
        and subject of various controls (like time-of-day,
        day-of-week limitations).

        It would be need to hack sudo to allow for an
        MD5 check before execution as well.

        Maybe I'll work on that before next year.


        Jim Dennis,
        Starshine Technical Services