Kysymys:
Vastuu vahingoista Yhdysvalloissa "0 päivän" tietokoneen hyödyntämisen löytämisestä ja paljastamisesta
Digital fire
2015-05-28 17:21:49 UTC
view on stackexchange narkive permalink

Tietotekniikan / ohjelmoinnin tietoturvamaailmassa ihmiset yleensä ottavat yhteyttä tietyn ohjelmiston myyjään / omistajaan, jos he löytävät virheen tai tietoturva-aukon ja antavat heille aikaa korjata se ennen virheen tai haavoittuvuuden julkaisemista julkisen valvonnan / tietoisuuden vuoksi. Tämä tapahtuu yleensä kohteliaisuutena, ellei sinua sido sopimus. Mutta kuten kysytään artikkelissa Jos löydän tai luon 0päivän: Entä jos löydän haavoittuvuuden laajasti käytetystä ohjelmistosta?

Voinko olla vastuussa vahingoista jos luovutan "Proof of Concept" -koodin yleisölle antamatta myyjälle aikaa korjata ja päivittää haavoittuvaa koodia oikein?

PÄIVITYS: Keskusteltuani tästä kysymyksestä joidenkin ikäisensä kanssa Tajusin, että minun on oltava hieman tarkempi kysymyksessä: Turvallisuustutkijat yrittävät yleensä toimittajan kanssa yrittää korjata (korjata) virheen / haavoittuvuuden. Jos riittävän (30 päivää?) Kuluttua on kulunut ja myyjä ei ole korjannut koodia, täydellinen paljastus julkaistaan ​​julkisesti.

Voinko olla vastuussa vahingoista, jotka ovat aiheutuneet "Proof of Concept" -koodin julkaisu, jos ohjelmisto / toimittaja on avoimen lähdekoodin? Entä jos myyjä / ohjelmisto on suljettu lähde?

üks vastaus:
kevin
2015-05-28 18:53:45 UTC
view on stackexchange narkive permalink

Voitteko olla vastuussa vahingoista? Tort Law -kohdassa kyllä.

Oletetaan, että joku on kehittänyt viruksen koodisi perusteella. Virus aiheutti miljoonia dollareita vahinkoa. Kantaja (ohjelmistotoimittaja) voi väittää, että:

  1. sinulla on hoitovelvollisuus

välttääksesi tekoja tai laiminlyönnit, joiden voit kohtuudella ennakoida, vahingoittavat todennäköisesti naapuriasi.

Donoghue v. Stevenson (1932) (Iso-Britannia)

Hoitovelvollisuuden käsite löytyy myös Yhdysvaltain laista, esimerkiksi julkaisusta MacPerson v. Buick Motor Co. (1916) , jossa todettiin, että huolimattomuus ei vaadi sopimusta .

  1. Velvollisuuden rikkominen: järkevä henkilö ennakoida , että "käsitteen todistaminen" voi aiheuttaa vahinkoa. Koodin vapauttaminen ei siis ole odotettua tasoa. Jos olet IT-ammattilainen, on vaikea puolustaa tätä asiaa.

  2. Koodisi välillä on syy-yhteys -suhde vapauttaminen ja siitä aiheutunut vahinko.

  3. Olet vastuussa laiminlyönnistä .

  4. Vahinko: Se on todennäköistä, että käyttäjät haastavat ohjelmistotoimittajan oikeuteen vahingoistaan. Ohjelmistotoimittaja nostaa sinut sitten haasteen, koska sinun takia ohjelmistotoimittajan on maksettava korvaus asiakkailleen.

Tämä riippuu tietysti siitä, mitä julkaisit tarkalleen. julkisuuteen. Esimerkiksi, jos "todistuskonseptisi" muuntamiseksi todelliseksi hyödyntämiseksi tarvitaan huomattavia ponnisteluja ja olet tarjonnut kiertotavan tämän haavoittuvuuden välttämiseksi, voit puolustautua väittämällä, että syy-seuraussuhde on liian etäinen .

Joten minun on pidettävä raportti yksityisenä? Entä jos ohjelmisto on avoimen lähdekoodin?

Ei oikeastaan. Sinun on ryhdyttävä kohtuullisiin toimenpiteisiin varmistaaksesi, että "todistesi käsitteestäsi" ei ole todellinen hyödyntäminen, ja hakkeri tarvitsee paljon aikaa toimivan haittaohjelman kehittämiseen. CVE on foorumi, jossa haavoittuvuudet jaetaan julkisesti.

Entä jos olet antanut toimittajalle kohtuullisen ajan korjata haavoittuvuuden?

Ei ole väliä (sinulle), jos toimittajalle on annettu aikaa korjata haavoittuvuus. Sillä on merkitystä myyjälle, koska jos jotain tapahtuu myöhemmin, myyjä on vastuussa ongelman tuntemisesta hyvissä ajoin eikä ole jakanut asianmukaisia ​​resursseja ongelman korjaamiseen.

Haavoittuvuuden osoittamiseksi ei ole vaativat ohjeita tämän haavoittuvuuden käytöstä. Voit esimerkiksi tallentaa videon, joka näyttää hakkeroinnin vaikutukset.

Täällä (Wayback Machine; alkuperäinen linkki on kuollut) on mielenkiintoinen luku siitä, kuinka Motorola ottaa asiat huomioon omiin käsiinsä havaittuaan haavoittuvuuden Xerox CP-V -järjestelmässä, eikä Xerox paikannut ongelmaa.

Olen päivittänyt kysymyksen. Uskon vastauksen soveltuvan vain tilanteisiin, joissa haavoittuvuus on 'suljetun lähdekoodin' ohjelmistossa / laitteistossa.
Mainitsemasi tapaus oli Yhdistyneen kuningaskunnan tapaus. Koska kysymys merkittiin yhdysvaltoiksi, kannattaa ehkä nimenomaisesti mainita, että mainitsit Yhdistyneen kuningaskunnan tapausta (tai jos koko vastaus perustuu Yhdistyneen kuningaskunnan lakiin, sano se).
@cpast Olen lisännyt viittauksen Yhdysvaltain tapaukseen.
Muista mainita, että Yhdysvaltojen tapaus on osavaltion oikeustapaus. Liittovaltion lakia ei ole (vaikka oikeustieteilijät voivatkin jakaa hiukset). Huomaa myös, että vaikka huolimattomuusvaatimus on olemassa, on suurempi kysymys ** pysyvyydestä ** eli kenellä on oikeus nostaa kanne aluksi, ja on myös kysymys ** vahingoista **. Joten huolimattomuusvaatimuksessa kaikki vaaditaan ** (1) ** tulli; ** (2) ** rikkomus; ** (3) ** syy-yhteys; ja ** (4) ** vahingonkorvaukset ja ** (5) ** kantajalla on oltava oikeus nostaa kanne.
Tämä vastaus näyttää olevan hieman taaksepäin - miksi se on tutkijan vika, jos koodin kirjoittaneen yrityksen ohjelmoijat eivät osaa laskea ja / tai kirjoittaa? Esim. yksitellen jne. Samoin useimmilla ohjelmistoilla ei ole takuuta; jos valmistaja on nimenomaan päättänyt antaa takuun, se ei ole sinun syytäsi, että hän teki niin varmistamatta, että koodiinsa ei liity näitä yksitellen tai muita suoraviivaisia ​​virheitä.
@cnst: ei ole vika, se on väärä teko opettaa muille kuinka hyödyntää ohjelmistoa, jota voidaan käyttää vahingoittamiseen. Ei myöskään ole totta, että useimmilla ohjelmistoilla ei ole takuuta: ainakin useimmat yritysohjelmistot tekevät.
@kevin Olen eri mieltä siitä, että muiden opettaminen käyttämään taitoja on väärin. Aivan kuten näyttää aseita tai vasaraa jollekin, ei tee heistä rikollisia. Se, mitä he tekevät tuon aseen tai vasaran kanssa, olisi rikos.
@DigitalFire Olen samaa mieltä. On tehtävä ero sen välillä, miten opetetaan jotakuta käyttämään asetta ja jätetäänkö aseistettu ase pöydälle. Kuten sanoin, haavoittuvuus * voidaan * julkistaa CVE: ssä.
Kevin, kuollut linkki "Tässä on mielenkiintoinen lukema siitä, kuinka Motorola ottaa asiat omiin käsiinsä löydettyään haavoittuvuuden Xerox CP-V -järjestelmässä eikä Xerox ole paikannut ongelmaa." Haluan lukea sen):
@LateralTerminal Löysin sen web-välimuistista ja tein sen saataville liitetiedostoon.
Kevin, onko tämä totta tarina? Vaikka niin ei ole, rakastan sitä.
@kevin Se on aika hyvä.
"Sinulla on huolellisuusvelvollisuus välttää sellaisia ​​tekoja tai laiminlyöntejä, jotka voit kohtuudella ennakoida vahingoittavan lähimmäistäsi" Se on harhaanjohtava lainausmerkintä. Donoghue ei havainnut yleistä huolellisuusvelvollisuutta huolimattomuuden välttämiseksi, ja totesi, että * jos * huolellisuusvelvollisuus on olemassa, niin tämä velvollisuus voidaan rikkoa huolimattomuudesta. Lisäksi, jos hakkeri käyttää julkistamistaan ​​hyödyntääkseen, hakkerin toimet ovat selvästi väliintuleva syy. Lisäksi mikä tahansa vastuun löytäminen vaikuttaisi ensimmäiseen muutokseen.


ⓘ
Tämä Q & A käännettiin automaattisesti englanniksi.Alkuperäinen sisältö on saatavilla stackexchange-palvelussa, jota kiitämme cc by-sa 3.0-lisenssistä, jolla sitä jaetaan.
Loading...