|
Home > Archive > Debian Developers > August 2004 > init scripts and su
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
init scripts and su
|
|
| Russell Coker 2004-07-28, 6:23 pm |
| The start scripts for some daemons do "su - user" or use
"start-stop-daemon -c" to launch the daemon, PostgreSQL is one example.
During the time between the daemon launch and it closing it's file handles and
calling setsid(2) (which some daemons don't do because they are buggy) any
other code running in the same UID could take over the process via ptrace,
fork off a child process that inherits the administrator tty, and then stuff
characters into the keyboard buffer with ioctl(fd,TIOCSTI,&c) (*).
To address these issues for Fedora I have written a program named init_su.
init_su closes all file handles other than 1 and 2 (stdout and stderr). File
handles 1 and 2 are fstat()'d, if they are regular files or pipes then they
are left open (no attack is possible through a file or pipe), otherwise they
are closed and /dev/null is opened instead. /dev/null is opened for file
handle 0 regardless of what it might have pointed to previously. Then
setsid() is called to create a new session for the process (make it a group
leader), this invalidates /dev/tty. Then the uid is changed and the daemon
is started.
I have attached the source code to init_su, please check it out and tell me
what you think. After the discussion concludes I will write a patch for
start-stop-daemon to give similar functionality.
(*) On system boot and shutdown there is no problem. It's when the
administrator uses /etc/init.d/postgresql to start or stop the database that
there is potential for attack.
http://www.redhat.com/archives/fedo...y/msg01314.html
I have also started a similar discussion on the Fedora development list about
this issue, see the above URL.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
| |
| Miquel van Smoorenburg 2004-07-28, 6:23 pm |
| In article <200407261453.56729.russell@coker.com.au>,
Russell Coker <russell@coker.com.au> wrote:
>The start scripts for some daemons do "su - user" or use
>"start-stop-daemon -c" to launch the daemon, PostgreSQL is one example.
>
>During the time between the daemon launch and it closing it's file handles and
>calling setsid(2) (which some daemons don't do because they are buggy) any
>other code running in the same UID could take over the process via ptrace,
>fork off a child process that inherits the administrator tty, and then stuff
>characters into the keyboard buffer with ioctl(fd,TIOCSTI,&c) (*).
>
>To address these issues for Fedora I have written a program named init_su.
>
>init_su closes all file handles other than 1 and 2 (stdout and stderr). File
>handles 1 and 2 are fstat()'d, if they are regular files or pipes then they
>are left open (no attack is possible through a file or pipe), otherwise they
>are closed and /dev/null is opened instead. /dev/null is opened for file
>handle 0 regardless of what it might have pointed to previously. Then
>setsid() is called to create a new session for the process (make it a group
>leader), this invalidates /dev/tty. Then the uid is changed and the daemon
>is started.
The problem is, if the daemon fails to initialize, say there's
a typo in the config file, it won't be able to print this
fact to the tty.
You probably should attach stdout/stderr to a pipe or pseudo-tty,
fork off the daemon, and poll() the pipe/pseudo-tty writing all
output to stdout, until the child dies (actually, daemonizes).
If you use a pseudo-tty you can invalidate the tty filehandle
in the parent just before exiting so that no resources are held
by the daemon.
Still it should be optional somehow since I have a similar idea
as a replacement for bootlogd. Perhaps an environment
variable called INIT_SU_TRANSPARANT or somesuch.
Mike.
--
The question is, what is a "manamanap".
The question is, who cares ?
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Russell Coker 2004-07-28, 6:23 pm |
| On Mon, 26 Jul 2004 19:17, "Miquel van Smoorenburg" <miquels@cistron.nl>
wrote:
> The problem is, if the daemon fails to initialize, say there's
> a typo in the config file, it won't be able to print this
> fact to the tty.
The details of the error can be logged to syslog, the main daemon process can
then return an error code which the script can use to display a message of
the form "daemon foo failed to start, check syslog for details".
> You probably should attach stdout/stderr to a pipe or pseudo-tty,
> fork off the daemon, and poll() the pipe/pseudo-tty writing all
> output to stdout, until the child dies (actually, daemonizes).
I've done this in the past via an expect script, but it didn't work well with
some daemons. asterisk is one example.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Andrew Pimlott 2004-07-28, 6:23 pm |
| On Mon, Jul 26, 2004 at 02:53:56PM +1000, Russell Coker wrote:
> The start scripts for some daemons do "su - user" or use
> "start-stop-daemon -c" to launch the daemon, PostgreSQL is one example.
>
> During the time between the daemon launch and it closing it's file handles and
> calling setsid(2) (which some daemons don't do because they are buggy) any
> other code running in the same UID could take over the process via ptrace,
> fork off a child process that inherits the administrator tty, and then stuff
> characters into the keyboard buffer with ioctl(fd,TIOCSTI,&c) (*).
If this is a real problem (which it sounds like), it's not specific to
init scripts. Shouldn't it be fixed in su?
> init_su closes all file handles other than 1 and 2 (stdout and stderr). File
> handles 1 and 2 are fstat()'d, if they are regular files or pipes then they
> are left open (no attack is possible through a file or pipe)
In principle any resource leaked to the target uid is a potential
threat. The question is whether it can be blocked without breaking
intentional "leakage", eg echo ... | su - nobody .... I think your
point is that a tty is usually dangerous and unnecessary leakage, and
thus should be blocked.
Maybe your changes should happen in su by default, with a --leak-tty
option if you want to keep the terminal.
Andrew
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Russell Coker 2004-07-28, 6:23 pm |
| On Tue, 27 Jul 2004 07:48, Andrew Pimlott <andrew@pimlott.net> wrote:
>
> If this is a real problem (which it sounds like), it's not specific to
> init scripts. Shouldn't it be fixed in su?
Ideally yes. But that involves proxying all operations on the pseudo-tty
which is quite a difficult task.
> Maybe your changes should happen in su by default, with a --leak-tty
> option if you want to keep the terminal.
I can't imagine us changing the way su works by default. The only way to make
"su user" not have this problem by default is to proxy the pseudo-tty stuff.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Andrew Pimlott 2004-07-28, 6:23 pm |
| On Wed, Jul 28, 2004 at 04:56:20PM +1000, Russell Coker wrote:
> On Tue, 27 Jul 2004 07:48, Andrew Pimlott <andrew@pimlott.net> wrote:
>
> Ideally yes. But that involves proxying all operations on the pseudo-tty
> which is quite a difficult task.
Ok, I don't know enough about how terminals work. I thought from your
description that there was some way to protect the terminal from the
child by creating a new session or something.
But if su is really as unsafe as you say, maybe the pseudo-tty is the
right answer. I verified that if I "su - andrew bash" as root, then
andrew can write to root's terminal, even after bash exits (just hold
the fd open). I don't know how to go further, but from what you say I
believe it's possible. Sounds scary.
Andrew
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Miquel van Smoorenburg 2004-07-28, 6:23 pm |
| In article <200407281656.20481.russell@coker.com.au>,
Russell Coker <russell@coker.com.au> wrote:
>On Tue, 27 Jul 2004 07:48, Andrew Pimlott <andrew@pimlott.net> wrote:
>
>Ideally yes. But that involves proxying all operations on the pseudo-tty
>which is quite a difficult task.
Wait a minute. Is this about TIOCSTI only ? You can only use TIOCSTI
on your controlling tty. After calling setsid(), stdin/stdout/stderr
are still connected to the tty, but that tty isn't the controlling
tty anymore. So TIOCSTI doesn't work at all.
So you don't need to close fd 0/1/2. Just make sure to fork()
(to make sure you're not a process group leader anymore) and
call setsid() before setuid() and TIOCSTI won't work.
Perhaps start-stop-daemon should have a command line option that
makes it fork() and setsid() (--setsid ?)
Mike.
--
The question is, what is a "manamanap".
The question is, who cares ?
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Russell Coker 2004-07-29, 2:52 am |
| On Wed, 28 Jul 2004 20:04, "Miquel van Smoorenburg" <miquels@cistron.nl>
wrote:
>
> Wait a minute. Is this about TIOCSTI only ? You can only use TIOCSTI
> on your controlling tty. After calling setsid(), stdin/stdout/stderr
> are still connected to the tty, but that tty isn't the controlling
> tty anymore. So TIOCSTI doesn't work at all.
Great!
> Perhaps start-stop-daemon should have a command line option that
> makes it fork() and setsid() (--setsid ?)
Why would it ever be desirable to not have start-stop-daemon call setsid()?
I think that we should just have start-stop-daemon call setsid() regardless.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Miquel van Smoorenburg 2004-07-29, 2:52 am |
| In article <200407291624.29653.russell@coker.com.au>,
Russell Coker <russell@coker.com.au> wrote:
>On Wed, 28 Jul 2004 20:04, "Miquel van Smoorenburg" <miquels@cistron.nl>
>wrote:
>
>Great!
>
>
>Why would it ever be desirable to not have start-stop-daemon call setsid()?
Don't know .. you have to do an extra fork() (and wait() for it) in
start-stop-daemon, so it might be a tad slower (a ms at most).
There are also people using start-stop-daemon for all other kinds
of things, as replacement for 'su' (--start --chuid xx --exec /bla/bla)
and doing setsid() might break those applications .. but you could
argue that setsid should be used esp. in the --chuid case
>I think that we should just have start-stop-daemon call setsid() regardless.
An unconditional change would have to go in after sarge, in case
it breaks something .. it needs a long period of testing I think.
Mike.
--
The question is, what is a "manamanap".
The question is, who cares ?
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Russell Coker 2004-07-31, 7:49 am |
| On Thu, 29 Jul 2004 18:14, "Miquel van Smoorenburg" <miquels@cistron.nl>
wrote:
>
> Don't know .. you have to do an extra fork() (and wait() for it) in
> start-stop-daemon, so it might be a tad slower (a ms at most).
I don't think that an extra fork() is required.
In the usual operation of start-stop-daemon it is called from a script which
waits for it to end, therefore it is not the process group leader and
setsid() will succeed without a fork.
Is there any situation in which setsid() can fail, but in which stuffing input
into /dev/tty will allow it to be received by another process?
> There are also people using start-stop-daemon for all other kinds
> of things, as replacement for 'su' (--start --chuid xx --exec /bla/bla)
> and doing setsid() might break those applications .. but you could
> argue that setsid should be used esp. in the --chuid case
Yes! chuid is exactly where it's needed.
>
> An unconditional change would have to go in after sarge, in case
> it breaks something .. it needs a long period of testing I think.
I guess so, I wasn't expecting it to go in immediately. We can easily produce
a back-port for people who want secure systems.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Jan Minar 2004-08-01, 8:47 pm |
| -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, Jul 28, 2004 at 04:54:35AM -0400, Andrew Pimlott wrote:
> I verified that if I "su - andrew bash" as root, then
> andrew can write to root's terminal, even after bash exits (just hold
> the fd open).
Did You use the ioctl() method Russel described, or another means?
(Would You care to share the code?)
Jan.
- --
"To me, clowns aren't funny. In fact, they're kind of scary. I've wondered
where this started and I think it goes back to the time I went to the circus,
and a clown killed my dad."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQFBDTVd+uczK20Fa5cRAqV2AJ0X7nJxwDrJ
nVxCXNGsuTLQzBfIqwCg2e3T
jc9mVA6BtolheZLmgkd5qck=
=MRa3
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Andrew Pimlott 2004-08-01, 8:47 pm |
| On Sun, Aug 01, 2004 at 08:24:29PM +0200, Jan Minar wrote:
> On Wed, Jul 28, 2004 at 04:54:35AM -0400, Andrew Pimlott wrote:
>
> Did You use the ioctl() method Russel described, or another means?
> (Would You care to share the code?)
No, I just meant write(2). Eg,
# ls -l `tty`
crw--w---- 1 root tty 136, 159 Aug 1 18:37 /dev/pts/671
# su - andrew bash
$ (sleep 20; echo hello) &
[1] 5764
$ disown %1
$ exit
# hello
Or even
# su - andrew bash
$ ./sendfd
$ exit
# hello
Where sendfd sends stdout over a unix socket to recvfd, which waits 10
seconds after it receives the fd, then writes "hello". (Rough sources
attached.) Obviously, neither scenario is realistic in that you don't
just give a shell to the user you su to. However, I think at least the
sendfd version is just as possible, with a little more work, by the
target user attaching to the process and running the code that way. As
a small proof of that, i note that I can run, from another terminal, as
andrew,
gdb =bash $(pidof bash)
...
(gdb) p write(1, "hello\n", 6)
and have "hello" show up on the terminal running "su - andrew bash".
Maybe I'm missing something, or maybe read/write is not considered a
serious vulnerability, but it looks unsafe to me.
(BTW, be sure that the tty you are using is actually owned by root. At
one point, I was working in a terminal in which I had su'ed to root, but
the tty was still owned by andrew.)
Andrew
| |
| Jan Minar 2004-08-27, 6:25 pm |
| Hi all!
Has anyone made any progress in solving the su/sudo/super TIOCSTI ioctl
vulnerability?
--
Jan
| |
| Thomas Hood 2004-08-27, 6:25 pm |
| Jan Minar wrote:
> Has anyone made any progress in solving the su/sudo/super TIOCSTI
> ioctl vulnerability?
Am I correct in thinking that the vulnerability occurs when the
admin runs "su foouser barcmd" from a shell *and* there is some
compromised program running as user foouser which waits for this
to happen and, when it does, injects characters into the admin's
terminal to cause arbitrary commands to be executed with root
privilege?
--
Thomas Hood
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Russell Coker 2004-08-28, 7:48 am |
| On Thu, 26 Aug 2004 17:01, Thomas Hood <jdthood@yahoo.co.uk> wrote:
> Jan Minar wrote:
>
> Am I correct in thinking that the vulnerability occurs when the
> admin runs "su foouser barcmd" from a shell *and* there is some
> compromised program running as user foouser which waits for this
> to happen and, when it does, injects characters into the admin's
> terminal to cause arbitrary commands to be executed with root
> privilege?
Yes. Or alternately the admin runs "su - user" and the .login file for the
account is trojaned.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
|
|
|
|
|