On Sun, Aug 24, 2008 at 10:33 AM, Jan Minář <[EMAIL PROTECTED]> wrote:
> On Sun, Aug 24, 2008 at 7:26 AM, Jan Minář <[EMAIL PROTECTED]> wrote:
> (...)
> Thanks for reporting this. Forget my last email. This is the fix:
It works fine after v3 patch. Thanks.
>
>
> /*
>* Now g
On Sun, Aug 24, 2008 at 2:45 AM, Pınar Yanardağ <[EMAIL PROTECTED]> wrote:
> After applying this patch to Vim 7.2, I got following errors while
> trying to use K command (and shell also freezes after getting the
> errors). I tried to reproduce them with a stable scenario, but
> couldn't find a reas
On Sun, Aug 24, 2008 at 7:26 AM, Jan Minář <[EMAIL PROTECTED]> wrote:
> On Sun, Aug 24, 2008 at 2:45 AM, Pınar Yanardağ <[EMAIL PROTECTED]> wrote:
>> After applying this patch to Vim 7.2, I got following errors while
>> trying to use K command (and shell also freezes after getting the
>> errors). I
Hi,
After applying this patch to Vim 7.2, I got following errors while
trying to use K command (and shell also freezes after getting the
errors). I tried to reproduce them with a stable scenario, but
couldn't find a reasonable one. And also, K command sometimes works as
expected, too.
I don't kn
On Sat, Aug 23, 2008 at 8:59 AM, Bram Moolenaar <[EMAIL PROTECTED]> wrote:
>
>
> John Becket wrote:
>
>> Tony Mechelynck wrote:
>> > Maybe you should set a config-time option (or create one) to
>> > avoid any interaction with the shell?
>> >
>> > Even better: If you don't want ever to become the v
John Becket wrote:
> Tony Mechelynck wrote:
> > Maybe you should set a config-time option (or create one) to
> > avoid any interaction with the shell?
> >
> > Even better: If you don't want ever to become the victim of
> > any exploit, turn your computer off at the wall switch and
> > leave it o
> was not checked, so I fixed that as well. The updated patch (version
> 2) is attached.
It is now.
Cheers,
Jan.
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~
On Fri, Aug 22, 2008 at 10:25 PM, Bram Moolenaar <[EMAIL PROTECTED]> wrote:
>
> Jan Minar wrote:
>
>> > Thanks. I'll have a good look at it later. One thing I noticed: you
>> > don't need to give an error message for running out of memory at this
>> > level, it's already done at a lower level in
Tony Mechelynck wrote:
> Maybe you should set a config-time option (or create one) to
> avoid any interaction with the shell?
>
> Even better: If you don't want ever to become the victim of
> any exploit, turn your computer off at the wall switch and
> leave it off.
>
> :-b
I haven't studied this
On Fri, Aug 22, 2008 at 6:41 PM, Tony Mechelynck wrote:
>
> On 22/08/08 21:20, Jan Minář wrote:
>>> Thanks. I'll have a good look at it later. One thing I noticed: you
>>> don't need to give an error message for running out of memory at this
>>> level, it's already done at a lower level in alloc(
On 22/08/08 21:20, Jan Minář wrote:
>> Thanks. I'll have a good look at it later. One thing I noticed: you
>> don't need to give an error message for running out of memory at this
>> level, it's already done at a lower level in alloc(). There it also
>
> That's what I thought, too. But vim_str
Jan Minar wrote:
> > Thanks. I'll have a good look at it later. One thing I noticed: you
> > don't need to give an error message for running out of memory at this
> > level, it's already done at a lower level in alloc(). There it also
>
> That's what I thought, too. But vim_strsave_shellesc
> Thanks. I'll have a good look at it later. One thing I noticed: you
> don't need to give an error message for running out of memory at this
> level, it's already done at a lower level in alloc(). There it also
That's what I thought, too. But vim_strsave_shellescape() is
documented to return
Jan Minar wrote:
> Thanks again to Ben for reporting this.
>
> It's not just the K command. The and g] commands are vulnerable
> too. Patch attached.
>
> Attack vectors:
>
> (1) K -- arbitrary shell command execution via additional shell
> commands (insufficient sanitization of
On 22/08/08 13:37, Jan Minář wrote:
> Hi!
>
> Thanks again to Ben for reporting this.
>
> It's not just the K command. The and g] commands are vulnerable
> too. Patch attached.
>
> Attack vectors:
>
> (1) K -- arbitrary shell command execution via additional shell
> commands (insu
Hi!
Thanks again to Ben for reporting this.
It's not just the K command. The and g] commands are vulnerable
too. Patch attached.
Attack vectors:
(1) K -- arbitrary shell command execution via additional shell
commands (insufficient sanitization of a shell command string)
On 21/08/08 08:25, Matt Wozniski wrote:
[...]
> 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 expa
On Thu, Aug 21, 2008 at 1:05 PM, Tony Mechelynck wrote:
>
> On 21/08/08 08:25, Matt Wozniski wrote:
> [...]
>> 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(
On 20/08/08 13:09, Matt Wozniski wrote:
> On Wed, Aug 20, 2008 at 4:33 AM, Tony Mechelynck wrote:
>> On 20/08/08 09:47, Jan Minář wrote:
>>> The above will of course not work. The following will:
>>>
>>> /* We use an obscure glibc function -- check out the man page! */
>>> clockface =
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
>>> 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 al
On Thu, Aug 21, 2008 at 12:55 AM, Bram Moolenaar <[EMAIL PROTECTED]> wrote:
>
> Matt Wozniski wrote:
>
>> Jan got the exploit right, but formatted his modeline wrong. Try this
>> document:
>> /* We use an obscure glibc function -- check out the man page! */
>> clockface = &(xclock)&pwnme (a, b,
Matt Wozniski wrote:
> On Wed, Aug 20, 2008 at 4:33 AM, Tony Mechelynck wrote:
> >
> > On 20/08/08 09:47, Jan Minář wrote:
> >>
> >> The above will of course not work. The following will:
> >>
> >> /* We use an obscure glibc function -- check out the man page! */
> >> clockface =&(xcl
> This time Vim says ":!seamonkey www.example.com&xclock& which apparently
> doesn't do anything. Pasting the URL into the Location bar gives
I bet you're in gvim, right, Tony? I expect you're encountering the
"can't run processes in the background" problem that a number of users
have commented
On Wed, Aug 20, 2008 at 4:33 AM, Tony Mechelynck wrote:
>
> On 20/08/08 09:47, Jan Minář wrote:
>>
>> The above will of course not work. The following will:
>>
>> /* We use an obscure glibc function -- check out the man page! */
>> clockface =&(xclock)&pwnme (a, b, x + y);
>> /* :vi
On 20/08/08 09:47, Jan Minář wrote:
> On Wed, Aug 20, 2008 at 8:18 AM, Tony Mechelynck
> <[EMAIL PROTECTED]> wrote:
>> On 20/08/08 06:51, Jan Minář wrote:
>> [...]
>>> Opening the following URL using the K command will launch the
>>> xclock(1x) program:
>>>
>>> http://www.google.co.uk/searc
On Wed, Aug 20, 2008 at 8:18 AM, Tony Mechelynck
<[EMAIL PROTECTED]> wrote:
>
> On 20/08/08 06:51, Jan Minář wrote:
> [...]
>> Opening the following URL using the K command will launch the
>> xclock(1x) program:
>>
>> http://www.google.co.uk/search?q=&xclock&;
>
> Pasting this into the SeaMonk
On 20/08/08 06:51, Jan Minář wrote:
[...]
> Opening the following URL using the K command will launch the
> xclock(1x) program:
>
> http://www.google.co.uk/search?q=&xclock&;
Pasting this into the SeaMonkey location bar opens a Google page.
Hitting K on it in gvim with 'keywordprg' set to "
Jan Minář wrote:
> On Wed, Aug 20, 2008 at 4:38 AM, Ben Schmidt
> <[EMAIL PROTECTED]> wrote:
>> the shell. It should be checked that the keyword is properly
>> shell-escaped, too. I can't quickly think of a way to easily exploit
>> this one, so I don't think it's a security risk, but it's definite
Ben Schmidt wrote:
> Ex command substitutions (:help cmdline-special) seem to be done on
> the keyword when using the K command. Due to normal settings for
> iskeyword this won't usually show up for K, but will for {Visual}K if
> you, e.g., highlight a URL with a # in it and use K on it (with
>
Hi, Ben!
Thanks for pointing this out.
On Wed, Aug 20, 2008 at 4:38 AM, Ben Schmidt
<[EMAIL PROTECTED]> wrote:
> the shell. It should be checked that the keyword is properly shell-escaped,
> too. I
> can't quickly think of a way to easily exploit this one, so I don't think
> it's a
> security
Ex command substitutions (:help cmdline-special) seem to be done on the keyword
when using the K command. Due to normal settings for iskeyword this won't
usually
show up for K, but will for {Visual}K if you, e.g., highlight a URL with a # in
it
and use K on it (with keywordprg set to 'firefox
32 matches
Mail list logo
