[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <2ECE9D9EEF1F524185270138AE23265955B0BAE7@S0MSMAIL112.arc.local>
Date: Fri, 3 Nov 2017 12:57:25 +0000
From: Fiedler Roman <Roman.Fiedler@....ac.at>
To: "'oss-security@...ts.openwall.com'" <oss-security@...ts.openwall.com>
Subject: Re: Security risk of server side text editing in
general and vim.tiny specifically
>From: Solar Designer [mailto:solar@...nwall.com]
> ...
> IMO, there's really absolutely nothing to reasonably embargo here, not
> even the PoC and not even for a week. The only reason I mentioned the
> possibility to optionally delay the posting of the PoC "by at most a
> week" is because the distros list policy allows that, and you're the one
> reporting this, so it's your call and you wouldn't be violating list
> policy by this unfortunate delay. But that doesn't make it a good idea.
Yes, I know - and also those with little above script-kiddie-level of
knowledge will now know how to exploit anyway just using the information from
those mails. It's just that I want to lessen possible legal issues by
notifying vim developers first and giving them chance to react before posting
POC code. But they might benefit from this discussion too, so telling nothing
about the issue here is also no option.
> On Fri, Nov 03, 2017 at 11:07:14AM +0000, 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.
> >
> > As .swp security problems also arise from unclear software behaviour
> expectations, I looked at the behaviour of vim.tiny to verify it works
> according
> to specification (man pages as reference). As it seems, the tool is not
> suited
> for editing of files not owned by the same user, which is not mentioned in
> the
> man pages. Maybe that indicates, that the software design process did not
> include that specific security requirement or implementation was
> insufficient.
> Therefore I would assume, that numerous bugs of similar kind might be found,
> but there is no time (funding) to do in depth checks.
>
> I think it's an exaggeration to say these are bugs (except for ignoring
> of umask maybe), but there's room to make uses and even misuses of these
> tools safer, as well as their interactions with other tools (such as the
> original example of editing of .php files on a web server, where the
> editor should use explicit safe permissions on its temporary files
> regardless of the original file's permissions and regardless of umask,
> but also limited to at most what's permitted by umask).
The bug may be in the documentation/specification: in my opinion,
documentation of good, security aware software should a) implement things
considering security bordercases (vim.tiny reporting, that a file was replaced
or symlink encountered, proceed?) or b) state, they are not made for that
purpose. Even when such statements are redundant for many different tools,
they give users at least the chance to learn, that an operation is dangerous
and may link to additional information, e.g. the link you provided below on
secure root file access.
Why has each plastic bag of a new consumer device printed "There is a risk
that children pull them over their head and suffocate." for safety reasons,
but in software development, we assume, everybody knows and do not include
such warnings at least in the footer of man pages?
> > I would be interested in consensus, if editing of non-root files by root
> > user is
> bad practice in general (thus, e.g. should be mentioned in SECURITY section
> of
> man pages of various common server side test editing tools to raise
> awareness, but no CVEs) or if you think, that this is software misbehaviour.
>
> Editing of non-root files by root should be safe (or be made safe by
> making changes to the editors where necessary) only in the rare special
> case when those files are located in a trusted directory. For example,
> editing as root /var/run/foo owned by user foo should be safe as long as
> /, /var, and /var/run are owned by root, but editing as root
> /home/foo/foo or /tmp/foo is unsafe and is likely to stay so.
I would need to check that on vim.tiny. As stat-ing, getxattr, renaming,
chmod, ... are not atomic, I am not sure if vim.tiny as example would fulfil
your expectations.
But before that: why do you expect the software to behave like that, when it
is not stated anywhere?
> I doubt this belongs to "SECURITY section of man pages" because this is
> by no means limited to just text editors. Most tools are unsafe to use
> on files in untrusted directories, with very few exceptions - for
> example, "cp" and "mv" are generally unsafe, but "ln" is generally safe.
But also those tools seem not state, how they really behave regarding security
in man-pages, declaring what security expectations they fulfil and which the
will not fulfil (I searched for security/concurrent/user/owner/privileg but no
relevant hits in the man page). How should a normal user know the difference?
> It is tricky to access files in an untrusted directory safely. Programs
> that knowingly do it end up using O_EXCL or O_NOFOLLOW|O_NOCTTY and
> such, and doing various *stat() calls, and even that is sometimes not
> enough. It'd be naive to expect the same from every other program
> accepting an arbitrary pathname.
>From my point of view, this mandates something like a "libSecureOpen" (trying
to get that into libc as first step might be in vain), which has a solid
implementation also considering different UNIX-system peculiarities and should
be used by open source software doing that kind of risky operations. Other
software should explicitely declare: "is not safe for operating on file of
different users/NFS in untrusted environments".
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.
