Re: [Evolution] PGP -> execvp() : Security problems?

[Jeffrey Stedfast <fejj ximian com>]

Point me to the documentation stating why it is bad?

Jeff

On Wed, 2002-11-13 at 09:46, Anton Aylward wrote:
> On Wed, 2002-11-13 at 00:46, Jeffrey Stedfast wrote:
> > On Tue, 2002-11-12 at 19:08, Anton Aylward wrote:
> >
> > > My point is the use of execvp().
> >
> > this is the same as issuing "gpg" in your shell.
>
> No its not, because its run from within Evolution.
>
> > I type /usr/bin/gpg *all* the time
> >
> > </sarcasm>
>
> Belittling me doesn't change anything.  It may be fun but it doesn't
> address the issue.
>
> That you can't envision an attack mode that makes use of this doesn't
> mean that other malicious people can't.  The history of malicious
> hacking has shown that time and time again.
>
> Let me give a simple scenario:
>
> The user constructs a completely artificial environment whose sole
> purpose is to cause execpv() to overflow the stack, so as to introduce
> his own code fragment and gain access to the innards of Evolution.
>
> Perhaps that doesn't matter with 1.0.8, but I see in the mailing list
> that people are proposing scripting languages and embedding interpreters
> in Evolution for other purposes.  We've seen what happens when the MUA
> becomes a programming system with Microsoft's Outlook and the
> vulnerabilities and risks that arise from that and how the increased
> complexity makes dealing with them difficult.
>
> Right now, using execpv() may not be a problem.  But this may not hold
> in the future.  Evolution is a big piece of code and who knows how a
> hacker might figure out how to use this to achieve other ends.
>
> As I say, just because you and I can't see how it could be done doesn't
> mean some hacker can't work it out.
>
> > sure, maybe it's a risk if you blindly trust your shell environment, but
> > guess what? you can setup your PATH environment to not include
> > directories that you feel are risky (ie, don't include ".").
>
> That's not the kind of thing I'm talking about.
> You're assuming a benign user and the security incident happening by
> accident.  But this started off with you assuming the user might not be
> sophisticated enough to know about the file system structure and so
> avoiding making them enter the full path to gpg.  Now you want them to
> be smart enough to know about their path.
>
> Many users will be using a graphical login - gdm - and invoke Evolution
> from a menu.  They won't see their PATH any more than they will know the
> absolute location of gpg.   You can't have this both ways.  Either they
> are not smart enough (or don't care) to know about gpg being in /usr/bin
> and hence not smart enough to edit their PATH OR they are smart enough
> to edit their PATH and know where key binaries live.
>
> Of course all this ignores any setting they may or may bot have in their
> shell start-up files that do aliasing or or override the path set in
> gdm.  As one advisory says:
>
>       Generally, you should not use execlp(3), execvp(3), popen(3) 
>       and system(3), since unpredictable interactions with complex
>       command shells creates an unacceptable security risk!
>
>
>
> The risks associated with execpv() are well established; see various
> security advisories from L0pht, ISS and many others
>
> This is quite apart from the side effects that may result from the
> complexity of the shell and its start-up files. Just as execpv()
> "believes" the inherited PATH, it also blindly accepts the settings for
> the shell.  
>
> In addition, the PATH is not always relevant.  For example, when BASH
> starts up to run non-interactively it looks for the environment variable
> BASH_ENV, ignoring the PATH, and "sources" the file it find in that
> setting.  Its not difficult to imagine this mechanism being used
> maliciously.  
>
> There are many other things that can influence the behaviour of a shell,
> global, local and environment settings.  You as an application
> programmer have no control over them.  Ultimately you don't even know
> what shell is being used unless you take a peek at SHELL in the
> environment.  
>
> > > The user of Evo may not the the owner or administrator of the machine.
> >
> > this is not assumed.
>
> Yes, but suppose this is some business and there is a malicious insider,
> or even just an insider who is not overtly malicious but just want to
> see if he can crack the system but doesn't have the experience not to
> cause collateral damage.
>
> I presume XIMIAN is interested in in Evolution becoming a desktop
> standard for business, so I can't see why you want to make it more risky
> than it needs to be.
>  
> As I've said, you're assuming a benign user and the security incident
> happening by accident.  I'm considering cases other than that.
>
> There is no excuse for failing to make the application robust.  The
> execpv() issues is a well documented weakness.  There are other forms of
> the exec() family that you can use where you force an explicit PATH and
> avoid the use of the shell. 
>
> If this were robustness in other areas such as the UI you wouldn't be
> arguing with me.
>
> /anton
>
>
> _______________________________________________
> evolution maillist  -  evolution ximian com
> http://lists.ximian.com/mailman/listinfo/evolution
-- 
Jeffrey Stedfast
Evolution Hacker - Ximian, Inc.
fejj ximian com  - www.ximian.com