bugtraq - 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>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.44.0307040411170.33-100000@irc>
Date: Fri, 4 Jul 2003 05:18:02 +0200 (CEST)
From: Spybreak <spybreak@...teria.sk>
To: bugtraq@...urityfocus.com
Subject: Generic way to exploit an insecure /tmp file creation - Red Hat
 7,8,9  (Re: Red Hat 9: free tickets)

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.

Hello Michal and BugTraq,

there already has been a generic way to exploit O_CREAT w/o O_EXCL
in a world-writable directory issues, especially on Red Hat boxes.

My method exploits the Logwatch utility, what is a perl script
used for monitoring logfiles. Logwatch is a part of the Red Hat
distribution since releases 7.x , run daily by the cron daemon.
But the method is still usable on any system that runs Logwatch.

When I found the Logwatch tempdir vulnerability (BID-4374) in march
2002, I looked for a way to exploit this bug to get a root shell.
Basically we had the possibility to create or overwrite any file on
the filesystem, but with content we couldn't control much.

While I knew of possible attack vectors, they were not very interesting
in this case. Another audit run through the Logwatch code showed that the
problem is solved by Logwatch itself.

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.

Here is the guilty code snippet from the latest Logwatch version - 4.3.2
(http://www.logwatch.org) :

if (opendir (LOGDIR,$BaseDir . "scripts/logfiles/" . $LogFile)) {
   foreach (sort readdir(LOGDIR)) {
      unless ( -d $BaseDir . "scripts/logfiles/$LogFile/$_") {
         $FilterText .= ("| $BaseDir" . "scripts/logfiles/$LogFile/$_");
      }
   }
   closedir (LOGDIR);
}
if ($FileText) {
   my $Command = $FileText . $FilterText . ">" . $TempDir . $LogFile;
   if ($Config{'debug'}>4) {
      print "\nPreprocessing LogFile: " . $LogFile . "\n" . $Command ."\n";
   }
   `/bin/cat $Command`;
}

Simply put, Logwatch has its filter scripts located in the
/etc/log.d/scripts/logfiles/* directories, and when some logfile is
parsed, Logwatch takes all filenames from the corresponding subdirectory
and constructs a command line including the filenames with pipes
between them and passes the command line to the shell.

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.

So if we have some buggy privileged software that insecurely writes into 
e.g. /tmp/trash, the only thing we may need to do is something like this:

ln -s /etc/log.d/scripts/logfiles/xferlog/'`cd etc;chmod 666 passwd`' /tmp/trash

and wait for Logwatch to be run by cron.

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.

This method was already used to exploit e.g. vulnerabilities BID-4374
BID-5708, BID-5602.

Cheers,
Spybreak