Hello,

the new version addresses the issue below. Policyd-weight does now exit if it
detects symlinks on directories or sockets at startup or directory creation.

The flaw can lead to altered or deleted files on following systems:


    1: multiuser or 3rd-party-holes hosts that plan to use
       policyd-weight prior to 0.1.14 beta-15

    2: multiuser or 3rd-party-holes hosts that empty the /tmp directory

On systems wich do have an existing working directory this should not have 
an impact as the permissions and ownership is set to write only by root or 
polw, and once the directory is created policyd-weight doesn't delete it.


Workaround/Advice:

users can also use /var/run/.policyd-weight as $LOCKPATH.
Users who change the $LOCKPATH must issue 'policyd-weight -k stop' first.
Otherwise they have to kill the children and cache manually.



MD5 (policyd-weight)                        = 
    b33265ca797eb545ed9df5b0032282e5

SHA256 (policyd-weight)                     =
    84aba66c39a016e60c073a2a2063d0433fc7f28d87baafb5846c48cb26bea5db

MD5 (policyd-weight-0.1.14.15.tar.gz)       =
    a3b23cdb37c1179587305b65d9a18515

SHA256 (policyd-weight-0.1.14.15.tar.gz)    = 
    c8b8e3eaaf8e96794d5bfdd2a4f5e7a959c0348f1fff5b1c0e7c8ed17a20c731



On Mon, Mar 24, 2008 at 11:19:55AM +0100, Andrej Kacian wrote:
> Hello guys,
> 
> I am a maintainer of Gentoo package for policyd-weight. We had following
> report coming in from Chris about insecure lockfile creation in your software:
> 
> ------------------------------8<--------------------------------------------
> Hi,
> 
> I believe I have discovered an insecure temporary file vulnerability in
> policyd-weight, which is in the repositories of Debian etch.
> 
> Snippets of code from /usr/sbin/policyd-weight
> 
> my $LOCKPATH          = '/tmp/.policyd-weight/';
> 
> Then the function create_lockpath chown's lockpath:
> 
> sub create_lockpath
> {
>     my $who = shift(@_);
> 
>     if(!( -d $LOCKPATH))
>     {
>         mkdir $LOCKPATH or die "$who: error while creating $LOCKPATH: $!";
>     }
> 
>     my $tuid = $USER;
> 
>     if($USER =~ /[^0-9]/)
>     {
>         if( !(defined( $tuid = getpwnam($USER) ) ) )
>         {
>             mylog(warning=>"User $USER doesn't exist, create it, or set
> \$USER");
>         }
>     }
>     if( !(chown ($tuid, -1, $LOCKPATH)) )
>     {
>         mylog(warning=>"Couldn't chown $LOCKPATH to $USER: $!");
>     }
>     if( !(chmod (0700, $LOCKPATH)) )
>     {
>         mylog(warning=>"Couldn't set permissions on $LOCKPATH: $!");
>     }
> }
> 
> I have verified that by doing something like this:
> 
> mkdir /home/chris/foo
> ln -s /home/chris/foo /tmp/.policyd-weight
> 
> and starting policyd-weight you can change the ownership or any arbitrary
> directory around the system - /home/chris/foo got chown'ed to polw:root.
> 
> I'm sure you can also play tricks with the creation and deletion of the socket
> too as they get unlink'ed in a few places, but haven't bothered trying to
> exploit them as I think this is plenty to be sure that there is a problem.
> ------------------------------8<--------------------------------------------
> 
> Maybe you have already been contacted by Debian or FreeBSD security teams, as
> Chris has reported this there as well, but in case you weren't, I thought you
> should be made aware, in order to fix the issue.
> 
> The bug report in Gentoo Bugzilla is restricted, so this is still confidential
> as far as I am concerned.
> 
> Kind regards,
> -- 
> Andrej "Ticho" Kacian <ticho at gentoo dot org>
> Gentoo Linux Developer - net-mail, antivirus, x86



-- 
    Robert Felber (PGP: 896CF30B)
    Munich, Germany

____________________________________________________________
Policyd-weight Mailinglist - http://www.policyd-weight.org/

Reply via email to