[25947] in bugtraq
Acrobat reader 5.05 temp file insecurity
daemon@ATHENA.MIT.EDU (Paul Szabo)
Wed Jun 26 17:54:29 2002
Date: Tue, 25 Jun 2002 07:33:42 +1000 (EST)
From: psz@maths.usyd.edu.au (Paul Szabo)
Message-Id: <200206242133.g5OLXgS78108@milan.maths.usyd.edu.au>
To: bugtraq@securityfocus.com
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
