0002201: Security issue with starting up multiple resin instances in cluster mode

Viewing Issue Advanced Details [ Jump to Notes ]

[ View Simple ] [ Issue History ] [ Print ]

Category

Severity

Reproducibility

Date Submitted

Last Update

0002201

[Resin]

major

always

11-22-07 11:52

11-30-07 15:14

Reporter

ckchris

View Status

public

Assigned To

ferg

Priority

normal

Resolution

fixed

Platform

Status

closed

Projection

none

OS Version

ETA

none

Fixed in Version

3.1.4

Product Version

3.1.3

Product Build

Summary

0002201: Security issue with starting up multiple resin instances in cluster mode

Description

Normal/unauthorized users are able to start up and shutdown individual server instances without any restrictions.

I have been toying around with creating two clusters running on the same machine, each with its own <server> (cluster a, server a and cluster b, server b) running on separate srun ports. I have user-name set to change from root to resin for the servers. Watchdog process runs as root.

So if you look at the process tree, it will look something like this:

root 19266 0.0 1.3 278620 45208 pts/1 Sl 04:07 0:03 /usr/java/jdk1.5.0_14/bin/java -Djava.util.logging.manager=com.c
resin 20179 6.5 8.2 933960 278436 pts/1 Sl 11:09 0:22 \_ /usr/java/jdk1.5.0_14/bin/java -Djava.util.logging.manager=c
resin 20221 9.8 2.1 861036 73812 pts/1 Sl 11:14 0:04 \_ /usr/java/jdk1.5.0_14/bin/java -Djava.util.logging.manager=c

Server a has an http port configured to be 80. Server b is running only a srun server that gets used through a rewrite-dispatch from server a.

The Security Problem
========================

*) If no instances are running, a normal user cannot start up resin without hitting a "binding address" error since port 80 requires superuser access. This works as expected.

*) If watchdog process is started to run either server a or b as root, then everything starts up fine.

*) Once watchdog process is started, a normal user is able to start and stop server a at will that binds to port 80 with no problems. This is because the watchdog process is running as root.

It appears that the watchdog process is listening for any commands asking it to start up any instances without security checks. Since it's running as root, it's possible that once a watchdog process is started as root, any user can ask the watchdog process to start any resin instances and bind the http to listen on any ports under 1024.

This security risk can probably be mitigated by running watchdog process as a normal "resin" user, but that would of course require the firewall configuration, which is not preferred. However, even with the watchdog running as a normal "resin" user, any user can still ask resin to start up any instances that can then inadvertently give them access to resin state information and logs in the server root directory (ie. session.db and cache.db and admin data).

Normally, these are not readable by the world so normal users can't see them, but if they can start up any resin instance that can be run under the same watchdog process, they can create servlets to read into the resin-own directories with no problems.

There is one thing that I noticed. The server that's started will only run under the same watchdog process if, I believe, the same server-root directory, config, and others are used. I am not sure though. If this is the case, then the security risk is a bit lower. This means that I can simply make the resin.conf file unreadable by the world and everything should be ok.

-Chris Chen

Steps To Reproduce

Additional Information

JDK 1.5_12 on Linux CentOS 5

Attached Files

Relationships

Notes
(0002549) ferg 11-30-07 15:13	Added watchdog-password

Issue History
Date Modified	Username	Field	Change
11-22-07 11:52	ckchris	New Issue
11-22-07 12:01	ckchris	Issue Monitored: ckchris
11-30-07 15:13	ferg	Note Added: 0002549
11-30-07 15:14	ferg	Assigned To	=> ferg
11-30-07 15:14	ferg	Status	new => closed
11-30-07 15:14	ferg	Resolution	open => fixed
11-30-07 15:14	ferg	Fixed in Version	=> 3.1.4

Mantis 1.0.0rc3[^]

30 total queries executed.
26 unique queries executed.