¿Cuál es el código más peligroso jamás escrito?

Creo que por pura simplicidad peligrosa, es difícil vencer a la Bomba Tenedora.

Bomba tenedor

Un código de autorreplicación que se puede escribir de manera increíblemente simple en casi todos los lenguajes de programación y detendrá la mayoría de las máquinas en muy poco tiempo debido a la naturaleza del aumento exponencial.

Aquí está en C. básico. Todo lo que hace el programa es crear otro programa, una y otra vez hasta que todos los recursos se extingan, generalmente simplemente llenando la tabla de procesos del sistema operativo.

#include

int main (nulo)
{
mientras que (1) tenedor ();
}

Como se señaló en el ejemplo de Wikipedia, el uso cuidadoso de ulimits para usuarios no root en máquinas * nix puede ayudar a proteger contra esto.

EDITAR:

Ah, sí, guarde todo su trabajo antes de intentar ejecutar cualquiera de estos ejemplos … es posible que se sorprenda de lo rápido que lo bloquean. (No, en realidad, no me molesté la primera vez que lo intenté, y lo lamenté).

EDITAR 2:

Como lo señala la respuesta del usuario de Quora a ¿Cuál es el código más peligroso que se haya escrito? Por supuesto, hay muchas definiciones de “peligroso” y señala un ejemplo directamente a la vida y las extremidades.

Otro ejemplo de código en su mayoría peligroso involuntariamente es el humilde error Off-by-one, que es probablemente una de las causas más comunes de fallas de seguridad en el software moderno. Aquí es donde los programadores no prestan suficiente atención a la extensión de la memoria que han asignado, o no protegen sus límites correctamente y alguien puede (accidental o deliberadamente) inyectar bytes donde no deberían estar, con errores impredecibles resultantes o fallas, o potencialmente explotaciones completas de la máquina host.

SSL (Secure Sockets Layer) es el estándar de facto para las comunicaciones seguras de Internet. La seguridad de las conexiones SSL contra un atacante de red activo depende de validar correctamente los certificados de clave pública presentados cuando se establece la conexión. Demostramos que la validación del certificado SSL está completamente rota en muchas aplicaciones y bibliotecas críticas para la seguridad. El software vulnerable incluye la biblioteca Java EC2 de Amazon y todos los clientes de la nube basados ​​en ella; Los SDK de comerciantes de Amazon y PayPal responsables de transmitir detalles de pago desde sitios de comercio electrónico a pasarelas de pago; carritos de compras integrados como osCommerce, ZenCart, Ubercart y PrestaShop; Código de AdMob utilizado por sitios web móviles; Chase banca móvil y varias otras aplicaciones y bibliotecas de Android; Middleware de servicios web Java, incluidos Apache Axis, Axis 2, Codehaus XFire y la biblioteca Pusher para Android, y todas las aplicaciones que emplean este middleware. Cualquier conexión SSL de cualquiera de estos programas es insegura contra un ataque de hombre en el medio. Las causas principales de estas vulnerabilidades son API mal diseñadas de implementaciones SSL (como JSSE, OpenSSL y GnuTLS) y bibliotecas de transporte de datos (como cURL) que presentan a los desarrolladores una confusa variedad de configuraciones y opciones. Analizamos los peligros y las dificultades de la validación de certificados SSL en software basado en estas API y presentamos nuestras recomendaciones.

El software en esta bolsa negra es posiblemente el más peligroso del mundo porque si funciona mal, podría incinerar a millones y conducir a una nueva era oscura de la humanidad.

Es el fútbol nuclear y muy pocas personas conocen los detalles técnicos, por una buena razón. Y nadie dará esa información pública o privada, por razones igualmente obvias.

Sin embargo, podemos inferir (y esperar) que se trata de un código muy libre de errores que se ejecuta en un hardware muy resistente. Sin embargo, cualquier código que detecte si se presiona o no un botón y / o se gira la tecla para luego enviar una señal para poner fin al mundo sigue siendo solo … un fragmento de código. Un código muy, muy peligroso.

