On Thu, Aug 21, 2008 at 1:56 AM, Ben Schmidt wrote:
>
>>>> place your cursor on 'pwnme', and press K.  xclock appears.
>>> Yeah, this is the kind of exploit where you have to tell the user to do
>>> something stupid and them blame Vim that the user is stupid.
>
> Yes. Still...that seems to be the current trend...
>
>>> The command executed can be an shell alias.  The command may not be in
>>> $PATH.  And a few other reasons we don't see right now.
>>
>> execlp() handles commands not in $PATH just fine, as long as its first
>> parameter is an absolute or relative path, rather than just a
>> filename.  And a shell alias being used there is definitely not a good
>> thing - and is not done by default.  If you want to replace or create
>> a program, you create a script, if you want to change the way a
>> program is used interactively, you use an alias.  Aliases are
>> certainly not designed to ever be called from an external program, and
>> forcing bash to pretend to be an interactive shell when it's not, in
>> fact, being used interactively, just for the sake of expanding
>> aliases, is a Bad Thing.
>
> I agree aliases should be interactive, and not used here. However, $PATH
> and so on is often set/adjusted from shell startup files, and
> particularly when using gvim started via GUI, etc., this can be relevant.

PATH should be set from .profile, not from .bashrc - Interactive vs
noninteractive should have nothing to do with whether or not PATH is
correct; either your x session or your login shell at a tty should set
up such things.

> On the other side, shell escaping when exactly which shell is being used
> is not known is a nightmare, too.

And it's here that I'm convinced we'll be able to find a ton of
security vulnerabilities as soon as someone with some security
expertise decides to look.

> I think it's one of those issues where there are so many good arguments
> on both sides, it comes down to a matter of opinion.
>
> Ben.

In that vein, perhaps using the shell should be an option... but
doubtless the best default behavior is to use system(3) for places
like :! where shell expansion is good,and execlp() for those places
where we decidedly don't want any shell expansion.  Relying on uniform
escaping required for /bin/sh is still not terribly easy, but it's a
much less moving target than escaping for every possible shell...  It
just strikes me that vim's present use of the user's shell is
inherently impossible to sanitize, and thus inherently insecure for at
least the simplistic "file name has a command embedded" sort of
attack...

~Matt

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To post to this group, send email to vim_dev@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/vim_dev?hl=en
-~----------~----~----~----~------~----~------~--~---

Raspunde prin e-mail lui