Grave falla en el diseño del protocolo BGP podría colapsar Internet

Aunque no se ha hecho mucha propaganda sobre el asunto, la falla de diseño del protocolo BGP explotada por Alex Pilosov y Anton Kapela, que permite escuchar todo el tráfico de una red bajo la modalidad de man in the middle y que fuera motivo de su disertación en el último Defcon de Las Vegas, poco a poco comienza ha conocerse a través de los medios, al menos de los medios espacializados, porque justo el día de hoy (27 de agosto) he visto que Kim Zetter ha blogueado sobre el tema en los blogs de la revista Wired.

El asunto había pasado más o menos desapercibido hasta hace poco, eclipsado por el más publicitado problema con el protocolo DNS que fuera expuesto en el mismo evento por Dan Kaminsky y al cual le dedicáramos el post "Toda la verdad sobre la vulnerabilidad de los DNS". Pero como dice Peiter Zatko, éste problema con el protocolo BGP es mucho más grave que el de los DNS y tiene la capacidad de colapsar toda Internet en menos de 30 minutos si es convenientemente explotado. Pero antes de que la desesperación cunda, y los profetas del desastre comiencen a comentar sin saber de que se trata dedicare unas líneas de éste post a explicar cuál es el problema, por qué es un problema y bajo que condiciones puede aprovecharce esta devilidad del protocolo BGP.

En primer lugar hay que entender que el protocolo BGP está diseñado para permitir el ruteo de una "red" sobre multiples enlaces, así si uno de los enlaces cae el tráfico puede ser re-enrutado por otro, para ello la "red" que se re-enruta debe poseer un ANS (Autonomous System Number), que es asignado por IANA, el protocolo BGP confía en que todo router que forma parte de este anillo de super-routers de proveedores de Internet, es confiable y enviará la información correcta sobre los enlaces y las redes asociadas a los mismos. Por diseño del protocolo se supone que todos los routers que usan el protocolo BGP diran la verdad. En el experimento conducido por Alex y Anton, lo que se hizo fue introducir una ruta falsa (haciendo un spoofing del IP real del router dueño de la red que se pretende secuestrar, creado una paquete BGP manipulado) y forzar a que todo el tráfico fuera re-enrutado a través del data center de Alex en New York, en el cuál la empresa donde trabajo tiene hosteado sus racks (dicho sea de paso conozco a Alex Pilosov personalmente). Ésto fue posible por dos cosas, primero el hecho de que Alex tiene acceso a un router BGP reconocido por todos los proveedores Internet, y segundo a que cuenta con bastante ancho de banda para que la nueva ruta no sea más costosa en términos de tiempo y sólo añada un salto más a la ruta original. Osea que cualquier aprendiz de brujo que crea que puede colapsar Internet desde su línea ADSL es tan fantacioso como aquel adolescente que creía que era cierto que desde un Altair 8800 se podía iniciar la tercera guerra mundial así como en la película "Juegos de Guerra". El protocolo tiene una falla sí, pero es explotable sólo desde un router que pertenezca a un proveedor de Internet importante.

En teoría un terrorista que tuviera acceso a uno de estos routers principales, podría enviar información de rutas ciclicas, que colapsarian el tráfico porque enviarian los paquetes a un loop sin fin entre una pareja o trio de routers, claro sólo hasta que se reinicie el router que esta confundiendo a los demás. Es sólo un ataque que teóricamente es posible, pero dado a que los routers BGP en Internet son sólo unos miles, es relativamente fácil detectar al culpable.

Es por ello que si quiere estar seguro de que la información que esta transmitiendo por Internet esta segura, y Alex no la está escuchando , use protocolos de encriptación como SSL, así si alguién esta escuchando el tráfico sus claves e información personal no viajara en texto claro. Así que concluyendo aunque la falla de diseño del protocolo lo expone a un ataque que podría afectar a millones de usuarios, éste ataque sólo puede realizarce desde un lugar específico, el cuál puede ser custodiado.

Atados al pasado

