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 - pszmaths.usyd.edu.au http://www.maths.usyd.edu.au:8000/u/psz/
> School of Mathematics and Statistics University of Sydney 2006 Australia
>

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]