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

Oracle está en problemas esta semana por una publicación de blog escrita por su jefa de seguridad, Mary Davidson. La publicación, aunque cubre una variedad de temas, trata principalmente de 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 los clientes de ingeniería inversa de nuestro código para intentar encontrar vulnerabilidades de seguridad en él. Es por eso que he estado escribiendo muchas cartas a clientes que comienzan con “hola howzit aloha” pero termina con “cumpla con su acuerdo de licencia y deje de aplicar ingeniería inversa a nuestro código, ya.”

Davidson explica que hay un número creciente de clientes conscientes de la seguridad que están haciendo ingeniería inversa del software de Oracle en busca de vulnerabilidades de seguridad (o contratando 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 malas personas. Si el cliente ha encontrado una vulnerabilidad real, mientras que Oracle la solucionará.

“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 sobre tal problema (que encontraron a través de ingeniería inversa) un parche especial (único) para el problema. Tampoco proporcionaremos crédito en ningún aviso que podamos emitir. Realmente no puedes esperar que digamos “gracias por romper el acuerdo de licencia.””

Esto hizo no ir bien en la comunidad de seguridad, y la publicación fue eliminada rápidamente, aunque no antes de generar un nuevo hashtag Hashtag Activism: #poderoso o #punto sin sentido? Activismo hashtag: ¿#poderoso o #punto sin sentido? #BringBackOurGirls, #ICantBreathe y #BlackLivesMatter han visto una amplia cobertura internacional en el último año, pero los hashtags son un medio efectivo de activismo? .

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

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

Pero, si no está 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 sobre dónde la filosofía de seguridad de Oracle se aparta de la corriente principal, y por qué es un problema.

Explicando la controversia

Entonces, ¿qué es exactamente la ingeniería inversa y por qué está tan preocupado Davidson? Básicamente, cuando Oracle lanza una pieza de software, ellos “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 humanos (en lenguajes como sitios web C ++ 3 para comenzar a aprender lenguaje de programación C ++ 3 sitios web para comenzar a aprender lenguaje de programación C ++ Aprender a programar puede ser difícil para muchos, incluso con lenguajes de programación relativamente fáciles Si bien es más fácil comenzar con Java (donde tenemos numerosos artículos aquí en MakeUseOf para Java, así como ...) 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 la intención de dificultar que otros roben 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 nuevamente en código legible por humanos. Esto no entrega exactamente el código fuente original, pero sí entrega código que funciona de la misma manera, aunque a menudo es difícil de leer, debido a la pérdida de comentarios y estructura organizativa..

Este es el “Ingeniería inversa” a lo que se refiere Davidson. Oracle está en contra porque creen 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 propiedad intelectual es un poco como usar un felpudo redactado severamente para evitar la invasión de la casa. Al tipo de personas que van a tratar de clonar sus productos no les importan los acuerdos de licencia. 4 maneras de leer y comprender un acuerdo de licencia de usuario final (EULA) más fácilmente 4 formas de leer y comprender un acuerdo de licencia de usuario final (EULA) Más fácilmente Los EULA, o acuerdos de licencia de usuario final, son uno de los males de la vida moderna. Estos son acuerdos interminables, generalmente escritos en letra minúscula. Estas son las cosas que se desplazan ciegamente hacia abajo, buscando eso ... y, a menudo, no se encuentran en 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] Como he decidido 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 molesto DRM. Arte electrónico ..., pero de alguna manera aún más ineficaz.

¿Por qué los clientes querrían descompilar estos ejecutables? Se trata de seguridad. Tener acceso al código fuente le permite explorarlo en busca de errores y posibles problemas. A menudo, esto se hace usando un software que realiza un “análisis de código estático” - Una lectura automática del código, que identifica errores conocidos y prácticas de software peligrosas que tienden a generar errores. Si bien existen herramientas que analizan el archivo ejecutable directamente, descompilarlo 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 conscientes de la seguridad utilizan dicho software internamente para producir código que es menos probable que contenga errores graves..

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

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

En otras palabras, la herramienta que muestra un resultado no es prueba de un error real y, dado que Oracle usa 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 se supone que deben servir como objetivo para la calidad y seguridad del código. Si volca la base de código de Oracle en una herramienta de análisis estático estándar de la industria y escupe 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 escupe 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 generalmente son malas prácticas en general, y su capacidad para determinar si un problema determinado realmente causa o no un error es falible. Durante miles de problemas, te perderás cosas. Es mejor no tener tales cosas en su base de código en primer lugar.

Aquí está el CTO de Oculus, John Carmack, cantando las alabanzas de estas herramientas de su tiempo en iD Software. (En serio, lea todo el ensayo, es algo 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 lo noté y lo volví a habilitar, 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 efectivamente de muchos de ellos..”

En resumen, es probable que muchos de los clientes de Oracle no intentaran necesariamente informar errores específicos: se preguntaban por qué las prácticas de codificación de Oracle eran tan pobres 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 Sun se haya ido. ¿Y quién fue el genio que los vendió a Oracle? Eso es como dejar que Darth Vader cuide a sus 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 usar herramientas de análisis estático? Afortunadamente, la publicación del blog de Davidson fue extremadamente detallada sobre ese tema. Además de defender 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, por ejemplo, hablar con los proveedores sobre sus programas de aseguramiento o verificar las certificaciones de los productos para los que existen sellos de Good Housekeeping (o “buen código” sellos) como certificaciones de Criterios comunes o certificaciones FIPS-140. La mayoría de los proveedores, al menos la mayoría de los grandes que conozco, tienen programas de garantía 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 formalizar los requisitos de seguridad en una certificación que se actualiza cada pocos años es absurdo. 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 embalaje, está siendo irresponsablemente estúpido.

Heck, las herramientas de análisis estático se actualizan con mucha más frecuencia que estas certificaciones, en algunos casos, diariamente, y eliminando todos los problemas que surgen todavía no es suficiente 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 pedirles a los piratas informáticos que intenten descifrarlo. Así es como operan la mayoría de las principales compañías de software: si encuentra un problema con su código, no le criticarán condescendientemente por violar su acuerdo de uso. Te pagarán dinero. Quieren que la gente haga todo lo posible para romper su software todo el tiempo. Es la única forma en que pueden confiar en que su código es seguro.

Estos programas se llaman “generosidad” 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..

“Las recompensas de errores son la nueva banda de chicos (muy bien aliterativa, ¿no?) Muchas compañías gritan, se desmayan y arrojan ropa interior a los investigadores de seguridad [...] para encontrar problemas en su código e insisten en que This Is The Way, Walk In It: si usted no están haciendo errores, su código no es seguro.

Ah, bueno, nosotros encontramos el 87% de las vulnerabilidades de seguridad, los investigadores de seguridad encuentran alrededor del 3% y el resto lo encuentran los clientes. […] No estoy descartando las recompensas de errores, solo señalando que sobre una base estrictamente económica, ¿por qué debería tirar una gran cantidad de dinero al 3% del problema?.”

Para empezar, según los resultados de esos análisis de código estático, podría resultar 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 de manera más eficiente si gastara el mismo dinero en expertos en seguridad interna? Bueno, probablemente no, pero arrojemos a Oracle un hueso y supongamos que podrían hacerlo. Sin embargo, también podrían tomar el dinero, depositarlo y luego no hacer absolutamente nada. Si la seguridad resultante es inferior, 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 web oscuros de Onion. Encuentre sitios web .Onion Dark activos (y por qué podría desearlo) La web oscura, en parte, consiste en sitios .onion, alojados en la red Tor. ¿Cómo los encuentras y dónde ir? Sígueme… .

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

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

Las recompensas 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 puedes 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..

Las recompensas de errores no existen para su conveniencia, Oracle, existen porque no confiamos en usted.

¡Tampoco nosotros! Muchas empresas grandes permiten que la seguridad se quede en el camino, ya que los numerosos megabreaches Target confirma que hasta 40 millones de tarjetas de crédito de clientes estadounidenses potencialmente pirateadas Target confirma que hasta 40 millones de tarjetas de crédito de clientes estadounidenses potencialmente pirateadas Target acaba de confirmar que un pirateo podría haber comprometido 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. se muestra con demasiada claridad. Eres el segundo fabricante de software más grande del mundo. Es absurdo pedirnos que confiemos en que sus productos son 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 auditorías ambiciosas del código de Oracle, sin tomarse el tiempo para eliminar problemas de seguridad más mundanos de sus sistemas..

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

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

Sin embargo, en su conjunto, el artículo revela algunas ideas seriamente desactualizadas sobre la seguridad del sistema y la relación entre desarrolladores y clientes. Aprecio que el trabajo de Davidson sea frustrante, pero los usuarios que se desviven por verificar la seguridad del software que usan no son el problema. Aquí está el presidente de Security Awareness, Ira Winkler:

“Oracle es una compañía muy grande y rica, con productos que están ampliamente distribuidos y utilizados 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 una gran cantidad de software que tiene 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 arreglar esos miles de problemas. Si les molesta que las personas entreguen los mismos no errores una y otra vez, tal vez deberían tener un programa de recompensas de errores adecuado que tenga mecanismos para lidiar con los envíos repetidos de problemas. Los clientes de Oracle claman por un mayor estándar de seguridad, y no los avergüenzan por ello.la respuesta correcta.

A pesar de que Oracle ha eliminado y, en general, ha rechazado la publicación, el hecho de que se haya escrito revela una cultura de seguridad profundamente equivocada dentro de Oracle. El enfoque de seguridad de Oracle prioriza la protección de su propia propiedad intelectual sobre la seguridad y la tranquilidad de sus clientes, y si confía al software de Oracle información crítica, eso debería asustarlo..

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