Le di mi extensión de VS Code a un modelo de ciberseguridad y encontró un cuelgue infinito

CertView es una extensión de VS Code que escribí para inspeccionar certificados: abrís un .pem, un .p12, un .cer, y te muestra el sujeto, las fechas, el fingerprint, todo offline. Está publicada en el Marketplace. Parsea archivos binarios que te puede mandar cualquiera, así que es superficie de ataque, y hasta esta semana nunca la había mirado pensando como atacante.

Ahora tengo acceso a Daybreak Blue, el carril defensivo del modelo cyber de OpenAI. Le di mi propio código, el que mantengo yo, y le pedí una cosa concreta: asumí que te mando un certificado malicioso y Juan lo abre en el editor, ¿qué se rompe? Encontró dos formas de colgar VS Code con un archivo que pesa menos que una foto del celular. Las dos las arreglé antes de escribir esto.

El PEM que tarda 88 segundos en no hacer nada

El parser de PEM separa el archivo en bloques. Por cada línea que leía, volvía a pegar todo el bloque acumulado para medir su tamaño. Un join por línea. Eso es O(n²): si duplicás las líneas, cuadruplicás el trabajo.

Lo medí sobre el código real. Un bloque PEM con muchas líneas de un solo carácter, por debajo del límite de 256 KiB que el propio plugin impone:

• 39 KiB → 2,4 segundos
• 78 KiB → 9,8 segundos
• 156 KiB → 39,7 segundos
• 234 KiB → 87,7 segundos

El límite de tamaño no ayudaba, porque se chequeaba después de volver a pegar todas las líneas. El arreglo es de una línea de idea: llevar un contador de largo y hacer un solo join al cerrar el bloque. O(n) en lugar de O(n²).

El PKCS#12 que no termina nunca

Este es peor, y es el quilombo que me hizo parar.

Un archivo .p12 trae adentro un número: cuántas iteraciones usar para derivar la clave desde la contraseña. Es un mecanismo legítimo — más iteraciones, más caro de atacar por fuerza bruta. El problema es que CertView le pasaba ese número a la librería de parsing (node-forge) tal cual venía del archivo, sin ningún tope, y la derivación corre de forma síncrona: mientras corre, VS Code no responde.

Un atacante puede declarar un número enorme. Y acá está el detalle que lo vuelve un cuelgue y no una demora: node-forge lee ese número con parseInt. Un entero de 128 bytes de 0xFF dentro del archivo se convierte, en JavaScript, en Infinity. El bucle de derivación es for (round = 0; round < iteraciones; round++). Con iteraciones = Infinity, no es que tarda mucho: no termina jamás.

Lo verifiqué en una línea de Node:

parseInt("f".repeat(256), 16) === Infinity // true

Y lo peor: CertView prueba la contraseña vacía automáticamente apenas abrís el archivo, antes de preguntarte nada. Así que el atacante no necesita saber ninguna contraseña. Vos abrís el .p12 para ver qué es, y el editor se te congela para siempre.

El arreglo es un preflight: antes de tocar la librería, CertView ahora lee los números de iteraciones directamente de la estructura del archivo — sin parseInt, así que no hay camino a Infinity — y rechaza cualquiera por encima de 100.000. Si el archivo pide más, no se parsea.

Lo que no encontró, que también importa

No todo era un hallazgo. El modelo revisó el webview (la vista donde se muestran los datos del certificado) y confirmó que los campos hostiles se escapan bien, que la Content-Security-Policy es restrictiva, que las contraseñas no se loguean ni se guardan, y que las llaves privadas cifradas ni se descifran. En vez de inventar vulnerabilidades para llenar una lista, dijo dónde el código ya estaba bien. Eso es lo que lo hace útil: un reporte que es puro hallazgo no te deja saber qué revisó y descartó.

Sol contra Blue, mismo código

Corrí la misma auditoría, con el mismo pedido palabra por palabra, en dos modelos: GPT-5.6-Sol (el de uso general) y Daybreak Blue (el defensivo). Los dos leyeron el código, ninguno inventó nada. La diferencia no fue que Blue "hiciera algo prohibido": fue profundidad. Sol vio que el PKCS#12 "congela el host"; Blue vio además el caso Infinity, que es la diferencia entre lento y no-terminante. Y Blue encontró una cosa más que Sol no: una ventana de carrera entre medir el tamaño del archivo y leerlo.

Esa es la parte honesta del experimento. Esto era trabajo defensivo sobre mi propio código, y para eso el modelo de uso general también sirve. El carril especializado se notó en el detalle, no en destrabar algo que el otro se negaba a hacer.

El obstáculo real no fue el modelo

Dos cosas que no esperaba, y que cuento porque son la parte que no sale en el anuncio:

Para tener la cuenta habilitada tuve que validar identidad y dejar una YubiKey física como único login — una sola llave, la que ahora abre todo mi laburo. No es opcional, y tiene sentido: un modelo al que le sacaron frenos para trabajo de seguridad es exactamente lo que alguien querría usar con una cuenta robada.

Y el día que corrí la auditoría, lo que más me frenó no fue ninguno de los dos modelos: fue el sandbox de la herramienta, que dejó de poder aislar la red en esa máquina y bloqueó toda lectura de archivos. El modelo estaba listo; el plumbing alrededor, no. Casi siempre es así.

Qué hacer si usás CertView

Actualizá a la 0.5.1. Las dos vulnerabilidades están corregidas ahí, con tests que fallan si alguna vuelve. Y si vos escribís un parser de algo que te mandan de afuera: medí tus límites antes de hacer el laburo caro, no después, y nunca le pases a una librería un número que vino del archivo sin un tope.