Transplantes de código para arreglar fallos

Bicho Me dan un poco de miedo las analogías ‘médicas’ porque siempre hay quien termina tomándoselas al pie de la letra (recuerdo hace un montón de años escuchar una conversación en el tren de alguien que le contaba a otro como los virus informáticos se inoculaban con una jeringuilla).

En este caso la idea es muy sugerente: MIT tests ‘software transplants’ to fix buggy code, utilizar el código de programas que funcionan correctamente para ‘reparar’ programas con fallos:

La idea se basa en entradas de datos que hacen fallar el programa y otras que no lo hacen fallar.

To fix a buggy program, CodePhage requires two sample inputs, one that causes the program to crash, and another that does not.

Se utilizan para verificar en un ‘donante’ que se obtienen los resultados correctos y a partir de allí ya se sabe que se puede utilizar ese nuevo código para corregir el programa defectuoso:

It runs those inputs through a second program, known as the donor program, that has similar functionality. The Internet is awash with open source software that could provide parts for donor programs, though there’s no particular reason the donor code needs to be open source.

Si leemos algunos detalles más en System fixes bugs by importing functionality from other programs—without access to source code podemos ver que se trata de algo que deberíamos denominar, más bien, ‘microtransplantes’, porque se trataría de pequeños bloques de código.

En el artículo (seguramente no accesible para todos), Automatic error elimination by horizontal code transfer across multiple applications se puede ver, por ejemplo un fallo en el programa gif2tiff, corregido mediante la ‘donación’ desde ImageMagick:

#define MaximumLZWBits  12
if (data_size > MaximumLZWBits)
   ThrowBinaryException(CorruptImageError,
         "CorruptImage",image.filename);

Este código sería susceptible de un ataque de desbordamiento de memoria y el programa propondría corregirlo con:

if (!(datasize <= 12)) {exit(-1);}

Me encanta.

Correo para la gestión de accesos

Asignando identificadores Traigo hoy un par de referencias sobre algo que muchas veces ya estamos haciendo los usuarios en la práctica (y que algunos proveedores han ‘estandarizado’ más o menos en lo que denominan sistemas de acceso sin clave): cuando no recordamos la contraseña utilizamos el botón de recordarla y accedemos al sitio. Posteriormente, si no es un sitio que visitamos con frecuencia la olvidamos y la próxima evez seguiremos el mismo procedimiento.

En este caso lo contaban en How to Fix Authentication: Email as a Password Manager. En este caso proponen que este sea el método de acceso y, por lo tanto, proponen que la contraseña remitida sea de un sólo uso. Las ventajas: no hacen falta aplicaciones extra, no hay problemas de sincronización (aunque a veces sabemos que los correos se ‘atascan’ o no podemos acceder a ellos de forma temporal), simple para los desarrolladores (al final los protocolos de recuperación de contraseña tienen su complejidad, recordemos Introducing the “Secure Account Management Fundamentals” course on Pluralsight), el registro y la entrada son iguales (con matices, supongo, por la cuestión de si estás ya registrado con una cuenta de correo diferente), sólo es necesario un click, podemos controlar la duración de la validez del enlace, y no necesitamos almacenar constraseñas (y, por lo tanto, no nos las pueden robar). No termino de estar de acuerdo con la ‘ventaja’ de evitar el Facebook Connect (y similares) salvo por evitar su complejidad. Y tampoco con que no se puede aplicar fuerza bruta: obviamente se puede, aunque nosotros ahora tenemos más control sobre la dificultad de encontrar los enlaces, frente a las contraseñas que los usuarios suelen elegir de manera inadecuada.

Como inconveniente, está claro que trasladamos toda la seguridad de nuestro sistema al proveedor de correo y a la gestión que el usuario haga de él. Hay más, claro, nunca nada es tan fácil como creemos al principio.

No habría que olvidar la vigilancia de las cuentas gestionadas de esta manera (observación de anomalías, cambios, novedades,…) que también parece ser una de las tendencias en seguridad de cuentas hoy en día.

