Debian Bug report logs - #334616
yiff-server: runs as root and opens any file a client asks for

Display info messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Javier Fernandez-Sanguino Pen~a <jfs@computer.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: yiff-server: runs as root and opens any file a client asks for

Date: Wed, 19 Oct 2005 02:03:41 +0200

Package: yiff-server
Version: 2.14.2-7
Severity: critical
Tags: security
Justification: root security hole

The yiff server, by default, will run as the root user, even though it
only requires privileges to access the audio devices (/dev/dsp and
/dev/mixer), no effort is make by the package to create an specific user
and run the server as such.

This means that this opens up yiff-server to, at least, local attacks,
since the localhost is always allowed access to the yiff server. Thus, a
rogue (local) user can get the yiff-server to (try to) open up any local
file. This can have bad consequences if a local user forces the yiff
server to open up a device file if even reading it might be dangerous
(consider the case, for example, if you can make the server read a hard
disk drive).


The server does not make any effort to review the files it is requested,
it will just open whatever is provided and try to determine if it's a
Wav, Voc, or Raw file and try to play it.

This day and age, servers like yiff should run

a) under a non-priviledged user
b) chrooted, if possible, so that it will only be able to access a set
   of files
c) do input checks to prevent it from going places it did not expect,
   for example, the server could only allow relative patchs and resolve
   them to a fixed directory (/var/spool/yiff or whatever)

It looks like the code of the server has not been audited for security
issues, which adds even more reasons to have this running as non-root in
the default Debian installation.

Regards

Javier


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.4.27-2-686
Locale: LANG=es_ES, LC_CTYPE=es_ES (charmap=ISO-8859-1)

Versions of packages yiff-server depends on:
ii  debconf [debconf-2.0]         1.4.58     Debian configuration management sy
ii  libc6                         2.3.5-6    GNU C Library: Shared libraries an
ii  liby2-14                      2.14.2-7   Y Sound Server Library

yiff-server recommends no packages.

-- debconf information excluded

Message #10 received at 334616@bugs.debian.org (full text, mbox, reply):

From: Phil Brooke <pjb@cs.york.ac.uk>

To: Javier Fernandez-Sanguino Pen~a <jfs@computer.org>, 334616@bugs.debian.org

Subject: Re: Bug#334616: yiff-server: runs as root and opens any file a client asks for

Date: Wed, 19 Oct 2005 08:48:49 +0100 (BST)

> The yiff server, by default, will run as the root user, even though it
> only requires privileges to access the audio devices (/dev/dsp and
> /dev/mixer), no effort is make by the package to create an specific user
> and run the server as such.
> [...]

I agree that this is badly broken.  Thanks for the report.

Can you assist? (e.g., do you have a patch available?)  I don't have
access to a suitable machine at the moment (I'm moving home, starting new
job, etc.).  Otherwise, I'll tag this as needing help and do what I can on
the project machines.

Cheers,

Phil.

Message #15 received at 334616@bugs.debian.org (full text, mbox, reply):

From: Javier Fernández-Sanguino Peña <jfs@computer.org>

To: Phil Brooke <pjb@cs.york.ac.uk>

Cc: 334616@bugs.debian.org

Subject: Re: Bug#334616: yiff-server: runs as root and opens any file a client asks for

Date: Wed, 19 Oct 2005 10:49:19 +0200

[Message part 1 (text/plain, inline)]

On Wed, Oct 19, 2005 at 08:48:49AM +0100, Phil Brooke wrote:
> > The yiff server, by default, will run as the root user, even though it
> > only requires privileges to access the audio devices (/dev/dsp and
> > /dev/mixer), no effort is make by the package to create an specific user
> > and run the server as such.
> > [...]
> 
> I agree that this is badly broken.  Thanks for the report.
> 
> Can you assist? (e.g., do you have a patch available?)  I don't have
> access to a suitable machine at the moment (I'm moving home, starting new
> job, etc.).  Otherwise, I'll tag this as needing help and do what I can on
> the project machines.

I don't have a patch available, but I could write one that:

a) modifies the postinst/postrm to create a 'yiff' user (might need to belong
   to the 'audio' group too)
b) modifies the init script to run yiff-server as the 'yiff' user instead of as
   root
