Desmitificar las inseguridades de Madaidan

Madaidan es un autoproclamado "genio" de seguridad, y escribió un artículo sobre unas supuestas 'inseguridades' de Linux. En algunos temas, estoy completamente de acuerdo con su análisis, mientras que en otras, no estoy de acuerdo. Voy a analizar su artículo con el propósito de generar más discusión e interés en linux, e desmitificar las mentiras que cuenta.

Su artículo se encuentra aquí

introducción:

"Overall, other operating systems have a much stronger focus on security and have made many innovations in defensive security technologies, whereas Linux has fallen far behind."

Eso es completamente falso. Linux ha tenido muchas mejoras de seguridad, como escrito aquí Linux siempre ha sido uno de los primeros en adoptar remedios contra vulnerabilidades como spectre. A diferencia de Linux, otros sistemas operativos han tardado mucho tiempo en crear un patch para las vulnerabilidades. Por ejemplo, en algunos Windows, había que manualmente descargar e instalar un patch .msu.

Sandboxing

"there is no resemblance of a strong sandboxing architecture or permission model in the standard Linux desktop — current sandboxing solutions are either nonexistent or insufficient. All applications have access to each other’s data and can snoop on your personal information. "

Estoy de acuerdo con su opinión. A linux le falta los sistemas de sandboxing que existen en otros sistemas operativos. Sin embargo, la forma más segura de sandboxing es creando máquinas virtuales. Existe una distribución de linux llamada QubesOS en la que se crean máquinas virtuales para aplicaciones diferentes. Y así este QubesOS se convierte en el SO más seguro que existe. Ahora estamos afortunados que programadores con mucho talento están trabajando en mejoras y alternativas a QubesOS (ejemplo: SpectrumOS), y esto está progresando y desarrollando la seguridad en linux.

Madaidan señala como las formas de sandboxing actuales en linux (con excepción de máquinas virtuales) no son muy seguras, y todavía requieren mucho más trabajo para ser seguras.

Flatpack

El autor se basa en el website FlatKill.org que ha sido desaprobado y desmitificado por muchos expertos aquí Madaidan señala que un programa de flatpack, aún podría ex-filtrar datos. Pero de alguna manera se olvida por completo pensar en cuántas aplicaciones contienen malware en el Microsoft + Apple store, comparado a flatpack.

Aunque el autor se imagina problemas con la tecnología de flatpack, tiene la impresión que bubblewrap es el único método seguro para hacer sandbox en linux. El problema? Bubblewrap fue creada especificamente para flatpack, y flatpack utiliza a bubblewrap para su sandbox.

Exploit Mitigations

"Linux has not made significant progress on implementing modern exploit mitigations, unlike other operating systems." No hay ninguna prueba. De hecho, siempre están trabajando en el kernel de linux para mitigar posibles vulnerabilidades.

"Most programs on Linux are written in memory unsafe languages, such as C or C++, which causes the majority of discovered security vulnerabilities. Other operating systems have made more progress on adopting memory safe languages, such as Windows, which is leaning heavily towards Rust, a memory safe language, or macOS which is adopting Swift."

...Es que Madaidan no sabe que son los autores de software quienes deciden en qué lenguaje de programación escribir ese software? Los autores escriben programas en C/C++ para Windows, Mac, y Linux. O sea, el mismo problema existe para cada S.O

Es verdad que lenguajes de programación que son 'seguros de memoria' pueden ser más seguros para el sistema operacional ya que es menos probable que hayan bugs relacionados con over/underflows de memoria. Sin embargo, eso no es todo el cuento. Muchas programas 'high-level' se pueden escribir en lenguages 'seguros de memoria' y eso les ayuda tener menos probabilidad de bugs, pero el kernel es diferente. El kernel es muy 'low-level' y trabaja muy cerca del CPU y el código de máquina. Así que el kernel debe trabajar rápido. Si digamos un juego de ajedrez está escrito en Java/Rust u otro lenguaje 'seguro', y por eso toma unos milisegundos extra, y corre un poco más lento, no hay problema. Pero si el kernel corre un poco más lento, entonces el sistema se vuelve casi que basura.

