Sobre el último BUG de OpenSSH

En la página de erratas encontramos esto.

001: SECURITY FIX: March 30, 2008 All architectures
sshd(8) would execute ~/.ssh/rc even when a sshd_config(5) ForceCommand directive was in effect, allowing users with write access to this file to execute arbitrary commands. This behaviour was documented, but was an unsafe default and an extra hassle for administrators.
A source code patch exists which remedies this problem.

Es muy normal que OpenBSD anuncie los problemas de seguridad de esta forma, sin embargo mucha gente se queda sin entender que fue lo que pasó. Esta es una breve explicación del problema.

El problema esta en el demonio SSH, el cuál tiene un parámetro de configuración (en el archivo /etc/ssh/sshd_config) que permite que la cuenta ssh solo ejecute un comando de forma forzada, impidiéndole al usuario logueado ejecutar un shell y por lo tanto trabajar normalmente.

Para que se quiere algo así?, por ejemplo cuando deseamos que una cuenta no tenga shell, pero se requiere autenticación para ejecutar algún comando, como por ejemplo conexión a un CVS, apagado automático de estaciones, ejecución de scripts de mantenimiento, etc.

El parámetro en cuestión se llama ForceCommand y se usa muy fácil, por ejemplo:

...
Match User tatiana
ForceCommand echo "hola amigo" && echo "chao amigo"
...

Con esa configuración, cada vez que el usuario tatiana se loguee en el sistema usando ssh, ejecutará los dos comandos mostrados y se saldrá del sistema (automáticamente).

debian:/home/tatiana# ssh [email protected]
[email protected]'s password:
hola amigo
chao amigo
Connection to 192.168.0.5 closed.
debian:/home/tatiana#

Bueno y el problema cual es?.

En el archivo fuente session.c del demonio SSH, tenemos unas líneas:

...
/*
* Run $HOME/.ssh/rc, /etc/ssh/sshrc, or xauth (whichever is found
* first in this order).
*/
static void
do_rc_files(Session *s, const char *shell)
{
FILE *f = NULL;
char cmd[1024];
int do_xauth;
...

Esas líneas me anuncian que el demonio ssh ejecuta unos ficheros si los encuentra, en su orden son: $HOME/.ssh/rc, /etc/ssh/sshrc y xauth.

Así que si un usuario quiere ejecutar comandos de forma automatizada cada vez que se conecta por ssh, lo único que debe hacer es grabar los respectivos comandos en $HOME/.ssh/rc, donde $HOME obviamente es el home del usuario, casi siempre /home/usuario.

El bug entonces es que si el administrador le ha configurado un ForceCommand a un usuario especifico y este usuario consigue de alguna manera editar el archivo rc en cuestión, entonces el demonio ssh ejecutará el archivo rc, sin importar las restricciones que le haya puesto el admin. El parche de la errata corrige esto, validando que se ejecutará el archivo $HOME/.ssh/rc, siempre y cuando no tenga restricciones de ForceCommand.

¿Con esto se podría hackear un sistema?, ¿que opinan ustedes?, ese es el concepto de seguridad de OpenBSD, que esta muy lejos del concepto normal de BUG de seguridad del común. Hay que seguir por un tiempo las listas y leer los CVS para tratar de entender cual es el concepto de seguridad que tiene el CORE de OpenBSD.

Cosas peores se han visto reportadas como “problemas de mejoramiento, estabilidad, fiabilidad” y no como problemas de seguridad. Esto sin embargo lo clasifican como problema de seguridad, solo por dos motivos, por que hace sentir incomodo al administrador y esta by default. Jajaja.

! Larga vida a OpenBSD !

Fin de la historia.