public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libc/14749] New: Dangerous race condition with vfork in posix_spawn
@ 2012-10-21 16:58 bugdal at aerifal dot cx
2014-02-10 21:22 ` [Bug libc/14749] " sionescu+BugTrackers at cddr dot org
2014-09-20 4:13 ` carlos at redhat dot com
0 siblings, 2 replies; 3+ messages in thread
From: bugdal at aerifal dot cx @ 2012-10-21 16:58 UTC (permalink / raw)
To: glibc-bugs
http://sourceware.org/bugzilla/show_bug.cgi?id=14749
Bug #: 14749
Summary: Dangerous race condition with vfork in posix_spawn
Product: glibc
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: libc
AssignedTo: unassigned@sourceware.org
ReportedBy: bugdal@aerifal.cx
CC: drepper.fsp@gmail.com
Classification: Unclassified
posix_spawn uses vfork (to avoid momentary doubling commit charge and improve
performance) in cases where it seems "safe", or when explictly requested.
However, at least one major race condition seems to have been missed:
Consider a program running with elevated privileges (perhaps a daemon or suid
program which initially has root) which is multi-threaded, and which will drop
privileged and then execute untrusted code (perhaps a user-provided script or
module). The scenario looks like:
Thread A is calling posix_spawn to run a fixed external command (call it child
C) that will work fine, and which is safe to invoke, with either the initial
privileges or the reduced privileges. Think of something stupid like running
"date" to get the current date and time.
Thread B is calling setuid() to drop privileges, then executing untrusted code.
And let's suppose events happen in the following order:
A: vfork
C: vfork returns in child
B: setuid
B: untrusted code runs and pokes at memory A is using
C: now running arbitrary code as root
C: ...
A: vfork returns in parent
Fundamentally, the danger of this race is the possibility of it giving rise to
two threads/processes sharing an address space, but with different privileges;
this kind of situation must never be allowed to arise.
The simplest way to avoid the race is by using fork instead of vfork, unless
vfork is specifically requested. However, that brings back the
double-commit-charge issue. An alternative fix is to hold a lock that prevents
changing uids/gids during the vfork window. This is also easy since NPTL is
already doing a global lock for set*id() to synchronize the id changes across
all the threads (since Linux requires each thread to make its own set*id()
syscall).
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug libc/14749] Dangerous race condition with vfork in posix_spawn
2012-10-21 16:58 [Bug libc/14749] New: Dangerous race condition with vfork in posix_spawn bugdal at aerifal dot cx
@ 2014-02-10 21:22 ` sionescu+BugTrackers at cddr dot org
2014-09-20 4:13 ` carlos at redhat dot com
1 sibling, 0 replies; 3+ messages in thread
From: sionescu+BugTrackers at cddr dot org @ 2014-02-10 21:22 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=14749
Stelian Ionescu <sionescu+BugTrackers at cddr dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |sionescu+BugTrackers at cddr dot o
| |rg
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug libc/14749] Dangerous race condition with vfork in posix_spawn
2012-10-21 16:58 [Bug libc/14749] New: Dangerous race condition with vfork in posix_spawn bugdal at aerifal dot cx
2014-02-10 21:22 ` [Bug libc/14749] " sionescu+BugTrackers at cddr dot org
@ 2014-09-20 4:13 ` carlos at redhat dot com
1 sibling, 0 replies; 3+ messages in thread
From: carlos at redhat dot com @ 2014-09-20 4:13 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=14749
Carlos O'Donell <carlos at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |carlos at redhat dot com
--- Comment #1 from Carlos O'Donell <carlos at redhat dot com> ---
I agree this should be fixed. I think posix_spawn and setXid functions should
serialize against eachother. Note that vfork should not serialize against
setXid functions becuase there I think users need to be clever enough to know
what they are doing, but we should still provide better documentation and
example code.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2014-09-20 4:13 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-10-21 16:58 [Bug libc/14749] New: Dangerous race condition with vfork in posix_spawn bugdal at aerifal dot cx
2014-02-10 21:22 ` [Bug libc/14749] " sionescu+BugTrackers at cddr dot org
2014-09-20 4:13 ` carlos at redhat dot com
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).