8652440 2002-06-25 07:33 +1000  /135 rader/ Paul Szabo <psz@maths.usyd.edu.au>
Sänt av: joel@lysator.liu.se
Importerad: 2002-06-26  23:53  av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <22826>
Ärende: Acrobat reader 5.05 temp file insecurity
------------------------------------------------------------
From: psz@maths.usyd.edu.au (Paul Szabo)
To: bugtraq@securityfocus.com
Message-ID: <200206242133.g5OLXgS78108@milan.maths.usyd.edu.au>

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
(8652440) /Paul Szabo <psz@maths.usyd.edu.au>/(Ombruten)
Kommentar i text 8657977 av Juan M. Courcoul <courcoul@campus.qro.itesm.mx>
8657977 2002-06-26 19:04 -0500  /152 rader/ Juan M. Courcoul <courcoul@campus.qro.itesm.mx>
Sänt av: joel@lysator.liu.se
Importerad: 2002-06-28  01:44  av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Externa svar till: courcoul@campus.qro.itesm.mx
Mottagare: Bugtraq (import) <22864>
Kommentar till text 8652440 av Paul Szabo <psz@maths.usyd.edu.au>
Ärende: Re: Acrobat reader 5.05 temp file insecurity
------------------------------------------------------------
From: "Juan M. Courcoul" <courcoul@campus.qro.itesm.mx>
To: bugtraq@securityfocus.com
Message-ID: <3D1A569A.6030909@campus.qro.itesm.mx>

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
>
(8657977) /Juan M. Courcoul <courcoul@campus.qro.itesm.mx>/(Ombruten)