20 años enviados desde AWS: nunca dije “no es mi trabajo”
(daemonology.net)- Colin Percival, responsable de seguridad de FreeBSD y fundador de Tarsnap, repasa en orden cronológico cómo, desde la creación de su primera cuenta de AWS en 2006 hasta hoy, ha participado ampliamente en la evolución de AWS desde la posición de colaborador externo, no empleado oficial: desde habilitar el soporte de FreeBSD en EC2 hasta descubrir y reportar vulnerabilidades de seguridad de forma proactiva y aportar retroalimentación sobre el diseño de servicios
- En los inicios de AWS era necesario activar cada servicio por separado; los primeros servicios habilitados por defecto fueron Amazon SQS y el poco conocido Amazon E-Commerce Service
- Para ejecutar FreeBSD en EC2 fue necesario resolver durante años obstáculos técnicos como la compatibilidad de versiones de Xen, el soporte de PAE y la transición a HVM; en 2010 se logró la primera ejecución exitosa en t1.micro
- Descubrió y reportó de forma anticipada múltiples problemas de seguridad, entre ellos la vulnerabilidad por colisión de canonización en el esquema de firmas de AWS, el riesgo de exposición de credenciales mediante IMDS (materializado en 2019 con la brecha de Capital One) y problemas de seguridad en Seekable OCI
- Desde 2024 continúa el mantenimiento de FreeBSD/EC2 con el apoyo de GitHub Sponsors de Amazon; es un caso en el que, incluso sin acceso interno a los sistemas de Amazon, logró resultados gracias a la colaboración de ingenieros de la empresa
Creación de la cuenta de AWS y servicios iniciales
- El 10 de abril de 2006, tras ver el anuncio de Amazon S3, creó su primera cuenta de AWS; el detonante fue su interés por los servicios de almacenamiento en línea, y además ya tenía experiencia construyendo servicios web basados en HTTP desde 1998
- En los inicios de AWS había que solicitar la activación de cada servicio por separado para cada cuenta; los únicos servicios incluidos por defecto eran Amazon SQS y Amazon E-Commerce Service (la API del catálogo de productos para afiliados de Amazon)
- Amazon E-Commerce Service fue, en la práctica, el primer servicio de AWS, pero casi nadie lo conocía y terminó desapareciendo discretamente incluso de la historia de AWS
Interés temprano en la seguridad y retroalimentación
- Basándose en su experiencia como FreeBSD Security Officer, se interesó de inmediato por la arquitectura de seguridad de AWS, y señaló que las solicitudes de AWS estaban firmadas con claves API para garantizar autenticación e integridad, pero las respuestas no tenían firma
- En ese momento era común hacer solicitudes a AWS por HTTP, por lo que la posibilidad de alterar respuestas era un riesgo real; incluso tras la migración a TLS, mantuvo la postura de que la firma de extremo a extremo es superior a la seguridad de la capa de transporte
FreeBSD en EC2 — el desafío inicial
- Poco después del lanzamiento de Amazon EC2, se propuso ejecutar FreeBSD allí; a través de Jeff Barr fue puesto en contacto con responsables internos de Amazon y, a comienzos de 2007, firmó su primer Amazon NDA
- En ese entonces Amazon usaba fax, pero como él no tenía uno, envió el original firmado por correo postal, lo que retrasó la primera sesión informativa
- Al principio EC2 se lanzó sin soporte para kernels personalizados (de forma similar a la AWS Lambda actual), y en noviembre de 2007, cuando esa función se habilitó junto con el soporte para Red Hat, también se permitió a su cuenta de FreeBSD acceder a la API interna de “publicación de Amazon Kernel Images”
Auditoría de seguridad de Xen y alerta por ataques de canal lateral
- En marzo de 2007 planteó a su contacto en Amazon la necesidad de una auditoría de seguridad de Xen, y al no conocer un auditor adecuado recomendó a Tavis Ormandy
- Ese mismo año Tavis reportó dos vulnerabilidades en Xen (CVE-2007-1320, CVE-2007-1321), aunque no está claro si hubo relación con esa recomendación
- En una reunión de usuarios de AWS dentro de Second Life organizada por Jeff Barr, pidió una raíz de disco de solo lectura y una garantía de borrado de memoria tras reinicios; eran requisitos para escenarios de ejecución de código no confiable, como la compilación de paquetes de FreeBSD, y EC2 Instance Attestation llegó 18 años después
- En re:Invent 2012 explicó a un Principal Engineer de EC2 la investigación sobre robo de claves RSA mediante HyperThreading, y recomendó firmemente no ejecutar en paralelo instancias EC2 en los dos hilos del mismo núcleo
- Se dice que esa recomendación influyó en que muchas familias de instancias EC2 se saltaran el tamaño “medium” y comenzaran directamente con 2 vCPU (“large”)
Eventual Consistency y una propuesta teórica
- A fines de 2007, en una entrada de blog muy leída dentro de Amazon, señaló los problemas de Eventual Consistency y propuso un modelo ligeramente más fuerte llamado Eventually Known Consistency
- La idea era mantener el camino “A” (disponibilidad) del teorema CAP y, al mismo tiempo, exponer el estado interno para también lograr “C” (consistencia) en el camino normal
- Más adelante Amazon S3 pasó de optimizar disponibilidad a optimizar consistencia, y DynamoDB ofreció la opción entre lecturas Eventual y Strongly Consistent
Problemas de compatibilidad con Xen y fallos de arranque de FreeBSD
- A comienzos de 2008 Kip Macy escribió un kernel de FreeBSD con soporte Xen PAE, y portar a FreeBSD las herramientas internas para crear AMI tomó varias semanas
- Comentó además que una estructura en la que scripts de Ruby generan y ejecutan scripts de bash justificaba reconsiderar la elección del lenguaje
- La AMI de FreeBSD no arrancaba en EC2, y la causa era un bug en Xen 3.0, usado por EC2, que no soportaba las tablas de páginas recursivas del código VM de FreeBSD
- El problema se corrigió en Xen 3.1, pero como no había un ABI estable, Amazon optó por seguir con Xen 3.0 para mantener compatibilidad con las AMI existentes
Descubrimiento y corrección de una vulnerabilidad en las firmas de AWS
- En abril de 2008, al usar Amazon SimpleDB para la beta de Tarsnap, descubrió una colisión de canonización en el esquema de firmas
- En aquel entonces Amazon no tenía un canal para reportar problemas de seguridad, así que lo transmitió a través de Jeff Barr
- Amazon le pidió revisar el diseño de Signature Version 2, y tras corregir ambigüedades en la documentación, ajustar decisiones de diseño y agregar su cuenta a una lista de permitidos, el problema quedó resuelto en diciembre
Problema de higiene de seguridad en NextToken de SimpleDB
- En junio de 2008 descubrió que el valor NextToken de SimpleDB era simplemente un objeto serializado de Java codificado en base64
- Reportó que era necesario cifrarlo para evitar fuga de información interna y firmarlo para prevenir alteraciones, pero no recibió respuesta
- Seis meses después lo volvió a reportar a través de otro ingeniero y se abrió un ticket interno, aunque tampoco hubo respuesta oficial posterior
Prueba alfa de EBS y el momento adecuado para dar retroalimentación de diseño
- En marzo de 2008 Matt Garman, del equipo de EC2, lo invitó a la alfa privada de Elastic Block Storage (hoy Elastic Block Store)
- Sostiene que el momento más útil para dar retroalimentación sobre un nuevo servicio es la fase de diseño antes de construirlo; por su formación en matemáticas y teoría, revisar documentos de diseño le parecía más efectivo que las pruebas alfa
Una anécdota de entrevista para entrar a Amazon
- En 2008, por recomendación de Jeff Barr, consideró entrar a trabajar a Amazon; en una entrevista telefónica con Al Vermeulen pasó 30 de 45 minutos debatiendo las ventajas y desventajas de las excepciones
- Mantuvo su postura de que el manejo de excepciones es una forma inherentemente inadecuada de tratar errores, porque facilita bugs difíciles de detectar en revisiones informales de código
IAM y claves de acceso restringidas — el camino hasta SigV4
- En noviembre de 2008, durante el Seattle AWS Start-up Tour, se reunió en persona con ingenieros de Amazon para discutir la necesidad de claves de acceso restringidas a AWS
- Defendió un enfoque de claves derivadas criptográficamente, donde las claves por servicio se derivan por hash desde un secreto maestro; Amazon prefería un diseño basado en reglas
- En enero de 2010 fue invitado a la beta privada de IAM, y en 2012, con el lanzamiento de SigV4, se adoptó el enfoque de claves derivadas
Problema con el firewall de EC2 y Path MTU Discovery
- En 2009 descubrió y reportó que las reglas predeterminadas del firewall de EC2 bloqueaban mensajes ICMP Destination Unreachable (Fragmentation Required), lo que impedía el funcionamiento de Path MTU Discovery
- En diciembre de 2009 un gerente de EC2 aceptó la solución propuesta, pero el cambio real no llegó hasta que planteó el problema públicamente en 2012
El rodeo vía NetBSD y la transición a HVM
- A comienzos de 2010, como EC2 seguía usando una versión antigua de Xen, intentó el camino de NetBSD y en una semana logró arrancar, montar el sistema de archivos, configurar la red y ejecutar
sshd - En julio de 2010 las instancias Cluster Compute añadieron soporte HVM, lo que devolvió esperanza para FreeBSD y dejó claro que PV (paravirtualización) era un callejón tecnológico sin salida
La primera ejecución de FreeBSD/EC2 — t1.micro
- La familia de instancias t1.micro, lanzada en septiembre de 2010, ejecutaba internamente Xen 3.4.2, con lo que se eliminó el bug que impedía arrancar FreeBSD
- A mediados de noviembre de 2010 logró conectarse por SSH a una instancia FreeBSD/EC2 t1.micro, y el 13 de diciembre se anunció oficialmente el soporte de FreeBSD EC2 t1.micro
Expansión a más tipos de instancia y el truco de “Defenestration”
- Un Solutions Architect de Amazon lo puso en contacto con usuarios de FreeBSD que querían instancias más grandes, y así implementó soporte para instancias Cluster Compute
- Aprovechando que EC2 en realidad no sabía qué sistema operativo se estaba ejecutando, mediante defenestration (hacerse pasar por una instancia Windows) pudo usar FreeBSD en todos los tipos de instancia de 64 bits
- Había que pagar el “impuesto Windows”, algo que tampoco agradaba a Amazon, pero era imprescindible para cubrir la demanda de clientes; en julio de 2014, cuando las instancias T2 completaron el soporte HVM “Linux”, ese truco dejó de ser necesario
Diagnóstico de una falla de hardware en el router de S3
- En abril de 2012 empezaron a fallar muchas solicitudes hacia un endpoint específico de S3, incluyendo errores SignatureDoesNotMatch
- A partir del patrón en el que el valor StringToSign de la respuesta no coincidía con el enviado, identificó un stuck bit y, mediante traceroute y millones de pings, localizó una falla de hardware en un router específico de la ruta
- Tras reportarlo en los AWS Developer Forums, Amazon confirmó la avería y reemplazó el hardware en pocos días
re:Invent 2012 y la alerta sobre ataques de canal lateral
- El primer re:Invent tenía poco contenido técnico y demasiados trajes, pero ofreció la oportunidad de intercambiar en persona con numerosos ingenieros de Amazon
- Después de que un VP de Intel que daba una charla sobre “seguridad de máquinas virtuales” respondiera que no conocía los ataques de canal lateral, explicó personalmente esa investigación a un Principal Engineer en el stand de EC2
Oficialización de FreeBSD/EC2 e ingeniería de releases
- En abril de 2015 el proceso de construcción de AMI de FreeBSD/EC2 se integró en el árbol
srcde FreeBSD, y la creación de imágenes pasó al equipo de ingeniería de releases de FreeBSD, transformándolo de proyecto personal en parte del proyecto oficial de FreeBSD - En septiembre de 2020, a pedido de Glen Barber, líder de Release Engineering de FreeBSD, aceptó el rol de Deputy Release Engineer
- A fines de 2022 Glen fue hospitalizado por neumonía y, debido a secuelas prolongadas que dificultaron su regreso, el 17 de noviembre de 2023 asumió directamente como FreeBSD Release Engineering Lead
- Reforzó las compilaciones semanales de snapshots, el calendario y un ciclo de lanzamientos rápido y predecible, administrando cuatro releases al año
Alerta de seguridad sobre IMDS y la brecha de Capital One
- En octubre de 2016 analizó IAM Roles for Amazon EC2 y publicó en su blog que era riesgosa la exposición de credenciales mediante IMDS, que operaba sobre HTTP sin autenticación y cuya documentación advertía “no almacenar datos sensibles”
- En julio de 2019 Capital One sufrió exactamente ese riesgo y se produjo la filtración de datos de 106 millones de clientes; tras hablar con Amazon en noviembre de ese año, dos semanas después se lanzó IMDSv2
- Su postura es que IMDSv2 mitiga una ruta de ataque concreta, pero no resuelve el problema de fondo: exponer credenciales a través de una interfaz inadecuada
Programa AWS Heroes
- En mayo de 2019 fue invitado al programa AWS Heroes, que reconoce a personas ajenas a Amazon que han hecho contribuciones importantes a AWS
- Fue una selección poco común dentro de un programa centrado principalmente en contribuyentes dedicados a educación de desarrolladores (blogs, YouTube, talleres), aprobada por recomendación de un Distinguished Engineer y un Senior Principal Engineer
Arranque UEFI y BootMode=uefi-preferred
- En marzo de 2021 EC2 añadió soporte para arranque UEFI en instancias x86, y al hacer la transición en FreeBSD dejó de ser necesario el I/O en modo de 16 bits, reduciendo el tiempo de arranque en 7 segundos
- Como no todos los tipos de instancia admitían UEFI, pidió una configuración BootMode=polyglot para imágenes que pudieran arrancar tanto con BIOS legado como con UEFI
- En marzo de 2023 se implementó con el nombre BootMode=uefi-preferred
Hallazgo de un problema de seguridad en Seekable OCI y demora en la corrección
- En agosto de 2023, durante el Heroes Summit, revisó el diseño de Seekable OCI y detectó que, en cierto caso de uso, sus afirmaciones de seguridad no se sostenían; lo reportó al equipo de seguridad de AWS
- Le prometieron una corrección interna, pero no hubo avances reales; volvió a pedir confirmación en re:Invent 2024 y, tras reportarlo nuevamente en enero de 2025, se confirmó que un commit de 2023 solo evitaba corrupción accidental de datos y no bloqueaba ataques intencionales
- Tras señalarlo, la respuesta fue rápida y, para fines de febrero de 2025, la funcionalidad había sido desactivada para la mayoría de los clientes, a la espera de una “major revision”
Patrocinio de Amazon y modelo de colaboración
- En abril de 2024 informó a Amazon que no estaba pudiendo dedicar suficiente tiempo al mantenimiento de FreeBSD/EC2 y pidió apoyo financiero; en pocas semanas se acordó un patrocinio de 10 horas semanales por 1 año mediante GitHub Sponsors
- Tras resolver numerosos problemas y pasar por una pausa de 6 meses (dedicada en su mayor parte, sin remuneración, a la ingeniería de releases de FreeBSD 15.0), comenzó un segundo patrocinio de 12 meses
- Subraya que sus contribuciones de estos 20 años no fueron obra de una sola persona: incluso sin acceso a sistemas internos de AWS, ingenieros de Amazon actuaron como “manos remotas”, abriendo tickets, buscando contactos internos, investigando logs de API y consiguiendo documentación técnica
1 comentarios
Comentarios de Hacker News
El autor hizo la broma de que los ‘Heroes’ son básicamente empleados no remunerados de Amazon, pero eso no es una broma, es la realidad
Yo no publico mi investigación personal. No quiero darle I+D gratis a una máquina de extracción de valor que ya es lo suficientemente eficiente
Amazon destruyó las premisas económicas del open source, y como resultado muchos proyectos se están cambiando a la Business Source License
Estos desarrolladores saben lo codiciosa que es Amazon. Al final, las contribuciones de la comunidad terminan como trabajo no remunerado para megacorporaciones, y Amazon absorbe usuarios con servicios administrados mientras debilita el soporte y la comunidad del proyecto original
Si escribes “cualquiera puede usarlo libremente excepto Amazon”, Amazon no lo usará por el riesgo legal
Aun así, si considera que vale la pena, Amazon podría crear su propia versión desde cero
Como en el caso de Redis, la protección legal sobre la superficie de una API no está clara
Recuerdo que antes el caso Google v. Oracle intentó establecer esa protección, pero quedó pospuesto
De hecho, es muy probable que las empresas que eligen BSL hayan publicado su código no por un verdadero espíritu open source, sino más bien por manejo de imagen o para ganarse la simpatía de los desarrolladores
Aun así, estoy totalmente de acuerdo. Ahora el código que publique será o completamente open source o completamente privado
Si existe la posibilidad de que alguien gane dinero con eso, no lo publico
Entiendo la postura de no querer regalarle tiempo a las grandes empresas, pero quiero ofrecer otra perspectiva
En 2006 hice un proyecto y en 2012 otro desarrollador quiso usar ese nombre, así que se lo cedí con gusto
Ese proyecto era scrypt, y el desarrollador era Colin
Este tipo de amabilidad comunitaria se convierte en buen karma acumulado incluso sin expectativas comerciales
Me parece muy interesante eso de que “el meetup de usuarios de AWS de Jeff Barr se hizo en Second Life”
Second Life fue uno de los primeros usuarios de AWS, y Jeff Bezos participó personalmente en su ronda de inversión de 2005
Gracias a eso, Jeff Barr hizo meetups de AWS dentro de Second Life, y en esa época grupos como Reuters o Jonathan Coulton también estaban entrando en espacios virtuales
Nosotros salimos en el stand de Evolution Robotics para mostrar el robot ER1, y Second Life realmente me impresionó
Me quedó como un gran recuerdo
Claro, Second Life en la pantalla de una laptop y un headset de VR eran experiencias completamente distintas
El marco de “trabajo gratis para Amazon” se está perdiendo lo esencial
Colin no estaba haciendo caridad; estaba mejorando algo de lo que Tarsnap depende en FreeBSD/EC2
Ese modelo es una de las formas más sanas del open source: arreglar la base de tu propio producto de una manera que termina beneficiando a todos
Esperar a que Amazon se interese por su cuenta es como esperar para siempre
Me sorprendió leer que Amazon lo patrocinó por GitHub Sponsors con 10 horas por semana durante un año
$300 por hora está al nivel del sueldo de un ingeniero L6 de Google
Ojalá ahora le paguen más
En la Europa germanoparlante, con 120 euros puedes conseguir a un excelente ingeniero. Europa del Este es todavía más barata
No estoy de acuerdo con la crítica del autor sobre IAM Roles for EC2
IAM es una función clave que permite administrar credenciales basadas en políticas
Es mucho más seguro que Outlook, Slack o Teams, e incluso se puede demostrar matemáticamente que un miembro del equipo no puede ver la clave de firma
Azure aplica un concepto similar para manejar limpiamente el acceso a MSSQL
Antes propuse pasar las credenciales al kernel mediante XenStore. Con Nitro, hoy sería aún más fácil de implementar
Bastaría con que el kernel recibiera las credenciales y las expusiera como un sistema de archivos virtual donde pudiera establecer propiedad y permisos
Es curioso que solo los procesos con el permiso CAP_NET_BIND_SERVICE puedan acceder
Si usas sockets vsock(7), se vuelve un mecanismo de conexión más difícil de falsificar, así que es más seguro
Yendo más lejos, si metes credenciales bootstrap en los datos DMI, quedarían ubicadas en un directorio de sysfs que solo root puede leer
Revisé un correo de 2007 y efectivamente era cierto que al principio había que pedir acceso a los servicios de AWS de forma individual
Primero me aprobaron solo “Amazon E-Commerce Service”, y después fui obteniendo acceso a S3 y luego al beta de EC2
En esa época, “Alexa Web Information Service” no era un asistente de voz sino una API de búsqueda web. Qué tiempos tan interesantes
Es un registro histórico técnico realmente fascinante
Me impresionó ver que incluso un ingeniero conocido como Tavis Ormandy puede equivocarse en una entrevista
Me encantan este tipo de posts de blog con experiencias personales
Es llamativo que en una retrospectiva de 20 años no se mencione a Hetzner ni OVH
Yo uso AWS, Hetzner y nubes pequeñas al mismo tiempo, y la diferencia de precio es enorme
AWS me cuesta $350 al mes; Hetzner, entre 20 y 25 euros, con especificaciones parecidas y 20 TB de tráfico incluidos
Lo que AWS vende ahora ya no es cómputo, sino un modelo de IAM, infraestructura global y consenso organizacional
La verdadera propuesta es esa idea de que “si eliges AWS, nadie va a ser despedido”
Quisiera preguntarles a quienes movieron cargas de trabajo fuera de AWS recientemente: ¿qué parte fue más dolorosa de lo que esperaban?