En History of Email-Only Auth hay más información y opiniones de diversas personas sobre ideas similares.

Hacen falta más expertos en desarrollo seguro

Libros sobre desarrollo seguro Hoy traemos un vídeo reciente sobre la escasez de talento en temas de seguridad en la industria (en EEUU, por nuestros lares ahora parece que nos acabamos de dar cuenta de que los informáticos son importantes, lo de seguridad llegará dentro de una temporada).

En el vídeo se habla de muchos temas, algunos de los cuales hemos tratado por aquí y en clase (ejemplos inseguros y otros asuntos).

Aunque no pude dedicarle toda la atención que debería me pareció interesante porque incide bastante en el tema de la formación, la seguridad en el desarrollo (y no sólo la del sistema y esas cosas en las que pensamos normalmente cuando se habla de seguridad informática).

Biometría y autenticación

Huellas humanas Traigo aquí una entrada del blog del INCIBE sobre biometría: Patrones biométricos y autenticación dinámica.

Todavía no se puede decir que sea una tecnología de alta implantación pero ya los teléfonos móviles de gama alta llevan lector de huellas y no es raro verla en portátiles, pero los expertos (y algunos productos comerciales) ya están pensando en la siguiente generación: la autenticación contínua. Cuando estamos utilizando una máquina, ésta debería ser capaz (y es) de medir determinados parámetros y evaluar si se parecen a los ‘de siempre’ o algo ha cambiado, para tratar de detectar intentos de uso fraudulento. En realidad estamos en un nivel más allá de los métodos tradicionales de autentificación con el ‘algo que eres’ como elemento identificativo. Si lo piensan, nuestro estándar de ‘autentificación’ en el mundo físico era la firma, que ahora se podría reforzar con sistemas informáticos no sólo a su aspecto sino a otros como presión, velocidad, dinámica…

Estos mecanismos siguen un esquema de análisis en tiempo real que monitoriza pulsaciones de teclado o gestos táctiles del usuario que son contrastados con patrones previamente registrados. Estos registros almacenan varios parámetros que caracterizan los patrones de comportamiento esperados para cada individuo tales como como la velocidad de tecleo, pausas, tiempo que se mantienen pulsadas las teclas, presión, etc.

Aunque no habrá que olvidar Algunos problemas de la biometría y repasar las Guías sobre biometría del INTECO.

La seguridad como argumento publicitario

Sensor Ya hemos hablado otras veces de estos temas: la seguridad hoy por hoy no constituye un argumento de venta. Los usuarios nos fijamos más en las funcionalidades, diseño y otros argumentos. Muchas veces la seguridad la vemos como algo molesto, que nos frena.

Por eso traigo aquí una nota de prensa que ni siquiera conozco si ha tenido efecto en las ventas y si el programa sigue activo Panda Security compensará a sus clientes en caso de infección. Indudablemente, utiliza la seguridad como argumento de ventas (algunos dirán que es trampa puesto que publicitan programas anti-virus que van, precisamente, de eso) pero hasta donde yo se, es la primera (o una de las primeras veces) que un anti-virus ofrecía ese nivel de garantía. Se pueden leer los términos en Garantía Panda y dice:

Si te infectas tienes 6 meses de servicio gratis. Y si tienes daños, o no te lo resolvemos en 24 horas, te devolvemos el diner.

Ataques a la BIOS en Apple

Apple Store Uno de los problemas cuando queremos tener un sistema seguro es que hay demasiados sitios donde alguien puede querer probar a atacarnos y es bastante difícil que seamos expertos en todo y/o que podamos dedicarle atención a todos los problemas durante todo el tiempo.

Como ejemplo, en Veneno, manzanas y un amargo despertar nos cuentan la historia de un rootkit que se podía instalar en el firmware de todos los MacBooks anteriores al año 2014 mediante un ataque bastante sofisticado, que se basaba en que las protecciones contra escritura de la BIOS se encontraban desactivadas tras la vuelta del sistema desde el modo Sleep.

