Buscar

2008/01/07

Los bugs increíbles de las máquinas de votar: no arrastre el dedo que se cuelga

Fuente: Blog de Ricardo Galli.
Vía Joel on software veo el artículo Can You Count on Voting Machines?. En él relatan un bug descubierto en las Diebold AccuVote-TSX después que el estado de California se quejase en 2005 de que las máquinas se colgaban cada pocos cientos de votos.
Luego de bastantes estudios han descubierto que al momento de poner el voto si el usuario arrastraba el dedo el sistema operativo lo consideraba un drag&drop, como el programa no trataba ese evento directamente se colgaba. ¿Cuál era el sistema operativo? Windows CE.
El tema es alucinante y preocupante a la vez. Por un lado esos programas de votaciones, además de simples y pequeños (poco más de 50.000 líneas en C++ en 2002), pasaron por todas las etapas formales de especificaciones, diseño, programación, aduitorias y certificaciones. Además asumimos que los programadores deben ir con mucho cuidado y no deben ser los más tontos de la profesión. Igualmente se cometen errores graves aunque muy estúpidos.
Lo que alucino en primer lugar es en cómo el sistema operativo y sus herramientas de desarrollo porculeen de esta manera. El programa está en C++. Aunque no conozco el sistema de desarrollo del Windows CE supongo que debía ser muy similar a las MFC que se usaron al menos hasta el Visual Studio 6. En estas los eventos se tratan en clases, donde cada programa deriva esas clases para tratamientos específico. Si el programa no crea subclases el comprotamiento debe, o debía, ser un “noop”, o sea no hacer nada.
Sin embargo en este caso parecía que se llamaba a una rutina inexistente y el programa se colgaba. ¿Fallos de las librerías o fallos de los programadores?
En todo caso parece culpa de ambas partes. En 2002 por un error de empleados de Diebold el código fuente llegó a manos de Avi Rubin, profesor de la universidad John Hopkins. Enseguida encontró muchos errores: se podían emitir varios votos, un usuario normal podía realizar operaciones administrativas, etc. etc., incluso algunas tan absurdas como que los votos eran almacenados cifrados localmente –con algo tan débil como el DES–, pero cuando se enviaban a la “autoridad central” por la red se enviaban en texto plano.
Además encontró que se usaban librerías de audio de otras empresas, que también pueden introducir problemas de seguridad. Y un largo etcétera de chapuzas que fueron fácilmente detectadas cuando unas pocas personas tuvieron acceso al código.
¿Todavía alguien duda de que los mejores programadores cometen errores estúpidos aún en programas relativamente simples? ¿todavía alguien duda que no te puedes ni fiar de las librerías de desarrollo de un sistema privativo?
A mí también me impresiona, aunque era de esperar, cómo es que esos programas pasaron procesos de certificación con auditorias “profesionales” de empresas independientes sin que hayan detectado ninguno de estos problemas que detectó un profesor universitario en poco tiempo y sin que nadie le haya pedido.
Para aquellos que no están convencidos del software libre, vale, pero después de ver estas chapuzas encadenadas desde el SO hasta las “auditorías oficiales”, ¿todavía les queda dudas de que hay software que sí debe ser libre y estar publicado para que todos los interesados puedan analizarlo?
Con tantas evidencias ni siquiera sirve la manida excusa de que se “contratan auditorías externas”. Ninguna consultora o auditora podrá igualar a los buenos programadores que están interesados y motivados en analizar el programa. Y eso porque no quiero suponer que haya corrupción en todo el sistema de “auditorías-certicaciones”…

No hay comentarios: