Desbordamientos de búfer, violaciones de licencia y código incorrecto: el cierre de FreeBSD 13

El equipo de desarrollo central de FreeBSD, en su mayor parte, no parece ver la necesidad de actualizar sus procedimientos de revisión y aprobación.
Agrandar / El equipo de desarrollo central de FreeBSD, en su mayor parte, no parece ver la necesidad de actualizar sus procedimientos de revisión y aprobación.

Aurich Lawson (después de KC Green)

A primera vista, Matthew Macy parecía una opción perfectamente razonable para portar WireGuard al kernel de FreeBSD. WireGuard es un protocolo de túnel de punto a punto cifrado, parte de lo que la mayoría de la gente considera una “VPN”. FreeBSD es un sistema operativo similar a Unix que alimenta todo, desde los enrutadores Cisco y Juniper hasta la pila de red de Netflix, y Macy tenía mucha experiencia en su equipo de desarrollo, incluido el trabajo en múltiples controladores de red.

Entonces, cuando Jim Thompson, el CEO de Netgate, que fabrica enrutadores con tecnología FreeBSD, decidió que era hora de que FreeBSD disfrutara del mismo nivel de soporte WireGuard en el kernel que Linux, se acercó para ofrecerle un contrato a Macy. Macy portaría WireGuard al kernel de FreeBSD, donde Netgate podría usarlo en la popular distribución de enrutadores pfSense de la compañía. El contrato se ofreció sin plazos ni hitos; Macy fue simplemente para hacer el trabajo en su propio horario.

Con el nivel de experiencia de Macy, en particular con la codificación del kernel y las pilas de red, el proyecto parecía un fracaso. Pero las cosas salieron mal casi de inmediato. El desarrollador fundador de WireGuard, Jason Donenfeld, no se enteró del proyecto hasta que apareció en una lista de correo de FreeBSD, y Macy no pareció interesada en la ayuda de Donenfeld cuando se la ofreció. Después de aproximadamente nueve meses de desarrollo a tiempo parcial, Macy comprometió su port, en gran parte sin revisar y sin pruebas adecuadas, directamente en la sección HEAD del repositorio de código de FreeBSD, donde estaba programado para su incorporación a FreeBSD 13.0-RELEASE.

Este compromiso inesperado elevó las apuestas para Donenfeld, cuyo proyecto sería finalmente juzgado por la calidad de cualquier lanzamiento de producción bajo el nombre de WireGuard. Donenfeld identificó numerosos problemas con el código de Macy, pero en lugar de oponerse al lanzamiento del puerto, Donenfeld decidió solucionar los problemas. Colaboró ​​con el desarrollador de FreeBSD Kyle Evans y con Matt Dunwoodie, un desarrollador de OpenBSD que había trabajado en WireGuard para ese sistema operativo. Los tres reemplazaron casi todo el código de Macy’s en una loca carrera de una semana.

Esto fue muy mal con Netgate, que patrocinó el trabajo de Macy. Netgate ya había tomado el código beta de Macy’s de una versión candidata de FreeBSD 13 y lo había puesto en producción en la versión 2.5.0 de pfSense. La actualización de la carretilla elevadora realizada por Donenfeld y sus colaboradores, junto con la aguda caracterización de Donenfeld del código de Macy’s, presentó a la empresa un serio problema de relaciones públicas.

La respuesta pública de Netgate incluyó acusaciones de “sesgo irracional contra mmacy y Netgate” e irresponsable divulgación de “una serie de exploits de día cero”, a pesar de las prácticas casi simultáneas de Netgate declaración que no existían vulnerabilidades reales.

Esta respuesta combativa de Netgate provocó un mayor escrutinio de muchas fuentes, que descubrió elementos sorprendentes del propio pasado de Macy. Él y su esposa Nicole habían sido detenido en 2008, después de dos años intentando desalojar ilegalmente a los inquilinos de un pequeño edificio de apartamentos de San Francisco que la pareja había comprado.

Los intentos de los Macys de expulsar a sus inquilinos incluyeron serrar a través de las vigas de soporte del piso para hacer que el edificio no fuera apto para la habitación humana, aserrar agujeros directamente a través de los pisos de los apartamentos de los inquilinos y falsificando correos electrónicos extremadamente amenazantes que parecen provenir de los propios inquilinos. La pareja huyó a Italia para evitar el enjuiciamiento, pero finalmente fueron extraditados a los Estados Unidos, donde se declararon culpables de un número reducido de delitos graves y cumplieron cuatro años y cuatro meses cada uno.

Como era de esperar, la historia de Macy como propietario lo persiguió profesionalmente, lo que contribuyó a su propia falta de atención al condenado puerto WireGuard.

“Ni siquiera quería hacer este trabajo”, finalmente nos dijo Macy. “Estaba agotado, pasé muchos meses con el síndrome post-COVID … Había sufrido durante años de abuso verbal por parte de los no hacedores y los semi-no hacedores en el proyecto, cuyo gran problema para mí es que no están delincuentes. Aproveché la oportunidad de dejar el proyecto en diciembre … sentí la obligación moral de conseguir [the WireGuard port] sobre la línea de meta. Así que tendrás que perdonarme si mis esfuerzos finales fueron un poco a medias “.

Esta admisión responde por qué un desarrollador tan experimentado y calificado podría producir un código inferior, pero plantea preguntas mucho más importantes sobre el proceso y el procedimiento dentro del propio comité central de FreeBSD.

¿Cómo es que tanto código por debajo del par se convirtió en un importante sistema operativo de código abierto? ¿Dónde estaba la revisión del código que debería haberlo detenido? ¿Y por qué tanto el equipo central de FreeBSD como Netgate parecían más centrados en el hecho de que el código estaba siendo menospreciado que en su calidad real?

Calidad del código

El primer problema es si el código de Macy’s realmente tuvo problemas importantes. Donenfeld dijo que sí, e identificó una serie de problemas importantes:

  • Duerme para mitigar las condiciones de la carrera
  • Funciones de validación que simplemente devuelven verdadero
  • Vulnerabilidades criptográficas catastróficas
  • Partes del protocolo wg que no se implementaron
  • Pánico de kernel
  • Bypasses de seguridad
  • Declaraciones de printf profundamente en código criptográfico
  • Desbordamientos de búfer “espectaculares”
  • Laberintos de Linux → FreeBSD ifdefs

Pero Netgate argumentó que Donenfeld se había excedido con su evaluación negativa. El código original de Macy, argumentaron, simplemente no era tan malo.

A pesar de no tener desarrolladores de kernel en el personal, Ars pudo verificar al menos algunas de las afirmaciones de Donenfeld de manera directa, rápida y sin asistencia externa. Por ejemplo, encontrar una función de validación que simplemente devolvió verdadero, y printf declaraciones enterradas profundamente en bucles criptográficos, no requirieron nada más complicado que grep.

Función de validación vacía

Para confirmar o negar la afirmación de una función de validación vacía, una que siempre “devuelve verdadero” en lugar de validar realmente los datos que se le pasan, buscamos instancias de return true o return (true) en Macy’s if_wg código, como se comprueba en FreeBSD 13.0-HEAD.

root@banshee:~/macy-freebsd-wg/sys/dev/if_wg# grep -ir 'return.*true' . | wc -l
21

Este es un número lo suficientemente pequeño de devoluciones como para auditarlo manualmente, por lo que usamos grep para encontrar los mismos datos pero con tres líneas de código inmediatamente antes y después de cada return true:

root@banshee:~/macy-freebsd-wg/sys/dev/if_wg# grep -ir -A3 -B3 'return.*true' .

Entre los usos válidos de return true, descubrimos una función de validación vacía, en module/module.c:

wg_allowedip_valid(const struct wg_allowedip *wip)
{

 return (true);
}

Probablemente valga la pena mencionar que esta función de validación vacía no está enterrada en la parte inferior de una gran masa de código:module.c tal como está escrito tiene solo 863 líneas de código en total.

No intentamos perseguir más el uso de esta función, pero parece tener la intención de verificar si el origen y / o destino de un paquete pertenece a WireGuard allowed-ips list, que determina qué paquetes pueden enrutarse por un túnel WireGuard determinado.

Leave a Reply

Your email address will not be published. Required fields are marked *