Description of problem: I'm not sure if this bug should be severity security or enhancement. In normal operation, the netdump client copies its session cookie to the server using ssh on startup. The /var/crash/.ssh/authorized_keys2 file doesn't limit the commands the client can run on the server over ssh. Therefore, root on a compromised but trusted netdump client can run *any* command on the server as user netdump without a password. Version-Release number of selected component (if applicable): netdump-0.6.6-1 How to reproduce: 1. Set up a netdump server (10.0.0.1 below) and a client that crash dumps to it. 2. Run the following command on the client as root: ssh -i /etc/sysconfig/netdump_id_dsa netdump.0.1 cat /etc/passwd 3. The server's /etc/password file is displayed to stdout. Suggested fix: Restrict the /var/crash/.ssh/authorized_keys2 file to only allow the cookie distribution command by starting each key entry with a command option: command="echo "$MAGIC2$MAGIC1" \> /var/crash/magic/$LOCALADDR"
Steve -- thanks for the report. I guess I've never seen an authorized_keys entry with a command restriction. Can you suggest how would that be properly scripted in the netdump init script? Here's what it does now: propagate () { # propagate netdump ssh public key to the crashdump server cat /etc/sysconfig/netdump_id_dsa.pub | \ ssh -x netdump@$NETDUMPADDR cat '>>' /var/crash/.ssh/authorized_keys2 }
Damn -- the MAGIC numbers are only calculated at each boot time registration; the "propagate" command is a one-time only operation.
Even though we can't encode the MAGIC numbers into the conditional we can submit that information via standard input. I suggest we format the authorized entry like this: command="cat /var/crash/magic/$LOCALADDR",no-port-forwarding $KEY ... and do: echo "$MAGIC2$MAGIC1" | ssh -x -i /etc/... netdump@NETDUMPADDR Thoughts?