Pregunta:
Responsabilidad por daños y perjuicios en los EE. UU. Por encontrar y divulgar un exploit informático de "día 0"
Digital fire
2015-05-28 17:21:49 UTC
view on stackexchange narkive permalink

En el mundo de la seguridad de TI / programación, por lo general, las personas se comunican con el proveedor / propietario de un software en particular si encuentran un error o una vulnerabilidad de seguridad y les dan tiempo para corregirlo antes de publicar el error o la vulnerabilidad para el escrutinio / conciencia pública. Esto suele ser una cortesía, a menos que esté obligado por contrato. Pero como se pregunta en Si encuentro o creo un día 0: ¿Qué sucede si encuentro una vulnerabilidad en un software ampliamente utilizado?

¿Puedo ser responsable de los daños si publico el código de "Prueba de concepto" sin darle tiempo al proveedor para parchear y actualizar correctamente su código vulnerable?

ACTUALIZACIÓN: Después de tener una discusión sobre esta pregunta con algunos compañeros, Me di cuenta de que tenía que ser un poco más específico con la pregunta: los investigadores de seguridad suelen trabajar con el proveedor para intentar corregir (corregir) el error / vulnerabilidad. Si después de suficiente (¿30 días?) Ha pasado el tiempo y el proveedor no ha corregido el código, se publica una divulgación completa.

¿Puedo ser responsable de los daños causados ​​después la publicación de un código de "prueba de concepto" si el software / proveedor es de código abierto? ¿Qué pasa si el proveedor / software es de código cerrado?

One responder:
#1
+14
kevin
2015-05-28 18:53:45 UTC
view on stackexchange narkive permalink

¿Puede ser responsable de los daños? Bajo Ley de agravios, sí.

Supongamos que alguien desarrolló un virus basado en su código. El virus causó daños por millones de dólares. El demandante (proveedor de software) puede argumentar que:

  1. Usted tiene un Deber de cuidado

de evitar actos u omisiones que puede prever razonablemente que puedan dañar a su vecino

Donoghue v. Stevenson (1932) (Reino Unido)

El concepto de deber de diligencia también se encuentra en la legislación estadounidense, por ejemplo, en MacPerson v. Buick Motor Co. (1916) , que estableció que negligencia no requiere un contrato .

  1. Incumplimiento del deber: una persona razonable puede prever que la "prueba de concepto" puede causar daño. El acto de publicar código, por lo tanto, no alcanza el estándar esperado. Si es un profesional de TI, será difícil defender este punto.

  2. Existe una relación de causalidad entre su código liberación y el daño resultante.

  3. Usted es responsable de la negligencia

  4. Daño: Es probable que los usuarios demanden al proveedor de software por sus pérdidas. El proveedor de software lo demandará, ya que debido a usted, el proveedor de software tiene que compensar a sus clientes.

Esto, por supuesto, depende de qué lanzó exactamente para el publico. Por ejemplo, si se necesita un esfuerzo significativo para convertir su "prueba de concepto" en un exploit real, y ha proporcionado una solución para evitar esta vulnerabilidad, puede defenderse argumentando que el vínculo de causa y efecto es demasiado remoto. .

¿Entonces debo mantener el informe privado? ¿Qué pasa si el software es de código abierto?

En realidad, no. Debe tomar medidas razonables para asegurarse de que su "prueba de concepto" no sea un exploit real y que un pirata informático necesite un tiempo considerable para desarrollar un software malicioso que funcione. CVE es una plataforma en la que las vulnerabilidades se comparten públicamente.

¿Qué pasa si le ha dado al proveedor un tiempo razonable para corregir la vulnerabilidad?

No le importa (a usted) si se le ha dado tiempo al proveedor para corregir la vulnerabilidad. Es importante para el proveedor, porque si algo sucede más tarde, el proveedor es responsable de conocer el problema con mucha anticipación y no ha asignado los recursos adecuados para corregir el problema.