c) creates /var/run/yiff/ so that the pidfile can be created by the program
   there (the directory should belong to 'yiff' so it needs to be created on
   package installation by root)

That would mitigate the risk a lot, another improvement, which might need to
change code in the source package include limiting file calls to only access
a given directory and reject absolute paths  (i.e. those including a '/')
from client requests. That would prevent remote attacks to the server by
having it read files that a remote user would not have access otherwise.

Regards

Javier

[signature.asc (application/pgp-signature, inline)]

Message #20 received at 334616-quiet@bugs.debian.org (full text, mbox, reply):

From: Phil Brooke <pjb@cs.york.ac.uk>

To: Javier Fernández-Sanguino Peña <jfs@computer.org>, 334616-quiet@bugs.debian.org

Subject: Re: Bug#334616: yiff-server: runs as root and opens any file a client asks for

Date: Wed, 19 Oct 2005 12:58:10 +0100 (BST)

On Wed, 19 Oct 2005, Javier [UTF-8] Fernández-Sanguino [UTF-8] Peña wrote:
> I don't have a patch available, but I could write one that:
>
> a) modifies the postinst/postrm to create a 'yiff' user (might need to belong
>    to the 'audio' group too)
> b) modifies the init script to run yiff-server as the 'yiff' user instead of as
>    root
> c) creates /var/run/yiff/ so that the pidfile can be created by the program
>    there (the directory should belong to 'yiff' so it needs to be created on
>    package installation by root)

Those three points should fix the problem you've identified.

I wouldn't worry about the other two bugs you filed -- I should be able to
tidy those up within a few weeks (I hope!).

> That would mitigate the risk a lot, another improvement, which might need to
> change code in the source package include limiting file calls to only access
> a given directory and reject absolute paths  (i.e. those including a '/')
> from client requests. That would prevent remote attacks to the server by
> having it read files that a remote user would not have access otherwise.

Probably not worth the effort right now: it's been previously suggested
that the only depending package (searchandrescue) should use something
else for its audio support.  I might investigate that again.

Alternatively, we could suggest this to upstream.

Cheers,

Phil.

Message #27 received at 334616-quiet@bugs.debian.org (full text, mbox, reply):

From: Javier Fernández-Sanguino Peña <jfs@computer.org>

To: Phil Brooke <pjb@cs.york.ac.uk>

Cc: 334616-quiet@bugs.debian.org, control@bugs.debian.org

Subject: Re: Bug#334616: yiff-server: runs as root and opens any file a client asks for

Date: Thu, 20 Oct 2005 01:28:53 +0200

[Message part 1 (text/plain, inline)]

tags 334616 patch
thanks

On Wed, Oct 19, 2005 at 12:58:10PM +0100, Phil Brooke wrote:
> 
> Those three points should fix the problem you've identified.
> 
> I wouldn't worry about the other two bugs you filed -- I should be able to
> tidy those up within a few weeks (I hope!).

Attached is a patch introducing a 'yiff' user (and group) for the package and
making the server run as such. I've tested (albeit slightly) to confirm that
the user is created on installation, the server starts correctly, and the
user is removed on purge.

[ Notes on using chroot () ]
> Alternatively, we could suggest this to upstream.

Yes, either that or make upstream warn louder that this software should run
with lower priviledges.

Regards

Javier

[yiff-drop-privs.diff (text/plain, attachment)]

[signature.asc (application/pgp-signature, inline)]

Message #32 received at 334616@bugs.debian.org (full text, mbox, reply):

From: Moritz Muehlenhoff <jmm@inutil.org>

To: 334616@bugs.debian.org

Cc: jfs@computer.org

Subject: This doesn't seem to be a serious security problem

Date: Fri, 21 Oct 2005 11:44:58 +0200

Hi,
while I agree that running yiff with lesser privileges is desirable
I can't see a RC security problem in this case. You can't crash
a system be reading from /dev, /proc or /sys, even reading from raw
hard disk devices doesn't cause harm. If you know such a scenario
please describe it, otherwise this bug should be downgraded to
"normal".
From your description yiff does sanity checks, whether a file it has
opened is really a sound file, so I don't even see an acoustic DoS
attack here :-)

Cheers,
         Moritz

Message #37 received at 334616@bugs.debian.org (full text, mbox, reply):