En junio de 2010, Stuxnet, el gusano malicioso, fue detectado por primera vez por los ingenieros de Symantec. El código no robó contraseñas ni eliminó archivos. Buscó una pieza de hardware particular utilizada en instalaciones clave como petróleo y gas, tratamiento de agua, instalaciones eléctricas y plantas de energía nuclear. ~ Fuente: ver video documental a continuación.

Extracto : se dice que el gusano informático altera la velocidad de cierto ventilador centrífugo que pertenece a una instalación de enriquecimiento de uranio en Irán. Según los informes, el código era tan sofisticado y tortuoso que podía ocultar sus actividades a los técnicos de la planta, justo debajo de sus narices.

Consecuencias nefastas . Hemos visto lo que sucedió si algo (o algo) salió mal dentro de una planta nuclear. Lea Chernobyl: Cronología de una pesadilla nuclear.

¿Quién hizo Stuxnet? ¿Stuxnet sigue hibernando en otras plantas nucleares de otros países? ¿Podría usarse también como puerta trasera en otras máquinas?

[matemáticas] \ color {azul} {\ require {cancel} \ cancel {\ color {red} {\ require {cancel} \ cancel {\ color {green} {\ text {Is there}}}}}} [/ matemáticas] ¿Dónde está Stuxnet “2.0” al acecho?

En primer lugar, nunca asuma que ha descubierto cuál es el código más peligroso conocido por el hombre. Eventualmente, alguien tomará esas expectativas y solo dirá “no”. Aparte de eso, depende, como lo han dicho muchas personas mejor que yo, de su definición de peligroso. Si está hablando de habilidades destructivas puras y no adulteradas del software real, tenemos la bomba de horquilla defendida por el Sr. Turner. Francamente, la mitigación de la cosa ya se ha convertido en el foco de algunos grupos en este momento.

Si estamos hablando de representar un peligro claro y presente para el mundo al afectarlo físicamente de una manera destructiva, tenemos el código fuente que entra en drones, misiles y varios otros implementos militares de muerte. Eso, o gusanos como Stuxnet que han demostrado ser capaces de destruir la infraestructura.

Por otro lado, tenemos nuestras incursiones actuales en aprendizaje automático e inteligencia artificial, que han demostrado ser bastante difíciles de predecir e implementar de una manera no destructiva garantizada. Por ejemplo, un programa codificado para jugar Tetris había logrado explotar sus instrucciones al pausar el juego y, por lo tanto, evitar una pérdida. Ampliando el concepto a algo un poco más crítico, tenemos la posibilidad de algo similar a HAL en la vida real, aunque eso aún está por verse.

El Therac-25 mató al menos a 5 personas, sobredosándolas con radiación. Por lo general, se cita en la industria informática cuando se discuten errores en el código, pero lo más importante, desde mi punto de vista, es la ética del diseño de sistemas que fallan de manera segura. Este sistema carecía de estas características, y las personas murieron como resultado.

Se menciona en el artículo vinculado en la respuesta de Pier-David Morel, pero pensé que debería discutirse específicamente.

Alguien por ahí escribió el sistema de navegación para ICBM autoguiados que llevan cargas útiles termonucleares. El código está clasificado y nunca lo verá a menos que algún día se le cobre el mantenimiento. Es probablemente el único software que puede causar de manera realista la extinción de la raza humana en unos pocos días. Definitivamente algo en lo que no puedes tolerar errores, y no puedes probarlo en el campo.

En un proyecto anterior, enfrentamos un problema peculiar. Se suponía que el código indexaría miles de páginas. El servidor se apaga automáticamente después de indexar alrededor de cien. Nos volvía locos por unas horas, el equipo estaba revisando los tamaños de las pilas, las colas de mensajes, etc. El culpable era una línea de código en un frasco de terceros (apache).

