En Deterministic Doom hace la prueba de eliminar la aleatoriedad del conocido juego Doom. Para ello, primero observa que el juego no utiliza ninguna fuente de aleatoriedad externa, sino que incluye una tabla de valores de donde se toman los valores para diversas acciones en el juego:

Rather than consume system randomness, Doom has a fixed 256-value random number table from which numbers are pulled by aspects of the game logic

Por otra parte, los efectos son los que uno podría imaginar (y algunos otros): desde el comportamiento de los atacantes a diversos efectos de imagen, pasando por las armas que se utilizan.

Prueba con distintos valores, por ejemplo:

With 0x00, monsters never make their idle noises (breathing etc.) On the other hand, with 0xFF, they always do: so often, that each sample collides with the previous one, and you just get a sort-of monster drone. This is quite overwhelming with even a small pack of monsters.

Curioso.

Es un tema recurrente hablar sobre el mito de los miles de ojos mirando. Ni en código abierto Bugs con una larga historia. El caso de LZO ni, por supuesto, en código propietario (supuestamente profesionalmente controlado).

Traemos esta vez un fallo con casi 20 años, 18-year-old bug can be exploited to steal credentials of Windows users en el que no entraremos en los detalles técnicos:

A new technique for exploiting an 18-year-old bug in Windows Server Message Block (SMB), which would allow attackers to intercept user credentials, had been uncovered by Cylance researcher Brian Wallace.

Pero que muestra que a veces los fallos son muy resistentes al paso del tiempo. Y algún día se descubren.

Para los interesandos, más detalles técnicos en SPEAR: Redirect to SMB.

Desde hace tiempo tengo una idea un poco loca: en estos tiempos en los que tanto software se ejecuta directamente en un servidor y no tenemos ninguna forma de verificar lo que sucede sería interesante poder ‘certificar’ de alguna forma que el código que se ejecuta es el debido. Por ejemplo, si alguien está usando el servidor web Apache, tal vez debería ser posible en algunos casos poder verificar que efectivamente se ejecuta el código sin modificar, etc. Ya que no podemos auditar el programa que utilizamos, sería una forma de poder ver el código (que tal vez estaría disponible en algún repositorio) y estar seguros de que lo que se ejecuta es justamente lo que vemos.

Por eso me llamó la atención la propuesta/pregunta de Propuesta: ¿Un plugin para autorizar JS en cifrados online? donde se limita el problema a la ejecución de código en JavaScript:

En todos estos casos se emplea código javascript (JS) que se descarga y ejecuta en el navegador del usuario, de manera que el servidor nunca llega a conocer su pasword, desarrollándose todo el proceso de cifrado y descifrado siempre del lado del cliente.

El punto débil de este criptosistema ocurre cuando la web ve comprometida su seguridad y con ella la de su código JS, ya sea por la intervención de un programador deshonesto de la misma organización, ya sea por la intervención de terceros que pueden introducir fragmentos de código malicioso con objeto, por ejemplo, de abrir un socket durante el proceso de cifrado para capturar y enviar la clave del usuario a un determinado sitio.

No se si la propuesta ha avanzado en alguna dirección pero a lo mejor valía la pena probar.

Nunca he sido un gran fan de Java. Tampoco he hecho programas de tamaño suficinte como para poder criticarlo o alabarlo con criterio, la verdad. El otro día leía una ‘queja’ que ahora no soy capaz de encontrar donde alguien decía que Oracle no le estaba prestando suficiente atención. Y también otra ¿Se ha convertido Java en un problema para el acceso a la administración electrónica? aunque en este caso no termino de tener clara la conclusión porque me resisto a creer que nadie haya sido capaz de superar el problema de los certificados utilizando algo que no sea el navegador y Java.

A pesar de todo lo dicho, me gustó leer una serie de diez entradas que se pueden leer a partir de 10 Reasons Why Java Now Rocks More Than Ever: Part 1 – The Java Compiler donde se van desgranando diversos motivos por los que debería gustarnos la plataforma.

Para perezosos y personas interesadas sólo en alguna de las partes (o como anzuelo para, a partir de ahí, leerlas todas), el índice:

