Durante décadas, los programadores han escrito sistemas críticos en C y C++. Ahora, recurren a Rust .Muchos proyectos de software surgen porque, en algún lugar, un programador tenía un problema personal que resolver. Eso, más o menos, le ocurrió a Graydon Hoare. En el año 2006, Hoare era un programador informático de 29 años que trabajaba para Mozilla, la empresa de navegadores de código abierto. Al volver a su apartamento de Vancouver, descubrió que el ascensor no funcionaba: su software se había bloqueado. Y no era la primera vez que le ocur
|
etiquetas: historia de rust , lenguaje de programación , c , graydon hoare 
Yo te hablo del chip que controla el motor de un barco que tiene 40 años , y está encapsulado dentro de un motor y el jefe del barco no tiene un dongle para actualizarlo...
Te hablo del chip de un semáforo de un pueblo remoto , que lleva funcionando 20 años....
Te hablo de todo eso , ....
Insisto que internet hay varios experimentos cambiado la hora a varios sistemas operativos de 32 bits y cascan de lo lindo
Te hablo de los problemas que ya hemos tenido, mira youtube.
Te l,o he explicado de…...
Rust viene por un motivo diferente "overflow" de ahí vino el nombre de la página tan famosa Stack Overflow , desbordamiento de pila... de esos desbordamientos se aprovechaban antiguamente los virus y actualmente es un vector de ataque para un porcentaje muy alto de software. Rust no te deja compilar si hay desbordamientos de ese tipo , aunque tengas bien escrito todo , etc...
Todos en C. A C le queda cuerda para rato.
De hecho Rust está bien para reemplazar a C++.
Sobre overflows, las mitigaciones de OpenBSD junto con pledge y unveil machacan el 99% de ataques.
Rust está guapísimo, es un lenguaje cojonudo, pero el mundo entero está hecho en C y C++ y eso no se cambia de la noche a la mañana. Por otro lado, C++ está viviendo una segunda juventud: el lenguaje ha mejorado muchísimo con respecto a hace 15 años, no digamos ya 25. Sigue siendo el lenguaje premier para videojuegos, sistemas de IA, ML, etcétera.
Igual que Python destronó a Java para muchísimas aplicaciones, Rust quizá termine destronando a C++ que es su objetivo real. Pero seguramente muchos estemos ya jubilados cuando eso suceda.
(*) Y Python es más antiguo que Java
Ese 1% que dejas al aire es suficiente para que te ataquen y te roben todos los datos.
Un sistema es tan fuerte como su parte mas debíl.
fn overflow() {
overflow();
}
fn main() {
overflow();
}
thread 'main' has overflowed its stack
fatal runtime error: stack overflow
Aborted (core dumped)
Ten en cuenta los niveles de los lenguajes.
Maquina
Ensamblador
C , C++ , Rust ...etc
Python , java etc
Lenguajes de muy alto nivel , yo uso uno que no puedo nombrar por confidencialidad.
Rust es un lenguaje de bajo nivel , entra en contacto con el hardware directamente.
Hoy en dia sl usar c y c++ hay que usar programas auxiliares para verificsr el código.
Por eso el tema es bastante gordo , pero se tardará décadas como tu dices.
Nadie sabe que sucederá , se espera que esté todo a 64 para entonces... pero....
¿Tienes tu la censados todos los sistemas de 32 bits del planeta?
Chips, microcontroladores , .... quien sabe ...
En internet hay un reloj de cuenta atras.
Ahora bien, si tienes una Debian Lenny o Squeeze de la época, pues allá tu.
¿Para ejecutar usas el compilador dd Rust no?
Pregunto porque a lo mejor me pierdo algo.
En mi trabajo diario si me da un error de ejecución no puedo seguir y tengo que arreglarlo...
Si hablamos de parches no oficiales para el y2k38 s los hay hasta para BSD 4.3 bajo SIMH en una VAX
Como ejercicio es cojonudo, y el código en C no es precisamente difícil de retocar.
Es un coredump como cualquier otro. Y el error es diciendo que es un desbordamiento de pila me ha salido porque está compilado en modo debug, nada más.
Los desbordamientos de pila son inevitables si hay recursividad, es imposible que el compilador pueda saber de antemano el nivel de profundidad de las llamadas.
Yo te hablo del chip que controla el motor de un barco que tiene 40 años , y está encapsulado dentro de un motor y el jefe del barco no tiene un dongle para actualizarlo...
Te hablo del chip de un semáforo de un pueblo remoto , que lleva funcionando 20 años....
Te hablo de todo eso , ....
Insisto que internet hay varios experimentos cambiado la hora a varios sistemas operativos de 32 bits y cascan de lo lindo
Te hablo de los problemas que ya hemos tenido, mira youtube.
Te l,o he explicado de varias formas diferentes , no insito mas
www.youtube.com/watch?v=jrGWMaUOSvk
Ese es el reloj , lo lógico es que todo estuviera actualizado para entonces, pero ya lo veremos..
www.epochalypse.today/
The signed 32-bit integer that is historically used to keep unix epoch time has already exhausted 89.07% of all possible values.
0
1100100
00000010
10000011
10101100
Only 5435 days (14 years) until it's finally 20:45:52 UTC on 13 December 1901 again!
Only 5435 days (14 years) until it's finally 20:45:52 UTC on 13 December 1901 again!
No estás entendido como hace Rust para evitar el overflow y no entiendes bien el overflow .
Haz pentesting y lo verás con tus ojos.
Me paso el día explicandoselo a compañeros , ingenieros , y no lo entienden.
Para entenderlo te recomiendo que veas un poquito de ensamblador y lo entenderás mejor.
Y la esctructura de un PE , portable ejecutable y como son los registros de una CPU . Te recomiendo empezar con un chip pequeño del tipo ESP32.
Ese 1% es suficiente para que se lie bien gorda.
Tampoco Rust lo va a solucionar todo , eso esta claro .
Por lo general, en el 99% de los casos, si encima usas UBo, Chromium ni se va a enterar. En el resto antes de que pase algo Chromium casca pero de pleno al intentar usar alguna syscall que no este visibilizada desde pledge. Con unveil impides que se accedan a cosas como ~/.ssh y no salga de ~/Downloads y ~/.local/share/chromium (y otras rutas del sistema) para operar.
En Firefox para OpenBSD era mágico. En el cuadro de descargas y subidas de GTK+ no salía ni $HOME como ruta a entrar, no te dejaba. ~/Downloads como ruta absoluta y gracias. No, tampoco ibas a ".." . O directo a ~/Descargas, o no entrabas.
Aquí lo dejo que no vamos a llegar a nada.
Con unveil no vas a ver desde el VFS nada que no se te haya indicado. Ni patrás. No es que que el exploit no intente un open o fopen, es que literalmente el proceso y subproceso los ficheros no existen para el, el kernel no los expone.
Luego si lo encuentro te lo paso .
Rompo un lanza en tu favor diciendo que yo pensaba igual que tu.
Practicamente todo lo que es Unix es muy seguro , por suerte para todos nosotros , nuestros datos vitales descansan sobre BBDD que están en sistemas Unix. Imaginate que se descargan nuestros datos de la seguridad social , del banco o algo así directamente desde la BBDD , sería problema muy serio.
Por eso no se debe instalar cualquier mierda de programa , mira lo que les ha pasado a los de Lastpass , a un ingeniero de DEVOps le atacaron un programa de reproducion multimedia ... y a través de eso entraron en su nuve de amazón.... es decir les abrió la puerta hasta la cocina...
fn main() {
let mut ar = [0; 1000];
ar[1049] = 1;
}
Al compilar te dice
error: this operation will panic at runtime
--> src/main.rs:4:5
|
4 | ar[1049] = 1;
| ^^^^^^^^ index out of bounds: the length is 1000 but the index is 1049
Si el índice es dinámico:
fn main() {
let mut ar = [0; 1000];
for i in 1..2000 {
ar[i] = 1;
}
}
✦ ❯ RUST_BACKTRACE=1 cargo run
Finished dev [unoptimized + debuginfo] target(s) in 0.00s
Running `target/debug/overflow`
thread 'main' panicked at 'index out of bounds: the len is 1000 but the index is 1000', src/main.rs:5:9
stack backtrace:
0: rust_begin_unwind
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/std/src/panicking.rs:575:5
1: core::panicking::panic_fmt
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/core/src/panicking.rs:64:14
2: core::panicking::panic_bounds_check
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/core/src/panicking.rs:147:5
3: overflow::main
at ./src/main.rs:5:9
4: core::ops::function::FnOnce::call_once
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/core/src/ops/function.rs:507:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
Las garantías estáticas de Rust no van de que tu programa nunca vaya a cascar - cualquiera puede hacer un programa que casque. Lo que no vas a poder hacer, al menos sin meter a propósito código que sea inseguro (y esté declarado como tal) es tener carreras (races) entre hilos, ni utilizar memoria una vez liberada, por ejemplo.
Si usas OpenBSD y chromium y a este último le hacen un overflow, ¿no podrían acceder a los datos guardados en el propio chromium sin acceder al sistema?
¿Con esto te podrían robar cookies de sesión, o contraseñas guardadas (si no tienes habilitado algo que proteja esas contraseñas con otra contraseña) o incluso manipular tu navegador para que haga alguna acción desde tu navegador (crear una cuenta en alguna interfaz web, usar tu sesión para robar datos, por ejemplo del repositorio)?
Como os veo metidos en esto de la seguridad, a ver si me podéis ayudar con una duda estúpida:
El otro día hablaba con un amigo sobre si cifrar el .env de un proyecto de django y yo argumenté que si alguien te entra por la propia instancia de django, será capaz de leer la clave de descifrado almacenada en un archivo del propio proyecto (manage.py), con lo que el único motivo para cifrar eso es que alguien pueda desde tu sistema operativo leer ese archivo, pero de nuevo, si pueden leer ese archivo podrán leer manage.py y decifrar el .env.
Solo te sirve para poder subir el .env a un repositorio público, y para que sea eficaz tienes que poner el manage.py en el git ignore para que no suba la clave de decifrado. Con lo cual seria mejor poner el .env en el git ignore y dejar el manage.py ya que contiene una información más útil para el proyecto (como qué fuentes de datos usas, que pueden ser varias) y sin exponer ningún dato crítico (ip, puerto, usuario y contraseña).
Vamos, que no sirve de nada cifrar un archivo cuando quien pueda leer el archivo también va a poder leer el que lo decifra.
Perdonad el offtopic pero me he puesto a pensar, OpenBSD puede ser todo lo robusto que quiera, pero al final, solo hace falta permisos de ejecución de la propia aplicación para hackear los datos de esa aplicación, los permisos del sistema sería más para tema de ramsonware o virus.
Es que no entiendo como funciona el overflow, pensaba que era básicamente "colgar" un software para "prácticamente" permitirte lanzar código "no autorizado" en un sistema, aunque sean con permisos del mismo software.
Hay que tener en cuenta el 70% de los parches de seguridad de Windows provienen de errores de memoria que se habrían evitado con Rust.
Y, en el otro extremo, el de los haters de C++, también hay movimientos importantes. Rust se va a convertir en el segundo lenguaje oficial para el kernel de Linux. Hasta ahora sólo C tenía ese privilegio.
No es cierto. Tanto Python como Java suelen compilarse a bytecode. Java también se compila a código máquina en algunos entornos.
El que sí compila a C es Cython, un superset de Python.
Ver un mensaje de stack overflow es una advertencia del compilador o del entorno de ejecución que no deja seguir el stack overflow.
En ese sentido se para el stack overflow, que sino resultaría en un crash irrecuperable, y no una ventanita que para el programa y te dice porque. Rust y C se pueden ejecutar en un OS que no tenga protección contra el stack overflow.
En Rust te ha salido una advertencia por lo menos :
warning: function cannot return without recursing
--> src/main.rs:1:1
|
1 | fn overflow() {
| ^^^^^^^^^^^^^ cannot return without recursing
2 | overflow();
| ---------- recursive call site
|
= help: a `loop` may express intention better if this is on purpose
= note: `#[warn(unconditional_recursion)]` on by default
warning: `playground` (bin "playground") generated 1 warning
play.rust-lang.org/?version=stable&mode=debug&edition=2018&
La buena práctica es cargar la configuración a partir de variables de entorno. Los archivos no les gustan mucho a los sysadmins.
Aquí hablan, entre otras cosas, sobre cómo configurar un server.
12factor.net/
Más que el lenguaje en sí, entiendo que la cualidad de Rust reside en cómo compila el código.
Para la sincronización y creación de temporizadores se emplea el reloj monotónico, que se reinicia junto al dispositivo, sobre todo en microcontroladores como los que comentas que ni siquiera suelen disponer de reloj de tiempo real (RTC). Además, estos dispositivos suelen sincronizarse con el entorno mediante E/S vía sensores y no mediante reloj.
La mayoría, por no decir la totalidad de los dispositivos que comentas no tienen ni siquiera conectividad a internet, donde es importante tener el RTC sincronizado exclusivamente por temas de cifrado de canal (SSL/TLS), que es donde interviene el reloj de tiempo real ya sea en HTTPS o túneles SSH. En TCP existe una cabecera timestamp que emplea el RTC, pero es opcional y la gran mayoría de sistemas hace caso omiso de esta, o la cumplimenta por dar compatibilidad pero no la revisa.
A mi sinceramente se me ocurren pocos sistemas críticos que dependan de un RTC y no puedan ser actualizados. Si algún sistema de 32 bits está haciendo de servidor NAS, SQL o HTTP, o incluso empleado como switch de red, tiene pinta de que va a ser un embebido cutre doméstico de mediados de 2010, con lo que en 2035 deberían estar más que muertos.
Desde 2020 cualquier linux tiene time_t de 64 bits, por lo tanto, el gran problema no parece que vaya a ser tan grande, más bien un problema de algunos gadgets a domésticos.
Perdona, se que las comparaciones son odiosas - pero el Cobol es como jugar al Mario Bros en su conceptualización
www.archdaily.com.br/br/782588/papel-quadriculado-a-origem-de-super-ma
No es ese el problema de la vulnerabilidad de desbordamiento de buffer.
Ahí lo único que ocurre es que llenas la pila. La vulnerabilidad consiste en desbordarla para sobreescribir datos guardados aprovechando variables creadas en la pila
Tachán!!
El caso que expone el compañero es una función recursiva sin caso base, cosa que Rust no es capaz de identificar.
Según las condiciones del sistema y problema puede producirse stack overflow incluso con la definición de un caso base, si como dice el compañero, la profundidad es grande ya que no se puede conocer de antemano. Por ejemplo en un gran grafo, o incluso en uno pequeño con un bucle (A-B-A-B...) si la función no ha sido pensada adecuadamente.
Jamás adivinarías en qué está desarrollado BSD...
Ahora Microsoft vuelve a las andadas con Power FX, que será programar usando las fórmulas de Excel.
Es posible que se pueda "compilar" a C Java, Python, Rust o lo que te dé la gana..... Si tienes un "compilador" que lo haga.
Java en Linux por ejemplo tiene un compilador a código máquina nativo (no a C)
Hago cosas muy importantes, muy sensibles, vuestra vida depende de mi, se más que todos vosotros juntos pero eh, no puedo decir nada, acuerdo de confidencialidad.
O es un invento o es un inconsciente
Pasate a Rust, cada vez somos más.
Tras leer de momento un trozo del artículo ya me surge una pregunta por el problema de la gestión y limpieza de la memoria: ¿Y no hay ningún software o incluso IA que sea capaz de corregir esos problemas al final de la fase de escritura del código fuente y una vez limpio este entonces compilar?
Es un código muy simple y por eso sale el warning.
es.m.wikipedia.org/wiki/Problema_de_la_parada
En concreto, este párrafo:
_Lo que se afirma es que no existe una manera automática computable de saber si todos los programas posibles terminan. No se niega que exista la prueba para programas concretos. De hecho, la construcción de pruebas para programas concretos es un paso obligatorio para demostrar su correctitud._
Con lo que, o limitas los programas que se pueden escribir (en el caso de Rust mediante reglas sobre qué código es el propietario de qué regiones de memoria, y qué referencias pueden existir a esa memoria en un momento dado), o, post-facto, sólo podrás eliminar un porcentaje (mayor o menor) de los problemas.