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 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!
Aquí lo dejo que no vamos a llegar a nada.
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...
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.
fn overflow() {
overflow();
}
fn main() {
overflow();
}
thread 'main' has overflowed its stack
fatal runtime error: stack overflow
Aborted (core dumped)
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.
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.
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.
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.
Rust no te deja compilar si hay desbordamientos
#24 procede a demostrar que ha compilado un código que provoca desbordamiento
…
No entiendes que es desbordamiento, los ingenieros tampoco lo comprenden, solo yo lo entiendo…
entre esto y el rollo espía de la KGB que traés con tu curro no se puede ser más patético jajajaj reconozco que me has alegrado la mañana ehhh
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
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.
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
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.
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.
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.
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.
Lo siento no tengo ni idea.
¿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...
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.
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...
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.
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
¿Deutsche? Crecieron mucho en sistemas medios, usando Java, C, y hasta COBOL, que sólo atacan al mainframe (Frankfurt) a base de CICS. El batch sigue siendo el de siempre, que lo van manteniendo a base de sustos y lloros.
Cuando aparecí por Deutsche había mucha gente que me conocía, algunos de Catalana, pero también otros de haber pasado por Caixa, y aún a algunos les sonaba de verme en la máquina de cerveza en el edificio de Sant Cugat. Este es un mundo pequeño.
¿Qué? No.
Todoterrennos verdaderos eran los ultimos que llevaban chasis y carroceria separada, pero hasta el defender se ha pasado al monocasco.
#6 Creo que los F-35 tuvieron un problema de cambio de hora al sobrevolar la zona del pacifico donde se pasa de un dia a otro. Yo pienso que seria facil evitar esto usando UTC, para las cosas que necesitan una hora consistente y luego la represetancion la adaptas a la zona horaria.
#13 Yo entiendo que el problema es la implementacion en sofware y que el SO sea de 32bit deberia ser poco relevante. Es un problema previsible y añadir otro byte, no cuesta nada.
El hardware creaba el problema de que la bios no sabia representar al 2k. Pero por sofware, se puede suplir sabiendo que el punto de partida ya no es 1980, por ejemplo.
HAbia programas que lo hacian en el arranque, cuando no habia internet permanente ni NTP estaba extendido.
#25 OK, entiendo que aunque el problema puede ser facil de solucionar, hay muchos sistema que pueden haberse olvidado de un problema que dará la cara dentro de decadas.
eltamiz.com/elcedazo/author/macluskey/
Creo que tiene un libro de Historia de un Viejo informatico.
eltamiz.com/elcedazo/2009/03/31/historia-de-un-viejo-informatico-la-ir
#68 #66 Eso entiendo yo que las gestion de memoria en C no tiene "topes" y si te sales, puede acabar en otra zona de memoria y si puede elegir donde, meterte en otras zonas y hacer cosas no previstas.
En pascal, creo que el BIt 0 tiene la longitud del array y en Rust, no se como evitar salirte de la memoria asignada.
#45 No responte tu pregunta. Pero Qmail tiene un diseño en dos partes. Una pequeña y sencilla y facil de vigilar conectada a internet y el resto de programa que se conecta a internet a traves de la anterior y solo le va a dejar acciones concretas. Ofrecen recompensa a quien encuentre un bug que les de acceso.
en.wikipedia.org/wiki/Qmail
Por otra parte yo seria partidario de limitar los permisos al minimo a los programas, no solo a todo el usuario.
Un word, necesita aceso a ficheros temporales y un sitema de guardar los archivos que se puede delegar en otro programa asegurado.
Un firefox parecido y se podria limitar lo que puede tocar en el disco duro y las acciones que pueda hacer por internet.
Seria interesante una recopilacion de mentiras de ChatGPT.
#102 En trading de alta velocidad la latencia es muy importante, contrataron a un desarrollador del nucleo de linux.
Puede que Rush podria tener alguna utilidad.
Hay aplicaciones forenses para el Rush, como una aplicacion que gana por ejemplo a Python.
yewtu.be/watch?v=hhRM-D5xn60
#107 A que te refieres?
Rust se compila a un pseudo-ASM/esperanto LLVM y de ahi se compila al ASM/codigo maquina de cada arquitectura( x86, arm, microcontroladorres, etc) .
Parece que Rust es un lenguaje para nenanzas, lo que puede generar una cooperacion positiva. Tal vez se estudia poco la sociologia del desarrollo de sofware.
Mientras tanto, la comunidad de Rust también fue construyendo una cultura conocida por ser amistosa y abierta a los recién llegados. "Nadie te llama nunca novato. Ninguna pregunta se considera estúpida", dice Nell Shamrell-Harrington, ingeniera principal de Microsoft que, por aquel entonces trabajaba en Rust en Mozilla.
Shamrell-Harrington explica que esto, en parte, se debe a que Hoare publicó muy pronto un "código de conducta", que prohibía el acoso, y se esperaba que cumpliera cualquiera que contribuyera a Rust. La comunidad lo aceptó y, según los miembros más veteranos de la comunidad Rust, por ello los programadores queer y trans se involucraron en Rust en mayor proporción que en otros lenguajes. Incluso los mensajes de error que crea el compilador cuando el programador erra son cuidadosos: describen el error, y sugieren amablemente cómo solucionarlo.
"Cuando cometo errores, los compiladores de C y C++ me hacen sentir como una persona terrible. El compilador de Rust es como si te guiara para escribir un código muy seguro", admite Shamrell-Harrington riendo.
Cuando trabajas con alguna placa de evaluación o un SoC de algún fabricante, este te ofrece un SDK (compilador, librerías para ese HW, etc...), y en entornos empresariales no se suele usar gcc/clang para producto final. ¿Existe algún SDK de algún fabricante que ofrezca Rust? A eso me refiero.
Ese 1% es suficiente para que se lie bien gorda.
Tampoco Rust lo va a solucionar todo , eso esta claro .
Luego si lo encuentro te lo paso .
Rompo un lanza en tu favor diciendo que yo pensaba igual que tu.
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.
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.
Tanto el intérprete de python como la máquina virtual de Java están hechos en C++.
La implementación oficial de Python, CPython, está escrita en C, no en C++, pero también existen implementaciones en otros lenguajes, como PyPy (escrita en RPython, un subset de Python). Por otra parte, existen compiladores y máquinas virtuales de Java escritos en diferentes lenguajes: C, C++, Java, Smalltalk...
Otra cosa es que ambos sean JIT que convierten Java/Python a código máquina sobre la marcha.
Nope. Lo que se convierte a código máquina sobre la marcha es el bytecode, no el código fuente. Y CPython no incluye JIT, otras implementaciones como PyPy o Jython sí.
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.
Los dos primeros bytes
Jamás adivinarías en qué está desarrollado BSD...
Si no llega a ser por los BSD a ver qué tendríais de pila de red, de conexiones seguras, de ciertas implementaciones de seguridad pioneras en OpenBSD y muchas cosas más.
Sobre GNU GCC vs Clang, no he visto cosa que devore más RAM y CPU salvo Chrome. Compilar algo en equipos modestos usando GCC es imposible. Luego normal, han probado compilaciones cruzadas pero no nativas y todo casca que da gusto.
No hay más que ver los bugs gordos que estoy viendo en algunos equipos con GNU/Linux X86 (y sin GNU) vs su contraparte en OpenBSD donde todo funciona sin tener segfaullts porque a esos desarrolladores Rockstar se la sudan los equipos usándo código de 32 bit totalmente funcional. Y hablo de algunos Celeron aún usados, y muchos Atom de 32 bits, no algo verdaderamente básico como un Pentium 4 con SSE2.
P: ¿en qué lenguaje de programación se comenzó a desarrollar Rust?
R: El lenguaje de programación Rust fue inicialmente desarrollado en el lenguaje de programación C++, aunque luego se reescribió en Rust a medida que el lenguaje se fue desarrollando. Rust se inició como un proyecto interno de Mozilla Research en 2006 y fue presentado públicamente en 2010. Desde entonces, Rust ha sido desarrollado de forma abierta y colaborativa por una comunidad global de desarrolladores.
Ahora Microsoft vuelve a las andadas con Power FX, que será programar usando las fórmulas de Excel.
Pasate a Rust, cada vez somos más.
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)
Ahora bien, si tienes una Debian Lenny o Squeeze de la época, pues allá tu.
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.
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/
Es un código muy simple y por eso sale el warning.
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&
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!!