6954840 2001-08-22 05:55 -0700 /111 rader/ Michael Paoli <michael1cat@yahoo.com>
Sänt av: joel@lysator.liu.se
Importerad: 2001-08-22 16:46 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Extern kopiemottagare: michael1cat@yahoo.com
Mottagare: Bugtraq (import) <18898>
Ärende: Adobe Acrobat creates world writable ~/AdobeFnt.lst files
------------------------------------------------------------
From: Michael Paoli <michael1cat@yahoo.com>
To: bugtraq@securityfocus.com
Cc: michael1cat@yahoo.com
Message-ID: <3B83ABD1.E1C10330@yahoo.com>
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.
Work-arounds are possible, such as by using wrapper script(s). Note
that direct patching of the Adobe binary would apparently conflict
with the Adobe license.
Vendor notified: on or before 2001-03-02
references/excerpts:
ftp://ftp.adobe.com/pub/adobe/acrobatreader/unix/4.x/linux-ar-405.tar.gz
http://www.google.com/search?q=AdobeFnt.lst+security&btnG=Google+Search
http://bugs.debian.org/acroread
ftp://ftp.debian.org/debian/pool/non-free/a/acroread/acroread_4.05-4.diff.gz
http://www.wiretrip.net/rfp/policy.html
example work-around wrappers (use at your own risk, standard disclaimers
apply ...):
########################################################################
if [ ! -e $HOME/AdobeFnt.lst ]; then
# AcroRead will happily create a world writable AdobeFnt.lst ...
trap "rm -f $HOME/AdobeFnt.lst" 0
ln -s /dev/null $HOME/AdobeFnt.lst
fi
########################################################################
#wrapper stuff to work around world writable ~/AdobeFnt.lst issues
#directory we'll use, relative to HOME, to work around the problem
kludgedir=.AdobeFnt.security_kludge_dir
#check HOME isn't null
[ X"$HOME" != X ] || {
1>&2 echo "$0: HOME is unset or null - aborting"
exit 1
}
#if pathname for our kludge directory exists
if >>/dev/null 2>&1 ls -d "$HOME/$kludgedir"
then
#check that it's properly secured
2>>/dev/null ls -lLd "$HOME/$kludgedir" | >>/dev/null 2>&1 grep '^d....--.--' || {
#not properly secured, complain and exit
1>&2 echo "$0: found $HOME/$kludgedir but expecting directory with no group or world write or execute permissions - aborting"
exit 1
}
else
#"$HOME/$kludgedir" doesn't exist, make it
(umask 077 && mkdir -p "$HOME/$kludgedir")
#we should have properly secure "$HOME/$kludgedir" at this point, verify
2>>/dev/null ls -lLd "$HOME/$kludgedir" | >>/dev/null 2>&1 grep '^d....--.--' || {
1>&2 echo "$0: unable to create properly secured $HOME/$kludgedir - aborting"
exit 1
}
fi
#does "$HOME"/AdobeFnt.lst exist in any form?
if >>/dev/null 2>&1 ls -d "$HOME"/AdobeFnt.lst
then
#"$HOME"/AdobeFnt.lst may already be set up properly - check
if [ X"`2>>/dev/null ls -ld "$HOME"/AdobeFnt.lst | sed -ne 's/^l.* -> \(.*\)/\1/p'`" != X"$kludgedir"/AdobeFnt.lst ]
then
#it's not what we were hoping for ... is it ordinary file?
if [ ! -L "$HOME"/AdobeFnt.lst -a -f "$HOME"/AdobeFnt.lst ]
then
rm -f "$HOME"/AdobeFnt.lst
#is it gone?
[ ! -f "$HOME"/AdobeFnt.lst ] || {
1>&2 echo "$0: failed to remove $HOME/AdobeFnt.lst file - aboring"
exit 1
}
ln -s "$kludgedir"/AdobeFnt.lst "$HOME"/AdobeFnt.lst
#test that "$HOME"/AdobeFnt.lst has been set up properly
[ X"`2>>/dev/null ls -ld "$HOME"/AdobeFnt.lst | sed -ne 's/^l.* -> \(.*\)/\1/p'`" = X"$kludgedir"/AdobeFnt.lst ] || {
1>&2 echo "$0: failed to create proper secure $HOME/AdobeFnt.lst - aborting"
exit 1
}
else
1>&2 echo "$0: $HOME/AdobeFnt.lst isn't set up as we need it, please remove it - aborting"
exit 1
fi
fi
else
ln -s "$kludgedir"/AdobeFnt.lst "$HOME"/AdobeFnt.lst
#test that "$HOME"/AdobeFnt.lst has been set up properly
[ X"`2>>/dev/null ls -ld "$HOME"/AdobeFnt.lst | sed -ne 's/^l.* -> \(.*\)/\1/p'`" = X"$kludgedir"/AdobeFnt.lst ] || {
1>&2 echo "$0: failed to create proper secure $HOME/AdobeFnt.lst - aborting"
exit 1
}
fi
#we're done with the kludgedir shell variable
unset kludgedir
########################################################################
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
(6954840) /Michael Paoli <michael1cat@yahoo.com>/(Ombruten)
6955581 2001-08-22 10:35 -0700 /75 rader/ Darren Moffat <Darren.Moffat@eng.sun.com>
Sänt av: joel@lysator.liu.se
Importerad: 2001-08-22 19:47 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Extern mottagare: michael1cat@yahoo.com
Externa svar till: Darren.Moffat@eng.sun.com
Mottagare: Bugtraq (import) <18902>
Ärende: Re: Adobe Acrobat creates world writable ~/AdobeFnt.lst files
------------------------------------------------------------
From: Darren Moffat <Darren.Moffat@eng.sun.com>
To: bugtraq@securityfocus.com, michael1cat@yahoo.com
Message-ID: <200108221735.f7MHZmH253088@jurassic.eng.sun.com>
>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 -------------
(6955581) /Darren Moffat <Darren.Moffat@eng.sun.com>/(Ombruten)
6955974 2001-08-22 20:54 +0200 /22 rader/ <wim@djo.wtm.tudelft.nl>
Sänt av: joel@lysator.liu.se
Importerad: 2001-08-22 21:19 av Brevbäraren
Extern mottagare: Darren.Moffat@eng.sun.com
Extern kopiemottagare: Wim Osterholt <wim@djo.wtm.tudelft.nl>
Extern kopiemottagare: bugtraq@securityfocus.com
Externa svar till: wim@djo.wtm.tudelft.nl
Mottagare: Bugtraq (import) <18906>
Ärende: Re: Adobe Acrobat creates world writable ~/AdobeFnt.lst files
------------------------------------------------------------
From: wim@djo.wtm.tudelft.nl
To: Darren.Moffat@eng.sun.com
Cc: wim@djo.wtm.tudelft.nl (Wim Osterholt), bugtraq@securityfocus.com
Message-ID: <20010822185446.6738.qmail@djo.wtm.tudelft.nl>
> >Adobe Acrobat creates world writable ~/AdobeFnt.lst files
...
> 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.
And what if that call fails?
chattr +i will do miracles, I imagine.
Regards, Wim.
(6955974) / <wim@djo.wtm.tudelft.nl>/---------------
6956719 2001-08-22 13:34 -0700 /97 rader/ Darren Moffat <Darren.Moffat@eng.sun.com>
Sänt av: joel@lysator.liu.se
Importerad: 2001-08-23 00:00 av Brevbäraren
Extern mottagare: wim@djo.wtm.tudelft.nl
Extern kopiemottagare: bugtraq@securityfocus.com
Externa svar till: Darren.Moffat@eng.sun.com
Mottagare: Bugtraq (import) <18907>
Ärende: Re: Adobe Acrobat creates world writable ~/AdobeFnt.lst files
------------------------------------------------------------
From: Darren Moffat <Darren.Moffat@eng.sun.com>
To: wim@djo.wtm.tudelft.nl
Cc: bugtraq@securityfocus.com
Message-ID: <200108222034.f7MKYxH305924@jurassic.eng.sun.com>
>> >Adobe Acrobat creates world writable ~/AdobeFnt.lst files
>...
>> 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.
>
>And what if that call fails?
What call ?
Note this code doesn't compile and is intended only as an outline of
what could be done. dlsym is how this is done on Solaris but there
are equivalent calls in most systems that have dynamic linking.
include <sys/types.h>
#include <dlfcn.h>
#include <stdio.h>
#include <stdlib.h>
static int fd = -1;
int open(const char *path, int oflag, ...)
{
static int (*fptr)(const char *path, int oflag, ...) = 0;
if (fptr == 0) {
fptr = dlsym(RTLD_NEXT, "open");
if (fptr == NULL) {
(void) printf("dlopen: %s\n", dlerror());
return NULL;
}
}
if (strcmp(path, fntlst) == 0)
fd = ((*fptr)(path, oflag));
return (fd);
else {
return ((*fptr)(path, oflag));
}
}
int fchmod(int fildes, mode_t mode)
{
static int (*fptr)(int fildes, mode_t mode) = 0;
if (fptr == 0) {
fptr = dlsym(RTLD_NEXT, "fchmod");
if (fptr == NULL) {
(void) printf("dlopen: %s\n", dlerror());
return NULL;
}
}
if ((fd != -1) && (fildes == fd)) {
mode = 0600;
}
return ((*fptr)(fildes, mode));
}
int close(int fildes)
{
static int (*fptr)(int fildes, mode_t mode) = 0;
if (fptr == 0) {
fptr = dlsym(RTLD_NEXT, "fchmod");
if (fptr == NULL) {
(void) printf("dlopen: %s\n", dlerror());
return NULL;
}
if (fd == fildes) {
fd = -1;
}
return ((*fptr(fildes));
}
>chattr +i will do miracles, I imagine.
The world is not Linux on ext2fs. Also that may break something
else, you don't really want AdobeFnt.lst being an imutable file, you
just want correct permissions on it.
--
Darren J Moffat
(6956719) /Darren Moffat <Darren.Moffat@eng.sun.com>/(Ombruten)
Kommentar i text 6956980 av Scott Howard <scott@doc.net.au>
6956980 2001-08-23 08:34 +1000 /27 rader/ Scott Howard <scott@doc.net.au>
Sänt av: joel@lysator.liu.se
Importerad: 2001-08-23 01:00 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <18910>
Kommentar till text 6956719 av Darren Moffat <Darren.Moffat@eng.sun.com>
Ärende: Re: Adobe Acrobat creates world writable ~/AdobeFnt.lst files
------------------------------------------------------------
From: Scott Howard <scott@doc.net.au>
To: bugtraq@securityfocus.com
Message-ID: <20010823083436.A26116@milliways.doc.net.au>
> >> >Adobe Acrobat creates world writable ~/AdobeFnt.lst files
> 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.
How about :
mkdir ~/.adobe
chmod 600 ~/.adobe
mv ~AdobeFnt.lst ~/.adobe/
ln -s ~/.adobe/AdobeFnt.lst ~
As the chmod will follow the symlink, it will change the permissions
of the file, not the link. This means that the file itself still ends
up as mode 0666, but as the directory it's in is mode 0600, then
nobody will be able to access it other than the owner.
Adding the above (with some checking that it hasn't already been
done, etc) to a script which start Acrobat would handle the problem
for all users.
Scott.
(6956980) /Scott Howard <scott@doc.net.au>/(Ombruten)
6963304 2001-08-23 13:07 -0700 /49 rader/ Darren Moffat <Darren.Moffat@eng.sun.com>
Sänt av: joel@lysator.liu.se
Importerad: 2001-08-23 22:42 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Externa svar till: Darren.Moffat@eng.sun.com
Mottagare: Bugtraq (import) <18930>
Ärende: Re: Adobe Acrobat creates world writable ~/AdobeFnt.lst files
------------------------------------------------------------
From: Darren Moffat <Darren.Moffat@eng.sun.com>
To: bugtraq@securityfocus.com
Message-ID: <200108232008.f7NK8PH602485@jurassic.eng.sun.com>
The AdobeFnt.lst file is actually comes from libCoolType.so.1 so
there is potential that other Adobe software that uses
libCoolType.so.1 would also be vulnerable to this bug.
I don't know if there is other stuff that uses libCoolType or not,
but looking at the symbol table it appears that it is a font library
of sorts [I also noticed that it was compiled with gcc ;-)].
It appears that the permissions are only set insecurely if the file
didn't already exist, so a very simple wrapper around AdobeFnt.lst
that created the file with good permissions first would probably
suffice.
Using truss on Solaris I discovered that the creation of the
AdobeFnt.lst file in the users home directory is the only time that
fchmod(fd, 0666) was called so my previous LD_PRELOAD fix that
circumvents Adobe's poor security can be simplfied to just this
(which I have compiled and tested):
#include <limits.h>
#include <sys/types.h>
#include <dlfcn.h>
#include <stdio.h>
#include <stdlib.h>
int fchmod(int fildes, mode_t mode)
{
static int (*fptr)(int fildes, mode_t mode) = 0;
if (fptr == 0) {
fptr = (int (*)(int, mode_t))dlsym(RTLD_NEXT, "fchmod");
if (fptr == NULL) {
(void) printf("dlopen: %s\n", dlerror());
return NULL;
}
}
mode = 0600;
return ((fptr)(fildes, mode));
}
--
Darren J Moffat
(6963304) /Darren Moffat <Darren.Moffat@eng.sun.com>/(Ombruten)