System.exit !! En un bloque catch de IOException, hubo System.Exit !! Increíble

¡Una línea de código aparentemente no traviesa puede crear grandes problemas si forma parte de sistemas críticos!

La base de código de Facebook, específicamente su algoritmo de filtrado anteriormente conocido como Edgerank.

En pocas palabras: lo que ves, obtienes más. Esto le da una capacidad incomparable para empujar a las personas que tienen una tendencia hacia cosas como el racismo, el terrorismo, etc., más adelante en el camino en el que se encuentran hasta que finalmente hacen algo muy desagradable.

1983 incidente de falsa alarma nuclear soviética – Wikipedia

El 26 de septiembre de 1983, el sistema de advertencia de misiles soviéticos informó que Estados Unidos había disparado algunos ICBM hacia los soviéticos.

Afortunadamente, la persona a cargo, Stanislav Petrov – Wikipedia, decidió que era un mal funcionamiento de la computadora, y desestimó los informes, en lugar de confirmarlo. El software de la computadora no estaba preparado para un caso de esquina al analizar las entradas del sensor, y las interpretó erróneamente como lanzamientos de misiles.

La respuesta normal de acuerdo con los procedimientos sería una represalia total, lo que provocaría la devolución del favor.

Cualquier error de software que incite a un intercambio completo de armas nucleares debería estar arriba en la parte superior.

Originalmente consideré el error Heartbleed, pero no, consideraría que fácilmente el código más peligroso es la referencia Null. Para los no programadores, nulo permite que los valores sean nada en lugar de 0; o nada en lugar de un conjunto vacío.

Un valor de Nulo puede pasar desapercibido cuando se escribe el software. Este es el momento en que se ejecutan la mayoría de las pruebas para garantizar que el código esté libre de errores. Cuando nulo rompe las cosas, generalmente sucederá cuando el código se esté ejecutando y este es el momento en que la falla puede causar el caos. Piense en cuántas máquinas dependen de las computadoras. La gente entró en pánico por el error Y2K, pero eso solo iba a estropear las computadoras que se preocupaban de qué año era. Las excepciones en torno a Null conciernen a todas las computadoras, ya que ha proliferado en casi todos los lenguajes de programación populares.

Tony Hoare fue el inventor del primer idioma en usar explícitamente Null y ahora lo considera como “su error de mil millones de dólares” y quizás el peor error de la informática: el peor error de la informática – Lucidchart

Nulo a menudo no tiene sentido: si tengo una función “getAddress ()” que acepta el nombre de una persona, ¿qué se supone que significa si devuelvo Nulo? Podría devolver un conjunto vacío o tal vez incluso un token que he definido como “dirección desconocida”. La excepción de puntero nulo ocurre cuando quien obtiene esta dirección intenta obtener la dirección para hacer algo, pero esta dirección en realidad no fue nada . Es totalmente posible tener un lenguaje sin Null, pero el paradigma se ha extendido tanto y hay tantos programadores autodidactas (que están influenciados inherentemente para que simplemente acepten las cosas) que Null ha causado una cantidad asombrosa de problemas con el software en ejecución. , así como retrasos en la escritura y las pruebas.

Un estudio de 2002 estimó que los errores de software cuestan solo a los EE.UU. $ 59.5 mil millones anualmente: NIST evalúa las necesidades técnicas de la industria para mejorar las pruebas de software

Editar : Gracias Clinton Chau por notificarme que es una broma, como lo demuestra el nombre del autor “Ray F. Piodasoll” que es un anagrama del “Día de los Inocentes”, y el título de la lectura del artículo ” pero ocasionalmente escribe artículos destinados a se publicará en abril, hacia principios de mes. “. Perdón por perder eso (y no buscar en la web el nombre del autor en la web antes de publicar). La “respuesta” se dejará aquí para recordarme a mí y a otros de la falla.

Original (sin respuesta):

Leí este de Ray F. Piodasoll en un libro titulado “Lo mejor de Perl Journal”: “Perl y las armas nucleares no se mezclan”. El siguiente extracto es la clave:

Lamentablemente, mis ex empleadores no quieren que hable sobre mi trabajo: sistemas de software para calibraciones de vuelo de misiles. Pero algunas historias deberían estar bien, ya que creo que le contarán más sobre Perl que sobre la seguridad nacional. No quiero alarmar a nadie por lo que sigue, pero debes saber cuán cerca estuvimos de un armagedón nuclear debido a mi malentendido de los conceptos básicos de Perl. Lo siento.

Wow … y el problema es la simple asociatividad del operador …

$ empuje = $ rho * $ A0 * (2 * ($ p- $ p0) / $ rho) ** $ expo ** 2);

¿Ves mi error? Si es así, hay un trabajo para usted en el aseguramiento de la calidad de la aviónica, suponiendo que todavía tengamos computadoras después de errores como estos que precipitan la era posterior al Holocausto.

Aquí está el problema: el operador ** es asociativo a la derecha. (Ve a buscarlo en la documentación de perlop si no me crees). Lo que esto significa es que

$ a ** $ b ** $ c

no es equivalente a

($ a ** $ b) ** $ c

como había supuesto, pero

$ a ** ($ b ** $ c)

Ese es un gran problema cuando su $ a, o 2 * ($ p – $ p0) / $ rho en mi código, es de aproximadamente dos millones, su $ b es 0.52 y su $ c es 2. Perl termina en desacuerdo con la física por un factor de más de cuatro, y en tales batallas la física gana. Este error no se detectó ya que mi código Perl se tradujo a C usando el compilador Perl, de C al código de máquina, y luego se quemó en EPROM de misiles. Seis semanas después, los misiles fueron enterrados en sus silos con sistemas de guía inercial basados ​​en mi código. De haber sido despedidos, habrían perdido su destino por miles de millas.

¿Qué tan malo es? Así es como lo expresa el artículo:

Un error de tan solo una centésima parte del porcentaje es la diferencia entre nivelar una ciudad y una granja cercana; un error de una décima parte del porcentaje es la diferencia entre Bagdad y Haifa; Un error del diez por ciento es la diferencia entre el Polo Norte y Boston.

¿Fuera por un factor de 4? Creo que es mejor que disparar al azar solo porque es determinista. Ciertamente no es divertido.

El gusano de internet.

http://groups.csail.mit.edu/mac/ …

Los programas autorreplicantes se conocían antes de esa época, pero nunca habían alcanzado este tipo de escala. Este fue el momento en que la gente se dio cuenta de que la seguridad realmente importaba. Antes de eso, nadie realmente se molestaba tanto.

Hay muchos ejemplos de personas que no se molestan en el libro de Hugo Cornwall “The Hacker’s Handbook”, que salió en la década de 1980. No era tanto un manual como una colección de fallas completas y completas en seguridad. Una de las historias clave que inspiró Wargames recibe una mención.

De todos modos, no considero que ningún software escrito después de esta fecha sea “peligroso” porque, después de esta fecha, el público en general apreció adecuadamente el costo de la falla. Por un momento. Por lo tanto, todo el software que causa daño después de esta fecha lo hace por negligencia y a pesar de saberlo mejor.

Incluso los virus polimórficos y las botnets zombis modulares explotaron el elemento humano ya que el elemento tecnológico ya era obsoleto y golpeado antes de que emergieran.

Creo que el grado de daño que puede hacer un código depende del tamaño del código. Si está buscando una sola pieza de código que sea más peligrosa, que yo sepa, es rm-rf con el permiso suficiente.

Puede eliminar toda su empresa de un solo uso de rm-rf . Esto es realmente cierto, un hombre accidentalmente ‘elimina a toda su compañía’ con una línea de código incorrecto. Esa mala línea de código era rm-rf .

Posiblemente el error sangriento de 2014:

/ * Tipo de lectura y longitud de carga útil primero * /

hbtype = * p ++;

n2s (p, carga útil);

pl = p;

Este es el código de OpenSSL, la biblioteca de cifrado en muchos sitios web. Un error en esto significa que los piratas informáticos pueden enviar una carga útil especializada al elemento con una carga útil de un byte, pero mienten y dicen que es 64 KB. Luego, la computadora del victem envía un paquete, pero ahora ha copiado 64 KB de su memoria interna en la carga útil. Esto podría incluir contraseñas, claves de cifrado y mensajes descifrados. Alrededor del 17 por ciento de los sitios web de confianza se vieron afectados.

Aquí hay uno que no se puede mostrar porque no cabe en una pantalla, que era el problema. John Chapin, de Capital Technology Services, habló de un controlador Ruby on Rails que reunió a todos los clientes en un número determinado de días y luego realizó un procesamiento.

“Cada vez que se ejecutaba la consulta, pasaba por una tabla completa de 250,000 registros unas 20 veces”, tomaba dos minutos, dijo. El problema era que el método estaba todo en una línea y era tan largo que nadie podía analizarlo. Reformatear y cambiar las claves de la tabla eventualmente redujo el tiempo de carga a 10 segundos.

Si pudieras leer esta línea de código, entonces no sería un problema.

De este artículo, recién publicado: 21 piezas de código peligrosas y errores de programación

El código más peligroso jamás escrito es el que lo está infectando en este momento o el que se puede escribir para esa vulnerabilidad que un parche de software disponible podría solucionar, pero es viernes y el parche significaría un sábado de trabajo. Nadie va a escribir una hazaña antes del lunes ¿verdad?

Pero para la sociedad en su conjunto, diría que Stuxnet y sus variantes son las más peligrosas. Todo lo que convierte a la civilización tal como la conocemos puede verse afectada por los virus PLC / SCADA. Generación y transmisión de energía, tratamiento de agua, sistemas de alcantarillado, construcción de HVAC y elevadores, generadores de respaldo hospitalarios, ferrocarriles (aproximadamente el 40% de los subterráneos de Nueva York funcionan con sistemas basados ​​en SCADA, lo sé porque trabajé en ellos).

Pero eso sigue siendo teórico, la realidad siempre será más personal. Como dice el dicho P: ¿Cuál es el animal más peligroso del mundo? A: El que te ha mordido.

¿Alguna vez borraste datos accidentalmente? Debe haber tenido algún software de recuperación para recuperarlos. Porque eliminar generalmente significa marcar ese bloque de datos como gratuito, pero sus datos aún están allí. Ahora intente (lea: no intente) lo siguiente

sudo dd if = / dev / zero of = / dev / sda

Lo que esto hace esencialmente es poner a cero su disco duro. A diferencia de eliminar lo que marca su bloque de datos como libre, esto los llenará a todos con ceros.

Esto es útil cuando vende su computadora portátil.

Si considera la consola DOS como codificación … lo cual es estrictamente porque no programa exactamente (en la) DOS (consola) sino que la codifica, el código más peligroso sería:

C:> FORMATO C: {agregar argumentos sin solicitud}.

Ni siquiera estoy seguro de que ESTA respuesta nunca llegue a un contexto donde dicha instrucción se interpretará incondicionalmente, y si lo hace, ¡simplemente perderá todo en su máquina! Entiendo que una vez iniciado, afecta la raíz del formato de la unidad, por lo que todo lo demás se convierte, localmente, en basura, incluso si interrumpe la operación. Eso es código, no un programa, y ​​nunca lo he usado antes de las tarjetas SD e incluso entonces me quejo cuando lo hago. Pero conceda que si habla errores, los que comete con MOVE y DEL pueden ser tan asquerosos, lo que los hace realmente muy peligrosos porque puede implementar fácilmente un FORMATO ligero con esas instrucciones y esas son instrucciones más típicas en la consola y los archivos por lotes . DOS, nadie?