oss-security - Re: CVE Request - cups, dovecot-managesieve, perl, wireshark

Follow @Openwall on Twitter for new release announcements and other news

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

Message-ID: <n9h6hLh2v/xEcEaj0SNgAcsxpfU@kjaK+/sQ5DW5981v71UogZJPf/0>
Date: Mon, 1 Dec 2008 00:52:18 +0300
From: Eygene Ryabinkin <rea-sec@...elabs.ru>
To: oss-security@...ts.openwall.com, jlieskov@...hat.com
Cc: "Steven M. Christey" <coley@...us.mitre.org>
Subject: Re: CVE Request - cups, dovecot-managesieve, perl,
	wireshark

Jan, good day.

Fri, Nov 28, 2008 at 04:29:10PM +0100, Jan Lieskovsky wrote:
> One point yet -- this is perl-5.8.8-1+ specific issue (different than
> CVE-2004-0452, CVE-2005-0448 and even different than recently fixed
> CVE-2008-2827). Seems that upstream forgot to apply the fix for
> CVE-2005-0448 to 5.8 perl after rebase. This newly reported issue
> already fixed in perl-5.10.
> 
> CVE-2008-2827 affects only perl-5.10 (and it already applies additional
> fix to CVE-2005-0448, which has been properly applied in perl-5.10).

The following code seems to be still vulnerable to the attack, described
in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=286905 (I am citing
by the virgin sources of perl-5.10.0 from
http://www.cpan.org/authors/id/R/RG/RGARCIA/perl-5.10.0.tar.gz,
file lib/File/Path.pm, starting at line 305):
-----
            # ensure that a chdir upwards didn't take us somewhere other
            # than we expected (see CVE-2002-0435)
            ($device, $inode) = (stat $curdir)[0,1]
                or _croak("cannot stat prior working directory $arg->{cwd}: $!, aborting.");

            ($arg->{device} eq $device and $arg->{inode} eq $inode)
                or _croak("previous directory $arg->{cwd} changed before entering $canon, expected dev=$ldev inode=$lino, actual dev=$device ino=$inode, aborting.");

            if ($arg->{depth} or !$arg->{keep_root}) {
                if ($arg->{safe} &&
                    ($Is_VMS ? !&VMS::Filespec::candelete($root) : !-w $root)) {
                    print "skipped $root\n" if $arg->{verbose};
                    next ROOT_DIR;
                }
                if (!chmod $perm | 0700, $root) {
                    if ($Force_Writeable) {
                        _error($arg, "cannot make directory writeable", $canon);
                    }
                }
                print "rmdir $root\n" if $arg->{verbose};
                if (rmdir $root) {
                    push @{${$arg->{result}}}, $root if $arg->{result};
                    ++$count;
                }
                else {
                    _error($arg, "cannot remove directory", $canon);
                    if (!chmod($perm, ($Is_VMS ? VMS::Filespec::fileify($root) : $root))
                    ) {
                        _error($arg, sprintf("cannot restore permissions to 0%o",$perm), $canon);
                    }
                }
            }
-----
While it tries to make sure that inode and mounpoint aren't changed,
there is still a window between this check and chmod/rmdir/chmod triple.
This leaves much smaller time frame for a race, but doesn't eliminate
it completely.  The proper fix for the platforms with $Force_Writeable
is to check for its value and do chmods only when $Force_Writeable is 1.
Just as in
  http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=85;filename=sid_fix_file_path;att=2;bug=286905

Am I missing something and this won't make files setuid or you're talking
about different perl-5.10?

Thanks!
-- 
Eygene

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.