Package: mplayer nws ppp twiki
Severity: grave
Tags: security

This message about the error concerns a few packages at once. I've
tested all the packages on my Debian mirror. (post|pre)(inst|rm) and
config scripts were tested.

In some packages I've discovered scripts with errors which may be used
by a user for damaging important system files.

For example if a script uses in its work a temp file which is created
in /tmp directory, then every user can create symlink with the same
name in this directory in order to destroy or rewrite some system
file.

I set Severity into grave for this bug. The table of discovered
problems is below.

+------------------+-----------------+----------------------------------
| package | script | file for attack
+------------------+-----------------+----------------------------------
| mplayer-1.0~rc2 | config | /tmp/HACK (pipe)
| | |
| nws-2.13 | postinst | /tmp/nws.debug (cp)
| | |
| ppp-2.4.4rel | postinst | /tmp/probe-finished (rm -f, pipe)
| | postinst | /tmp/ppp-errors (rm -f, pipe)
| ppp-udeb | /etc/ppp/ip-up | /tmp/resolv.conf.tmp (cp)
| | |
| twiki-4.1.2 | postinst | /tmp/twiki (chmod 1777, chown)
+------------------+-----------------+----------------------------------


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Mon, 11 Aug 2008 10:57:56 +0400, Dmitry E. Oboukhov wrote:

> Package: mplayer nws ppp twiki
> Severity: grave
> Tags: security
>
> This message about the error concerns a few packages at once. I've
> tested all the packages on my Debian mirror. (post|pre)(inst|rm) and
> config scripts were tested.
>
> In some packages I've discovered scripts with errors which may be used
> by a user for damaging important system files.
>
> For example if a script uses in its work a temp file which is created
> in /tmp directory, then every user can create symlink with the same
> name in this directory in order to destroy or rewrite some
system
> file.

A while ago, the use of libpam-tmpdir was suggested in order to mitigate
some of these attacks. It would be nice to see it in use by default, some
day.

Obviously there will always be some programs that don't look at the
TMPDIR environment variable and directly use /tmp. Isn't there some fancy
thing in current kernels that allows /tmp to be mounted individually for
each user?

--
Sam Morris
http://robots.org.uk/

PGP key id 1024D/5EA01078
3412 EA18 1277 354B 991B C869 B219 7FDB 5EA0 1078


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Dmitry E. Oboukhov wrote:
>>>> A while ago, the use of libpam-tmpdir was suggested in order to mitigate
>>>> some of these attacks. It would be nice to see it in use by default, some
>>>> day.
>>>> Obviously there will always be some programs that don't look at the
>>>> TMPDIR environment variable and directly use /tmp.
>>> write file to /tmp/filename == write file to $TMPDIR/filename
>>> both cases are security holes if TMPDIR=/tmp
>
>> The idea behind libpam-tmpdir is that it creates a subdirectory of /tmp
>> that is only accessible by that user, and then sets TMPDIR and other
>> variables to that. Hence, it doesn't matter nearly as much if you
>> create a non-random filename, because nobody but you can access it.
>
> Yes, but
> scripts must use $TMPDIR instead '/tmp' or mktemp/tempfile utils
tempfile uses $TMPDIR by default

--
Eugene V. Lyubimkin aka JackYF, Ukrainian C++ developer.

Dmitry E. Oboukhov wrote:
> EVL>>> The idea behind libpam-tmpdir is that it creates a subdirectory of /tmp
> EVL>>> that is only accessible by that user, and then sets TMPDIR and other
> EVL>>> variables to that. Hence, it doesn't matter nearly as much if you
> EVL>>> create a non-random filename, because nobody but you can access it.
> EVL>>
> EVL>> Yes, but
> EVL>> scripts must use $TMPDIR instead '/tmp' or mktemp/tempfile utils
> EVL> tempfile uses $TMPDIR by default
>
> sorry,
> scripts must use $TMPDIR or _must_ _use_ mktemp/tempfile

Why use $TMPDIR at all?

$TMPDIR may not be set (libpam-tmp may not be installed[1]), so you have
to test for it. If the test fails, you have to fall back to mktemp or
tempfile.

As mktemp and tempfile are both essential[2], they can be relied upon.

If $TMPDIR is set, it may be set to something bad, like /tmp. You can be
left with the exact same problem you are trying to solve.

Both mktemp and tempfile support $TMPDIR, and will fall back gracefully
if $TMPDIR does not exist in the environment.

My impression is that mktemp or tempfile should be used, and ignore
TMPDIR anyway. If you really need a directory to write lots of files to,
mktemp -d is there for you.

Is there any scenario where using mktemp or tempfile fails, and sing
$TMPDIR succeeds?

[1] % aptitude search libpam-tmp
p libpam-tmpdir - automatic per-user temporary directories

