[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2ECE9D9EEF1F524185270138AE23265955B0C1F8@S0MSMAIL112.arc.local>
Date: Mon, 6 Nov 2017 09:44:32 +0000
From: Fiedler Roman <Roman.Fiedler@....ac.at>
To: "'oss-security@...ts.openwall.com'" <oss-security@...ts.openwall.com>
Subject: AW: Re: Security risk of server side text editing in
general and vim.tiny specifically
Hello Jan,
> From: Ian Zimmerman [mailto:itz@...y.loosely.org]
>
> On 2017-11-03 11:07, Fiedler Roman wrote:
>
> > Due to the recent discussion on vim swap file use, I expected also
> > attraction of of evil-minded to the topic of text editing security and
> > thus an increase in attack probability on server side text editing in
> > general. Therefore I wanted to review our software qualification
> > criteria for text editing on servers, where vim/vim.tiny is used and
> > probably update the SOPs and guidelines.
>
> How much of this (and the parallel thread of course) applies to nvi?
Sorry about the parallel threads, Outlook removes the relevant mail headers
without asking under some circumstances.
Nvi avoids the chmod/chown trickery, at least for Ubuntu Xenial. So all those
bugs do not apply.
As written in another post, using /var/tmp in that way is really a bad idea.
In my opinion it is a pity, that the vim recover redesign did not cleanly
separate locking and recovery. In my opinion, a good solution would be to
create a [].lock file where the file resides, thus also working across network
shares, ... Recovery files should go only to user directories, where tmp dir
cleanup is not an issue. When same user attempts recovery, his personal
recovery copy is found anyway. If another user finds the lock, he has to
decide his actions anyway, e.g. a) make the change without knowing the "lost"
changes from another user, because it is urgent or b) find out, who the other
use is, search his change files (if root and allowed), ....
With a lock file, nothing can leak. If "recovery of other user's changes" is a
common procedure in some companies, a special setting could cause the lock
file not to be empty but to contain the last editing user name, login time so
that it is easier to contact that user.
LG Roman
Download attachment "smime.p7s" of type "application/pkcs7-signature" (4814 bytes)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
