Pytanie:
Odpowiedzialność za szkody w USA za wykrycie i ujawnienie luki w komputerach typu „0-day”
Digital fire
2015-05-28 17:21:49 UTC
view on stackexchange narkive permalink

W świecie bezpieczeństwa IT / programowania zazwyczaj ludzie kontaktują się z dostawcą / właścicielem konkretnego oprogramowania, jeśli znajdą błąd lub lukę w zabezpieczeniach i dają im czas na załatanie go przed udostępnieniem błędu lub luki w celu publicznego zbadania / uświadomienia. Zwykle jest to jednak grzeczność, chyba że jesteś związany umową. Ale zgodnie z pytaniem w Jeśli znajdę lub utworzę 0day: Co się stanie, jeśli znajdę lukę w powszechnie używanym oprogramowaniu?

Czy mogę zostać pociągnięty do odpowiedzialności za szkody jeśli udostępnię publicznie kod „Proof of Concept”, nie dając dostawcy czasu na poprawne załatanie i zaktualizowanie kodu zawierającego luki?

AKTUALIZACJA: Po dyskusji na ten temat z kilkoma osobami, Zdałem sobie sprawę, że muszę bardziej szczegółowo zadać pytanie: badacze bezpieczeństwa zwykle współpracują z dostawcą, aby spróbować załatać (naprawić) błąd / lukę. Jeśli po upływie wystarczającego (30 dni?) Czasu, a sprzedawca nie naprawił kodu, wówczas pełne ujawnienie zostanie podane do wiadomości publicznej.

Czy mogę zostać pociągnięty do odpowiedzialności za szkody spowodowane po wydanie kodu „Proof of Concept”, jeśli oprogramowanie / dostawca jest open source? Co się stanie, jeśli dostawca / oprogramowanie ma zamknięte źródło?

Jeden odpowiedź:
#1
+14
kevin
2015-05-28 18:53:45 UTC
view on stackexchange narkive permalink

Czy możesz odpowiadać za szkody? Zgodnie z prawem deliktowym, tak.

Załóżmy, że ktoś opracował wirusa na podstawie Twojego kodu. Wirus spowodował szkody o wartości milionów dolarów. Powód (sprzedawca oprogramowania) może argumentować, że:

  1. Masz obowiązek zachowania ostrożności

, aby uniknąć działań lub zaniedbania, które możesz rozsądnie przewidzieć, mogą zranić twojego sąsiada

Donoghue przeciwko Stevenson (1932) (Wielka Brytania)

Pojęcie obowiązku zachowania ostrożności występuje również w prawie amerykańskim, na przykład w sprawie MacPerson przeciwko Buick Motor Co. (1916) , która ustaliła, że ​​ zaniedbanie nie wymaga umowy .

  1. Naruszenie obowiązku: rozsądna osoba może przewidzieć , że „dowód słuszności koncepcji” może spowodować szkody. W związku z tym czynność udostępniania kodu nie spełnia oczekiwanego standardu. Jeśli jesteś informatykiem, trudno będzie obronić ten punkt.
  2. Istnieje związek przyczynowy między Twoim kodem zwolnienia i wynikłych szkód.

  3. Ponosisz odpowiedzialność za zaniedbanie”.

  4. Uszkodzenie: to jest prawdopodobne, że użytkownicy będą pozwać sprzedawcę oprogramowania za swoje straty. Dostawca oprogramowania następnie pozwie Cię do sądu, ponieważ z twojego powodu dostawca oprogramowania musi wypłacić odszkodowanie swoim klientom.

To oczywiście zależy od tego, co dokładnie wydałeś Publicznie. Na przykład, jeśli potrzebny jest znaczny wysiłek, aby przekształcić swój „dowód słuszności koncepcji” w rzeczywisty exploit, a zastosowałeś obejście, aby uniknąć tej luki, możesz się bronić, argumentując, że powiązanie przyczynowo-skutkowe jest zbyt odległe .


Więc muszę zachować raport jako prywatny? A jeśli oprogramowanie jest oprogramowaniem typu open source?

Niezupełnie. Powinieneś podjąć rozsądne kroki, aby upewnić się, że Twój „dowód słuszności koncepcji” nie jest rzeczywistym exploitem, a haker potrzebuje dużo czasu, aby opracować działające złośliwe oprogramowanie. CVE to platforma, na której luki są publicznie udostępniane.


Co zrobić, jeśli dałeś dostawcy rozsądny czas na usunięcie luki?

Nie ma znaczenia (dla Ciebie), czy dostawca miał czas na naprawienie luki. Ma to znaczenie dla dostawcy, ponieważ jeśli coś wydarzy się później, jest on odpowiedzialny za poznanie problemu z dużym wyprzedzeniem i nie przydzielił odpowiednich zasobów do rozwiązania problemu.

Aby wykazać istnienie luki, nie ma wymagają instrukcji, jak wykorzystać tę lukę. Na przykład możesz nagrać film pokazujący skutki włamania.


Tutaj (Wayback Machine; oryginalny link nie działa) to interesująca lektura o tym, jak Motorola bierze sprawy własnymi rękami po tym, jak odkryli lukę w systemie Xerox CP-V, a Xerox nie załatał problemu.

Zaktualizowałem pytanie. Uważam, że odpowiedź miałaby zastosowanie tylko do sytuacji, w której luka dotyczy oprogramowania / sprzętu z „zamkniętego źródła”.
Sprawa, którą cytowałeś, dotyczyła Wielkiej Brytanii. Ponieważ pytanie zostało oznaczone jako stany zjednoczone, możesz wyraźnie wspomnieć, że cytujesz sprawę z Wielkiej Brytanii (lub jeśli cała odpowiedź jest oparta na prawie brytyjskim, powiedz to).
@cpast Dodałem odniesienie do sprawy w USA.
Pamiętaj, aby wspomnieć, że sprawa w USA jest sprawą prawa stanowego. Nie ma federalnego prawa zwyczajowego (chociaż prawnicy mogą dzielić włosy). Należy również pamiętać, że chociaż istnieje roszczenie z tytułu zaniedbania, istnieje szersza kwestia ** stojąca **, tj. Kto jest uprawniony do wniesienia roszczenia na początku, a także kwestia ** odszkodowania **. Więc w przypadku roszczenia z tytułu zaniedbania wszystkie są wymagane ** (1) ** obowiązek; ** (2) ** naruszenie; ** (3) ** związek przyczynowy; oraz ** (4) ** odszkodowanie, oraz ** (5) ** powód musi mieć legitymację do wniesienia roszczenia.
Ta odpowiedź wydaje się być nieco cofnięta - dlaczego to wina badacza, skoro programiści firmy, która napisała kod, nie potrafią liczyć i / lub pisać? Na przykład. pojedynczo itp. Podobnie, większość oprogramowania nie jest objęta gwarancją; jeśli producent specjalnie zdecydował się udzielić gwarancji, to nie twoja wina, że ​​zrobił to bez upewnienia się, że ich kod nie jest podatny na te pojedyncze lub inne proste błędy.
@cnst: to nie wina, a nauczanie innych, jak wykorzystywać oprogramowanie, które może zostać użyte do wyrządzenia szkody, jest złem. Ponadto nie jest prawdą, że większość oprogramowania nie jest objęta gwarancją: przynajmniej większość oprogramowania dla przedsiębiorstw ma taką gwarancję.
@kevin Nie zgadzam się, że uczenie innych, jak używać zestawu umiejętności, jest złe. Tak jak pokazanie komuś, jak posługiwać się bronią lub młotkiem, nie czyni z nich przestępców. To, co robią z tym pistoletem lub młotem, stanowiłoby przestępstwo.
@DigitalFire Zgadzam się. Należy dokonać rozróżnienia między nauczeniem kogoś, jak posługiwać się bronią, a pozostawieniem uzbrojonej broni na biurku. Jak powiedziałem, luka * może * zostać publicznie ujawniona w CVE.
Kevin, Dead link „Oto ciekawa lektura o tym, jak Motorola bierze sprawy w swoje ręce po tym, jak odkryli lukę w systemie Xerox CP-V, a Xerox nie załatał problemu”. Chcę to przeczytać):
@LateralTerminal Znalazłem go w pamięci podręcznej sieci i udostępniłem w koszu wklejania.
Kevin, czy to prawdziwa historia? Nawet jeśli nie, uwielbiam to.
@kevin To całkiem nieźle.
„Masz obowiązek zachowania ostrożności, aby uniknąć działań lub zaniedbań, które możesz rozsądnie przewidzieć, które mogą zranić sąsiada”. To myląca prezentacja cytatów. Donoghue nie stwierdził, że istnieje ogólny obowiązek zachowania ostrożności, aby uniknąć zaniedbania, stwierdził, że * jeśli * istnieje obowiązek zachowania ostrożności, wówczas ten obowiązek może zostać naruszony przez zaniedbanie. Ponadto, jeśli haker wykorzystuje ujawnienie informacji w celu dokonania exploita, działania hakera są wyraźnie przyczyną interwencji. Ponadto jakiekolwiek stwierdzenie odpowiedzialności wiązałoby się z pierwszą poprawką.


To pytanie i odpowiedź zostało automatycznie przetłumaczone z języka angielskiego.Oryginalna treść jest dostępna na stackexchange, za co dziękujemy za licencję cc by-sa 3.0, w ramach której jest rozpowszechniana.
Loading...