[2] % aptitude show $(dpkg -S $(which mktemp tempfile) | sed 's/:.*//') | grep -E '^(Pa|E)'
Package: mktemp
Essential: yes
Package: debianutils
Essential: yes

[3] I liked [2] too much to remove it. Sorry.

--
John H. Robinson, IV jaqque@debian.org
http ((((
WARNING: I cannot be held responsible for the above, sbih.org ( )(:[
as apparently my cats have learned how to type. spiders.html ((((


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Dmitry E. Oboukhov wrote:

qemu makes mount the directory /tmp/mount.$$. Attacker creates many
symlinks /tmp/dir.d+ -> /etc and if qemu
(/usr/sbin/qemu-make-debian-root) starts then /etc goes
out from root directory tree. The result: system is unusable.


I might be dense, but I don't get this.

Attacker does:

root@andean:/tmp# ln -s /etc /tmp/mount-1234

Then the genuine user does:

root@andean:/tmp# mkdir /tmp/mount-1234
mkdir: cannot create directory `/tmp/mount-1234': File exists

strace shows:
mkdir("/tmp/pmount-1234", 0777) = -1 EEXIST (File exists)

So, ok, this means the process can't continue any more (denial of
service attack), and if the process does continue this is a problem,
otherwise I can't see how this would bring the entire system down.


Brian May


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

"Dmitry E. Oboukhov" <unera@debian.org> writes:
> On 18:42 Wed 13 Aug , Brian May wrote:
>> Dmitry E. Oboukhov wrote:
>>> qemu makes mount the directory /tmp/mount.$$. Attacker creates many
>>> symlinks /tmp/dir.d+ -> /etc and if qemu
>>> (/usr/sbin/qemu-make-debian-root) starts then /etc goes
>>> out from root directory tree. The result: system is unusable.
>>>
>> I might be dense, but I don't get this.
>
>> Attacker does:
>
>> root@andean:/tmp# ln -s /etc /tmp/mount-1234
>
>> Then the genuine user does:
>
>> root@andean:/tmp# mkdir /tmp/mount-1234
>> mkdir: cannot create directory `/tmp/mount-1234': File exists
>
>> strace shows:
>> mkdir("/tmp/pmount-1234", 0777) = -1 EEXIST (File exists)
>
>> So, ok, this means the process can't continue any more (denial of
>> service attack), and if the process does continue this is a problem,
>> otherwise I can't see how this would bring the entire system down.
>
>> Brian May
>
> yes, set -e directive is present in this script


Don't know if this is considered an attack, but root may be tricked into
unmounting a file system pointed to by the symlink since the script also
does:

cleanup()
{
echo Cleaning up... >&2
umount -d /tmp/mount.$$ || true
rm -f $IMAGE.ext2 $IMAGE
}
trap cleanup EXIT


This will of course not do anything if the file system is busy which
limits its useability as a DoS attack. Anyway, it wouldn't harm if the
script used mktemp.


Bjørn
--
You know, Lassie was Moonie


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Wed, 13 Aug 2008, Brian May wrote:

Dmitry E. Oboukhov wrote:

qemu makes mount the directory /tmp/mount.$$. Attacker creates many
symlinks /tmp/dir.d+ -> /etc and if qemu
(/usr/sbin/qemu-make-debian-root) starts then /etc goes
out from root directory tree. The result: system is unusable.


I might be dense, but I don't get this.

Attacker does:

root@andean:/tmp# ln -s /etc /tmp/mount-1234

Then the genuine user does:

root@andean:/tmp# mkdir /tmp/mount-1234
mkdir: cannot create directory `/tmp/mount-1234': File exists

strace shows:
mkdir("/tmp/pmount-1234", 0777) = -1 EEXIST (File exists)

So, ok, this means the process can't continue any more (denial of service
attack), and if the process does continue this is a problem, otherwise I
can't see how this would bring the entire system down.


qemu-make-debian-root will continue running even if mkdir failed. Also,
assuming qemu-make-debian-root is running with PID 1234, an attacker is
free to change the /tmp/mount.1234 symlink during the execution of the
script. If /tmp/mount.1234 is linked to /etc/, the script will mount the
freshly created filesystem image on top of /etc, making a lot of programs
very sad.


An attacker could then change the symlink such that debbootstrap will
install anywhere he wants. (which may allow him to overwrite some files,
but I haven't looked closely at debbootstrap.)


And then he could change the symlink again to overwrite and delete a few
more files.


Of course some of these are timing attacks, so may work with varying
reliability.


Ivan


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Ivan Jager wrote:

qemu-make-debian-root will continue running even if mkdir failed.

Dmitry said the script has -e set - if so the script will not continue running if mkdir failed (unless it somehow overrides the -e check, e.g. mkdir /tmp/file || true).

Also, assuming qemu-make-debian-root is running with PID 1234, an
attacker is free to change the /tmp/mount.1234 symlink during the
execution of the script. If /tmp/mount.1234 is linked to /etc/, the
script will mount the freshly created filesystem image on top of /etc,
making a lot of programs very sad.


An attacker could then change the symlink such that debbootstrap will
install anywhere he wants. (which may allow him to overwrite some
files, but I haven't looked closely at debbootstrap.)
I don't think these attacks are possible if the script aborts when mkdir
fails. mkdir won't succeed if there is a symlink.


In any case, doing something better would be good because it means an
attacker can't run a denial-of-service type attack and prevent the
script from running.


Brian May


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Brian May wrote:
> Ivan Jager wrote:
>> qemu-make-debian-root will continue running even if mkdir failed.
> Dmitry said the script has -e set - if so the script will not continue
> running if mkdir failed (unless it somehow overrides the -e check, e.g.
> mkdir /tmp/file || true).

You must take care to sub shell, too. For example, try to type this in bash:
( set -e ; ( false ) ; echo ok )
You will see the 'ok'...
Situation can be more complex (function called from a sub shell, ...)

Regards,
Vincent

--
Vincent Danjean GPG key ID 0x9D025E87 vdanjean@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87
Unofficial pacakges: http://www-id.imag.fr/~danjean/deb.html#package
APT repo: deb http://perso.debian.org/~vdanjean/debian unstable main


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Hi *,

a little bit late, but since I am currently working in germany...


Am 2008-08-11 17:31:51, schrieb Sam Morris:
> A while ago, the use of libpam-tmpdir was suggested in order to mitigate
> some of these attacks. It would be nice to see it in use by default, some
> day.
>
> Obviously there will always be some programs that don't look at the
> TMPDIR environment variable and directly use /tmp. Isn't there some fancy
> thing in current kernels that allows /tmp to be mounted individually for
> each user?

I am using since some years a selvmade tool called tdtmpdir

[michelle.konzack@tp570:~] tdtmpdir --show-tmpdirs
You have following TMPDIR's cached:
FQDN | DIS | TMPDIR
---------------------------------+-----+--------------------------------------
| | /tmp/michelle.konzack.LbUVct
aspire1350.private.tamay-dogan.n | | /tmp/michelle.konzack.XC3917
mail.private.tamay-dogan.net | | /tmp/michelle.konzack.YG3771
samba3.private.tamay-dogan.net | | /tmp/michelle.konzack.iV5846
tp570.private.tamay-dogan.net | | /tmp/michelle.konzack.rATqyA
tp570.private.tamay-dogan.net | :0 | /tmp/michelle.konzack.rATqyA
tp570.private.tamay-dogan.net | :1 | /tmp/michelle.konzack.rATqyA


The TMPDIRS are cache with:

[michelle.konzack@tp570:~] ls .tmpdir*
-rw-r--r-- 1 michelle.konzack private 29 2007-11-01 22:00 .tmpdir_aspire1350.private.tamay-dogan.net
-rw-r--r-- 1 michelle.konzack private 29 2007-11-13 14:16 .tmpdir_mail.private.tamay-dogan.net
-rw-r--r-- 1 michelle.konzack private 29 2008-08-20 19:43 .tmpdir_samba3.private.tamay-dogan.net
-rw-r--r-- 1 michelle.konzack private 29 2008-08-19 23:19 .tmpdir_tp570.private.tamay-dogan.net
-rw-r--r-- 1 michelle.konzack private 29 2008-08-20 19:43 .tmpdir_tp570.private.tamay-dogan.net:0
-rw-r--r-- 1 michelle.konzack private 29 2007-12-29 22:04 .tmpdir_tp570.private.tamay-dogan.net:1


The FQDN is, because I am mounting /home/ over NFS and in the /etc/profile I have

if [ -x /bin/tdtmpdir ] ; then
. /bin/tdtmpdir
fi

and since not all programs are honoring $TMPDIR I have

[michelle.konzack@tp570:~] env |grep /tmp/
TMPDIR=/tmp/michelle.konzack.iV5846
TEMP=/tmp/michelle.konzack.iV5846
TEMPDIR=/tmp/michelle.konzack.iV5846
TMP=/tmp/michelle.konzack.iV5846

Unfortunately GIMP and OpenOffice ignore $TMPDIR and the other three
which is realy annoying. Some times ago I have already reported a BUG
against GIMP but it was closed.

Thanks, Greetings and nice Day/Evening
Michelle Konzack
Systemadministrator
24V Electronic Engineer
Tamay Dogan Network
Debian GNU/Linux Consultant


--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack Apt. 917 ICQ #328449886
+49/177/9351947 50, rue de Soultz MSN LinuxMichi
+33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com)