Digamos que entonces usamos Rust, que promete ser bien rápido. De todas maneras tenemos un problema, ya que en el kernel u otros programas que deben correr lo más rápido posible, muchas veces los programadores crean trucos y optimizaciones del programa para poder correr un pedazo de código más rápido. Si usamos Rust entonces habrá 2 opciones:

Escribirlo de manera segura y super lenta, o;
Implementar el mismo truco en Rust, y luego decirle al compilador que no se preocupe de los errores.

Ahora, no siempre es así, y hay muchos momentos en los cuales usar Rust es mejor. Y afortunadamente ahora en el kernel de linux, se está introduciendo código de Rust. Esperemos que más programadores escriban sus drivers etc en Rust.

"Microsoft is the only vendor to have solved the aforementioned problem by implementing Control Flow Guard support for Rust." ... Linux usa Reuse attack Protector (RAP) y control flow integrity (cfi). Como que Madaidan tiene las cosas muy confundidas...

Control Flow Integrity

Qué basura. Linux lo tiene implementado desde 5.14.

PTEs ya está arreglado. Linux usa Kernel-self protection

"On Linux, there is currently no equivalent to VBS." Incorrecto, existe Linux Kernel Runtime Guard

Kernel

"The Linux kernel itself is also extremely lacking in security. It is a monolithic kernel, which means that it contains a colossal amount of code all within the most privileged part of the operating system and has no isolation between internal components whatsoever."

No hay ninguna prueba que Windows o Mac hagan algo mejor.

"The kernel has huge attack surface and is constantly adding new and dangerous features."

No me digas. Están agregando funciones nuevas!!!??? XDXD y... No piensa que Windows y Mac también agregan funciones nuevas?...

"One example of such dangerous features is eBPF. In a nutshell, eBPF is a very powerful framework within the Linux kernel that allows unprivileged user space to execute arbitrary code within the kernel in order to dynamically extend kernel functionality. eBPF also includes a JIT compiler, which is fundamentally a W^X violation and opens up the possibility of JIT spraying. The kernel does perform a number of checks on the code that is executed, but these are routinely bypassed, and this feature has still caused numerous security vulnerabilities."

También hay JIT en Windows. Se puede atacar el kernel en Windows en la misma manera

"The kernel is written entirely in a memory unsafe language and has hundreds of bugs, many being security vulnerabilities, discovered each month."

Windows y Macos tienen el mismo problema, o incluso hasta más grave.

Ataques de root

"On ordinary Linux desktops, a compromised non-root user account with access to sudo is equal to full root compromise" Pues claro, si el usuario tiene permiso de root, y ese usuario está comprometido, pues kaput. Pero ese mismo problema existe en cada SO. Si tienes una cuenta con permisos de root, bien sea en Windows o Macos, y corres un malware en esa cuenta, pues, kaput. Nada te puede proteger.

"Even if one were to mitigate every single way to log keystrokes, the attacker can simply setup their own fake sudo prompt by manipulating $PATH or shell aliases/functions to intercept the user's password, completely unbeknownst to the user."

Lo mismo aplica a Windows y Macos, ya que el sistema ya está comprometido.

Lo que no cuenta es la manera en que se infecta con un virus, ya que eso es un ejemplo crucial de por qué linux es mucho más seguro que otros SO (Windows+Mac).

Digamos que queremos instalar una aplicación como htop. En linux con un 'sudo apt install htop' ya estamos listos, y es de una manera muy segura. En windows/macos: Entramos a google, entramos 'descarga htop', y cliceamos el primer resultado y... brrr ya estamos infectados con un virus. Se supone que entramos en un website de phishing que se ve igualito al original, pero que contiene un malware.

Y resulta que la supuesta 'seguridad' de windows/macos de 'User Account Control (UAC)' y 'secure event input' trabajó... hasta el momento que hicimos clic en "Sí". (Y no es extraño que en windows/mac para instalar una aplicación nueva, hay que correr la aplicación de instalo como root? en vez de correr algo seguro como apt en root?)

Y que tal de Mac/Android/IOS? Pues, un poco mejor que windows, ya que tienen un 'app store'. Miremos este ejemplo: Queremos instalar una nueva aplicación ejemplo para analizar el wifi. Entramos al 'app store' / 'play store', y lo buscamos. Encontramos una aplicación que nos guste, y la instalamos y... brr, ya estamos infectados con un virus. Se supone que de las docenas de aplicaciones de wifi, todas con nombres casi que igualitos, instalamos la versión que tenia incluido un virus. El problema aquí es que a diferencia de linux, donde para incluir una aplicación en los repositorios hay un proceso entero para verificar y comprobar que la aplicación sea verdadera, segura, y con fuente abierto, eso no existe en los 'app stores' de Mac/Android/IOS, y cualquier don Juan y Petro pueden incluir su versión que contiene viruses.

Stable release model

Madaidan tiene un problema con el modelo estable, y piensa que no es seguro. Afortunadamente, los héroes en el Security Team de Debian, Ubuntu, y otras distribuciones trabajan de dia y noche para patch vulnerabilidades en los repositorios estables, así que Madaidan se puede relajar y calmarse. El mundo no se va a acabar tan pronto.

En un tono más serio, los modelos estables y rolling-release tienen sus pros y contras relacionados con la seguridad. Es posible que el comando de seguridad de las distribuciones no se de cuenta de un bug/patch importante? Claro que sí. Pero también es posible que entren nuevos bugs o vulnerabilidades a los repositorios de fuente, y que se el modelo de rolling-release incluya esa versión vulnerable antes de que otros programadores se den cuenta. Podemos ver el ejemplo reciente del backdoor XZ, el cual entró en unas distribuciones rolling-release, pero afortunadamente (casi por un milagro) lo detectaron antes de que la versión vulnerable se incluyera en la versión estable.

Además, es supremamente fácil cambiar a la versión rolling-release más actual, por ejemplo en debian, cambiando al repositorio testing.

Lo que me parece extraño es que no menciona los modelos de Windows/Mac/Android/IOS etc. En Windows, las actualizaciones automáticas están prendidas por defecto, y así se distribuyen los patches para vulnerabilidades en el momento más inadecuado... Bueno, al menos sí se actualiza el sistema. Pero Windows solamente actualiza, pues, Windows y sus drivers. Si hay una aplicación vulnerable como...chrome/firefox, pues, ya tenemos un problema, ya que hay que rezar que el usuario milagrosamente decida actualizar el programa bien rapidito, y no posponer para después... Y existe el mismo problema para los demás SO: Las aplicaciones no se actualizan de una manera eficaz y segura.

Linux hardening

Madaidan tiene la opinión que es supremamente difícil de hacer que linux sea seguro, y piensa que para que sea seguro necesita: "completely redesign how the operating system functions and implement full system MAC policies, full verified boot (not just for the kernel but the entire base system), a strong sandboxing architecture, a hardened kernel, widespread use of modern exploit mitigations and plenty more."

Afortunadamente, es muy simple segurar linux. Lo único que hay que hacer es instalar una distribución super-segura como QubesOS, y ya! No hay que implementar full verified boot (que en realidad es completamente inútil), y la virtualización se encarga del resto.

Otros "genios" que cayeron en la misma trampa que Madaidan:

developer of grsecurity, el producto más inútil para el kernel. No me asombra que el que trata de vender unos 'patches' inútiles para supuestamente hacer el kernel 'más seguro', encontró 'inseguridades' en linux...
lead developer of GrapheneOS: Se ha envuelto en múltiples escándalos con otros expertos de seguridad. Su culto (comunidad) está llena de desinformación de seguridad. Como ejemplo, dicen que ni F-Droid ni Aurora-store son seguros, y lo mejor es usar... google play (el que está lleno de malware)...! (en serio, esos "genios" están repartiendo esta basura)