Anyone fixing SA31464?

10 views
Skip to first unread message

Martti Kuparinen

unread,
Aug 15, 2008, 2:33:44 AM8/15/08
to vim...@googlegroups.com
Hi,

Is anyone working to fix this:

http://secunia.com/advisories/31464/

Martti

Bram Moolenaar

unread,
Aug 15, 2008, 7:11:51 PM8/15/08
to Martti Kuparinen, vim...@googlegroups.com

Martti Kuparinen wrote:

> Is anyone working to fix this:
>
> http://secunia.com/advisories/31464/

I'm sure Charles is thinking of a solution. But it's a really minor
issue, it's hard to imagine this could be used to intentionally obtain
login name and password. It's more that it might happen accidentally.
Just like you may type the right password at the wrong site.

--
"Lisp has all the visual appeal of oatmeal with nail clippings thrown in."
-- Larry Wall

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ download, build and distribute -- http://www.A-A-P.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

Martti Kuparinen

unread,
Aug 16, 2008, 4:35:48 AM8/16/08
to vim...@googlegroups.com
Bram Moolenaar kirjoitti:

>> http://secunia.com/advisories/31464/
>
> I'm sure Charles is thinking of a solution. But it's a really minor
> issue

I agree, but I have to do something to fix this as I'm the NetBSD pkgsrc
maintainer for vim and I get daily warning about this...

Martti

Charles E. Campbell, Jr.

unread,
Aug 16, 2008, 5:43:37 PM8/16/08
to vim...@googlegroups.com
Its been "fixed" already -- on my website. See v133k at
http://mysite.verizon.net/astronaut/vim/index.html#NETRW . I wouldn't
put it in a package yet -- my website's packages are typically
alpha/beta releases, and it awaits comment.

Regards,
Chip Campbell

Jan Minář

unread,
Aug 17, 2008, 12:06:11 PM8/17/08
to Vim Developers
Charles E. Campbell, Jr. wrote:
> Its been "fixed" already -- on my website. See v133k at
> http://mysite.verizon.net/astronaut/vim/index.html#NETRW . I wouldn't

"fixed" indeed:

You check that the domain name has changed, but not the TCP port. An
FTP server on the same host, but a different port name has no business
knowing the credentials of the other server. This allows for example
collecting credentials of local users -- an FTP server set up by a
mere user will be sent credentials for the FTP server set up by root
(i.e., real user names + passwords for this machine):

FTP server set up by root:

ftp://rdancer@localhost/

FTP server set up by a mere user:

ftp://localhost:31337/

You may also want to read the advisory. It's there, right at the top:

``Once vim successfully connects to an FTP server using a user name and
password credentials, it will re-use them in all subsequent FTP
sessions, regardless of the domain name or TCP port.''
^^^^^^^^
-- http://www.rdancer.org/vulnerablevim-netrw-credentials-dis.html


Cheers,
Jan.

Charles E. Campbell, Jr.

unread,
Aug 17, 2008, 3:29:42 PM8/17/08
to vim...@googlegroups.com
Any person changing the port should use :NetUserPass uid p/w ; if they
don't, then I'm assuming that they're using the same id and password on
that unchanged hostname, deliberately. A typical situation would be when
the user forgot to use the non-standard port number and wishes to redo
the transaction but with the correct port.

Chip Campbell

Jan Minář

unread,
Aug 17, 2008, 3:44:41 PM8/17/08
to vim...@googlegroups.com

Yes. Now that it has been shown that this is in fact insecure, and
can lead to credentials disclosure in the very environment where FTP
is secure overall (over local loopback, no snooping possible), it's
perhaps time to forgo that assumption. Requiring users to use
NetUserPass() is ridiculous.

Cheers,
Jan.

Bram Moolenaar

unread,
Aug 17, 2008, 5:45:35 PM8/17/08
to Jan Minář, vim...@googlegroups.com

Jan Minar wrote:

Ftp basically is an insecure protocol. It sends passwords out in the
open over the internet. Perhaps there is a specific way in which nobody
will be able to spot the password, but this is too complicated for most
users to understand. In general the statement is not to use ftp for
something where you don't want to take a risc of giving away your
password.

Trying to put a secure layer op top of an insecure protocol doesn't make
much sense. We can only try to avoid the most common mistakes a user
might make. But the general recommendation must still be not to use ftp
for things that should be secure.

--
DENNIS: Look, strange women lying on their backs in ponds handing out
swords ... that's no basis for a system of government. Supreme
executive power derives from a mandate from the masses, not from some
farcical aquatic ceremony.
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

Reply all
Reply to author
Forward
0 new messages