Oracle está en problemas esta semana por una publicación de blog escrita por su jefe de seguridad, Mary Davidson. La publicación, aunque abarca una variedad de temas, se trata principalmente de la práctica de informar las posibles vulnerabilidades de seguridad a Oracle. Específicamente, por qué no deberías.
"Recientemente, he visto un gran repunte en los clientes que realizan ingeniería inversa de nuestro código para intentar encontrar vulnerabilidades de seguridad en él. Esta es la razón por la que he estado escribiendo muchas cartas a clientes que comienzan con "hola, howzit, aloha" pero terminan con "por favor cumpla con su contrato de licencia y deje de aplicar ingeniería inversa a nuestro código".
Davidson explica que hay un número creciente de clientes conscientes de la seguridad que son software de ingeniería inversa de Oracle que buscan 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 para ellos y, en general, de ser personas malas. Si el cliente ha encontrado una vulnerabilidad real, mientras que Oracle lo 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 mediante ingeniería inversa) un parche especial (único) para el problema. Tampoco proporcionaremos crédito en los avisos que podamos emitir. Realmente no se puede esperar que digamos "gracias por romper el acuerdo de licencia".
Esto no funcionó bien en la comunidad de seguridad, y la publicación se eliminó rápidamente, aunque no antes de generar un nuevo hashtag Hashtag Activism: #powerful o #pointless? Activismo Hashtag: #powerful o #pointless? #BringBackOurGirls, #ICantBreathe y #BlackLivesMatter han tenido una amplia cobertura internacional en el último año, pero ¿son las etiquetas un medio efectivo 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á familiarizado con el mundo de la seguridad, puede que no sea obvio por qué la publicación original es tan errónea. Por lo tanto, 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 ingeniería inversa, y por qué Davidson está tan preocupado por eso? Básicamente, cuando Oracle lanza una pieza de software, "compilan" su código fuente interno en archivos ejecutables y luego los entregan a los clientes. La compilación es un proceso que traduce código legible por humanos (en lenguajes 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 . Mientras que Java es más fácil de empezar (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 en un procesador de computadora.
El código fuente de Oracle no es público. Esto tiene la intención de 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 archivos ejecutables de nuevo en código legible por humanos. Esto no entrega exactamente el código fuente original, pero 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 la estructura de la organización.
Esta es la "ingeniería inversa" a la que se está refiriendo 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 IP es un poco como usar un felpudo con una redacción severa para evitar la invasión del hogar. 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 (CLUF). Más fácilmente 4 maneras de leer y entender un contrato de licencia de usuario final (CLUF) Los CLUF más fáciles o los acuerdos de licencia de usuario final son uno de los males de la vida moderna. Estos son acuerdos infinitamente prolijos, usualmente escritos en minúsculas. Estas son las cosas que deslizas ciegamente hacia abajo, buscando ese maldito ... Leer más, y con frecuencia no están en jurisdicciones donde podrías 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 los clientes legítimos. La situación es similar a la del videojuego DRM. 6 Places To Buy Juegos sin DRM [MUO Gaming] 6 Places To Buy 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 está llena de DRM molesto. Electronic Art ... Leer más, pero de alguna manera aún más ineficaz.
¿Por qué querrían los clientes descompilar estos ejecutables? Se trata de seguridad. Tener acceso al código fuente le permite explorarlo buscando 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 peligroso que tienden a provocar errores. Si bien hay 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 para el comercio de seguridad, y la mayoría de las compañías conscientes de la seguridad usan 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 lo explique.
"Un cliente no puede analizar el código para ver si hay un control que evite el ataque por el cual la herramienta de escaneo está gritando (lo cual es muy probable que sea un falso positivo) [...] Ahora, debo señalar que no solo aceptamos escanear 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 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 arroja 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 atraer su atención. También se supone que sirven como un objetivo para la calidad y seguridad del código. Si transfiere la base de códigos de Oracle a una herramienta de análisis estático estándar de la industria y arroja cientos de páginas de problemas, es una señal realmente mala.
La respuesta correcta, cuando una herramienta de análisis de código estático responde un problema, es no 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 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 un error es falible. Sobre miles de problemas, vas a extrañar cosas. Es mejor que no tengas tales cosas en tu código base en primer lugar.
Aquí está el CTO de Oculus, John Carmack, cantando los elogios de estas herramientas de su tiempo en iD Software. (En serio, lee el ensayo completo, es algo interesante).
"Tuvimos un período en el que accidentalmente uno de los proyectos obtuvo la opción de análisis estático desactivada durante unos meses, y cuando lo noté y lo reactivaba, había montones de nuevos errores que se habían introducido en el ínterin. [...] Estas fueron demostraciones de que las operaciones normales de desarrollo estaban produciendo continuamente estas clases de errores, y [el análisis del código estático] nos estaba protegiendo efectivamente de muchos de ellos ".
En resumen, es probable que muchos de los clientes de Oracle no estuvieran necesariamente tratando de informar errores específicos: preguntaban por qué las prácticas de codificación de Oracle eran tan pobres que su base de códigos 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? Es como dejar que Darth Vader cuide a sus hijos.
- Brad Neuberg (@bradneuberg) 15 de agosto de 2015
Seguridad por pegatinas
Entonces, ¿qué deberían hacer los clientes preocupados por la seguridad, en lugar de utilizar herramientas de análisis estático? Afortunadamente, la publicación de Davidson en el blog fue extremadamente detallada sobre ese tema. Además de defender las prácticas de seguridad básicas generales, hace sugerencias concretas para quienes están preocupados por la seguridad del software que utilizan.
"[T] aquí hay muchas cosas que un cliente puede hacer, Dios, hablando con los proveedores sobre sus programas de aseguramiento o verificando certificaciones para productos para los que hay sellos Good Housekeeping (o sellos de buen código) como Common Criteria. certificaciones o certificaciones FIPS-140. La mayoría de los vendedores, al menos, la mayoría de los más grandes que conozco, ahora tienen programas de aseguramiento bastante robustos (lo sabemos porque todos comparamos notas en conferencias) ".
Esta es una respuesta horrible de una organización tan grande como Oracle. La seguridad informática es un campo en rápida evolución. Las nuevas vulnerabilidades se encuentran 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ías en que un pedazo de software crucial está seguro sobre la base de un sello en el embalaje, estás siendo irresponsablemente estúpido.
Diablos, las herramientas de análisis estáticos se actualizan con mucha más frecuencia que estas certificaciones, en algunos casos, diariamente, y eliminar todos los problemas que aparecen todavía no es suficiente para tener mucha confianza en la seguridad de su código, porque la mayoría de las vulnerabilidades también complejo para ser detectado por este tipo de herramientas automatizadas.
La única manera de tener confianza en su propia seguridad es exponer su código al mundo y pedirles a los piratas informáticos que intenten romperlo. Así es como operan la mayoría de las principales compañías de software: si encuentra un problema con su código, no le gritarán condescendientemente por violar su acuerdo de uso. Te pagarán dinero. Quieren personas que hagan 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 programas de "bonificación de errores" y son lo mejor que le puede pasar a la seguridad de nivel empresarial en mucho tiempo. También son, casualmente, algo en lo que Davidson tiene opiniones muy fuertes.
"Las recompensas de errores son la nueva banda de chicos (muy aliterarias, ¿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 no estás haciendo faltas de errores, tu código no es seguro.
Ah, bueno, 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 criticando las bondades de los errores, simplemente observando que, desde el punto de vista estrictamente económico, ¿por qué arrojaría una gran cantidad de dinero al 3% del problema? ".
Para empezar, en función de los resultados de esos análisis de códigos estáticos, podría llegar a ser mucho más del 3% si los pagas. Pero yo divago. El verdadero punto 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 de seguridad interna? Bueno, probablemente no, pero le echamos un hueso a Oracle 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 no está a la altura, los clientes solo se enterarán años después cuando sus números de seguridad social misteriosamente terminen en la web profunda. Cómo encontrar sitios de cebollas activas y por qué es posible que desee encontrar sitios de cebolla activos y Los sitios de Why You Want To Onion, llamados así porque terminan con ".onion", están alojados como servicios ocultos de Tor, una forma completamente anónima de alojar sitios web. Lee mas .
"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 a medias porque son una forma genuinamente efectiva de identificar errores, y la otra mitad porque son una forma de seguridad que no puedes fingir. Una recompensa de errores le dice al mundo que cualquier error que quede en el código es más costoso de encontrar que la recompensa declarada.
Las recompensas de errores no existen para su conveniencia, Oracle, existen porque no confiamos en usted.
¡Tampoco deberíamos! Muchas grandes empresas permiten que la seguridad se quede en el camino, ya que los numerosos megabrechas Objetivo confirma hasta 40 millones de clientes estadounidenses Tarjetas de crédito Potente pirateado Target confirma hasta 40 millones de clientes estadounidenses Tarjetas de crédito potencialmente pirateadas Target acaba de confirmar que un hack podría haber comprometido la información de la tarjeta de crédito para 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. Lea más, demuéstrelo con demasiada claridad. Eres el segundo fabricante de software más grande del mundo. Es absurdo pedirnos que demos su palabra de que sus productos son seguros.
Lo que Davidson tiene derecho
Para ser justos con Davidson, hay elementos de esto que son razonables en su contexto. Probablemente, muchos de sus clientes se embarquen en auditorías ambiciosas del código de Oracle, sin tomarse el tiempo para eliminar los problemas de seguridad más mundanos de sus sistemas.
Las "amenazas persistentes avanzadas" -organizaciones hackers habilidosas que intentan acceder a organizaciones específicas para robar datos- son ciertamente aterradoras, pero según los números, son mucho menos peligrosas que los millones de hackers 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 parecido a instalar una sala de pánico cuando todavía no tiene un candado en la puerta de entrada.
Del mismo modo, probablemente sea frustrante e inútil recibir el mismo análisis automatizado una y otra vez.
Sin embargo, tomado en su conjunto, el artículo revela algunas ideas muy 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 utilizan no son el problema. Aquí está el presidente de Awareness Security, la opinión de Ira Winkler:
"Oracle es una compañía muy grande y rica, con productos que se distribuyen ampliamente y se usan para aplicaciones críticas. Período. Tienen la responsabilidad de hacer que su software sea lo más potente posible [...] Puede haber muchos falsos positivos y costos asociados, pero ese es un factor de [su venta] de un montón 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 Microsoft y col. quejumbroso."
Si Oracle no quiere seguir recibiendo miles de problemas encontrados por las herramientas de seguridad estáticas, tal vez deberían solucionar esos miles de problemas. Si les molesta que las personas entreguen los mismos errores una y otra vez, tal vez deberían tener un programa de recompensas correcto que tenga mecanismos para lidiar con envíos repetidos de no problemas. Los clientes de Oracle están clamando por un mayor nivel de seguridad y avergonzarlos porque no es la respuesta correcta.
A pesar de que Oracle ha desmantelado y generalmente ha negado la publicación, que fue escrito revela una cultura de seguridad profundamente equivocada dentro de Oracle. El enfoque de Oracle para la seguridad prioriza la protección de su propia propiedad intelectual sobre la seguridad y la tranquilidad de sus clientes, y si confía en el software de Oracle con 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 dureza? Háganos saber en los comentarios!