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
Description: Digital signature
