From:	 Darren Moffat <Darren.Moffat@eng.sun.com>
To:	 bugtraq@securityfocus.com, michael1cat@yahoo.com
Subject: Re: Adobe Acrobat creates world writable ~/AdobeFnt.lst files
Date:	 Wed, 22 Aug 2001 10:35:07 -0700 (PDT)

>Adobe Acrobat creates world writable ~/AdobeFnt.lst files
>
>This problem is present in at least the Linux version:
>ftp://ftp.adobe.com/pub/adobe/acrobatreader/unix/4.x/linux-ar-405.tar.gz
>
>Even with umask as restrictive as 077, the Adobe binary explicitly
>creates and changes the AdobeFnt.lst file in the HOME directory to be
>world (and group) writable.

What anoys me almost as much as ignoring the umask is that this file
is placed directly into $HOME and isn't a "." file.

>Vendor notified: on or before 2001-03-02

I notified Adobe of this on October 27th 1999 and never got any reply,
see attached.


Another possible workaround would be to create a shared object that
replaced the open/chmod calls that change the permissions on the file,
this could then be LD_PRELOAD'd so that acroread doesn't do the wrong thing.

Using truss on Solaris we can easily see that acroread actually makes
an explicit call to set the permissions to 0666.

251032: open("/home/darrenm/AdobeFnt.lst", O_WRONLY|O_CREAT|O_TRUNC, 01) = 6
251032: fchmod(6, 0666)         

--
Darren J Moffat




------------- Begin Included Message -------------

From darrenm Wed Oct 27 10:08:37 1999
Date: Wed, 27 Oct 1999 10:08:37 +0100 (BST)
From: Darren Moffat - Solaris Sustaining Engineering <darrenm@otis.uk>
Subject: Acrobat Reader 4.0 for Solaris
To: security@adobe.com
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_33 SunOS 5.8 sun4u sparc
Mime-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: vU9ym6j5UvaH9PQ8ueMX+A==
Content-Length: 654
Status:  O
X-Status: $$$$
X-UID: 0000000176

When starting the Acrobat Reader 4.0 for the first time a new file
called AdobeFnt.lst is created in the users home directory.  This file
is created with world writeable permissions (666).

Given that this file contains font mappings, this is a security hole as
it would allow someone else to replace your font definitions thus making
the documents appear different to what the author intended.

While you are fixing this security hole, may I suggest that you put the
file in a less obtrusive place.  Dumping non "." files in a users home
directory is considered very bad form in UNIX.

Thanks

--
Darren J Moffat
Solaris Software Sustaining Engineering

------------- End Included Message -------------