Es sabido que los sistemas de tipo Unix tienen un directorio común (pero un poco especial) que permite a cualquiera escribir para almacenar información de trabajo, ficheros temporales, …

En against /tmp comentan sobre el tema. Empiezan hablando de las peculiaridades, como es el sticky bit (¿pegajoso?) que es un permiso especial 01000 que se representa con una ‘t’:

drwxrwxrwt  5 root  wheel  160 Oct 22 10:22 /tmp/

Se inventó en los 70 para indicar que determinados programas debían permanecer en el núcleo porque eran de uso frecuente y así todo iba más fluido.

Originally in the 1970s the sticky bit was invented to speed up frequently-used programs such as the shell: the sticky bit indicated to the kernel that the executable file should stick in core. This functionality was made obsolete in the 1980s by filesystem page caches.

El bit se utilizó para los directorios con un objetivo diferente, impidiendo el borrado de ficheros aunque estuvieran en un directorio en el que tuviéramos permiso para borrar (el sistema de permisos de Unix siempre ha sido un poco básico).

To fix this, a file in a sticky directory may only be removed or renamed by a user if the user has write permission for the directory and the user is the owner of the file, the owner of the directory, or the super-user.

Esto es, el fichero en un directorio con el sticky bit solo puede borrarlo el propietario (o el propietario del directorio, o el administrador, claro).

Luego discute sobre las diferentes formas de crear un fichero temporal en Unix, con hasta cinco versiones diferentes:

bad: mktemp, tempnam, tmpnam ok: mkstemp, tmpfile new: mkdtemp, mkostemp, mkstemp

Tanto mkstemp como tmpfile están pensadas para crear ficheros (o directorios temporales) que no puedan colisionar con la actividad de otros programas.

The purpose of all these functions is to create a temporary file (or directory) that doesn’t collide with other concurrent activity.

El objetivo es evitar, fundamentalmente, condiciones de carrera (alguien consigue que abramos un fichero sobre el que tiene el control); para ello, hay que creaa nombres difíciles de predecir, con las restricciones adecudadas O_CREAT | O_EXCL, y hacer reintentos si el fichero ya existe EEXIST, para evitar (también) la denegación de servicio.

Luego discute sobre la limpieza (borrar lo que ya no se necesita) porque el /tmp tiene tendencia acumular basura y los problemas que puede tener alguien que intenta mantener ese directorio con los borrados.

Lo que debería suceder, afirma, es que debería haber directorios temporales diferenciados para cada usuario.

If you have per-user $TMPDIR then temporary filenames can safely be created using the simple mechanisms described in the mktemp(1) rationale or used by the old deprecated C functions. There’s no need to defend against an attacker who doesn’t have sufficient access to mount an attack! There’s no need for sticky directories because there aren’t any world-writable directories.

Y la razón de que eso no se hiciera tiene que ver (otra vez) con las prestaciones y los límites de los usuarios: podía ocurrir que el espacio del usuario estuviera montado a través de la red (lentitud), tuvier limitaciones de espacio (cuotas), o en un sistema de ficheros que no permitiera algunas características necesarias (como las named pipes).

Interesante. Un poco de historia, un poco de seguridad,…

Como hacía mucho que no escribíamos por aquí traigo una lectura de hace bastante tiempo, pero que tiene una (pequeña) dosis de actualidad por el reciente incidente que tuvo el sitio.

Comentaremos sobre Breaking the 4Chan CAPTCHA y la actualidad tendría que ver con su reciente caída (How the Internet Left 4chan Behind).

No vamos a hablar de la segunda parte, que es algo que no toca mucho aquí (salvo que nos cuenten los detalles técnicos, claro, que es algo que creo que no ha pasado todavía) sino de los CAPTCHAS y el caso de 4Chan. Como saben, se trata de un tablón donde la gente cuelga textos, fotografías, … muchas veces de muy dudoso gusto y con un sesgo bastante descerebrado.

Ya hemos hablado (creo) de cómo las inteligencias artificiales pueden romper con cierta facilidad los CAPTCHAS, estos códigos ofuscados, que pretenden ayudar a las máquinas a discernir entre humanos y otras máquinas (por ejemplo, de pasada en Las amenazas en los tiempos de la IA, aunque una referencia más extensa podría ser An Empirical Study & Evaluation of Modern CAPTCHAs).

El caso es que el autor se propuso entrenar una IA (sí, hay gente que hace esas cosas, en lugar de utilizar las herramientas que nos ‘dan’ otros). Los datos los obtuvo directamente de los retos que envía el sitio.

I scraped several hundred CAPTCHAs in this manner - not enough to train the model, but it’s at least a start. This still leaves us with a problem, though. We have all these CAPTCHAs, but we don’t have the solutions. I could fill them out manually, but instead, let’s try something else.

El problema ahora era resolverlos, para alimentar a su IA, aunque el problema, como ya anticipaban en el artículo de arriba es que los humanos no somos demasiado buenos con esos retos.

Or, Humans are bad at solving the 4Chan CAPTCHA.

Se le podría pedir a un humano de confianza ayuda, pero se le ocurrió una idea mejor: ¿qué tal simular CAPTCHAS al estilo de los que tenía, pero con un contenido que él ya conocía?

What if we could generate our own 4Chan CAPTCHAs? 4Chan, and the CAPTCHA it uses, are not open source, so I couldn’t literally run the same code locally. But I could definitely approximate it.

Después, crear el modelo ya es una tarea más sencilla y el resultado no parece malo del todo. Además, claro, el aprendizaje.

I enjoyed this project a lot. It had a few challenges to overcome, and I learned a ton about machine learning and computer vision in the process. There are surely improvements that can be made, but for now, I’m pleased with the results, because I achieved what I set out to do from the start.

Interesante.

No será la primera vez que hablamos de contraseñas y de las políticas que se definen para ‘mejorarlas’. Ya sabemos que muchas de estas políticas son contraproducentes por varios motivos:

• Reducen el tamaño de búsqueda de las claves (a pesar de aumentar la diversidad).
• Hacen que los usuarios elijan contraseñas peores.

Pero, aún así, parece que hay que repetirlo de vez en cuando. Por eso me gustó leer How some of the world’s most brilliant computer scientists got password policies so wrong.

Nos dice que las reglas nacieron hace un montón de años, con buena intención y dictadas por gente muy inteligente:

The story of why password rules were recommended and enforced without scientific evidence since their invention in 1979 is a story of brilliant people, at the very top of their field, whose well-intentioned recommendations led to decades of ignorance. These mistakes are worth studying, in part, because the people making them were so damn brilliant and the consequences were so long lasting.

Ya en el año 1979 hacían análisis de las contraseñas y descubrían que no eran de muy buena calidad.

They discovered that 2,339 (71%) were either six or fewer characters of the same type (lower-case, upper-case, or digits) or 3 characters of mixed types. They found an additional 492 of the remainder (15% of all the passwords) were available in “dictionaries, name lists, and the like.”

Y, claro, diseñaron una política de contraseñas para mejorarlas.

They incorrectly assumed that if they prevented the specific categories of weakness that they had noted, that the result would be something strong.

La lectura es muy agradable y vale la pena ver la historia (y cómo algunas organizaciones permanecen ancladas en esas ideas obsoletas) y quedarse con la conclusión. Más aún cuando no ha sido hasta fechas relativamente recientes que se ha abordado el problema con más seriedad y los descubrimientos son claros, y los consejos también.

As a result of Morris and Thompson’s recommendations, and those who believed their assumptions without evidence, it was not until well into the 21st century that the scientific community learned just how ineffective password policies were. This period of ignorance finally came to an end, in part, because hackers started stealing password databases from large websites and publishing them.

El ingenio humano es infinito. Y se puede usar para el mal. En Hackers now use ZIP file concatenation to evade detection nos cuentan un truco que se basa en la utilización de varios ficheros ZIP (el formato permite utilizar varios para facilitar el envío de cantidades grandes de información). El problema es que el resultado parece un fichero ZIP normal pero contiene algo mucho más complicado (por ejemplo, otros datos en formato ZIP, que pueden ser pasados por alto por algunas soluciones de análisis).

Siempre se había dicho que había que tener cuidado con lo que había en la definición de los sitios donde nuestro sistema busca los ejecutables por defecto (el PATH). La cuestión es que la superficie de exposición y dónde puede haber elementos peligrosos se va ampliando con el tiempo. En This New Supply Chain Attack Technique Can Trojanize All Your CLI Commands nos dan idea sobre elllo.

Primero nos habla de los ‘puntos de entrada’ (entry points) que es un mecanismo que permite que algunas funcionalidades estén disponibles a través de la línea de instrucciones sin necesidad de que el usuario conozca la estructura de un paquete; esto es, no sólo tenemos una biblioteca (librería) o un programa, sino que podemos tener otras formas de ejecutar algunas partes que puedan ser interesantes por algún motivo.

Entry points are a powerful feature of the packaging system that allows developers to expose specific functionality as a cli command without requiring users to know the exact import path or structure of the package.

¿El truco? Los malos pueden insertar en paquetes de apariencia normal sustitutos de algunas instrucciones habituales y utilizar estos puntos de entrada para ejecutar sus programas.

Malicious packages can use entry points to masquerade as widely-used third-party tools. This tactic is particularly effective against developers who frequently use these tools in their workflows.

En casos como estos podría ser bastante fácil darse cuenta de que algo va mal, así que una solución puede ser utilizar el nombre para hacer un programa que tiene el efecto esperado, además de los efectos maliciosos.

In addition to silently executing the attacker’s malicious code, it calls the original, legitimate command with all the user’s arguments.

La clave aquí (y la dificultad) es que el usuario ejecutará una instrucción, recibirá el resultado esperado y puede que a la vez esté sufriendo algún tipo de ataque (robo, borrado, ejecución de otras cosas,…).

Otro motivo para tener mucho cuidado con lo que se instala, dónde y cómo lo ejecutamos.