1. The Java Compiler
2. The Core API
3. Open-Source
4. The Java Memory Model
5. High-Performance JVM
6. Bytecode
7. Intelligent IDEs
8. Profiling Tools
9. Backwards Compatibility
10. Maturity With Innovation

Lo de la compatibilidad hacia atrás me ha recordado una historia vieja de Joel Spolsky How Microsoft Lost the API War. Lo enlazámabos en su día en la bitácora de BarraPunto, que allí sigue: Joel, la API de Windows y el desarrollo web. Pocas veces nos acordamos cuando empezamos un proyecto nuevo que su vida debería larga y que eso tiene consecuencias cuando apostamos por tecnologías muy novedosas.

Actualización (2015-11-25): El amigo @vrruiz me señala Even If Oracle Is Losing Interest In Java, Should You Worry? como una posible fuente acerca de lo que comentaba arriba de la pérdida de interés en Java por parte de Oracle. Allí se enlaza a esta nota Insider: Oracle has lost interest in Java que creo que es la que yo vi en su momento. Quede aquí referenciada por completitud.

Seguimos con el tema de las actualizaciones.

En la introducción de la parte de la asignatura de desarrollo seguro en la que participo, comentábamos el otro día (transparencias en [PDF] Algunos datos sobre desarrollo y seguridad de aplicaciones que no podemos esperar que los usuarios actualicen (y mucho menos que lo hagan rápidamente).

En los últimos años se ha conseguido que determinados grupos de usuarios estén pendientes, al menos, de las últimas versiones de sus sistemas e instalen las actualizaciones, pero todavía parece que no es lo habitual entre la generalidad de los usuarios (ejercicio: observar la reacción de cualquier usuario medio ante las alertas de actualización de su dispositivo móvil; leer los mensajes con ellos para ver qué interpretan y sus intenciones al respeto).

Si pasamos al internet de las cosas (internet of things, IoT) con dispositivos de lo más variopinto conectados la cosa se complica: las interfaces son más escuetas y los sistemas de actualización pueden ser algo más complicados.

Recientemente se descubrían fallos de seguridad que permitían atacar a algunos modelos de Jeep Cherokee. También otros fallos que permitirían realizar algo parecido a través del sistema de información y entretenimiento del Tesla Model S (lo cuentan en How the Jeep Hack Reveals Tesla’s Biggest Advantage.

En el caso de los primeros la firma se vio obligada a hacer una llamada a los propietarios de los vehículos y/o a enviarles un USB con la actualización:

But the big difference between these scenarios is what happened next. Fiat Chrysler had to recall 1.4 million Jeeps that could potentially be vulnerable to the hack, but the “recall” actually amounted to mailing Jeep owners a USB stick that they could plug into their vehicle’s dashboard port in order to give the car the necessary patch.

En el segundo caso, al tratarse de coches conectados y que reciben actualizaciones a través de internet (OTA, Over The Air) la actualización fue envíada por ese sistema y los coches actualizados (parece que tenían que aceptar, pero seguramente están en ese sector que actualiza y agradece las novedades; estaría bien poder conocer el porcentaje de los que dijo ‘no’):

Tesla, on the other hand, was able to automatically send a patch to all its Model S vehicles on Wednesday through an over-the-air update, a method more akin to how your smartphone gets software fixes.

En Researchers Hacked a Model S, But Tesla’s Already Released a Patch hablan de ventaja en seguridad (‘Tesla cars have one security advantage that a lot of other cars don’t’) y cuentan más detalles de los fallos.

En todo caso, parece una ventaja desde el punto de vista de la seguridad clara para Tesla, con la preocupación que siempre tendremos de que no sabemos qué ocurre realmente con esas actualizaciones ni qué incluyen.

Lo que no tengo tan claro es que alguien pueda terminar decidiéndose por un modelo u otro en función de esos factores; sí que puede ser un factor determinante para las marcas, que empiecen a darse cuenta del ahorro que puede suponer (¿con sus riesgos asociados?) instalar en los vehículos sistemas de actualización adecuados.

Esta entrada está basada en Las actualizaciones … ¿como ventaja competitiva?.