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
Que las empresas se hagan cargo de las infraestructuras clave de un país y que ellas decidan en post del mercado si deciden invertir unos millones en mantenimientos o dejarlo estar para ahorrarse ese dinero y aumentar sus cuentas… a ver si a los inversionistas no les gusta eso de gastar dinero y venden sus acciones…
EEUU y el tema de gasto en infraestructuras es una locura, todo lo que sea gastar en mantenimiento o nuevas es comunista.
#9 esto es otro ejemplo de lo que sucede si dejas a las empresas decidir y tener una legislación suave.
#25 ¡Hola!, que conversación tan interesante. He trabajado más de 20 años en programación de RTS y embebidos, os cuento mi visión por si a alguien le fuera de interés.
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.
#12 Tío, ese error no es a nivel compilador, sino en runtime (es decir, el código debe haber entrado en el flujo correspondiente para que se den las condiciones), y está generando un coredump...
#32 y así, con un simple comentario, te acabas de marcar como objetivo ante cualquiera de la comunidad que pueda tener interés en "datos especialmente sensibles"... en una página poco segura (no es la primera vez que las bases de datos de mnm caen) y aumentado tus posibilidades de que te hagan un doxxing guapo para ver quien eres, a que te dedicas y si puedes ser un vector de acceso a lo que quiera que haces/tocas
#8 por curiosidad, dices que eres de los que reclaman. Aparte de decírselo al encargado, ¿cómo reclamaste? Me habría gustado saberlo cuando trabajaba para una eléctrica que tampoco se tomaba en serio la PRL.
#30 No, no se lía. Pledge lo va a mandar a ATPC si intenta abrir una syscall. Pledge es implícito, no es explícito com Selinux en Linux. En OpenBSD si un programa compilado con pledge intenta acceder a una syscall el kernel le va a mandar un sigabrt bien guapo.
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.
#29 Creo que eres tú el que no entiende lo que es un overflow de pila Ni lo que hace Rust. Ya te he puesto un código trivial que te demuestra un programa en Rust que el compilador se traga sin problemas y que en ejecución casca con un stack overflow.
#16 Sobre CHrome, el Chromium de OpenBSD usa pledge y unveil por defecto, y no tiene WASM activado de serie. /etc/login.conf tiene limites de procesos y uso de memoria que o se aumentan o el software casca que da gusto.
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.
#22 A ver: El error me sale al ejecutar el programa compilado con Rust.
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.
Ni lo que hace Rust. Ya te he puesto un código trivial que te demuestra un programa en Rust que el compilador se traga sin problemas y que en ejecución casca con un stack overflow.
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