Hay más detalles en The Empire Strikes Back Apple – how your Mac firmware security is completely broken pero el aviso es claro: los malos tienen muchas puertas de entrada.

Almacenamiento seguro de claves

Hablando de almacenamiento Llevo dándole vueltas a este tema una temporada (incluso investigué un poquillo para un proyecto personal Storing credentials of your Python programs in the keyring, y ando jugando con el keyring en Python; se pueden ver ejemplos en cleanImapFolders.py, addToSieve.py . Tengo pendiente comentar sobre estos programas. Además he descubierto el proyecto passpie que aporta una solución de almacenamiento interesante también).

Pero me está quedando un preámbulo muy largo y en realidad quería comentar Storing Passwords Securely que es una introducción genérica (pero no superficial) y que aporta una buena panorámica a los temas que hay que prestar atención incluyendo algunos ejemplos. Lectura recomendable.

Seguridad y aseguradoras

Geekonomics Este tema me resulta muy interesante: hemos vivido (y seguimos viviendo en muchos casos) como si los programas no pudieran ocasionar daños y, si los causan, el desarrollador/vendedor no tiene ninguna responsabilidad. Eso va cambiando con el tiempo, claro. Ya hablámbamos de Las actualizaciones … ¿como ventaja competitiva? y en los casos de los coches ha habido demandas y juicios Desbordamientos de memoria y Toyota.

En este caso traemos Insurer tells hospitals: You let hackers in, we’re not bailing you out que iría en la misma línea. En este caso se observó que la seguridad informática era muy deficiente y en consecuencia la aseguradora se niega a abonar los costes asociados, reclamando su devolución:

Columbia argues that it is not liable for the payout because Cottage did not provide adequate security for its documents, a clause the California hospital network agreed to when it signed the insurance policy.

Among the allegations, Columbia claims that Cottage failed to check for and apply security patches within 30 days of release, replace default access settings on security devices, undergo annual security audits, and outsourced data to firms with poor security. Cottage is also accused of failing to provide adequate detection and tracking of changes to its network and data.

Java después de veinte años

Libro Java El año pasado Java cumplía 20 años. Por ese motivo se publicaba Java at 20: How it changed programming forever donde se hace un resumen de sus ventajas más notables.

Según el autor, su principal fortaleza consistiría en ser una herramienta para tener el trabajo hecho:

But Java’s core strength was that it was built to be a practical tool for getting work done. It popularized good ideas from earlier languages by repackaging them in a format that was familiar to the average C coder, though (unlike C++ and Objective-C) Java was not a strict superset of C. Indeed it was precisely this willingness to not only add but also remove features that made Java so much simpler and easier to learn than other object-oriented C descendants.

Habla sobre el problema de los ‘applets’ (casi en fase de certificación oficial de su muerte, en estos momentos):

The irony is that applets never worked very well. They were completely isolated from the content on the page, unable to read or write HTML as JavaScript eventually could. Security constraints prevented applets from interacting with the local file system and third-party network servers. These restrictions made applets suitable for little more than simple games and animations.

Por completar, traigo un elogio del Java hecho por un desarrollador de Python que se autocalifica como converso: Why Java? Tales from a Python Convert que destaca la máquina virtual, las bibliotecas, la robustez de los tipos de datos y la concurrencia. También habla de las construcciones más modernas. Nos ha recordado aquella serie de la que hablábamos en Motivos por los que debería gustarnos Java donde se daba un buen repaso a las principales características de Java.

Explicación de los principales algoritmos de minería de datos

Puente colgante Antes del ‘big data’ se hablaba de minería de datos (‘data mining’) como precursora (y con intersección no vacía) me resultó interesante Top 10 data mining algorithms in plain English donde justamente describen eso: los algoritmos de minería de datos más importantes descritos de una forma más o menos sencilla.

Puede ser de interés para alguien que quiera tener una idea de las posibilidades, o como recordatorio para los que ya las hayan olvidado. De paso, aprendemos un poco de terminología general.