Depurando PHP con Xdebug y Docker

Hasta hace poco he estado depurando PHP al viejo estilo, poniendo error_log, print_r y demás mensajes aquí y allá. La verdad es que era algo poco dañino y que, si programas bien, tampoco da mucho trabajo. Sin embargo echaba de menos las facilidades de java en el eclipse donde podía depurar de manera increíblemente eficiente sin modificar nada de mi código. El caso es que utilizando docker como base del desarrollo/despliegue de PHP se hacía muy complicado configurar las cosas para depurar. Al final, por circunstancias que no vienen al caso, me animé a ver cómo podríamos depurar código php desplegado usando docker… Y os hago aquí un resumen:

El problema básico

Supongamos que queremos hacer un programa básico en php y desplegarlo para poder verlo en nuestro navegador. Por ahora nos vamos a limitar a este archivo

phpinfo.php

<?php
phpinfo();

Si, es un archivo muy simplón, pero primero tenemos que desplegarlo utilizando docker y verlo en un navegador. Para ello creamos un directorio para nuestro proyecto (llamemosle php-samples, por ejemplo) y dentro del mismo creamos un subdirectorio llamado web y dentro de este directorio creamos el archivo phpinfo.php con el contenido anterior.

La forma más rápida

En el directorio superior creamos un archivo llamado docker-compose.yml con este contenido:

services:
  php:
    image: yoprogramo/php8.2:1.0.2
    volumes:
        - ./web:/var/www/Website
    ports:
        - 8080:80

Ya puestos cargamos el proyecto en visual studio code y nos quedará algo así:

Desde el terminal, o desde el menú de la extensión docker si la tenéis instalada, levantamos el contenedor. Una vez levantado ya podremos acceder a la url:

http://localhost:8080/phpinfo.php

Vale, prueba superada, ya tenemos nuestro servidor ejecutando php, ahora crearemos otro archivo dentro de web con un programa en php un poco más complejo para poder depurarlo a gusto. Vamos a llamar a ese archivo index.php y le daremos este contenido:

<?php
function isPrime($num) {
    if ($num <= 1) return false;
    if ($num == 2) return true;
    if ($num % 2 == 0) return false;
    for ($i = 3; $i <= sqrt($num); $i += 2) {
        if ($num % $i == 0) return false;
    }
    return true;
}

$randomNumber = rand(0, 19);

echo "<table border='1'>";
echo "<tr><th>Número</th><th>Primos menores que $randomNumber</th></tr>";
echo "<tr><td>$randomNumber</td><td>";

for ($i = 0; $i < $randomNumber; $i++) {
    if (isPrime($i)) {
        echo "$i ";
    }
}

echo "</td></tr>";
echo "</table>";
?>

Ahora podemos acceder a la url index.php (o no poner ruta ya que es el archivo que se cargará por defecto)

Vale, pero todo este rollo era para poder depurar el código, para poder hacerlo tenemos que hacer tres cosas:

  • Cambiar la imagen docker por yoprogramo/php8.2:1.0.2-xdebug en el docker-compose.yml y añadir este apartado al servicio php:
extra_hosts:
  - "host.docker.internal:host-gateway"
  • Instalar el plugin «PHP Debug»
  • Configurar el visual studio code para php, para ello pinchamos en el icono de depuración (run and debug) y pinchamos donde pone «create a launch.json file)

Esto nos creará un archivo por defecto donde tendremos que modificar la configuración «Listen for Xdebug» para añadir esto:

"pathMappings": {
   "/var/www/Website": "${workspaceRoot}/web"
}

Pulsamos sobre el icono de iniciar depuración con es configuración (o pulsamos F5)

