bugtraq - Re: Red Hat 9: free tickets

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Fri, 11 Jul 2003 13:48:07 -0400
From: Jon Hart <warchild@...ofed.org>
To: Stephen Samuel <samuel@...reen.com>
Cc: vuln-dev@...urityfocus.com, bugtraq@...urityfocus.com
Subject: Re: Red Hat 9: free tickets


On Sun, Jul 06, 2003 at 12:30:34PM -0700, Stephen Samuel wrote:
> The way it works is:
> 
> ln -s /var/run/sudo/mylogin/0:root /tmp/likely_tmp_name
> 
> Then you wait for or cause some setuid progrem to attempt to
> (insecurely) write to /tmp/likely_tmp_name .   When that happens,
> /var/run/sudo/mylogin/0:root is created, and pam_timestamp_check
> now allows you to run any helper application as if you'd
> typed in the root password...
> 
>  Since these helper applicaitons tend to allow all sorts
> of nasty work (like creating a uid=0 user), you've now got a
> *serious* security violation on your hands.
> 
> The face that /var/run/sudo is rwx root only is no protection
> because the open is doen by an suid-root program, and the symlink
> in /tmp can be created by anybody.
> 
> Proof of concept:
> 
> as youreslf:
> ln -s /var/run/sudo/$USER/unknown:root /tmp/oops
> 
> as root:
> touch /tmp/oops
> 
> as yourself: open the system-settings/users&groups utility from
> the desktop menu.
> 
> You can now create an account with uid=0
> 
> Now ANY exploit that can cause a setuid/root program to create
> an arbitrary file (regardless of content) can be used to create
> an arbitrary root user.
> 
> Finding such an exploit is left as an exercise for the user.

Actually, I'm not sure this entirely true.  Well, it is, but there is
another important condition that must be met for this (or similar)
attacks to work properly -- /var/run/sudo/$USER/ must exist.  This means
that the user must have previously sudo'd at lease once and
/var/run/sudo/$USER/ will have been created.

I'm sure there are ways to work around this, but in my experiments,
/var/run/sudo/$USER/ must exist if you hope to exploit something like
this with the predictable file name creation + symlink trick.

-jon