En su mayor parte, el equipo de desarrollo central de FreeBSD no parece ver la necesidad de actualizar sus procedimientos de revisión y aprobación.
Agrandar /. En su mayor parte, el equipo de desarrollo central de FreeBSD 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 que forma parte de lo que la mayoría de la gente considera una «VPN». FreeBSD es un sistema operativo similar a Unix que admite todo, desde los enrutadores Cisco y Juniper hasta la pila de red de Netflix. Macy tenía mucha experiencia en su equipo de desarrollo, incluido el trabajo en varios controladores de red.

Cuando Jim Thompson, el CEO de Netgate, que fabrica enrutadores basados ​​en FreeBSD, decidió que era hora de que FreeBSD aprovechara el mismo soporte WireGuard en el kernel que Linux, quiso 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 debería hacer el trabajo según su propio horario.

Con la experiencia de Macy, especialmente 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 el apoyo de Donenfeld cuando se le ofreció. Después de unos nueve meses de desarrollo a tiempo parcial, Macy ha transferido su puerto, en gran parte sin comprobar y sin pruebas suficientes, directamente al área HEAD del repositorio de código de FreeBSD, donde debería integrarse en FreeBSD 13.0-RELEASE.

Este compromiso inesperado aumentó el compromiso de Donenfeld, cuyo proyecto finalmente se mediría por la calidad de cada lanzamiento de producción bajo el nombre 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. Trabajó con el desarrollador de FreeBSD Kyle Evans y 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 recibido por Netgate, que patrocinó el trabajo de Macy. Netgate ya había tomado el código beta de Macy’s de un candidato de lanzamiento de FreeBSD 13 y lo había puesto en producción en pfSense 2.5.0. La actualización de la carretilla elevadora llevada a cabo por Donenfeld y los empleados y la aguda caracterización del código de Macy por Donenfeld presentaron a la empresa un serio problema de relaciones públicas.

La respuesta pública de Netgate incluyó acusaciones de «sesgos irracionales contra mmacy y Netgate» y la divulgación irresponsable de «una serie de exploits de día cero», a pesar de la declaración casi simultánea de Netgate de que no había vulnerabilidades reales.

Esta respuesta combativa de Netgate llevó a un escrutinio intensificado de múltiples fuentes que descubrieron elementos sorprendentes del propio pasado de Macy. Él y su esposa Nicole fueron arrestados en 2008 después de dos años de intentar desalojar ilegalmente a inquilinos de un pequeño edificio de apartamentos en San Francisco que la pareja había comprado.

Los intentos de Macy’s de desalojar a sus inquilinos incluyeron cortar las vigas del piso para hacer que el edificio no fuera adecuado para el hábitat humano, hacer agujeros directamente en los pisos de los apartamentos alquilados y falsificar correos electrónicos extremadamente amenazantes que aparentemente provienen de los propios inquilinos. La pareja huyó a Italia para evitar el enjuiciamiento, pero finalmente fue extraditada a Estados Unidos. Allí se declaró culpable y cumplió cuatro años y cuatro meses seguidos.

Como era de esperar, la historia de Macy como propietario lo perseguía profesionalmente, lo que contribuyó a su propia falta de conciencia sobre el 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 años de abuso verbal por parte de no infractores y semi-no infractores en el proyecto, cuya única gran ventaja es que ellos no son yo. oportunidad de dejar el proyecto en diciembre … Me sentí moralmente obligado a conseguirlo [the WireGuard port] a través de la línea de meta. Así que debes perdonarme si mis últimos esfuerzos fueron un poco a medias. «

Esta aprobación responde a la pregunta de por qué un desarrollador tan experimentado y hábil podría crear un código inferior, pero plantea preguntas mucho más importantes sobre los procesos y procedimientos dentro del propio comité central de FreeBSD.

¿Cómo es que tanto código por debajo del par lo ha convertido en un importante sistema operativo de código abierto hasta ahora? ¿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 centrarse más en el hecho de que el código se estaba degradando que en su calidad real?

Calidad del código

La primera pregunta es si el código de Macy’s realmente tuvo problemas importantes. Dönfeld dijo que este era el caso e identificó una serie de problemas clave:

  • Duerme para suavizar las condiciones de carrera
  • Funciones de validación que simplemente devuelven verdadero
  • Vulnerabilidades criptográficas catastróficas
  • Partes del protocolo wg no se implementaron
  • Panico kernel
  • Bypasses de seguridad
  • Instrucciones de printf en lo profundo del 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 no es tan malo.

Aunque no se emplearon desarrolladores de kernel, Ars pudo verificar al menos algunas de las afirmaciones de Donenfeld de manera directa, rápida y sin ayuda externa. Por ejemplo, busque una función de validación que simplemente devuelva verdadero, y printf Las declaraciones enterradas profundamente en bucles criptográficos no requerían 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 registrado en FreeBSD 13.0-HEAD.


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

Esta es una cantidad lo suficientemente pequeña de devoluciones como para poder verificarla fácilmente a mano, por lo que la usamos grep para encontrar las mismas fechas pero con tres líneas de código inmediatamente antes y después de cada una return true::

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

Entre los usos válidos de return truedescubrimos 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 señalar que esta función de validación vacía no está enterrada al final de una gran cantidad de código:module.c tal como está escrito, solo hay 863 líneas de código en total.

No hemos intentado continuar con el uso de esta función, pero parece intencional verificar que el origen y / o destino de un paquete pertenece a WireGuard. allowed-ips Lista que determina qué paquetes se pueden enrutar a través de un túnel WireGuard específico.

DEJA UNA RESPUESTA

Por favor ingrese su comentario!
Por favor ingrese su nombre aquí