Problemas al reproducir Ogg bajo Apache con ModSecurity desde Chrome y Chromium

HTML 5 y sus nuevos tags de <audio> y <video> terminaron desencadenando anoche, una batalla campal con mis neuronas.

A raíz de querer incorporar audio OGG en una de mis Webs, descubrí que si el audio estaba alojado en mi servidor, no se reproducía. En cambio, si modificaba la ruta del archivo de audio colocando una URI externa, el audio se reproducía sin problemas.

De allí en más, comencé a investigar si era necesario que el servidor tuviese algún requisito/configuración/cuidado/whatever para permitir la reproducción de audio. Hasta incluso, pedí ayuda por Twitter con la esperanza de que a alguien se le prendiese la lamparita y muchísimas personas colaboraron. Sin embargo, cuando hallé la respuesta final, me di cuenta que era mucho más compleja de lo que me esperaba.

El problema

  • Intentando acceder a la URL del archivo de audio, éste era loclizado y sin embargo no se podía acceder a él.
  • Con wget el archivo bajaba sin inconvenientes;
  • Con los navegadores Firefox, Chrome y Chromium (desde Ubuntu GNU/Linux) podía reproducir audio en el mismo formato sin inconvenientes, siempre y cuando estos archivos NO se encontrasen en mi servidor.

Contexto

Se trataba de un servidor Ubuntu 12.04, con Apache 2.2 y… ModSecurity instalado con el paquete de reglas de OWASP. Mi mayor sospecha estaba sobre estas últimas. Ya habíamos hablado la noche anterior con Dabo, sobre los falsos positivos de ModSecurity.

El camino hacia la solución

A través de Twitter, @mjimeneznet me explicaba que con solo los tags debería funcionar y que el server no necesitaba nada más. Lo mismo sobre los tags, mencionaba todo el mundo! Pero esto iba más allá de HTML 5. Había algo en el servidor, eso era seguro.

Y así fue que a @elrevo, @daviddfr, @hernanJ y @f_rojas se les ocurrió que podría ser necesario indicar los tipos MIME en Apache, ya sea a través de Virtual Host, en apache2.conf directamente o en .htaccess.

Tras agregar al VirtualHost un AddType con el formato ogg, probé y solo en Firefox, parecía haberse resuelto el problema. Sin embargo, en Chrome y Chromium aún seguía el fallo.

En eso apareció @MatiasKatz con quien desde Google Talk, estuvimos haciendo varias pruebas. Hasta que se me ocurrió mirar los logs de error de Apache. Hice un tail -f a los logs, y allí estaban “esperándome” esos “malditos”:

Este error se replicaba decenas de veces. Resaltado en negritas vemos:

  1. ModSecurity negaba el acceso con un error 403;
  2. La causa era el archivo de reglas crs_20 sobre violaciones de protocolo;
  3. La regla específica era la indicada en la línea 248 (vale aclarar que muchas veces, se edita la regla en cuestión y es otra la que prohíbe el acceso así que esto era para ser tomado con pinzas)
  4. La severidad del supuesto ataque evitado, era a penas un aviso (notice)
  5. Finalmente, la URI, era la de mi famoso archivo de audio Fenster.ogg

La parte más desagradable era que ninguna de las URL logueadas, era accesible, así que en principio, no tenía explicación ni justificación para esa regla.

Lo primero que hice para verificar si era o no ModSecurity quien me estaba jodiendo, fue mover el archivo a un directorio de pruebas a fin de eliminarlo de su origen pero mantenerlo en copia de resguardo. Reinicié Apache y el problema desapareció. Finalmente, solo comenté la regla en cuestión y volví a reiniciar Apache.

La solución

En el archivo de reglas modsecurity_crs_20_protocol_violations.conf comentar la regla de línea 248:

Reiniciar Apache y ¡problema resuelto!

La explicación a todo

Erradicar un error pero no encontrarle la explicación lógica es como estar co….

(por si no se entendió mi metáfora: lo anterior fue un ejemplo de algo que te deja con una sensación de discontinuidad y por consiguiente, de algo inconcluso xD)

Así que para no quedarme con esa asquerosa sensación, a pesar de haber resuelto el problema, seguí analizando lo sucedido hasta hallar respuestas y el tema es así:

  • En el archivo de reglas de OWASP, las líneas previas a la regla que se comentó, explicaban de manera abreviada, que la misma era en cumplimiento con lo establecido en las definiciones RFC 2616 (correspondiente a la definición de estándares del protocolo HTTP 1.1);
  • Los estándares HTTP están publicados nada más ni nada menos que por la W3C;
  • En dicha RFC, la sección 14.35.1 se refiere a los rangos de bytes que el cliente (navegador en este caso) envía en los campos de cabecera al servidor (a.k.a “headers” para los amigos). Es decir que la sección 14.35.1 de las RFC 2616 son las que definen los estándares para los rangos de bytes enviados por el cliente al servidor a través de las cabeceras HTTP;
  • Estas especificaciones, dicen claramente que: “si un rango de bytes sintácticamente válido, cuyo primer byte del rango sea menor a la longitud total del elemento a ser servido, o por lo menos, el sufijo del intervalo es distinto que cero, entonces la solicitud puede ser satisfecha por el servidor, pero de lo contrario, el servidor debe rechazar la petición;

Si volvemos a darle un vistazo al error que ModSecurity grabó en los logs, veremos esto:

El valor recibido indicaba un rango inválido en el cual, faltaba el sufijo del rango:

bytes=0-???

Recordemos que ese error, se producía al intentar acceder desde Google Chrome o desde su fork libre Chromium, al archivo de audio ogg. Es decir, que tanto Google Chrome como Chromium, envían como valor de rango de bytes en los encabezados HTTP, un rango inválido (sin sufijo). Dicha solicitud VIOLA LOS ESTÁNDARES DE LAS RFC 2616.

Vale aclarar que:

  1. A raíz de esto, revisando los logs, me di cuenta que el reclamo realizado por muchos usuarios que eran rechazados al intentar descargar un PDF desde dispositivos con Android, también era a causa de este problema. Vale decir que Android tampoco cumple con dichos estándares.
  2. A pesar de haberme enojado con MpdSecurity, no se puede responsabilizar del bloqueo a las reglas de OWASP ni mucho menos a ModSecurity, puesto que es el Software de Google quien al incumplir con dichos estándares provoca que sus aplicaciones actúen de forma similar a como lo haría una herramienta pensada para el ataque.

Lamentablemente, por la irresponsabilidad de Google, la única solución (que en realidad sería utilizar Mozilla Firefox), fue comentar la regla mencionada.

Happy Hacking, Fuckin’ Google!

Dedicado con todo googlelove a mi compañero Debish :P

6 Comentarios

Ubuntu, Apache, VirtualHost, 403 Forbiden y la putaqueloparió

Hace unos meses ya, desde que a un alumno se le ocurrió instalar Ubuntu 13.04, que vengo padeciendo del Síndrome del “pero qué mierda le pasa a esto, carajo!”.

Los pongo en contexto:

Ubuntu 13.04. Se crea un nuevo Virtual Host y al intentar acceder, Apache retorna el error 403 Forbiden.

Si uno ve un error 403 Forbiden, lo primero que piensa es lo obvio: problema de permisos. Pero los permisos pueden tener a la vez, “cientocincuentamillonesdeorígenes“.

En resumidas cuentas, para solventar el problema en su momento, se probaron no una, tampoco 2 ni 10 formas diferentes sino decenas de soluciones posibles y ninguna de ellas lo solucionaba.

Y ¿qué cambió ahora? El martes pasado, estábamos en clase de PHP con mi alumno Marcelo Lobato, quien harto de no poder solucionar el error en Ubuntu 13.04 decidió pasar al más querido estable 12.04 LTS. Estábamos creando nuevamente un Virtual Host, cuando para mi sorpresa, Apache volvió a arrojar un 403 Forbiden y mi grito de “Oh, pero qué mierda le pasa a esto, carajo!” se hizo evidente.

Puteada va, prueba viene, a Marcelo se le ocurrió la brillante idea de decir: - “¿No tendrá algo que ver que al momento de instalar Ubuntu yo haya elegido cifrar mi carpeta personal?”

¡Me cago en la puta! ¿Cómo pude no tener en cuenta que las carpetas personales podrían estar cifradas?!?! Si la carpeta está cifrada, el usuario de Apache, es decir, www-data, no tendría acceso a ella. Y, hablando con uno y otro, ¿podría ser que Ubuntu 13.04 más allá de la elección del usuario estuviese cifrando la carpeta personal por defecto? Sí, podría ser, pero aún falta laboratorio para dar una respuesta certera.

Por lo pronto, aquí les dejo la solución al problema.

