Bugtraq mailing list archives

Re: Acrobat reader 5.05 temp file insecurity

From: "Juan M. Courcoul" <courcoul () campus qro itesm mx>
Date: Wed, 26 Jun 2002 19:04:42 -0500

Acrobat Reader 5.0.5 on MacOS X does not seem to have this problem. Itcreates or overwrites the file


/Library/Application Support/Adobe/Fonts/AdobeFnt.lst

with the same owner as the user and with group "admin", but with 644file permissions. The directory does not have world-writeable permissions.


Cheers,

J. Courcoul

Paul Szabo wrote:

Product:

Acrobat Reader version "x86 linux 5.0.5 Apr 25 2002 11:55:36"
(Other UNIX versions probably also affected, see Comments.)


Problem and exploit:

Acroread creates or overwrites the file /tmp/AdobeFnt06.lst.UID, and
changes its permissions to wide open (mode 666); it also follows
symlinks. The attack is obvious:

  ln -s ~victim/.bashrc /tmp/AdobeFnt06.lst.VUID

and wait for victim to use acroread; then we can write his .bashrc.


Comments:

A similar problem has been reported in acroread 4.05 in August 2001:
  http://online.securityfocus.com/bid/3225
(apparently reported to Adobe in March 2001 and even in October 1999).
The problem is worse in acroread 5.05 than was in 4.05: the file is
written in /tmp, not the home directory. (The securityfocus description
has since been updated to say that also 5.05 has a problem.)

The file /tmp/AdobeFnt06.lst.UID is created on exit. Acroread seems to
respect the setting of TMPDIR in the environment: then creates the file
in that directory, and sets its permission to a sensible 600.

Could we mess with the data in /tmp/AdobeFnt06.lst.UID, to substitute
fonts so all PDFs look gibberish; or with enough creativity, to show
something else? Could we cause a buffer overflow?

Running strace on acroread 5.05, I find:

lstat64("/tmp/fileBfoZHm", 0xbfffe07c)  = -1 ENOENT (No such file or directory)
Whatever for?

open("/dev/null", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = -1 ENOTDIR (Not a directory)
Does not Adobe know that?

open("/users/psz/.acrobat/prefs", O_RDWR|O_CREAT|O_TRUNC, 0666) = 4
open("/tmp/Acro9vBGma", O_RDWR|O_CREAT|O_TRUNC|O_EXCL, 0666) = 11
Thankfully my umask is sensible.

open("/usr/share/Acrobat/505/Resource/Font/AdobeFnt06.lst.padua", O_WRONLY|O_CREAT|O_TRUNC, 01037355510) = -1 EROFS 
(Read-only file system)
open("/tmp/AdobeFnt06.lst.1001", O_WRONLY|O_CREAT|O_TRUNC, 01037355510) = 4
Semi-random modes, as if Adobe used open() with two arguments only.
(Often zero when there is a filename on the acroread command line.)
BEWARE, even more if running as root!

fchmod(4, 0666)                         = 0
Applied to "/tmp/AdobeFnt06.lst.1001" above. The mode would be 600
when there is a TMPDIR; I do not know what mode would be applied to
"/usr/share/.../AdobeFnt06.lst.padua".


Workaround:

I use the following wrapper around acroread (move original script or
binary to acroread.real, put this in its place). Use TMPDIR, but also
ensure file in /tmp is safe (in case writing in TMPDIR fails for some
reason: diskquota?). With file in /tmp, leaves no race with the open()
in acroread, just a window of opportunity to mess with the data.

#!/usr/bin/perl --

$PROG = '/usr/share/Acrobat/505/bin/acroread.real';
$TMPF = "/tmp/AdobeFnt06.lst.$<";
$MYTD = "$ENV{'HOME'}/.acrobat";
$MYTF = "$MYTD/AdobeFnt06.lst.$<";

$ENV{'TMPDIR'} = $MYTD;

use Fcntl;

sub checkfix {
  my ($nam, $msg) = @_;
  ($dev,$ino,$mode,$nlink,$uid,$gid,@rest) = lstat( $nam );
  ( -f _ and ! -l _ and ! -d _ ) or die "$msg: $nam is not a file\n";
  # BEWARE: on some systems, $gid comes from directory
  ( $uid == $< and $gid == $( ) or die "$msg: $nam is not your own\n";
  ( $nlink == 1 ) or die "$msg: $nam has hardlinks\n";
  chmod( 0600, $nam ) or die "$msg: cannot chmod $nam\n";
}

$< > 99 or die "No daemons\n";

sysopen( F, $TMPF, O_RDWR|O_CREAT|O_EXCL, 0600 )
  and close( F )
  #and print "Pre-created $TMPF\n"
  ;

mkdir( $MYTD, 0700 )
  #and print "Pre-created $MYTD\n"
  ;
sysopen( F, $MYTF, O_RDWR|O_CREAT|O_EXCL, 0600 )
  and close( F )
  #and print "Pre-created $MYTF\n"
  ;

&checkfix( $TMPF, "Tricked" );
&checkfix( $MYTF, "Tricked" );
system( $PROG, @ARGV );
&checkfix( $TMPF, "After acroread" );
&checkfix( $MYTF, "After acroread" );

#!#


Vendor status:

Reported to Adobe upon discovery, on 29 May 2002. After some initial
difficulties, they seem to understand that there is a problem and that
it needs to be fixed; they say this will take several weeks at least.


Acknowledgements:

Thanks to a user of my system, for noticing the wide-open permissions on
the /tmp files.

Thanks to Jarno Huuskonen, for tips and discussion following his
coincidental post http://www.securityfocus.com/archive/1/277932 .


Paul Szabo - psz () maths usyd edu au  http://www.maths.usyd.edu.au:8000/u/psz/
School of Mathematics and Statistics  University of Sydney   2006  Australia

Current thread:

Acrobat reader 5.05 temp file insecurity Paul Szabo (Jun 26)
- Re: Acrobat reader 5.05 temp file insecurity Juan M. Courcoul (Jun 27)