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»…
Ricardo Galli, de software 
Comparto contigo tus apreciaciones, incluso tus dos últimas líneas.
Otro ejemplo sería el sistema informático centralizado que intentan implantar en la sanidad (creo que en la comunidad valenciana), esperemos que poco a poco la gente se vaya concienzando de que el software libre tiene más GARANTÍAS que el software privativo, por lo menos nadie te quitará la garantía de aprender a programar y arreglarlo tu mismo xD
Estoy totalmente de acuerdo en lo referente al software libre. Pero creo que echar la culpa en este bug a Windows CE, o me lo demuestra el programador o alguien que lo sepa de primera mano, o me suena a excusa barata o interpretación muy libre del periodista. Y aunque fuese esa la razón, con los presupuestos que seguro manejan, ya se hubiesen podido permitir tener unas cuantas personas «de a pie» testeando ese programa, y no echar la culpa al sitema operativo o hasta al compilador, no? También podría ser él el culpable. Me refiero, que muy bien lo de software libre, pero lo del SO lo veo muy secundario, casi ni para nombrarlo.
Saludos!
Pingback: meneame.net
Pingback: www.planetalibro.com.ar
Un bug parecido que encontramos hace tiempo. Trabajo en un banco y el terminal financiero (java) a veces disparaba el consumo de memoria y había que reiniciar el PC, pero sólo pasaba a algunos usuarios, después de mucho dimos con la clave: sólo le pasaba a usuarios zurdos. Con esa pista fue más fácil, al pasar el puntero por la esquina superior izquierda se lanzaba a memoria otra ventana que no llegaba a abrirse (ni tenía que haber empezado a lanzarse), sólo le pasaba a los zurdos porque los diestros rara vez llevamos el puntero hasta la esquina superior izquierda si no hay algún control allí, mientras que muchos zurdos lo usan como punto de escape del ratón cuando van a teclear.
Eso de que pasara por todas las fases del proceso de ingeniería me extraña un poco, porque un fallo así se hubiera descubierto en fases tempranas de análisis o diseño, y si no ahí, al menos en el testing final.
Son fases incrementales e iterativas, así que me cuesta mucho creer que un fallo así no se hubiera detectado durante el desarrollo.vu
Otra cosa es que utilicen el mismo modelo de desarrollo de una conocida empresa de Balears que vende vuelos y alojamientos de hotel y que… me callo XD
¿Y no es mas facil pensar que la persona o personas encargadas de preparar esas maquinas fueron un poco gañanes?
NOooooo, Windows es muyyyyyy maaaalo, cacaca, demonio demonio, 666….
Si pones a un chimpance a configurar una maquina, pasa lo que pasa (Sea software libre o no)
#7 Miguel, el software ha pasado por audiorías externas y certificación de la administración norteamericana. Es de suponer que las exigencias en cuanto a métodos formales es mayor que la de programas que no pasan por el mismo proceso (la inmensa mayoría).
#8 Como lo explico en el apunte, lo de la empresa tiene más «pecado» (lee el PDF enlazado). Pero en el caso del bug de arrastrar el dedo el sistema de desarrollo del sistema seguramente tiene mucho que ver (por el tratamiento de eventos en C++). O es el causante directo o ayudó mucho a que el bug se produjese (de todas formas es estúpido, pero no el más grave).
El desarrollo de proyectos de software es muy complejo, sobre todo en proyectos criticos como puede ser un sistema de votación.
Muchas veces (la mayoria) la culpa de cualquier error o bug es hechada directamente al programador/es del proyecto, pero sin embargo y realmente en un 50% de las ocasiones la culpa tambien es:
– Jefes de proyecto que no tienen ni zorra idea y solo mandan cosas que a simple vista parecen logicas pero que introducidas dentro de la maravillosa ecuación de un modelo de software no parecen ser tan logicos ni correctos. (La realidad difiere del caso practico)
– Los directories de empresas TI que explotan a sus trabajadores por 4 duros. Los currantes (picadores de codigo) se ven forzados a trabajar a destajo dejandose un monton de errores de codigo, cambios sin comentar a modo de eXtreme Programming (mas bien mIerda Programming) porque lo importante es acabar en el día «D», da igual como acabes pero si no lo haces te ves enfrentado a la puerta de la calle (despues pasa lo que pasa).
– Otra vez los maravillosos directores de empresas que piensan que todo software debe ser perfecto y por esa misma razón no entienden que hay que contratar a beta testers.
– Los implantadores tambien tienen a veces culpa, pasando olimpicamente de las especificaciones y ensamblando o instalando el software como quien come churros.
– El cliente tambien tiene culpa, muchas veces no sabe lo que quiere o bien no fue entendido correctamente por el jefe de proyecto / comercial (digo comercial porque en muchas empresas de software el comercial es jefe de proyectos, lo cual seria como si el que te vende un piso fuese un arquitecto).
– La culpa es del gobierno que permite que cualquier economista con un cursillo de programación de 2 meses de visual basic .net se meta a desarrollar software critico.
De todas maneras desde mi punto de vista creo que es bueno que el software falle, si no fallase:
– Las votaciones no podrian manipularse.
– La gente no pagaria por las actualizaciones.
– Los politicos no podrian achacar la culpa del retraso de las obras del AVE o el colapso hospitalario a un problema informatico.
– Contratar programadores seguiria costando cuadro duros.
– Existirian mas puestos de trabajo porque habria que contratar mas informaticos que tiene que arreglar poblemas de otros informaticos (la pescadilla que se muerde la cola).
Asi pues no hay mal que por bien no venga o como dijo Bill Gates a Steve Jobs ya hace mucho tiempo: «Steve, no lo has entedido, no importa que tengais interfaz grafica o vuestros programas funcionen bien!» (Lo que importa era saber vender la moto).
Por si interesa:
El gran negocio de las máquinas de votación fraudulentas
Lewellen-Biddle, Andrew Gumbel y Amy Goodman
Proyecto Censurado
http://www.rebelion.org/noticia.php?id=7513
Hay 3 clases de programadores, los buenos, los malos y los que les echa la culpa a Windows 😉
La verdad es que el software libre no es mas seguro en si mismo, para que lo sea se requiere de observadores, y de observadores capaces de entender los bugs y repararlos o sugerir su reparacion.
Solo una minoria es capaz de programar, y de esa minoria otra minora es capaz de detectar bugs, y de esa minoria otra minoria es capaz de corregir efectivamente los bugs.
Tener acceso al codigo fuente no es suficiente, sino ya tendriamos resueltos todas las enfermedades, porque decodificamos el genoma 😉
Pingback: Si arrastras el dedo cuelgas la urna digital | Fondo del Tacho
Jajajajaja…
Profesor Ricardo. Ahora si trata de buscar el pecado donde no existe.
No fue problema de los programadores, ni de la auditoría. De hecho los programadores y los auditores siguieron fielmente las especificaciones que proporcionaron los responsables de diseñar las maquinas de votar.
La idea es hacer ganar al candidato del gobierno en turno.
Y es un orgullo decir que los analístas que proporcionaron todas las reglas de operación son los mismos analistas que hicieron ganar en México al presidente en turno. (Para mas referencias consultar http://es.wikipedia.org/wiki/Elecciones_generales_de_M%C3%A9xico_(2006))
En México hay expertos en robarse votos con diferentes técnicas. 77 Años de fraudes electorales en México nos respaldan.
Ahh.. como comentario. El presidente actual de México es muy amigo de Aznar.
Saludos y feliz año.
Aun a riesgo de ser vapuleado: Con colegios esto no hubiese pasado…
#13, vaya tontería demagógica a ignorante (incluso de la complejidad del software). Supongo que es una broma, por las dudas contesto (sino pasa de mí).
Como si los que desarrollaron y firmaron las auditorías y certificaciones no hubieses sido ingenieros y doctores en informática. ¿O estás seguro que no lo eran?
Por cierto, ya que estás y que sabría cómo hacerlo, ¿por qué el método DES no es seguro para almacenamiento local? ¿cuál deberían haber usado? ¿por qué la máquina tiene riesgos de «tampering»? ¿qué método de cifrado para enviar por red hubieses propuesto? ¿existen riesgos de buffer overflow? ¿por qué el C++ no es una buena opción para lo que han desarrollado? (y no pregunto nada difícil, es básico, y seguramente un «colegiado» lo sabe).
Por una vez, el que no ha entendido la ironía has sido tú XDDD. Esperaba ser vapuleado por quien sí quisiera ser un «colegiado».
#15, me lo sospechaba, no podía ser otra cosa que una ironía, pero por las dudas contesté 🙂
PS: Ayer he tenido una discusión de este estilo por este mismo problema, y quedé alucinado, pero lo decían en serio.
¿por qué el C++ no es una buena opción para lo que han desarrollado?
En meneame has hecho el mismo comentario y te he respondido, ¿porqué crees que C++ (o C, si lo prefieres) está fuera completamente de un proyecto así? No estoy diciendo que todo tenga que hacerse en C (o C++), pero sí es más que probable que habrá partes pequeñas que tendrán que usar código nativo.
#17.
LO que haces el programa es muy simple y puede hacerlo mejor cualquier lenguaje interpretado moderno. Con esos lenguajes no tendrás que preocuparte de problemas de seguridad por buffer overflow, por ejemplo, y seguramente no te hubiese pasado el bug del drag&drop, al menos lo hubieses descrubierto antes.
A estas alturas, ¿programarías una aplicación web en C++? ¿por qué sí hacerlo en un programa quizás más pequeño y simple?
Quería haberlo comentado antes, pero me dio pereza.
Ya el mes pasado (justo el 24), Bruce Schneier comentó el caso de Ohio (también con enlace al NYTimes), con increíbles problemas de seguridad (al menos no comentan nada de drag&drop) y resultados similarmente desesperanzadores:
y los fabricantes mintiendo descaradisimamente ante los hechos:
Pues si no son ataques, será lo que dice Tonas en #12, aunque en ese caso no creo que las autoridades las descertificasen.
#18 No, una aplicación web no, ni se me pasa por la cabeza. Pero ése no es el tema que nos ocupa, además de que en ningún momento he hablado de hacer toda la aplicación en C++ (o C), sino de alguna de sus partes. Si haces la mayoría en un lenguaje de alto nivel (que depende del caso, es una buena o mala idea), forzosamente tendrás una parte que tendrás que implementar de manera nativa: acceso a un dispositivo PKCS#15 (una smartcard por ejemplo), programación de la tarjeta de sonido para reproducir el audio con el nombre de los candidatos, cifrado de los votos, etc. además de que todo esto, es posible que se tenga que hacer en un procesador embedded (un ARM, por ejemplo), poco potente y del que necesitas sacar el máximo rendimiento posible (con más razón implementarlas en código nativo). ¿Seguirías haciéndolo todo en un lenguaje de alto nivel?
#18, por cierto, no es tan «simple» lo que hace un dispositivo como ese, a saber:
– almacenamiento transaccional (te tienes que asegurar incluso a nivel de aplicación que los votos, las firmas y todo lo demás no se guarda a medias)
– cifrado (tanto simétrico como asimétrico)
– firma periódica del registro para posteriores auditorías
– reproducción de audio para personas con problemas visuales
– cálculo de hashes acumulativos
– conexión a internet (depende del proyecto)
– impresión del voto (depende de la legislación)
todo esto sin apenas latencia, puesto que lo que veas en pantalla tiene que ser lo que se oye. Hacerlo todo en C o C++ es una locura (aunque depende del proyecto y las especificaciones, habrá que hacerlo), eso en ningún momento lo he negado, pero no son máquinas «tan simples». Otra cosa es que lo que Diebold implementa sea demasiado simple (lo cual no te da suficientes garantías de todo el proceso).
HAY QUE VOLVER A LA MAQUINA DE ESCRIBIR!
También estoy totalmente de acuerdo en lo referente al software libre.
No hay que echar la culpa a Windows ya que no me parece que tenga que ver con la plataforma sino con un claro entendimiento del entorno. Y creo tambien que aun en las grandes compañias que pasan miles de tests hay fallos de usabilidad horribles y bugs que compiten a la par.
Por ej. Citibank tiene una banca online que no actualiza desde hace 5 años, es asquerosa, y necesitas unos 12 clicks hasta llegar a ver cuanta pasta te queda en la cuenta. Parece que nadie se preocupa…Ahora lo de los votos da un poco mas de miedo 🙂
La explicación es muy sencilla: son productos micro$oft.