Con todo configurado solo nos queda reiniciar el docker con la nueva imagen y poner algún breakpoint en el código (eso se hace pinchando a la izquierda del número de línea donde queramos que se pare la ejecución, por ejemplo dentro del bucle de index.php

Ahora volvemos a cargar la página index.php y si todo ha ido bien la ejecución se parará y podremos ver en el editor los valores de las variables

Y continuar la ejecución o hacerlo paso a paso

Si queréis saber cual es el camino difícil o cómo hacerlo con vuestras propias imágenes docker, solo tenéis que preguntar…

De puertas traseras y software libre

Es casi imposible que no hayas oido hablar del backdoor xz, no es que yo pueda darte más información sobre el tema, os dejo un video de alguien que os cuenta el caso completo como si de un episodio de serie negra se tratase:

El caso es que, alguien durante tres años ha ido infiltrándose en un repositorio de un elemento pequeño pero crítico de software libre llamado xz, de tal manera que consiguió, no solo quedarse como mantenedor de ese repositorio sino que fue introduciendo, poco a poco, una puerta trasera que permitía el acceso remoto (todavía hay que ver el payload real lo que llegaba a hacer) y conseguir que ese backdoor se distribuyese en algunas de las más importantes distribuciones.

Por suerte, o mejor dicho, por la misma estructura del software libre, esta versión no pasó de las versiones inestables de las distribuciones y se descubrió el pastel porque una persona notó que algo iba más lento de lo que debía después de la actualización. Esta persona (Andres Freund) no se paró en medir el tiempo de respuesta sino que terminó encontrando la causa subyacente y la puerta trasera que habían metido (aquí el aviso que dió a la comunidad) y, obviamente, la reacción de los mantenedores de la distribución, e incluso del antiguo mantenedor del repositorio fue inmediata y reliminó todas las trazas del código dañino.

Hay varias cosas que podemos destacar, pero yo me quedo con un par de ellas:

  1. La dependencia que tenemos de código que han escrito terceros y que pueden estar bien mantenidos o no (dependiendo del ánimo de esa persona o de sus circunstancias personales)
  2. La potencia del ecosistema open source para descubrir y arreglar este tipo de problemas. Todos los sistemas operativos actuales, desde mac os hasta windows usan componentes externos, no hay ninguno 100% original y tampoco es que se pueda saber qué es lo que usan exactamente. Si hay un backdoor en windows o en macos nos lo tendremos que comer con patatas porque nadie puede mirar lo que hay dentro.

Estoy seguro de que esta forma de actuar, por muy inteligente y paciente que sea, no deja de ser un ataque en toda regla con unas finalidades seguramente malvadas (crear una botnet inmensa, por ejemplo) y no creo que sepamos realmente quien está detrás de ello y, posiblemente, nos de para una docuserie de Netflix un día de estos.

En fin, no ha pasado nada, todo está en orden de nuevo y lo malo es que nos deja un regusto amargo y hace bajar un peldaño la confianza que teníamos en el ecosistema (pero no mucho, oye, que seguimos estando a salvo).

AMAZON SES y cómo enviar correos desde un servidor ubuntu

Enviar correo desde una máquina virtual en Amazon siempre ha sido un castigo. Las limitaciones al puerto 25 y a los controles de tráfico de Amazon hacían poco recomendable poner un servidor de correo «normal» en la infraestructura. Sin embargo – y pagando, claro está – Amazon ha puesto a disposición de todo el mundo un servicio para poder enviar correos sin demasiada complicación (aunque, como veremos, también tiene sus limitaciones).

Lo primero es lo primero, si quieres mandar correos usando Amazon SES. La información general la puedes ver aquí: https://aws.amazon.com/es/ses/ y create una identidad verificada (tendrás que cambiar cosas en el dns para que puedas enviar correo desde cuentas de tu dominio. Lo siguiente será crear una configuración de SMTP para tu cuenta, eso te dará un servidor, usuario y contraseña que usar para mandar correos (y los puertos correspondientes)… Anotalos muy bien que será lo que vamos a utilizar.

Al principio tendrás unas limitaciones muy importantes (para probar no nos afectan demasiado) y tendrás que crear direcciones de correo validada, hazlo y prueba que puedes enviar correos a esas cuentas antes de continuar. Los pasos para poder enviar correo desde un servidor ubuntu serían los siguientes:

  1. Instala postfix
sudo apt install -y postfix libsasl2-modules
  1. Añade estas líneas a /etc/postfix/sasl_passwd
smtp_tls_note_starttls_offer = yes 
smtp_tls_security_level = encrypt 
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd 
smtp_sasl_security_options = noanonymous 
relayhost = [email-smtp.xx-xxxx-xx.amazonaws.com]:587 
smtp_sasl_auth_enable = yes 
smtp_use_tls = yes 
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt 
mydestination = 
  1. En /etc/postfix/sasl_passwd
[email-smtp.xx-xxxx-x.amazonaws.com]:587 USUARIO:PASSWORD
  1. Lanza las modificaciones
sudo newaliases 
sudo postmap hash:/etc/postfix/sasl_passwd 
sudo systemctl restart postfix

Y ya estaría, ya puedes enviar correos desde cuentas de tu dominio con sendmail. Si ves algún problema siempre puedes consultar el log en /var/log/mail.log

Si todo va bien lo siguiente es pedir a Amazon que, por favor, os pongan en producción el sistema para poder enviar correos a todo el mundo. Y ya si eso, en otro post, os cuento como configurar una imagen docker para que lo use…

Gestión de versiones de Flutter

Flutter es un framework que me está gustando bastante, es muy consistente en cuanto a las distintas versiones, se ve muy similar en todas las plataformas y Dart como lenguaje es bastante interesante y nada esotérico (por eso de que usa cosas que ya manejamos y no se dedica a reinventar la rueda).

Flutter Version Management

Tanto es así que empezamos hace unos meses un proyecto de aplicación móvil con Flutter, coincidiendo con la llegada de la versión 2.0 y las cosas empezaron a ir «demasiado deprisa». La comunidad y los mantenedores del sdk parece que se han puesto las pilas y han decidido incluir mejoras a un ritmo trepidante, cuando escribo estas líneas ya vamos por la versión 2.8.1.

Nosotros estabilizamos la app en un contenedor docker usando la versión 2.5.2 de Flutter y nos encontramos ahora que no hay manera de instalar desde cero esa versión con los sistemas que proporciona Flutter. Todos aquellos sistemas en los que hicimos un upgrade ya no los podemos utilizar para desarrollo porque, entre otras cosas, han cambiado librerías y ya no son compatibles algunas partes de nuestro código.

Pero no soy el único con ese problema. Varios de los desarrolladores de Flutter se han encontrado con la misma situación y, afortunadamente, han desarrollado una manera de poder disponer de una versión propia de flutter para cada proyecto… Mediante FVM.

Os cuento los pasos básicos para tener FVM funcionando (partiendo de que has instalado flutter en tu sistema) y cómo usarlo para cada proyecto:

1. Instalar FVM

dart pub global activate fvm

Esto te instala el paquete, pero tendrás que cambiar el entorno para poder acceder al comando fvm cada vez, en mi caso es algo como:

export PATH="$PATH":"$HOME/.pub-cache/bin"

Añadiendo esta línea al final del ~/.bashrc conseguiréis meter en el path el comando FVM

2. Instalar una versión de flutter para su uso posterior

En mi caso quería instalar la versión 2.5.2 y tuve que ejecutar esto:

fvm install 2.5.2

Puedes instalar tantas como quieras (o necesites), puedes conseguir la lista de todas las instaladas con el comando fvm list

3. Usar una versión concreta en tu proyecto

Dentro del directorio del proyecto en el que quieras usar esta versión puedes sustituir el uso del comando flutter por el comando fvm flutter que te ejecutará la versión correspondiente, para indicar qué versión quieres usar debes escribir:

fvm use 2.5.2

Esto te genera un directorio .fvm en donde se almacenarán los enlaces correspondientes, no olvides incluir en tu .gitignore el directorio .fvm/flutter_sdk

Con esto y algunas cosillas más (os dejo consultar la documentación) ya podréis desarrollar y depurar con la versión de flutter que queráis.

log4j, las vulnerabilidades, los parches y la sobre-ingeniería

Durante estos días si te dedicas mínimamente a esto de la informática y has creado algún sistema con Java habras sufrido el problema del log4jshell. Si es que no, pues te lo explico:

log4j es una librería de Java que lleva existiendo desde hace innumerables años y que es muy utilizada para registrar los eventos que tienen lugar en un sistema y poder controlar qué se registra y qué no. Pues bien, la versión 2 de esta librería incluía funcionalidades para hacer sustituciones en las cadenas que se guardan en el log y, continuando con la tradición más añeja de Java, se les ocurrió que sería buena idea que esas cadenas a sustituir pudiesen hacer llamadas a sistemas externos y recibir objetos completos. Utilizando el estandar jndi permitían incluso hacer llamadas RMI o acceder a servidores LDAP. Supongo que el programador que añadió estas funcionalidades vería su utilidad en algún momento, pero también es cierto que yo nunca he visto a nadie usarla.

En fin, que esto llevaba ahí un tiempo y a algún «hacker malvado» se le ocurrió probar qué pasaba si en la url que le pasaba a la cadena a loguear incluía la dirección de un servidor que él controlaba y que permitía descargarse un objeto que hacía «cosas malas» en el sistema… Y la prueba funcionó y en cuanto alguien se dió cuenta que había cadenas extrañas que empezaban por ${jndi:ldap:// y que provocaban funcionamientos anómalos se dio la voz de alarma y se creó un registro de vulnerabilidad (CVE-2021-44228) y con un exploit super-sencillo y que mostraba que había cientos de miles de sistemas afectados.

El parche a esa vulnerabilidad llegó pronto (y eso que log4j está mantenido solo por voluntarios) y mucha gente se pasó buna parte del fin de semana parcheando los sistemas (alguno tardó algo más), aunque sin tener muy claro si el sistema había sido comprometido y modificado antes, cosa que requiere otras medidas adicionales y muy costosas. A día de hoy se ha encontrado que el parche que se hizo no contempla todos los casos y se ha registrado otra vulnerabilidad (CVE-2021-45046) que requiere otro parche… Parches, que, al fin y al cabo lo único que hacen es deshabilitar esa funcionalidad que, en algún momento, a alguien, le pareció interesante.

Son incontables el número de horas que el personal de IT (desde programadores hasta técnicos de sistemas) se han dedicado a tapar este agujero (y seguro que habrá muchos agujeros sin tapar todavía). Eso se traduce en muchos millones de Euros de dinero gastado sin sentido… Y todo porque a alguién «le pareció una buena idea esa funcionalidad» y porque todo el mundo usa componentes que no conoce, en los que «confía», aunque no poga un duro para su desarrollo…

Por cierto… Hay por ahí ya los «negacionistas de los parches» que van diciendo que si los parches son malos, que no saben lo que hay dentro, que todo es parte de una conspiración y esas cositas… En fin, el ser humano es lo que tiene (o no).

ACTUALIZACIÓN 17-12-2021: Hay todavía otro parche que meter, el 2.17.0 ya que hay una cadena especial que puede dar como resultado un DDoS… A ver lo que nos dura.