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

List:       kde-devel
Subject:    Re: kdesu overrides user's PATH with hardcoded path
From:       Oswald Buddenhagen <ossi () kde ! org>
Date:       2008-08-31 9:25:30
Message-ID: 20080831092530.GA25406 () ugly ! local
[Download RAW message or body]

ha! an old thread waiting to be warming up! :D

On Tue, Aug 12, 2008 at 05:30:22PM -0400, Guillaume Pothier wrote:
> >> On Tue, Aug 12, 2008 at 3:39 PM, Michael Pyne <mpyne@purinchu.net>
> >> wrote:
> >>> On Tuesday 12 August 2008, John Tapsell wrote:
> >>>> 2008/8/12 Romain GUINOT <romainguinot@gmail.com>:
> >>>>> I have found a small bug in kdesu's stub.cpp source file.
> >>>>>
> >>>>> It overrides the user's own $PATH by adding
> >>>>> "/sbin:/bin:/usr/sbin:/usr/bin:" in front of it. This does not
> >>>>> interfere for most users, but is a problem when you sometimes
> >>>>> have a few local binaries sitting in non default directories.
> >>>>> When this is the case, kdesu picks up the "wrong" standard one.
> >>>>>
> >>>>> The fix is extremely simple, just add the hardcoded path after
> >>>>> the user's $PATH instead of before. The patch is attached.
> >>>>>
> >>>>> I am not sure if describing/fixing it here is the best way to
> >>>>> go? should i create a bug report and reference it here in place
> >>>>> of describing it here?
> >>>>>
> >>>> It would seem to me to be a security feature than a bug.
> >>>>
> >>> Indeed, if it is actually necessary to run a user's version
> >>> specifically of an application it is more reliable in general to
> >>> use the absolute path to the application instead of relying on
> >>> PATH.
> >>>
which isn't possible if some executable uses a hard-coded, path-less
name of a command and the only way to influence it is with $PATH. and
that's a perfectly reasonable thing to do, as $PATH is a standard
mechanism.

> >>> Prepending instead of appending to the user PATH prevents
> >>> duplicity involving depositing a sinister ls program in the user's
> >>> directory and then having the user inadvertently run the corrupt
> >>> ls when he meant /bin/ls. This is especially dangerous when
> >>> running the program via su or sudo.
> >>>
> > If I like to use the "cracked" executable, then I'm able to use the
> > full path. So there is no "limitation" to use it anyway.
> >
> Yes, you can use it if you really want to, but you are less likely to
> use it by mistake.
> 
this argument is nonsense. why would /usr/bin be less vulnerable than
/usr/local/bin? there is no probability involved here. attacker can
modify anything in your $PATH => you lose. period.
by extension that means that $PATH containing "." is an actual security
problem: when you happen to be in a directory to which an attacker (who
happens to be a legitimate user of the system) has write access (e.g.,
/tmp), you'll run his executable. this is somewhat alleviated by having
the "." as the last thing in $PATH instead of as the first one, but then
the attacker still can install mistyped versions of common commands and
thus have a realistic chance of having his code executed by a victim.
so kdesu filtering out "." from $PATH would be a reasonable thing (so
far, it only protects against "" (same as ".") at the start).

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--
Confusion, chaos, panic - my work here is done.
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]