Ciaran McCreesh wrote:
100 bytes is more than enough room to download and execute
a file that contains the real malicious code.
I actually agree that it is extremely unlikely that a length
check would make modelines more secure, but I'm being
argumentative because it's irritating to be authorit
On Fri, 4 May 2007 14:20:22 +1000
"John Beckett" <[EMAIL PROTECTED]> wrote:
> I mentioned that the first step for point 4 should (IMHO) be
> rejecting any modeline beyond some fairly small maximum size.
Most previous exploits have been exploitable with far below the line
length that is reasonably
Matthew Winn wrote:
My objection to your idea is that it won't improve security by even
the tiniest bit. It's not defence in depth at all.
We've probably slugged this out enough, but I'm glad to have
another opportunity to promote the "safe modelines" message.
Bram has made the point that desp
On Tue, 1 May 2007 19:42:02 +1000, "John Beckett"
<[EMAIL PROTECTED]> wrote:
> Matthew Winn wrote:
> > If there was a security problem in Vim do you really think it
> > couldn't be exploited in 100 characters? That's a pretty shaky
> > foundation on which to build your security.
>
> I am quite su
Tony Mechelynck wrote:
> Bram Moolenaar wrote:
> [...]
> > Modelines are default off when you are root. The mail filetype plugin
> > also switches it off.
> [...]
>
> Are you sure? In a terminal logged-in as root, using vim 7.0.235:
>
> vim -u NONE -N
> :set ml? mls?
>modeline
Bram Moolenaar wrote:
[...]
Modelines are default off when you are root. The mail filetype plugin
also switches it off.
[...]
Are you sure? In a terminal logged-in as root, using vim 7.0.235:
vim -u NONE -N
:set ml? mls?
modeline
modelines=5
Modelines default off when 'co
Matthew Winn wrote:
If there was a security problem in Vim do you really think it
couldn't be exploited in 100 characters? That's a pretty shaky
foundation on which to build your security.
I am quite surprised at the lack of appreciation for the merits
of "defense in depth" here. I am not claim
Bram Moolenaar wrote:
N times as safe still isn't 100% safe.
I am not claiming that sanity-checking a modeline before
execution would make it 100% safe. But there have been many
examples in other software where minor bugs have turned into
security disasters because some simple point that could
John Beckett wrote:
> A.J.Mechelynck wrote:
> >> Is folding really needed in a default modeline?
> > Folding may be useful in a modeline.
> > (Don't know what you call a "default" modeline.)
>
> By "default modeline" I mean I would like Vim to be changed so
> that its default behaviour is aggres
On Sun, 29 Apr 2007 19:10:55 +1000, "John Beckett"
<[EMAIL PROTECTED]> wrote:
> Matthew Winn wrote:
> > I don't like the idea of preventing modelines over 100 bytes.
>
> I imagine (haven't looked) that a modeline has no hard limit to
> its length. So multi-megabyte modelines are probably handled
A.J.Mechelynck wrote:
Is folding really needed in a default modeline?
Folding may be useful in a modeline.
(Don't know what you call a "default" modeline.)
By "default modeline" I mean I would like Vim to be changed so
that its default behaviour is aggressively safe. If wanted,
there could be
John Beckett wrote:
[...]
Is folding really needed in a default modeline?
John
Folding may be useful in a modeline. (Don't know what you call a "default"
modeline.) Depending on how the particular file is written, you may want to
set foldmethod=marker (and which marker), foldmethod=syntax,
Ciaran McCreesh wrote:
> On Sat, 28 Apr 2007 21:52:07 +0200
> Bram Moolenaar <[EMAIL PROTECTED]> wrote:
> > I don't like this solution. Opening some files would be OK in the
> > sandbox, e.g., for reading. readfile() would be OK in the sandbox,
> > right?
>
> Probably not. In a multi-user envi
On Sat, 28 Apr 2007 21:52:07 +0200
Bram Moolenaar <[EMAIL PROTECTED]> wrote:
> I don't like this solution. Opening some files would be OK in the
> sandbox, e.g., for reading. readfile() would be OK in the sandbox,
> right?
Probably not. In a multi-user environment it can be used as a
privilege e
Matthew Winn wrote:
I don't like the idea of preventing modelines over 100 bytes.
I imagine (haven't looked) that a modeline has no hard limit to
its length. So multi-megabyte modelines are probably handled by
Vim. That's potentially offering attackers extraordinary power.
Would someone who wa
On Sat, 28 Apr 2007 22:43:23 +1000, "John Beckett"
<[EMAIL PROTECTED]> wrote:
> "Potentially unsafe" means we're pretty sure it IS safe, but
> (for example), it's simply not worthwhile allowing a modeline
> longer than 100 bytes because if another vulnerability were
> ever found, we don't want to
Andrew Maykov wrote:
> On 4/28/07, Bram Moolenaar <[EMAIL PROTECTED]> wrote:
> >It's better to make sure the sandbox works as it should.
> Yet another function to disable in sandbox:
> vi: fdm=expr fde=writefile([""],"phantom_was_here")
Yep, you found another one. Seems some of the new functio
On 4/28/07, Bram Moolenaar <[EMAIL PROTECTED]> wrote:
>It's better to make sure the sandbox works as it should.
Yet another function to disable in sandbox:
vi: fdm=expr fde=writefile([""],"phantom_was_here")
Proposal. Maybe it's sane to put security checks not just in
functions like f_writefile(
Bram Moolenaar wrote:
Perhaps modelines should only allow a VERY limited set
of operations by default (even more restricted than now).
Sure, simply use ":set nomodeline".
I'm suggesting "defence in depth". My vimrc might have
':set nomodeline', but what if I make a mistake? What if I'm
using
John Beckett wrote:
> Bram Moolenaar wrote:
> > That's pretty nasty. I'll make a patch right away.
>
> Thanks. However, perhaps the modeline concept needs
> more safety - defence in depth.
>
> Perhaps modelines should only allow a VERY limited set
> of operations by default (even more restrict
Tomas Golembiovsky wrote:
today somebody came to #vim, and pasted some modeline (containig
joke or such).
Thanks for raising that issue. I found the April 1 "joke" with Google.
I actually noticed that posting (seeing "Vim" while browsing a security
list caught my attention), but there's so muc
Bram Moolenaar wrote:
That's pretty nasty. I'll make a patch right away.
Thanks. However, perhaps the modeline concept needs
more safety - defence in depth.
Perhaps modelines should only allow a VERY limited set
of operations by default (even more restricted than now).
Googling for 'vim feed
Tony Mechelynck wrote:
> Tomas Golembiovsky wrote:
> > Greetings mortals,
> >
> > today somebody came to #vim, and pasted some modeline (containig joke or
> > such). He muttered something about not knowing what that means and left
> > before long. But (!) what I noticed is that feedkeys() was us
Tomas Golembiovsky wrote:
> today somebody came to #vim, and pasted some modeline (containig joke or
> such). He muttered something about not knowing what that means and left
> before long. But (!) what I noticed is that feedkeys() was used as part of
> foldexpression and it turned out that feedk
Michael Henry wrote :
> A.J.Mechelynck wrote:
> > Tomas Golembiovsky wrote:
> >> vim: fdm=expr fde=feedkeys("\\:!touch\ phantom_was_here\\")
> >>
> >> I guess you can see the consequences. Is this known/intentional?
> >>
> >
> > IIUC, feedkeys() called from sandbox should execute as if in s
Tomas Golembiovsky wrote:
Greetings mortals,
today somebody came to #vim, and pasted some modeline (containig joke or
such). He muttered something about not knowing what that means and left
before long. But (!) what I noticed is that feedkeys() was used as part of
foldexpression and it turned ou
Greetings mortals,
today somebody came to #vim, and pasted some modeline (containig joke or
such). He muttered something about not knowing what that means and left
before long. But (!) what I noticed is that feedkeys() was used as part of
foldexpression and it turned out that feedkeys() is allowed
27 matches
Mail list logo