it-swarm-eu.dev

Jak eticky odhalit bezpečnostní chybu?

Jak eticky odhalit bezpečnostní chybu? Slyšel jsem, že na toto téma existují různé myšlenkové školy. Chtěl bych znát jejich výhody/nevýhody.

75
Olivier Lalonde

Vývojářům byste měli dát vědět soukromě, aby měli šanci to opravit. Poté, pokud a kdykoli se s touto chybou zabezpečení setkáte, byste měli vývojáři poskytnout dostatek času na vyřešení problému a kohokoli, kdo je mu vystaven, dostatek času na upgrade svých systémů. Osobně bych vývojářovi ve většině případů umožnil učinit oznámení v bulletinu zabezpečení, spíše než to oznámit sám. Alespoň bych čekal na potvrzení, že zranitelnost byla opravena. Pokud máte čas a máte přístup ke zdrojovému kódu, můžete také poskytnout opravu.

43
VirtuosiMedia

Osobně si myslím, že odpovědné zveřejnění se zdá být nejlepším způsobem, jak jít z etického hlediska a dobře fungoval pro Dana Kaminského, který odhalil podrobnosti o zranitelnosti otravy mezipamětí DNS. Ale vše záleží velmi na společnosti nebo skupině, se kterou jednáte, a také na uživatelské základně, na kterou bude mít vliv.

27
Mark Davidson

@VirtuosiMedia odvádí skvělou práci, když navrhuje „Odpovědné zveřejnění“.

Chtěl bych přidat dva body:

  • Spolupracujte s prodejcem (pokud můžete), abyste se ujistili, že jej plně pochopili a nevydávají napůl upečenou náplast.
  • Pokud vás dodavatel ignoruje nebo vás ignoruje, zkuste to dál. Pokud však tvrdí, že to není zranitelnost, pokračujte a publikujte. Tak hlasitě, jak je to možné. Pokud slíbili, že to napraví, ale ne, pokuste se od nich získat odpověď spolu s konečnou časovou osou, k níž se zavázali. V určitém okamžiku, pokud se budou stále odkládat, můžete jim nakonec říci, že přesto budete publikovat - a pak jim věnujte nějaký čas na to, aby to skutečně opravili (ale krátké a omezené).
18
AviD

Toto je jedna sakra složitého tématu. Zapojil jsem se do odhalení chyby opětného vyjednávání TLS před pár lety a věřte mi, že jsme se velmi těžko snažili být „zodpovědní“, ale nakonec se nám podařilo hlavně pissing všichni kolem nás a (možná) zpoždění skutečné vydání opravy. Nemluvě o tom, že oznámení dodavatele je nutně špatné, pouze to, že je opravdu snadné se rozšlehnout a ukončit, což způsobuje tolik škod, jako je dobré nebo horší.

V našem případě to vyřešilo akci IETF ( RFC 5746 ), a přestože jsme měli internetový koncept připraven v den, kdy došlo k úniku, skutečnou práci debatování a rozhodování o řešení trvalo asi další tři měsíce a opravdu nezačalo vážně, dokud nedošlo ke zveřejnění.

Každopádně to není odpověď na vaši otázku, ale je to jeden z nejzajímavějších příběhů o poznání, o kterých vím. Více o tomto příběhu v 2010 ShmooCon keynote Udělal jsem to s Marshem Rayem, který problém objevil.

11
Steve Dispensa

Obecně záleží na reakci dodavatele. Dobrou praxí je, když výzkumný pracovník v oblasti zabezpečení informuje dodavatele o zranitelnosti, a pak během konverzace hovoříte o podmínkách zveřejnění dokumentu o zneužití této chyby. Výzkumník si vlastně vybere, co s touto chybou zabezpečení dělat - publikovat později nebo ne. Pak prodejce uvolní opravu nebo novou verzi produktu. Možná. Jak ale ukazují zkušenosti - ne všichni prodejci jsou tak milí. Někteří z nich opravují chyby potichu, aniž by informovali konečné uživatele a vědce, někteří raději výzkumníka ignorují. Jiní se dokonce snaží žalovat. To je důvod, proč je někdy anonymita preferovaným způsobem počáteční komunikace s neznámým prodejcem.

Také bych chtěl připustit, že existují programy odměn za chyby - ty nabízí Google, Mozilla. Kromě toho si ostatní kupují zranitelnosti - ZDI , iDefense , SNOsoft , přichází „exploit hub“ a atd. Existují tedy alespoň tři způsoby, jak informovat dodavatele - přímo, zveřejněním informací o zranitelnosti na nějakém seznamu nebo prostřednictvím společností třetích stran.

8
anonymous

Pokud mají sledovač veřejných problémů, podívejte se, zda můžete podat chybu s označením „soukromý“ nebo „zabezpečení“.

E-mail [email protected] název společnosti a dejte jim vědět.

Pokud neodpovídají poměrně rychle (viz „Okno zveřejnění“ v článku Schneier níže), musíte přemýšlet o jejich prozrazení. Hledejte e-mailové seznamy, na kterých se akademici/odborníci na bezpečnost schovávají, a zeptejte se jich, jak hlásí problémy dotyčnému prodejci. Mohou být schopni představit správné místo v organizaci.

Pokud se vše nezdaří, přečtěte si Schneierův bit a přemýšlejte o tom, zda by úplné odhalení nebylo součástí problému nebo součástí řešení.

Bruce Schneier uvádí argument pro úplné zveřejnění za určitých okolností na základě standardu „být součástí řešení, nikoli součástí problému“. Určitě to stojí za přečtení.

Toto je klasická debata „bugové tajemství vs. úplné odhalení“. Napsal jsem o tom dříve v Crypto-Gram; ostatní o tom také napsali. Je to komplikovaný problém s jemnými důsledky po celé počítačové bezpečnosti a stojí za to znovu diskutovat.

...

Tento tok bezplatných informací, jak kódu popisu, tak dokladu o konceptu, je také nezbytný pro výzkum bezpečnosti. Výzkum a vývoj v oblasti počítačové bezpečnosti se v posledním desetiletí rozkvětu, a velkou část lze připsat hnutí za úplné zveřejňování. Schopnost publikovat výsledky výzkumu - dobré i špatné - vede k lepší bezpečnosti pro všechny. Bez zveřejnění se komunita zabezpečení nemůže poučit z chyb druhých. Každý musí pracovat se zavřenými žaluziemi a dělat stejné chyby znovu a znovu. Úplné zveřejnění je nezbytné, pokud chceme i nadále zlepšovat zabezpečení našich počítačů a sítí.

...

Za druhé, věřím v to, že prodávajícímu předem oznámím. CERT to vzal do extrému, někdy prodávajícímu poskytl roky, aby problém vyřešil.

...

Líbí se mi metrika „být součástí řešení, ne součástí problému“. Součástí řešení je zkoumání bezpečnosti. Součástí řešení je přesvědčování dodavatelů k řešení problémů. Výsev je součástí problému. Součástí problému je předání nástrojů útoku bezradným teenagerům.

6
Mike Samuel