FreeBSD 8 - Exploit

[ezeaguerre]

Se equivocaron de parche.... en fin lo más grave y bolud* me parece lo del linker...

[gnemmi]

Si, ni hablar ...
De todas formas .. me pareció interesante la siguiente nota:

FreeBSD Shines While Apple Fails

[Matutin]

Es logico que cualquier pieza de soft tenga bugs, el tema es que clase de bugs.... Si tenemos en cuenta que un sistema *nix esta basado en la seguridad, este tipo de bugs que le dan permiso de root son aberraciones ABISMALES lol
_________________

GRACIAS GEO POR LA FIRMA!!!

[ezeaguerre]

No sé... ¿basado en la seguridad? lo único que tenía Unix era:
* Usuarios
* Procesos, con memoria virtual (protección) y usuarios.
* Permisos user:group:world
No hay tanta seguridad ahí

Windows NT es bastante más seguro que eso... y perdón por decirlo, pero es la verdad

Bugs que te permiten acceso como root (o el equivalente en otros sistemas) siempre hubo (lamentablemente), tanto en Linux, como en FreeBSD, NetBSD, OpenBSD (Si, si, OpenBSD, el sistema operativo orientado a la seguridad), Solaris, Windows 9x, Windows NT/2000/XP...

Lo que me parece una aberración es la estupidez del bug en si... por decir algo... si veo código como este:

[Matutin]

Siempre tuve en cuenta que *nix se basa en seguridad. De ahi el tema de los permisos, que todo es un archivo y todas esas cosas que no se bie nque carajo son.... lol

Y que digas que NT es seguro, si, es una patada en las bolas


Y esos errores.... Que se yo, para mi que estan todo sborrachos!
_________________

GRACIAS GEO POR LA FIRMA!!!

[ezeaguerre]

No sé... quizás puede ser, cuando vio la luz tenía mucho énfasis en la seguridad... pero bueno, lo que hace 30/40 años era seguro, hoy... bueno, por algo poco a poco le fueron agregando cosas. Como desde el más bolud* cambio passwords de /etc/passwd a /etc/shadow hasta cosas como ACL en el sistema de archivos, POSIX CAPABILITIES, RBAC, MAC, firewalls, etc...

Me acabo de acordar de una anécdota que cuenta Tanenbaum en uno de sus libros de sistemas operativos... la cuento porque me parece graciosa... y de paso deja en _no_ tan ridículo a las películas en las que van descubriendo la clave de a pedacitos
La cosa es que había un sistema operativo que permitía a aplicaciones de usuario recibir una señal cuando se provocaba un fallo de página (más que nada para profiling y ese tipo de cosas supongo). Un programa malintencionado pedía una página de memoria, y ponía una clave de esta manera ( el "|" simboliza el fin de una página y el comienzo de la otra ):
* c | <no hay página>: Si se provocaba un fallo de página, entonces la 'c' la había procesado adecuadamente.

* cl | <no hay página>: Si se provocaba un fallo de página, entonces 'cl' había sido procesado adecuadamente, de lo contrario cambiaba la 'l' por otra letra y seguía probando.

Esto obviamente lograba crackear una clave en cuestión de segundos
Hoy día se podría hacer con mmap y el manejador de segfault... el tema es que hoy día dudo mucho que alguna librería vaya resolviendo la clave de a poco... directamente hace todo el hash y compara :-)


Otra anécdota interesante tiene que ver con los schedulers. Un sistema de tiempo compartido tenía un scheduler por prioridad. Basicamente dividía los procesos en dos:
* Interactivos: Procesos de consola (I/O Bound).
* No interactivos: Procesos de cálculo (CPU Bound).
Resulta que eligieron una manera muy sencilla de decidir si un proceso era interactivo o no... si presionabas el teclado era obviamente interactivo :-)
¿Cuál es el problema? Alguien se dió cuenta que apretando la barra espaciadora hacía que su proceso No interactivo adquiera cada vez más y más prioridad (como los procesos interactivos)... al final llevándose toda la CPU :-)

Hoy día nada de esto sería remotamente imaginable... pero en el inicio de la computación...

[gnemmi]