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

[Anton Aylward <aja si on ca>]

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