Cuándo el congreso del estado de California no aprobó el presupuesto enviado por el equipo económico del Gobernador Arnold Schwarzenegger, éste amenazó con pagar a los empleados del estado sólo el sueldo mínimo ($6.55 la hora), hasta que el nuevo presupuesto sea aprobado. El Contralor del estado de California (John Chiang) se opuso en un primer momento por cuestiones de principio, pero ahora alega una razón "técnica" para no aplicar la orden del Gobernador Schwarzenegger, de acuerdo a sus últimas declaraciones sobre el asunto aparecidas en el portal de noticias Sacbee.com, tomaría semanas hacer los cambios en el anticuado sistema de planillas del estado de California, que está escrito en COBOL, y podría llevar de 9 a 10 meses volverlo a su estado original, Chiang alega que el presupuesto para actualizar el sistema de planillas del estado es un proyecto de $177 millones de dólares que aún no ha sido aprobado, y aparentemente tampoco lo será en esta legislatura estatal.

Tres comentarios puntuales, el primero es por qué seguir usando una tecnología tan antigua como lo es COBOL (si el mantenerla es mucho más costoso que cambiarlo), segundo por qué no se actualizó el sistema cuando hubo tanto ruido mediático sobre el bug del años 2000 (de eso ya hace 8 años), y finalmente ¿por qué no hacer outsourcing de las planillas del estado de California a empresas como PayChex o ADP?.

En sus declaraciones Chiang alega que han tenido que llamar del retiro a varios ex-empleados para que trabajen parte del tiempo en darle mantenimiento al sistema de planillas, pero que éstos han sido despedidos con las últimas medidas de austeridad propuestas por Schwarzenegger.  En lo personal creo que aquí estamos hablando de un típico caso de estafa, programas que se hacen a medias y mal, para que siempre se esté llamando a los desarrolladores. Y una falta de criterio gerencial en Chiang, porque es tan sencillo y mucho más barato hacer el outsourcing de la planilla a empresas establecidas y que procesan las planillas de millones de negocios actualmente en USA, ¿por qué las planillas del estado de California deben ser procesadas internamente?, pues al ser empleados públicos sus sueldos están sujetos a escrutinio público si algún ciudadano piensa que hay algo turbio.

Y no se sienta Ud. tan contento, porque quien sabe a lo mejor ese futuro también le espera a su "sistema integrado", que está escrito en Clipper/FoxPro o VisualBasic. Cuando pasan estas cosas es que la gente recién comienza a darse cuenta de que existe algo que se llama ingeniería de software.

Piratas de Silicon Valley

El Valle del Silicio, o Silicon Valley en inglés, es el lugar geográfico donde se concentra la mayor cantidad de empresas relacionadas a las tecnologías de la información. Aunque en él han aparecido y evolucionado muchas empresas, sin duda alguna las dos empresas que han jugado el mayor rol en popularizar las micro-computadoras (PC como las conocemos ahora), han sido Microsoft y Apple, que han estado envueltas en una relación de amor/odio. Sus dos fundadores son personas que pueden despertar tanto odio como admiración.

Dado que hoy ha sido el último día de Bill Gates en Microsoft y probablemente Steve Jobs, sea reemplazado en Apple también, me parece un justo homenaje visionar la que es sin duda la película que mas fielmente retrata la vida de estos dos pioneros de las micro-computadoras, la película se llama "Piratas del Sillicon Valley", porque realmente en aquellos primeros años, las empresas y sus líderes se comportaban como asaltantes, que robaban impunemente la propiedad intelectual de otro, aunque ahora que ya son ricos defienden la legalidad.

Aquí les dejo la película en español para que la puedan ver tambien, lamentablemente la primera parte que es como 8 o 9 minutos que muentra la vida de Steve Jobs y Steve Wozniak antes de fundar Apple no la he podido encontrar en Youtube, todas las demás secuencias las he puesto en un solo playlist para que la puedan ver de principio a fin. Espero que les agrade.

Escribiendo software de calidad

