Acrobat Reader 5.0.5 on MacOS X does not seem to have this problem. It creates or overwrites the file /Library/Application Support/Adobe/Fonts/AdobeFnt.lst with the same owner as the user and with group "admin", but with 644 file 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 >
