[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    Bug#4340: KDE Vuln
From:       Stephan Kulow <coolo () kde ! org>
Date:       2000-06-01 9:39:43
[Download RAW message or body]

Matthias Hoelzer-Kluepfel wrote:
> 
> On Thu, 1 Jun 2000, Waldo Bastian wrote:
> 
> > > checkAccess() seems to be broken.
> >
> > checkAccess checks for write-permission of the file, that fails because it
> > isn't there yet. (so far so good)
> >
> > Then it checks for write-permission in the directory where the file is, but
> > that is the directory where the symlink is created, not the the directory to
> > which the symlink points. That's the problem.
> 
> I have attached a small patch that will follow the symlink.
> 
> Index: kapp.cpp
> ===================================================================
> RCS file: /home/kde/kdelibs/kdecore/kapp.cpp,v
> retrieving revision 1.122.4.3
> diff -u -r1.122.4.3 kapp.cpp
> --- kapp.cpp    1999/06/14 10:37:47     1.122.4.3
> +++ kapp.cpp    2000/06/01 09:10:14
> @@ -343,8 +343,8 @@
>  #include <sys/wait.h>
>  #include <stdlib.h> // getenv()
>  #include <signal.h>
> +#include <limits.h>
> 
> -
>  #include <qwidcoll.h>
> 
>  #include "kprocctrl.h"
> @@ -1728,6 +1728,19 @@
> 
>  bool checkAccess(const char *pathname, int mode)
>  {
> +  // if the file checked is a link, follow the link
> +  struct stat m;
> +  lstat(pathname, &m);
> +  if (S_ISLNK(m.st_mode))
> +    {
> +      char buffer[PATH_MAX];
> +      readlink(pathname, buffer, PATH_MAX);
> +      if (strcmp(pathname, buffer))
> +        return checkAccess(buffer, mode);
> +      else
> +       return false;
> +    }
> +
>    int accessOK = access( pathname, mode );
>    if ( accessOK == 0 )
>      return true;  // OK, I can really access the file
> 
> The patch should fix the problem mentioned in the exploit, but
> please review it thoroughly before applying.
Actually I would just remove the link and return true. We don't
support links for config files - period.

> 
> And it does not solve all problems, as we now have a
> race-condition. If we check the file permission, and (shortly)
> later open the file, an attacker could use the time inbetween
> to replace a legally writable file by an evil symlink.
> 
> >From 'man access':
> 
> Using access to check if a user is authorized to e.g. open a file
> before actually doing so using open(2)  creates a security hole,
> because the user might exploit the short time interval between
> checking and opening the file to manipulate it.
> 
Hmm, and what do they suggest instead to check if a file can be
written to without writing to it?

Greetings, Stephan

-- 
... but you ain't had mine

[prev in list] [next in list] [prev in thread] [next in thread]