En Slashdot, encontré el martes de la semana pasada el post de Chuck Connell, sobre su trabajo de investigación en Ingeniería de Software, "Principios de diseño de software". En dicho post Connell hace una pregunta a la comunidad que sigue el popular agregador de noticias, sobre cuáles son los principios que se deben seguir para asegurar un software de calidad. No había tenido tiempo de comentar sobre él porque toda esta semana la he tenido bastante ocupada en la oficina, pero ahora que es sábado y puedo disponer de algo de tiempo hablaré sobre dicha investigación.

Primero algo de antecedentes, Connell esta desarrollando una tesis de investigación para obtener su título de PhD en Computer Science en Tufts University. Dicha investigación busca delinear los principios básicos que permitan un diseño de software de calidad, es más el ha publicado un paper sobre el terrible estado del software en la actualidad que ha titulado "La mayoría de software apesta".

En el paper que mencione Connell propone ciertas características que debe tener el software, para ser considerado "bello" o de calidad, estas son:

  • Cooperativo
  • Forma apropiada
  • Minimalismo del sistema
  • Componentes singulares
  • Localización funcional
  • Facilidad de lectura
  • Simplicidad

Y a lo laro del documento describe cada una de estas propiedades que son necesarias para que un software sea "bello". Al parecer este trabajo de investigación esta redescubriendo la polvora, un poco más y concluirá que el mejor modelo para desarrollo de software es el Open Source, al parecer nadie le ha dicho a Connell que lea "La Catedral y el Bazar", de Eric Raymond.  En general todo lo que comenta Connell no sería más que una formalización del documento escrito por Raymond y que le valiera el reconocimiento mundial hacer más de 8 años.

Lo que me parece raro es que las instituciones educativas de todo el mundo ignoren el excelente documento de Raymond, porque el explica claramente por qué el desarrollo de software cerrado es un modelo que produce naturalmente software de menor calidad. La regla de oro que enuncia Raymond en su paper es que a más ojos vean el código, más fácil es detectar errores y corregirlos. Con lo que se concluye de que no importa la metodología que se emplee para desarrollar software, si éste es cerrado y sólo accesible por los programadores, les tomaría a estos mucho tiempo llegar a un nivel de calidad aceptable, así que software de calidad o "bello" como dice Connell y modelo propietario de código cerrado son dos objetivos incompatibles entre sí.

¿Programan las mujeres mejor que los hombres?

En un artículo que he leído el día de hoy en Wall Street Journal, aparecen las declaraciones de Emma McGrattan, que ostenta el cargo de senior vice-president of engineering for computer-database, en la conocida empresa de base datos Ingres. Según Emma las mujeres escriben un código más fácil de leer, lleno de comentarios y explican porque tomaron un determinado algoritmo, con lo que el código escrito por las mujeres suele ser más fácil de seguir pues los cometarios en él ofrecen una hoja de ruta del código. Por otro lado Emma afirma que debido a la tremenda competencia en el campo masculino, los hombre tienden a escribir un código más enrevesado y sin comentarios, para demostrar que tan inteligentes son, el resultado es un código difícl de interpretar por otros programadores.

Es más Emma dice que a ella hacierta entre el 70 al 80% de las veces al ver una porción de código y puede decir si el autor fue un hombre o una mujer. Una de las tareas a las que Emma esta abocada actualmente es ha convertir el código fuente de Ingres en más amigable e independiente del género, pues las mujeres en Ingres son una minoría, sólo 20% del total de programadores.

En lo personal no creo que la codificación de un algoritmos este atada al género de una persona y que los hombres escriban un código menos amigable e intencionalmente traten de ocultar lo que estan haciendo. Puede ocurrir que haya personas con personalidades difícil y que intencional o subconcientemente escribar código poco claro, pero creo que ésto debe ocurrir en proporciones iguales independiente del género. Es como decir que haya más neuróticos que neuróticas, solo viendo número absolutos, creo que todo debe estar en contexto. En fin, el artículo de WSJ no da estadísticas y tampoco ofrece un URL donde poder profundizar más sobre la discución.