bugtraq - Re: Generic way to exploit an insecure /tmp file creation - Red Hat 7,8,9 (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-next>] [day] [month] [year] [list]

Message-ID: <3F0B5E21.1090603@bcgreen.com>
Date: Tue, 08 Jul 2003 17:13:21 -0700
From: Stephen Samuel <samuel@...reen.com>
To: Spybreak <spybreak@...teria.sk>, vuln-dev@...urityfocus.com,
	bugtraq@...urityfocus.com
Subject: Re: Generic way to exploit an insecure /tmp file creation - Red Hat
 7,8,9  (Re: Red Hat 9: free tickets)


I actually *would* describe the bug below as a logwatch bug.
If you have a uid=0 program calling shell scripts from
data like filenames, those filenames should be sanitized.
It would be easy enough to scan the filename for unexpected
characters and refuse to use them on that basis.

something as simple as:

if ($command =~ /[^\w]){
	carp "Unexpected filename: [[$LogFile]]. Not used\n"
}else{
     	`/bin/cat $Command`;
};

I believe that PERL actually has a pragma that you can set that
should cause it to complain about cases like this. (sorry --
don't have my book here with me).

Spybreak wrote:
> On Wed, 2 Jul 2003, Michal Zalewski wrote:
>>As far as I know, there was no neat and generic way to exploit an
>>insecure /tmp file creation alone - well, until now.
....
> What Logwatch basically does, is feeding the logfiles through filter
> scripts and emailing the results to a designated user (root by default).
> But the whole issue is in the way how it is done.
....
> if ($FileText) {
>    my $Command = $FileText . $FilterText . ">" . $TempDir . $LogFile;
>    if ($Config{'debug'}>4) {
>       print "\nPreprocessing LogFile: " . $LogFile . "\n" . $Command ."\n";
>    }
>    `/bin/cat $Command`;
> }
> 
....
> It means if we create a file with a name of the form \`command\`
> in one of these directories, the command gets executed with root privs,
> when Logwatch is run by the cron daemon. And it doesn't matter, what the 
> content of the created file is. What does matter is the filename.
.....
> While this is not a Logwatch bug by itself, because the filter-script
> directories are writable only by root, it is a very helpful _flaw_
> once we have an above mentioned insecure file creation issue in 
> some privileged code, and provides an easy root access.

-- 
Stephen Samuel +1(604)876-0426                samuel@...reen.com
		   http://www.bcgreen.com/~samuel/
    Powerful committed communication. Transformation touching
        the jewel within each person and bring it to life.