Lo primero que hay que hacer, es cerciorarse de que el problema, realmente se debe al impedimento del usuario de Apache, de acceder a la carpeta raíz del dominio. Para comprobar esto, la forma fácil y rápida es editar el archivo de configuración de Apache, indicando como usuario y grupo al usuario y grupo propietarios de la carpeta en cuestión.

Supongamos que el DocumentRoot de tu Virtual Host es /home/pepe/miweb y que el propietario del directorio miweb es pepe:pepe. Como súper usuario, editas el archivo /etc/apache2/apache2.conf y buscas las siguientes líneas:

Y las reemplazas por el usuario y grupo propietarios de la carpeta en cuestión, respectivamente:

Reinicias Apache:

sudo service apache2 restart

Y pruebas nuevamente ingresar en tu host virtual. Si logras acceder SIN un 403 Forbiden, el problema, efectivamente, se debe al impedimento del usuario de Apache, de acceder a la carpeta raíz del dominio.

¿Cuál sería la solución entonces? Obviamente, volver las variables User y Group del apache2.conf a su estado original y luego, crear una carpeta FUERA de la carpeta cifrada, pero con el mismo propietario para no estar trabajando allí dentro ni como root ni cosas locas. Una buena alternativa es esta:

Y no olvidar de asignar como ruta del DocumentRoot del VirtualHost, el nuevo path /srv/miweb.

Ahora sí, Happy Hacking!

8 Comentarios

DaboBlog Podcast, número 33. “Kernel Panic” ya disponible (con Forat)

Amigos de DebianHackers, aquí volvemos con la entrega nº 33 del podcast. En esta ocasión le ha tocado a Forat (en el próximo estará n1mh) y como se puede ver debajo en el guión, hay alguna historia “para no dormir”. Tenemos pendiente un especial Fluxbox y Debian que grabaré con Debish espero que pronto (de hecho ya lo grabamos en su día pero nos quedó un “churro” de audio y hay que repetir). Sin más, os dejo con todos los datos del audio. Un saludo y gracias por el apoyo que nos llega por vuestra parte ;).

Al igual que en otras ocasiones, os animamos a dejar cualquier sugerencia sobre temas a tratar en sucesivas entregas del podcast, podéis hacerlo aquí o en nuestros Twitters; @antoniojperez, @daboblog, @foratinfo, @lurphoto, @n1mh,@oreixa donde los días de grabación, solemos anunciar cuando empezamos a grabar para que dejéis vuestras propuestas, comentarios o temas que os gustaría que tocásemos, pero también podéis hacerlas llegar en esta misma entrada.

Contenidos incluidos; (Duración 2,23 h)

> Intro (00:00 hasta el minuto 03:44)

(Por David Hernández, Dabo) Presentación y comentarios sobre este episodio 33.

> Kernel Panic (Minuto 03:45 hasta el 1:16 h)

En Twitter; DaboForat  (Diego aka n1mh estará en el próximo).

Alguno se quedará un tanto K.O cuando escuche a Forat y lo que le pasó con un Vaio y unos ¿drivers? para Windows 7. Hablamos también de las nuevas mejoras que vamos viendo en el Kernel, lógicamente Ubuntu 11.04 tiene un gran protagonismo (hablamos de las novedades y de cambios futuros) damos un repaso a su proyecto “Viejos ordenadores que hacen grandes cosas” (muy bien explicado),  Servers, Software libre en la empresa (o “la falta de”), seguimos con Unity – GNOME, aplicaciones, Distros “diferentes” y otras habituales recién salidas del horno, opinión, (IN) seguridad en DropBox, etc.

El equipo del podcast

DaboBlog Podcast nº33, “Kernel Panic” y “Manzanas traigo”.

Ficha completa en ivoox.com del episodio 33.

Baja >el audio. Escuchar o descargar. (Navegador, lector de feeds o móvil sin Flash)

Suscríbete  En GPodder | iTunes ico.itunes | iGoogle ico.igoogle | tu lector de RSS ico.rss

¿No ves el reproductor integrado vía tu lector de RSS?, entra con tu navegador

Nos volvemos a escuchar en el número 34 del podcast (Fecha “Primeros de Diciembre “).

Tenéis también todos los episodios desde el primero en esta nueva sección del blog y en este link de ivoox.com.

> Manzanas Traigo ( 1:16 h hasta 2:23 h)

3 Comentarios