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

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.

-- 
Stew Benedict
Mandriva
____________________________________________________
Want to buy your Pack or Services from Mandriva? 
Go to http://store.mandriva.com
Join the Club : http://www.mandrivaclub.com
____________________________________________________