From: Florian Weimer <fw@deneb.enyo.de>

To: Moritz Muehlenhoff <jmm@inutil.org>

Cc: 334616@bugs.debian.org, jfs@computer.org

Subject: Re: Bug#334616: This doesn't seem to be a serious security problem

Date: Fri, 21 Oct 2005 12:07:47 +0200

* Moritz Muehlenhoff:

> while I agree that running yiff with lesser privileges is desirable
> I can't see a RC security problem in this case. You can't crash
> a system be reading from /dev, /proc or /sys, even reading from raw
> hard disk devices doesn't cause harm. If you know such a scenario
> please describe it, otherwise this bug should be downgraded to
> "normal".

It's still a privacy issue, it seems.  I think you can ask it to serve
any sound file on the system.

Message #42 received at 334616@bugs.debian.org (full text, mbox, reply):

From: Javier Fernández-Sanguino Peña <jfs@computer.org>

To: Moritz Muehlenhoff <jmm@inutil.org>

Cc: 334616@bugs.debian.org

Subject: Re: This doesn't seem to be a serious security problem

Date: Fri, 21 Oct 2005 18:32:37 +0200

[Message part 1 (text/plain, inline)]

On Fri, Oct 21, 2005 at 11:44:58AM +0200, Moritz Muehlenhoff wrote:
> Hi,
> while I agree that running yiff with lesser privileges is desirable
> I can't see a RC security problem in this case. You can't crash
> a system be reading from /dev, /proc or /sys, even reading from raw
> hard disk devices doesn't cause harm. If you know such a scenario
> please describe it, otherwise this bug should be downgraded to
> "normal".

Reading from a device does not lock it, unless in some special cases, but
this daemon will happily read any file and "voice" it out. There's potential
security issues there, see below.

> >From your description yiff does sanity checks, whether a file it has
> opened is really a sound file, so I don't even see an acoustic DoS
> attack here :-)

It does those sanity checks by reading the file and trying to determine if
it's a valid music file, but one of those is the "raw format" which accepts
anything as a valid file:

yiff-2.14.2/yiff$ grep IsFile *.h
midi.h:extern int MidiIsFileMidi(const char *filename);
raw.h:extern int RawIsFileRaw(const char *filename);
voc.h:extern int VocIsFileVoc(const char *filename);
wav.h:extern int WavIsFileWav(const char *filename);

Notice, however this:

-------------------------------------------------------
int RawReadHeader(const char *filename, FILE *fp, raw_data_struct *rd)
{
(...)

        /* Here we should be checking if this is a raw file, but there
         * really is no way to tell so just assume that it is a raw
         * file.
         */

        /* Begin reading raw file header. */

        /* Record file name. */
        if(filename != NULL)
            rd->filename = strdup(filename);
(...)
}
-------------------------------------------------------

And  AFWOpen() calls that (as a last resort) to try to determine the sound
format. So files that are _not_ sound files are sent to the audio device. Try
this for yourself: 'yplay /etc/shadow' (mine sounds like a 'brrtit!' :-)

Not that it is inmediately possible to interpret the sound and convert it
(again) into bits. Not that I'm going to write such a program, the days I did
sound analysis are gone. But we are not going to determine the gravity of
security bugs just because somebody has not written a tool to exploit them
(yet). As Bruce Schneier says "attacks only get better, never get worst".

Also, and more importantly, yiff-server has _not_ been thoroughly audited for
security bugs (format strings, buffer overflows...). Having the server read
any file (even one specially crafted) is equivalent to having a setuid
program running on untrusted input. You rather be damn sure it has been
audited or you will see a remote code exploitation issue (as root) in the
future. I'm pretty sure the upstream author's don't intend to have this
(game-oriented) daemon running as root.

The patch I sent is really straightforward, does not reduce the functionality
and does not hinder the use of the server by local users. It only reduces the
scope of the files the server can read (to those the 'yiff' user can). It is
easily applied to both sid, sarge and woody.

This a security bug with (potentially) dangerous consequences with a
straightforward fix I'd say that it should be considered a RC bug and an RSA
should be issued to fix it.

Regards

Javier

[signature.asc (application/pgp-signature, inline)]