Demostrar que existe una vulnerabilidad no significa requieren instrucciones sobre cómo utilizar esta vulnerabilidad. Por ejemplo, puede grabar un video que muestre los efectos del hack.

Aquí (Wayback Machine; el enlace original está muerto) es una lectura interesante sobre Motorola tomando el asunto en sus propias manos después de que descubrieron una vulnerabilidad en el sistema Xerox CP-V y Xerox no solucionó el problema.

Actualicé la pregunta. Creo que la respuesta solo sería aplicable a una situación en la que la vulnerabilidad se encuentra en un software / hardware de 'código cerrado'.
El caso que citó fue un caso del Reino Unido. Dado que la pregunta se etiquetó como estados unidos, es posible que desee mencionar explícitamente que estaba citando un caso del Reino Unido (o si la respuesta completa se basa en la ley del Reino Unido, dígalo).
@cpast He agregado una referencia al caso de EE. UU.
Asegúrese de mencionar que el caso de EE. UU. Es un caso de ley estatal. No existe una ley federal de derecho consuetudinario (aunque los académicos legales pueden dividir los pelos). También tenga en cuenta que si bien existe el reclamo por negligencia, existe una cuestión más amplia de ** legitimación **, es decir, quién tiene derecho a presentar el reclamo para empezar y también está la cuestión de ** daños **. Por lo tanto, en un reclamo por negligencia, todos deben ** (1) ** deber; ** (2) ** incumplimiento; ** (3) ** causalidad; y ** (4) ** daños, y ** (5) ** el demandante debe tener legitimación para presentar el reclamo.
Esta respuesta parece estar un poco al revés: ¿por qué es culpa del investigador si los programadores de la empresa que escribieron el código no pueden contar y / o escribir? P.ej. uno por uno, etc. Asimismo, la mayoría del software no tiene garantía; Si el fabricante decidió específicamente brindar garantía, no es culpa suya que lo haya hecho sin asegurarse de que su código no esté sujeto a estos errores simples u otros errores sencillos.
@cnst: no es una falta, es una mala acción enseñar a otros cómo explotar un software que se puede utilizar para hacer daño. Además, no es cierto que la mayoría del software no tenga garantía: al menos la mayoría del software empresarial sí.
@kevin No estoy de acuerdo con que enseñar a otros cómo usar un conjunto de habilidades esté mal. Al igual que mostrarle a alguien cómo usar una pistola o un martillo no los convierte en criminales. Es lo que hacen con esa pistola o martillo lo que constituiría un acto criminal.
@DigitalFire Estoy de acuerdo. Se debe hacer una distinción entre enseñarle a alguien cómo usar un arma y dejar un arma armada sobre un escritorio. Como dije, la vulnerabilidad * puede * divulgarse públicamente en CVE.
Kevin, enlace muerto "Aquí hay una lectura interesante sobre Motorola tomando el asunto en sus propias manos después de que descubrieron una vulnerabilidad en el sistema Xerox CP-V y Xerox no solucionó el problema". Quiero leer eso):
@LateralTerminal Lo encontré en un caché web y lo puse a disposición en la papelera de pegado.
Kevin, ¿es esta una historia real? Incluso si no lo es, me encanta.
@kevin Eso es bastante bueno.
"Tiene el deber de diligencia de evitar actos u omisiones que razonablemente puede prever que pueden dañar a su vecino" Esa es una presentación engañosa de las citas. Donoghue no encontró que existe un deber general de cuidado para evitar la negligencia, descubrió que * si * existe un deber de cuidado, entonces ese deber puede ser incumplido por negligencia. Además, si un pirata informático utiliza la revelación de uno para hacer un exploit, las acciones del pirata informático son claramente una causa interviniente. Además, cualquier determinación de responsabilidad implicaría la Primera Enmienda.


ⓘ
Esta pregunta y respuesta fue traducida automáticamente del idioma inglés.El contenido original está disponible en stackexchange, a quien agradecemos la licencia cc by-sa 3.0 bajo la que se distribuye.
Loading...