Re: [Security-Discuss] Xine accessing /etc/passwd ????

On Mon May 22 2006 10:57 am, Stew Benedict wrote:
> On Sun, 21 May 2006, Mark Ouellet wrote:
> > On Sun May 21 2006 02:58 pm, Michael Scherer wrote:
> > > Le dimanche 21 mai 2006 à 09:36 -0400, Tuxiq a écrit :
> > > > 	OK guys this is my first post so I apologize in advance for any
> > > > mistakes...
> > > >
> > > > I noticed my latest XINE, when started from a konsole and provided
> > > > with a filename on the command line, suddenly started giving me the
> > > > following message when exiting ....
> > > >
> > > > 	mkdir(/spook) failed: Permission denied
> > > >
> > > > where "spook" is my normal user name. So I was curious and did an
> > > > STRACE of xine which revealed that something in the process was
> > > > accessing the /etc/passwd file and looking up the <root> entry
> > > > !!?????
> > > >
> > > > IS THIS NORMAL BEHAVIOUR???????
> > >
> > > can you please avoid overreacting ( ie no caps, no '!!!' and '???' ) ?
> >
> > Sorry Michael, but who is overreacting here? I was just trying to bring
> > attention to the point of the message which was, my wondering if it was
> > normal behaviour.
> >
> > Someone once said, "it is better to let people think you are a moron,
> > then to open your mouth and remove all doubts..." unfortunately this
> > doesn't apply to security. Some problems can be avoided by speaking up at
> > the risk of passing for a moron. I saw something that didn't make sense
> > to me and spoke up. If it's normal fine, if not, someone will now
> > hopefully be aware of it.
> >
> > > if you use strace, you will see that ls and most process actually
> > > read /etc/passwd to have information like the username, the group, etc
> > > etc. And so does xine.
> > >
> > > This is a normal behavior.
> >
> > Ok, but, I wasn't working as root at the time and that is the entry xine
> > read from the ect/passwd, not the entry for my current user. I can
> > understand reading the password file for the reason you mentionned. Which
> > would mean reading the entry for "spook" in my example. But I don't
> > understand why it was looking at "root" instead?
> >
> > > And, the file /etc/passwd is world readable because it no longer
> > > contain anything sensitive since years.
> > > The hash of the password is in /etc/shadow, as explained on almost unix
> > > tutorial on the subject.
> >
> > Yes, thanks. I'm well aware of the shadow file. And allthough the shadow
> > files have existed for a while, don't assume everyone is using an up to
> > date version of their OS. I'm sure hackers don't make that assumption. In
> > fact hackers make it a point to try every know trick in the book counting
> > on the fact that you are NOT using the latest version and still haven't
> > plugged some of the holes.
> >
> > Sorry if I offended you with my question. I debated for a while, the pros
> > and cons of posting it. My worry was that someone might simply skim the
> > subjects and assume xine had some security hole in it without reading
> > through.
> >
> > I love Xine, and jeoperdizing it is the farthest idea from my mind but
> > the "mkdir" thing is new and didn't make sense to me. Why create a
> > directory with the users name on the "/" <root> partition specially in
> > the termination phase of the program? A badly written hack might do just
> > that. Or it could just be a mistake introduced by a patched and the
> > directory is part of the routine to save parameters or a playlist, etc...
> > What ever the reason, someone needed to be made aware of it either to
> > correct a bug or fix a security risk. Better safe than sorry.
> >
> > Thanks for your reply.
>
> I'm working on another update for xine-lib, and had noted the "mkdir"
> issue myself earlier. It looks like it's coming from
> src/input/input_cdda.c:
>
>       /* file or directory no exist, create it */
>       if(mkdir(path, 0755) < 0) {
>         xprintf(xine, XINE_VERBOSITY_DEBUG,
>                 "input_cdda: mkdir(%s) failed: %s.\n", path,
> strerror(errno)); return;
>       }
>
> This isn't from any of our security patches, but from upstream. Cooker
> behaves the same way, and xine-lib cvs still has the same code.
> The only patch to this file is this (format string vulnerability):
>
> --- ./src/input/input_cdda.c.can-2005-2967      2005-05-28
> 03:26:59.000000000 -0600
> +++ ./src/input/input_cdda.c    2006-05-22 07:50:22.483789797 -0600
> @@ -1473,7 +1473,7 @@ static void _cdda_save_cached_cddb_infos
>      return;
>    }
>    else {
> -    fprintf(fd, filecontent);
> +    fprintf(fd, "%s", filecontent);
>      fclose(fd);
>    }
>
> The /etc/passwd access probably comes from src/xine-utils/utils.c:
>
> #ifdef HAVE_GETPWUID_R
>   if(getpwuid_r(getuid(), &pwd, homedir, sizeof(homedir), &pw) != 0 || pw
> == NUL
> L) {
> #else
>   if((pw = getpwuid(getuid())) == NULL) {
> #endif
>     char *tmp = getenv("HOME");
>
> getpwuid_r reads the whole passwd file and stores it in a structure.
>
> So, I don't think there's anything terribly insidious going on. The
> "mkdir" output looks to be a bug, but as the error output notes, the user
>  doesn't have permission to make the dir /$HOME. 

One thing I forgot to mention, I believe I'm using the PLF version of xine.

gxine-0.4.8-1mdk 
gxine-mozilla-0.4.8-1mdk
libxine1-1.1.1-0.1.20060plf
libxine1-devel-1.1.1-0.1.20060plf
xine-aa-1.1.1-0.1.20060plf
xine-arts-1.1.1-0.1.20060plf
xine-dxr3-1.1.1-0.1.20060plf
xine-esd-1.1.1-0.1.20060plf
xine-faad-1.1.1-0.1.20060plf
xine-flac-1.1.1-0.1.20060plf
xine-gnomevfs-1.1.1-0.1.20060plf
xine-image-1.1.1-0.1.20060plf
xine-plugins-1.1.1-0.1.20060plf
xine-polyp-1.1.1-0.1.20060plf
xine-skins-5.0-3mdk
xine-smb-1.1.1-0.1.20060plf
xine-ui-0.99.4-1.1.20060mdk
xine-ui-aa-0.99.4-1.1.20060mdk
xine-win32-1.1.1-0.1.20060plf

Well mostly anyways. The "gui"s are mdk and I suspect the exit procedure that 
generates the error message is part of the gui rather than the library.

 And my error message doesn't include the "input_cdda:" prefix that appears in 
your code snipet... I believe the input_cdda thingy is part of the streaming 
(server/client) capabilities of xine, which I'd suspect would imply creating 
the offending directory in the earliest possible moments of xine's 
initialisation. My error message doen't appear until you quit xine which is 
why I suspect it is part of some sort of history or playlist saving process.

Well your reply prompted me to do a little more testing and it turns out the 
reason the root appears to be the only one read from /etc/passwd is because 
it is the first one in the file and "strace" appears to only report the first 
occurence of the read instruction. Either that or a lazy hacker assumed the 
first entry is allways root. ;-) I confirmed it by editing the /etc/passwd 
file and moving root to another line. My next invocation of xine reported a 
read of the NEW first entry in /etc/passwd

So I'm satisfied points A and B of my original posts have been answered. In 
fact I suspect the cause of the errant "mkdir" is probably a mistype in the 
source that produces an empty value instead of "/home". Then appending 
"/username" to an empty string yields our mysterious attempt at creating 
"username" in "/" aka <root> partition.

My apologies to anyone who feels I've wasted their time,
lets put this thread to rest unless someone thinks there is still cause for 
debate.

Best regards,
Mark (Aka Tuxiq, aka Tux-IQ)
____________________________________________________
Want to buy your Pack or Services from Mandriva? 
Go to http://store.mandriva.com
Join the Club : http://www.mandrivaclub.com
____________________________________________________