Message #47 received at 334616-quiet@bugs.debian.org (full text, mbox, reply):

From: Phil Brooke <pjb@cs.york.ac.uk>

To: Javier Fernández-Sanguino Peña <jfs@computer.org>

Cc: 334616-quiet@bugs.debian.org

Subject: Re: Bug#334616: yiff-server: runs as root and opens any file a client asks for

Date: Tue, 25 Oct 2005 15:50:52 +0100 (BST)

On Thu, 20 Oct 2005, Javier [iso-8859-1] Fernández-Sanguino Peña wrote:

> tags 334616 patch
> thanks

Many thanks for the patch.  For today and tomorrow, I have intermittent
access to my dev machine, so I've looked over the patch, applied it and
just now uploaded it.

I think that this will be worth mentioning to the security team as a
possible security update.  I will copy the emails to you.

Cheers,

Phil.

Message #52 received at 334616-close@bugs.debian.org (full text, mbox, reply):

From: Phil Brooke <pjb@debian.org>

To: 334616-close@bugs.debian.org

Subject: Bug#334616: fixed in yiff 2.14.2-8

Date: Tue, 25 Oct 2005 08:02:08 -0700

Source: yiff
Source-Version: 2.14.2-8

We believe that the bug you reported is fixed in the latest version of
yiff, which is due to be installed in the Debian FTP archive:

liby-dev_2.14.2-8_i386.deb
  to pool/main/y/yiff/liby-dev_2.14.2-8_i386.deb
liby2-14_2.14.2-8_i386.deb
  to pool/main/y/yiff/liby2-14_2.14.2-8_i386.deb
yiff-server_2.14.2-8_i386.deb
  to pool/main/y/yiff/yiff-server_2.14.2-8_i386.deb
yiff_2.14.2-8.diff.gz
  to pool/main/y/yiff/yiff_2.14.2-8.diff.gz
yiff_2.14.2-8.dsc
  to pool/main/y/yiff/yiff_2.14.2-8.dsc



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 334616@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Phil Brooke <pjb@debian.org> (supplier of updated yiff package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Tue, 25 Oct 2005 15:11:44 +0100
Source: yiff
Binary: liby-dev liby2-14 yiff-server
Architecture: source i386
Version: 2.14.2-8
Distribution: unstable
Urgency: low
Maintainer: Phil Brooke <pjb@debian.org>
Changed-By: Phil Brooke <pjb@debian.org>
Description: 
 liby-dev   - Y Sound Server Library Header Files
 liby2-14   - Y Sound Server Library
 yiff-server - Y Sound Server
Closes: 334616
Changes: 
 yiff (2.14.2-8) unstable; urgency=low
 .
   * Added patch from Javier Fernandez-Sanguino Pen~a (closes: #334616)
     with the following changes:
   * Create a user 'yiff' (group 'yiff') to run the yiff-server, its home
     directory is /var/lib/yiff (currently unused, but could be used to setup
     a chroot)
     - new debian/yiff-server.preinst that creates the user and assigns it
       to the 'audio' group
     - modified debian/yiff-server.postrm to remove the user and the new
       files (/var/lib/yiff) as well as the new PID location (/var/run/yiff/)
     - modified debian/yiff-server.init so that it runs as the 'yiff' user
     - adjusted location of PIDFILE in yiff/main.c to point to
      /var/run/yiff/yiff.pid
   * Pre-Depends on adduser as we use it on preinst
Files: 
 fbf44369d55b9efc0b6ced04b55d18a7 664 libs optional yiff_2.14.2-8.dsc
 f2bf1769ed01c5b4a55e8db17bed2ce2 31623 libs optional yiff_2.14.2-8.diff.gz
 651ab65c4b04cff9f4c5d1a69ec9fd09 149346 sound optional yiff-server_2.14.2-8_i386.deb
 858dc42d616be4d1d403f1b67b421773 32650 libs optional liby2-14_2.14.2-8_i386.deb
 f4fd5446d5a66cfa3c679bb14869f1b7 89974 libdevel optional liby-dev_2.14.2-8_i386.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDXkToHb8HEVCXO5ERAskFAKCj+1BhP9j3gdxzMcYjf26Gpd27xgCgztTb
I4WVpwmsM1EEEDGn9q30YxU=
=sznA
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.