From: ebiederman@uswest.net (Eric W. Biederman)
To: Oliver Xymoron <oxymoron@waste.org>
Cc: Linus Torvalds <torvalds@transmeta.com>,
Horst von Brand <vonbrand@inf.utfsm.cl>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
Alexander Viro <viro@math.psu.edu>,
<linux-kernel@vger.kernel.org>
Subject: Re: Security question: "Text file busy" overwriting executables but
Date: 06 Oct 2001 13:05:34 -0600 [thread overview]
Message-ID: <m1hetcy4g1.fsf@frodo.biederman.org> (raw)
In-Reply-To: <Pine.LNX.4.30.0110051345450.30494-100000@waste.org>
In-Reply-To: <Pine.LNX.4.30.0110051345450.30494-100000@waste.org>
Oliver Xymoron <oxymoron@waste.org> writes:
> On Fri, 5 Oct 2001, Linus Torvalds wrote:
>
> > On Fri, 5 Oct 2001, Horst von Brand wrote:
> >
> > > Linus Torvalds <torvalds@transmeta.com> said:
> > > > On 5 Oct 2001, Eric W. Biederman wrote:
> > >
> > > [...]
> > >
> > > > > Currently checking to see if the file is executable looks good
> > > > > enough.
> > > >
> > > > [ executable by the user in question, not just anybody ]
> > > >
> > > > Yes, I suspect it is.
> > >
> > > Who is "user in question"? It is quite legal (if strange) to have a file
> > > user A can modify, but not execute, while B can execute it.
> >
> > The "user in question" being the one that actually does the
> > mmap(MAP_DENYWRITE). If _he_ can execute the file, that would be
> > reason enough to think that he can deny others from writing to it while he
> > has it mapped..
>
> This violates principle of least surprise. It _should_ be harmless for an
> admin to mark /var/log/utmp +x, yes? Stupid, but harmless. Now suppose it
> lives on VFAT...
Right now with some care you can theoretically still trigger the
/var/log/utmp DOS attack if the file is executable. First you
trick binfmt_misc into thinking it is an executable. Then you execute
it and immediately send it SIGSTOP before it exits. So marking
/var/log/utmp +x is not harmless.
What user space is really asking in this case is that the principle of
least suprise isn't violated with their shared library. With that
in mind it for the first implementation I will also check to make
certain that at the time of mmap no one can open the file for write,
in addition to the file being executable.
It may be reasonable to remove that check at a future time. But it
doesn't remove the usefulness, and it trivially protects against
logfile DOS attacks.
In a system that only has MAP_PRIVATE and not MAP_COPY your
executables and shared libraries should really be read only anyway to
prevent a spontaneous change.
Eric
next prev parent reply other threads:[~2001-10-06 19:16 UTC|newest]
Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-10-03 12:49 Security question: "Text file busy" overwriting executables but not shared libraries? Jesse Pollard
2001-10-03 18:06 ` Eric W. Biederman
2001-10-03 23:20 ` Rob Landley
2001-10-04 3:38 ` Eric W. Biederman
2001-10-04 4:19 ` Alexander Viro
2001-10-04 6:15 ` Eric W. Biederman
2001-10-04 8:21 ` CaT
2001-10-04 8:35 ` john slee
2001-10-04 8:45 ` CaT
2001-10-04 13:11 ` Eric W. Biederman
2001-10-04 14:24 ` Kernel size Richard B. Johnson
2001-10-13 20:35 ` Aaron Lehmann
2001-10-04 8:30 ` Security question: "Text file busy" overwriting executables but not shared libraries? Ville Herva
2001-10-04 9:46 ` Erik Andersen
2001-10-04 19:50 ` Security question: "Text file busy" overwriting executables but no Kai Henningsen
2001-10-04 8:53 ` Security question: "Text file busy" overwriting executables but not shared libraries? Andreas Schwab
2001-10-04 13:23 ` Eric W. Biederman
2001-10-04 9:12 ` Bloatware (was Re: Security question: "Text file busy"...) VDA
2001-10-04 5:38 ` Security question: "Text file busy" overwriting executables but not shared libraries? Linus Torvalds
2001-10-04 5:44 ` Alexander Viro
2001-10-04 5:49 ` Linus Torvalds
2001-10-04 15:01 ` Eric W. Biederman
2001-10-04 15:49 ` Linus Torvalds
2001-10-04 16:02 ` Richard Gooch
2001-10-04 16:20 ` Andreas Schwab
2001-10-04 17:19 ` Richard Gooch
2001-10-04 16:11 ` Alexander Viro
2001-10-04 19:28 ` Security question: "Text file busy" overwriting executables but no Kai Henningsen
2001-10-04 17:25 ` Security question: "Text file busy" overwriting executables but not shared libraries? Eric W. Biederman
2001-10-13 14:53 ` Jamie Lokier
2001-10-13 17:13 ` Linus Torvalds
2001-10-13 18:18 ` Rik van Riel
2001-10-13 18:40 ` Pablo Alcaraz
2001-10-13 19:05 ` Jamie Lokier
2001-10-13 18:54 ` Jamie Lokier
2001-10-13 19:23 ` Linus Torvalds
2001-10-13 19:46 ` Jamie Lokier
2001-10-13 21:43 ` Aaron Lehmann
2001-10-13 22:27 ` Eric W. Biederman
2001-10-13 22:50 ` Aaron Lehmann
2001-10-15 11:24 ` Jamie Lokier
2001-10-13 22:19 ` Linus Torvalds
2001-10-14 6:49 ` Eric W. Biederman
2001-10-14 8:17 ` Xavier Bestel
2001-10-14 15:40 ` Linus Torvalds
2001-10-14 18:49 ` Eric W. Biederman
2001-10-15 11:43 ` Jamie Lokier
2001-10-13 22:41 ` Richard Gooch
2001-10-15 11:35 ` Jamie Lokier
2001-10-15 11:51 ` Alexander Viro
2001-10-15 12:29 ` Jamie Lokier
2001-10-13 22:27 ` Linus Torvalds
2001-10-14 12:57 ` Security question: "Text file busy" overwriting executables but no Kai Henningsen
2001-10-14 21:43 ` Security question: "Text file busy" overwriting executables but not shared libraries? Mark H. Wood
2001-10-04 5:53 ` Richard Gooch
2001-10-04 20:39 ` Security question: "Text file busy" overwriting executables but Alan Cox
2001-10-05 16:30 ` Eric W. Biederman
2001-10-05 16:58 ` Linus Torvalds
2001-10-05 17:35 ` Horst von Brand
2001-10-05 17:44 ` Linus Torvalds
2001-10-05 18:51 ` Oliver Xymoron
2001-10-06 19:05 ` Eric W. Biederman [this message]
2001-10-14 8:02 ` [RFC] "Text file busy" when overwriting libraries Eric W. Biederman
2001-10-14 12:08 ` Alan Cox
2001-10-14 20:48 ` Eric W. Biederman
2001-10-15 1:44 ` Alan Cox
2001-10-15 2:06 ` Linus Torvalds
2001-10-15 10:11 ` Eric W. Biederman
2001-10-15 11:54 ` Alan Cox
2001-10-15 11:57 ` Alexander Viro
2001-10-15 12:08 ` Alan Cox
2001-10-15 12:11 ` Alexander Viro
2001-10-04 6:50 ` Security question: "Text file busy" overwriting executables but not shared libraries? George Greer
2001-10-04 12:54 ` John Levon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m1hetcy4g1.fsf@frodo.biederman.org \
--to=ebiederman@uswest.net \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=oxymoron@waste.org \
--cc=torvalds@transmeta.com \
--cc=viro@math.psu.edu \
--cc=vonbrand@inf.utfsm.cl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox