Oracle quiere que dejes de enviarles errores aquí es por qué eso es una locura

Oracle quiere que dejes de enviarles errores aquí es por qué eso es una locura / Seguridad

Oracle está en el agua caliente esta semana en una publicación de blog escrita por su jefe de seguridad, Mary Davidson. La publicación, aunque cubre una variedad de temas, trata principalmente sobre la práctica de informar posibles vulnerabilidades de seguridad a Oracle. Específicamente, por qué no deberías.

“Recientemente, he visto un gran aumento en el número de clientes de ingeniería inversa de nuestro código para intentar encontrar vulnerabilidades de seguridad en él.. Por eso he estado escribiendo muchas cartas a clientes que comienzan con “hola, howzit, aloha” pero termina con “cumpla con su contrato de licencia y deje de aplicar ingeniería inversa a nuestro código, ya.”

Davidson explica que hay un número cada vez mayor de clientes preocupados por la seguridad que utilizan el software Oracle de ingeniería inversa en busca de vulnerabilidades de seguridad (o contratan consultores para que lo hagan por ellos). Davidson acusa a estos clientes de violar sus acuerdos de licencia, de no tomar precauciones de seguridad mundanas, de tratar de hacer el trabajo de Oracle por ellos y de ser en general personas malas. Si el cliente ha encontrado una vulnerabilidad real, mientras que Oracle la arreglará.

“Casi odio responder a esta pregunta porque quiero reiterar que los clientes no deben y no deben aplicar ingeniería inversa a nuestro código. […] No le daremos a un cliente que informe un problema de este tipo (que encontraron a través de ingeniería inversa) un parche especial (único) para el problema. Tampoco proporcionaremos crédito en los avisos que podamos emitir. Realmente no puedes esperar que digamos “gracias por romper el acuerdo de licencia.””

Esto hizo no revise bien en la comunidad de seguridad, y la publicación fue eliminada rápidamente, aunque no antes de generar un nuevo hashtag Activación Hashtag: #powerful or #pointless? Hashtag Activismo: #powerful or #pointless? #BringBackOurGirls, #ICantBreathe y #BlackLivesMatter han visto una amplia cobertura internacional en el último año, pero ¿son las etiquetas un medio eficaz de activismo? Lee mas .

"Verifique primero el EULA de Enigma" dijo Alan Turing. #oraclefanfic

- Thorsten Sick (@ThorstenSick) 11 de agosto de 2015

Pero, si no estás familiarizado con el mundo de la seguridad, puede que no sea obvio por qué la publicación original está tan equivocada. Entonces, hoy vamos a hablar de dónde se aleja la filosofía de seguridad de Oracle de la corriente principal y por qué es un problema..

Explicando la controversia

Entonces, ¿qué es exactamente la ingeniería inversa y por qué le preocupa tanto a Davidson? Básicamente, cuando Oracle lanza una pieza de software, “compilar” su código fuente interno en archivos ejecutables, y luego entregar esos archivos a los clientes. La compilación es un proceso que traduce código legible por el ser humano (en idiomas como C ++ 3 Sitios web Para comenzar a aprender C ++ Lenguaje de programación 3 Sitios web para comenzar a aprender C ++ Lenguaje de programación Aprender a programar puede ser difícil para muchos, incluso con lenguajes de programación relativamente fáciles Si bien Java es más fácil comenzar (donde tenemos numerosos artículos aquí en MakeUseOf para Java, así como… Leer más) en un lenguaje binario más denso que se puede alimentar directamente a un procesador de computadora.

El código fuente de Oracle no es público. Esto tiene como objetivo hacer que sea más difícil para otros robar su propiedad intelectual. Sin embargo, también significa que es muy difícil para los clientes verificar que el código sea seguro. Aquí es donde entra en juego la 'descompilación'. Básicamente, la descompilación se traduce en la otra dirección, convirtiendo los archivos ejecutables de nuevo en código legible por humanos. Esto no entrega exactamente el código fuente original, pero sí proporciona un código que funciona de la misma manera, aunque a menudo es difícil de leer, debido a la pérdida de comentarios y la estructura organizativa..

Este es el “Ingeniería inversa” a lo que se refiere Davidson. Oracle está en contra porque piensan que pone en riesgo su propiedad intelectual. Esto es, al menos, un poco tonto, porque usar un acuerdo de licencia para prohibir el robo de la propiedad intelectual es un poco como usar un felpudo con palabras severas para evitar la invasión de hogares. El tipo de personas que intentarán clonar sus productos no se preocupan por los acuerdos de licencia. 4 maneras de leer y entender un acuerdo de licencia de usuario final (EULA) Más fácilmente 4 formas de leer y entender un acuerdo de licencia de usuario final (EULA) Más fácilmente Los EULAs, o acuerdos de licencia de usuario final, son uno de los males de la vida moderna. Estos son acuerdos interminablemente largos, generalmente escritos en letra pequeña. Estas son las cosas por las que se desplaza ciegamente hacia abajo, en busca de ese maldito ... Leer más y, a menudo, no se encuentran en las jurisdicciones donde podría hacer cumplir esos acuerdos en cualquier caso.

La humanidad está condenada ... #oraclefanfic #justoraclethings pic.twitter.com/e6MOzzkkvq

- CyberAnarchist (@ Cyb3rOps) 12 de agosto de 2015

La política realmente solo afecta a clientes legítimos. La situación es similar a la del videojuego DRM 6 Lugares para comprar juegos sin DRM [MUO Gaming] 6 Lugares para comprar juegos sin DRM [MUO Gaming] Desde que decidí no comprar juegos de Steam, necesito encontrar otros fuentes. Muchos de ellos son en realidad peores que Steam. La tienda de Ubisoft es desconcertante y llena de DRM molesto. Electronic Art's ... Leer más, pero de alguna manera aún más ineficaz.

¿Por qué querrían los clientes descompilar estos ejecutables? Se trata de la seguridad. Tener acceso al código fuente le permite profundizar en él buscando errores y posibles problemas. A menudo, esto se hace usando un software que realiza una “análisis de código estático” - una lectura automatizada del código, que identifica errores conocidos y prácticas de software peligrosas que tienden a provocar errores. Si bien hay herramientas que analizan el archivo ejecutable directamente, su descompilación permite análisis generalmente más profundos. Este tipo de análisis estático es una herramienta estándar del comercio de seguridad, y la mayoría de las empresas preocupadas por la seguridad utilizan dicho software internamente para producir código que es menos probable que contenga errores graves..

La política de Oracle en este tipo de análisis es simplemente “no hacer.” ¿Por qué? Dejaré que Davidson explique.

“Un cliente no puede analizar el código para ver si hay un control que evite el ataque por el que está gritando la herramienta de escaneo (lo que probablemente es un falso positivo) [...] Ahora, debo señalar que no solo aceptamos el escaneo informes como “prueba de que hay un allí, allí,” en parte porque si está hablando de análisis estático o dinámico, un informe de escaneo no es prueba de una vulnerabilidad real. […] Ah, y requerimos que los clientes / consultores destruyan los resultados de tal ingeniería inversa y confirmen que lo han hecho.”

En otras palabras, la herramienta que muestra un resultado no es la prueba de un error real y, como Oracle utiliza estas herramientas internamente, no tiene sentido que los clientes las ejecuten por su cuenta..

El gran problema con esto es que estas herramientas de análisis de código estático no existen solo para llamar la atención sobre los errores. También deben servir como un objetivo para la calidad y seguridad del código. Si vuelcas el código base de Oracle en una herramienta de análisis estático estándar de la industria y se reparten cientos de páginas de problemas, es una muy mala señal..

La respuesta correcta, cuando una herramienta de análisis de código estático repite un problema, no es mirar el problema y decir 'oh, no, eso no causa un error porque tal y tal'. La respuesta correcta es entrar y solucionar el problema. Las cosas marcadas por las herramientas de análisis de código estático suelen ser malas prácticas en general, y su capacidad para determinar si un problema dado realmente causa un error es falible. Durante miles de problemas, vas a extrañar cosas. Es mejor que no tengas esas cosas en tu base de código en primer lugar.

Aquí está el director de tecnología de Oculus, John Carmack, que elogia estas herramientas desde su época en iD Software. (En serio, lee el ensayo completo, es interesante).

“Tuvimos un período en el que uno de los proyectos accidentalmente desactivó la opción de análisis estático durante unos meses, y cuando me di cuenta y la reactivé, hubo montones de nuevos errores que se habían introducido en el ínterin. [...] Estas fueron demostraciones de que las operaciones de desarrollo normales producían continuamente estas clases de errores, y [el análisis de código estático] nos protegía de manera efectiva de muchos de ellos.”

En resumen, es probable que muchos de los clientes de Oracle no estuvieran necesariamente tratando de informar errores específicos; se preguntaban por qué las prácticas de codificación de Oracle eran tan deficientes que su base de código estaba plagada de miles y miles de problemas tan básicos que podían ser seleccionados. por software automatizado.

Todavía estoy triste de que el sol se haya ido. ¿Y quién fue el genio que los vendió a Oracle? Eso es como dejar que Darth Vader cuide a tus hijos.

- Brad Neuberg (@bradneuberg) 15 de agosto de 2015

Seguridad Por Pegatinas

Entonces, ¿qué deben hacer los clientes preocupados por la seguridad, en lugar de utilizar herramientas de análisis estático? Afortunadamente, la publicación del blog de Davidson fue extremadamente detallada sobre ese tema. Además de abogar por prácticas generales de seguridad básicas, hace sugerencias concretas para aquellos preocupados por la seguridad del software que utilizan..

“[T] aquí hay muchas cosas que un cliente puede hacer, gosh, en realidad hablar con los proveedores acerca de sus programas de aseguramiento o verificar las certificaciones de los productos para los cuales hay sellos de Good Housekeeping (o “buen código” sellos) como las certificaciones Common Criteria o las certificaciones FIPS-140. La mayoría de los proveedores, al menos la mayoría de los grandes que conozco, tienen programas de seguridad bastante sólidos ahora (lo sabemos porque todos comparamos notas en conferencias).”

Esto es un horripilante Respuesta de una organización tan grande como Oracle. La seguridad informática es un campo en rápida evolución. Se encuentran nuevas vulnerabilidades todo el tiempo, y la formalización de los requisitos de seguridad en una certificación que se actualiza cada pocos años es absurda. La seguridad no es una pegatina. Si confía en que una pieza de software crucial es segura sobre la base de un sello en el empaque, está siendo irresponsablemente estúpido..

Las herramientas de análisis estático se actualizan con mucha mayor frecuencia que estas certificaciones (en algunos casos, diariamente) y eliminan todos los problemas que surgen. todavía no es suficiente para tener mucha confianza en la seguridad de su código, porque la mayoría de las vulnerabilidades son demasiado complejas para ser detectadas por este tipo de herramientas automatizadas.

La única forma de confiar en su propia seguridad es exponer su código al mundo y pedir a los piratas informáticos que intenten romperlo. Así es como operan la mayoría de las compañías de software: si encuentra un problema con su código, no lo criticarán condescendientemente por violar su acuerdo de uso. Te pagarán dinero. Quieren que las personas que hacen todo lo posible por romper su software todo el tiempo. Es la única forma en que pueden tener la confianza de que su código es seguro..

Estos programas se llaman “recompensa de errores” programas, y son lo mejor que le puede pasar a la seguridad de nivel empresarial en mucho tiempo. También son, casualmente, algo sobre lo que Davidson tiene opiniones bastante fuertes sobre.

“Las recompensas de chinches son la nueva banda de chicos (agradablemente aliterado, ¿no?) Muchas compañías están gritando, desmayándose y tirando ropa interior a los investigadores de seguridad [...] para encontrar problemas en su código e insistiendo en que este es el camino. no están haciendo una serie de errores, su código no es seguro.

Ah, bueno, encontramos un 87% de las vulnerabilidades de seguridad, los investigadores de seguridad encuentran alrededor del 3% y el resto lo encuentran los clientes. […] No estoy divulgando las recompensas de errores, solo observando que, por razones estrictamente económicas, ¿por qué tiraría mucho dinero al 3% del problema?.”

Para empezar, según los resultados de esos análisis de código estático, puede resultar que sea mucho más del 3% si los paga. Pero yo divago. El punto real es este: las recompensas de errores no son para ti, son para nosotros. ¿Podría encontrar errores más eficientemente si gastara el mismo dinero en expertos en seguridad interna? Bueno, probablemente no, pero echemos un hueso a Oracle y supongamos que podrían. Sin embargo, también podrían tomar el dinero, depositarlo y luego no hacer absolutamente nada. Si la seguridad resultante es inferior a la media, los clientes solo lo descubrirán dentro de unos años, cuando sus números de seguridad social terminen misteriosamente en la Web profunda Cómo encontrar sitios de Onion activos (y por qué podría querer) Cómo encontrar Active Onion Sitios (y por qué podría querer) Los sitios de Onion están alojados en la red Tor. Pero, ¿cómo encontrar sitios activos de cebolla? ¿Y cuáles son los que debes ir? Lee mas .

"No hay vulnerabilidad. El EULA lo dice". #oraclefanfic pic.twitter.com/cUfafDCWbv

- Schuyler St. Leger (@DocProfSky) 11 de agosto de 2015

Las fuentes de errores existen la mitad porque son una forma realmente efectiva de identificar errores y la otra mitad porque son una forma de seguridad que no se puede falsificar. Una recompensa por errores le dice al mundo que cualquier error que quede en el código es más costoso de encontrar que la recompensa establecida..

Los errores no existen para su comodidad, Oracle, existen porque no confiamos en usted.

¡Tampoco deberíamos nosotros! Muchas grandes compañías permiten que la seguridad se quede en el camino, ya que los numerosos megabreaches Target confirma hasta 40 millones de tarjetas de crédito de clientes de EE. UU. Potencialmente pirateado Target confirma hasta 40 millones de tarjetas de crédito de clientes de EE. UU. La información de la tarjeta de crédito de hasta 40 millones de clientes que han comprado en sus tiendas de EE. UU. entre el 27 de noviembre y el 15 de diciembre de 2013. Leer más muestra todo muy claramente. Eres el segundo fabricante de software más grande del mundo. Es absurdo pedirnos que tomemos su palabra de que sus productos están seguros..

Lo que Davidson hace bien

Para ser justos con Davidson, hay elementos de esto que son razonables en su contexto. Probablemente, muchos de sus clientes se embarcan en ambiciosas auditorías del código de Oracle, sin tomarse el tiempo para eliminar los problemas de seguridad más mundanos de sus sistemas..

“Amenazas persistentes avanzadas” - Las organizaciones de piratas informáticos expertos que intentan obtener acceso a organizaciones específicas para robar datos son ciertamente temibles, pero en términos numéricos son mucho menos peligrosas que los millones de piratas informáticos aficionados oportunistas con herramientas automatizadas. Realizar este tipo de análisis estáticos de software comercial cuando no ha adoptado medidas de seguridad básicas es muy parecido a instalar una sala de pánico cuando aún no tiene un candado en la puerta frontal.

Del mismo modo, probablemente sea frustrante e inútil presentar el mismo análisis automatizado una y otra vez y otra vez.

Sin embargo, en general, el artículo revela algunas ideas seriamente obsoletas sobre la seguridad del sistema y la relación entre los desarrolladores y los clientes. Aprecio que el trabajo de Davidson sea frustrante, pero los usuarios que hacen todo lo posible para verificar la seguridad del software que utilizan no son el problema. Aquí está el presidente de Security Awareness, la opinión de Ira Winkler sobre esto:

“Oracle es una empresa muy grande y rica, con productos que se distribuyen ampliamente y se utilizan para aplicaciones críticas. Período. Tienen la responsabilidad de hacer que su software sea lo más sólido posible [...] Puede haber muchos falsos positivos y costos asociados, pero eso es un factor de [su venta] de muchos programas que tienen muchos usuarios. Es un costo de hacer negocios. Estoy seguro de que todas las compañías de software tienen los mismos informes falsos positivos. No escucho a Microsoft et al. quejumbroso.”

Si Oracle no quiere seguir recibiendo miles de problemas encontrados por las herramientas de seguridad estática, tal vez deberían arregla esos miles de problemas. Si les molesta que las personas vuelvan una y otra vez a los mismos que no tienen errores, tal vez deberían tener un programa de recompensas de errores adecuado que tenga mecanismos para tratar el envío repetido de problemas. Los clientes de Oracle claman por un estándar de seguridad más alto y los avergüenza porque no esla respuesta correcta.

A pesar de que Oracle ha eliminado y generalmente ha rechazado la publicación, el hecho de haber sido escrito revela una cultura de seguridad profundamente errónea dentro de Oracle. El enfoque de seguridad de Oracle da prioridad a la protección de su propia propiedad intelectual sobre la seguridad y tranquilidad de sus clientes, y si confía al software de Oracle con información crítica, eso debería asustarlo..

Qué piensas? ¿Te preocupa la filosofía de seguridad de Oracle? ¿Crees que Davidson está siendo tratado con demasiada dureza? Háganos saber en los comentarios.!

Explore más sobre: ​​Seguridad en línea, Licencias de software.