A biztonsági hibák részleteinek közlésével kapcsolatos hozzáállások közül szerintem a ... helyes.

Titkosítás, biztonság, privát szféra

teljes, azonnali, részletes (full disclosure)
12% (68 szavazat)
a meghatározott türelmi idő letelte utáni automatikus közlés (pl. a Google-féle 90 nap határidős irányelv)
68% (371 szavazat)
koordinált sebezhetőség-közlés (Microsoft által szorgalmazott irányelv)
8% (46 szavazat)
Egyéb, leírom.
1% (4 szavazat)
Csak az eredmény érdekel.
10% (56 szavazat)
Összes szavazat: 545

( dhary | 2015. 01. 13., k – 12:33 )

[ ] a másodikra szavaztam volna, de megláttam a google nevét és inkább gyorsan rákerestem valamire a duckduckgo-val

( gelei v | 2015. 01. 13., k – 13:57 )

Gondolom aki az elsőre szavazott, életében nem látott még kritikus rendszert közelről.

Vagy úgy gondolja, hogy az ellenség már úgyis ismeri ezeket, nem csak a közzétételből ismeri meg, viszont a kritikus rendszer üzemeltetője a türelmi idő alatt hamis biztonságérzetben él, miközben a kritikus rendszerre ki-be járkál az, aki akar.

Bezzeg ha közzéteszik, akkor a fenyegetettség ismeretében lehet valamit tenni addig is, amíg a bug nincs kijavítva. Pl. le lehet állítani a lukas szolgáltatást, vagy ilyesmi.

Naja, csak amikor valaki egyből elkezdi fosni az infót publikusra ahelyett, hogy írna egy levelet az info@-ra, azért ne várjon már teljes dícséretet. Főleg, ha olyan módon fért hozzá valamihez, amire láthatóan nem a normál használat mellett futott bele, hanem kifejezetten kotorászott.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Számomra a sokak szemében hősként körbeünnepelt fehérkalaposkodás is sok esetben felveti a rosszindulatot, mikor elkezdi elemezgetni olyan inputokkal a rendszert, amit normál használat mellett nem kerül bele a rendszerbe (és most ne ilyen yourbank féle töketlenkedésre gondolj), amit sikeresen megfejelnek azzal, hogy még anélkül, hogy te érdemben reagálni tudj, publikálják a nagyvilágnak.

Ez senkinek nem rossz, mert
- te nem tudsz reagálni a hibára
- rendszer veszélyeztetett
- aki magától nem találta volna meg vagy nem akarta eddig megtámadni a rendszert, az most egyből nekiállhat támadni.

Végeredményben mindenki szív.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

You made my day. Hint: a fehér kalapos nem azért elemez normális használat mellett nem előforduló inputot, mert rosszindulatú, hanem azért mert ebből él (ezért kapja a fizetését mint penteszter vagy ezzel akarja reklámozni a biztonsági cégét stb.). Ha ők nem tennék ezt, a fekete kalaposok akkor is csinálnák, de igazad van, akkor mindenki sokkal nyugodtabban aludna.

Kritikus rendszernél nem attól kell félned, aki egy exploittal együtt publikált hibát ki tud használni, hanem attól, aki ezt a hibát a fehér kalapostól függetlenül saját maga is meg tudta találni és nem publikálta.

Vagy ugy gondolkodik, hogy a hibarol jobb, ha mindenki tud, mert ha o megtalalta, mas is megtalalja, es esetleg senkinek sem szol. Vagy szol a vendornak, aki meg elhallgatja (megveszi a jelentot kilora, elhuzza az idot, stb, ezer modszer van ra). Emoge is lehet rosszindulatot sejteni, de az igazsaghoz kozelebb all, hogy a valosag bizony nem fekete-feher. Raadasul a hibat megtalalonak sem biztos, hogy van kapacitasa azzal foglalkozni, hogy a vendorral egyezkedjen.

Egy kutato szamara, aki tobb tucatnyi bug megtalalasaert es jelenteseert felel, full disclosure a legkenyelmesebb. Egy embernek tucat vendorral levelezgetnie netto szivas. Kompromisszum lehet az X ido utani publikalas, de annak is megvannak a kemeny hatulutoi.

--
|8]

Nem kell túl sokat egyezkedni a vendorral, de úgy kívánná a józan ész, hogy előbb a vendor tudjon róla, és utána mindenki más. Adott esetben elég lenne írni dobni nekik egy emailt, még ez is sokkal jobb, mintha kipakolná a netre a zeroday-t.

Az nem fehérkalapos, aki visszaél a megszerzett infóval, márpedig a full disclosure (a vendor értesítése nélkül) nem éppen jóhiszemű cselekedet.

Ertelmes vendornak vannak emberei arra, hogy a relevans listakon ott legyen. Pont ugyanakkor fog rola tudni, mint barki mas.

A full disclosure teljesen johiszemu dolog tud lenni, egyatalan nem visszaeles. Csak nem feltetlen a vendor szemszogebol kell nezni (bar amikor vendor oldalrol neztem, akkor sem volt gondom vele, se mint maganszemely, se mint cegnel alkalmazott). Mint uzemelteto, en sokkal jobban orulok egy FD-nek, mert akkor pikk-pakk kilovom a sebezheto alkalmazast, vagy - ha lehetseges - enyhitem vagy megkerulom a problemat. Ha nincs FD, akkor potencialisan hetekig, honapokig sebezheto a rendszer, es en nyugodtan ulok, azt hiszem, hogy jol van. Inkabb leallas legyen, mint hogy ki-be jarkaljanak rajta.

--
|8]

> Ha nincs FD, akkor potencialisan hetekig, honapokig sebezheto a rendszer, es en nyugodtan ulok,

Na várj. Attól még nem kell nyugodtan ülni, hogy nincs FD. Megkapod az infót, csak te, mint vendor. Kijavítjátok a hibát, mindenki örül. Ha ez nem így történik (t.i. a bejelentés ellenére nyugodtan ücsörögtök), az PEBKAC.

"Mint uzemelteto", kezdodik a relevans resz. Az uzemelteto szemszogebol nezd azt a reszt, ne a vendorebol.

Ha X vendor A termeket N uzemelteti, akkor N akkor fog a hibarol ertesulni, ha:

- FD esete forog fenn. Akkor letiltja, vagy egyeb modon kezeli amig nincs korrekt fix.
- Vendortol, amikor is elotte potencialisan hetekig tortek a rendszeret.
- Felfedezotol, ha vendor mellett valami oknal fogva N-t is megtalalta es szolt neki elore.

Harmadik eset ritka mint a feher hollo. Masodik eset uzemeltetoi szemmel remalom. Koszonom, FD nekem jo lesz. Mint irtam, inkabb alljon a rendszer, minthogy hosszu ideig sebezheto legyen (ha egyvalaki megtalalta a lyukat, mas is megfogja, lehet, hogy korabban mar meg is tette).

--
|8]

"Mint irtam, inkabb alljon a rendszer, minthogy hosszu ideig sebezheto legyen"

Kiváncsi leszek, hogy akkor is ezt mondod-e, mikor a megrendelőd/munkaadód felmondja a szerződést és/vagy szimplán nem fizet ki, mert leállítod azt a szolgáltatást, amiből a bevétele (és amiből a te fizetésed) van.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Botorság általánosítani. inkább örülnétek, hogy hallotok többféle véleményt.

Ha olyan a helyzet hogy féltened kell a seggedet akkor döntse el a munkaadó,megrendelő, hogy leállítsátok-e a szolgáltatást ilyen esetben és legyen erre utasítás/egyedi döntés, avagy vállalja ő a felelősséget a helyzet ismeretében. De ha fingja sincs a megrendelőd/munkaadódnak meg neked se az egészről.. ..akkor esélye sincs felháborodni se. Csak majd utólag főhet a feje..

Nyilvan a megrendelovel/munkaadoval egyeztetek leallitas elott, ahogy a multban is tettem, amikor ilyen eset volt. Volt amikor az volt a dontes, hogy leallitjuk, es ertesitjuk a sajat felhasznaloinkat, volt amikor az volt a dontes, hogy nem kritikus, majd odafigyelunk. Tapasztalatbol beszelek, nem hasbol.

Amelyik munkaado/megbizo nem tudja ezt a helyzetet kezelni, annak nem dolgozom. (Eddig mind tudta.)

--
|8]

Ahmednek, a zseniális informatikusnak és az IS titkos ügynökének egy lerészegedés alkalmával a következőt meséli a barátja, aki az Orion repülésirányító szoftveren dolgozik: "Beszéltem már neked Joe-ról, arról a balfékről, szerencsére már nem dolgozik nálunk. Olyan pocsék minőségű kódot írt most is azzal szívunk. A múlt héten valaki talált egy bugot benne, amivel át lehet írni a gépek magasság adatát. Csak egy input hossz ellnőrzést hagyott le a szerencsétlen, amit az előtét rendszerben is meg lehetne csinálni. Majd a következő verzióban ki lesz javítva... Még egy unicumot! “

Ha ezután 1 héttel meghal 600 ember, akik élhetnének, ha a bug nem csak a gyártó által ismert, azért ki a felelős?

Ps: elnézést minden Ahmedtől és Joe-tól

Na jó, de ilyet én is tudok: Ahmed nem a bennfentestől tudja meg az exploitot, hanem az együgyű fehérkalapos megoldja full disclosure-ral, így eljuttatva az infót a világ összes terrorszervezetéhek, scriptkiddie-éhek, stb.

Ők azonnal rácuppannak a dologra, így másnap lezuhan az összes repülő, ezzel meghal 542897523 ember. Harmadnapra persze megérkezik a patch, de ugye már meghalt 542897523 ember. Persze most a példa kedvéért direkt túltoltam a demagógiát, de ettől még a lényeg érezhető.

Ebben az esetben valoszinubb, hogy azok a repulok fel sem szallnak, ezzel elkerulve az egesz problemat. Mig ha Ahmed szol a vendornak, kozben Katyusa is ratalal a hibara, es mivel az o kalapja fekete, mint a szen, megvan a baj, mert a repulogepek bizony fel fognak szallni, vendor<->uzemelteto latency miatt is.

--
|8]

Na igen, csak ugye itt jön be az a dilemma, hogy mekkora a kockázat, és mekkora kiesést okoz egy leállás. Sajnos nem fekete-fehér, könnyen elképzelhető, hogy a rendszert nem állítják le, mert a garantált veszteség súlyosabb, mint a potenciális (beleszámolva persze, hogy ez utóbbi nem is biztos, hogy megtörténik)

Ez ott bukik meg, hogy az egyszeri felhasználó még sosem hallotta a 'kockázat' szót. Az átlagember továbbra sem ért az informatikához, mindenhova ugyanazt a jelszót használja, ami nagyjából az egytől hatig kisbé nagybé bonyolultságon mozog, az adatlapja pedig full public-ra van állítva Facebookon.

Hol dönt ő el bármit? Ha kihúzod alóla a szolgáltatást, akkor átmegy másik céghez, hiába magyarázod neki, hogy ez az ő érdeke.

Na jó, nézzünk egy példát.

> ISP
> kiderül, hogy sebezhetőség van egy rendszerben
> jön egy FD, lenyomom az egész országban a netet
> a javítás 3 napig tart, ezalatt pár tízezer B2C ügyfél szerződést bont
> néhány B2B ügyfél hatalmas kötbért követel és szerződést bont
> engem kirúgnak/kivégeznek

Senki sem nyer. :) Na mindegy, nyilván mindkét megoldásnak van előnye és hátránya, meggyőzni meg úgysem fogjuk egymást. :D

Ezert kell merlegelni. Nyilvan ebben az esetben nem huzza le az ember. De ha a merlegeles lehetoseget is elveszted, es azt a par B2* ugyfelet megtorik csunyan, akkor szerzodest bontanak, hogy nem figyelmeztetted oket, kotbert kovetelnek, es a hirneveden is esett egy szep csorba.

Ha nem nalad van a dontes, akkor te mindenkepp szivsz.

--
|8]

Nem pont ide, csak itt ötlött fel, hogy az nem lehetséges, hogy feketekalap már régóta tudja, használja és azzal, hogy időd adsz a cégnek foltozni, mivel hagysz átfutási időt a megoldásra, feketekalap malmára hajtod a vizet, mert se megoldás, se információ nincs, hogy védekezz ellene? És persze ettől a várakozástól zuhan le a repülő, érkezik el a világvége, satöbbi.

"Belépés díjtalan, kilépés bizonytalan."
"Vajon mit várok a sorstól, ha hányok az édestől, és izzadok a sóstól."

Amit mondtál nettó baromság, bocsi. Pont az a lényeg, hogy a feketekalaposok előtt találják meg a hibákat, és legyen a fejlesztőnek lehetősége kijavítani mielőtt nagyobb baj lenne. Még az azonnali könyörtelen publikáció is jobb annál, mint, hogy csak a feketekalaposok tudják, és a világ tudta nélkül ki-be járkálnak a rendszerekben. Félre ne értsd szerintem is elegánsabb előbb csak szólni, aztán közkinccsé tenni a hibát, de a legrosszabb nem szólni vagy nem is keresni. Elsődleges a felhasználók, és az érzékeny adatok biztonsága, az pedig, hogy a fejlesztő hogyan oldja meg a problémát az ő dolga, több alternatíva is létezik, de fájni mindenféleképpen fog a fejlesztőnek/üzemeltetőnek.

-
Változékony Grails alkalmazás konfiguráció facepalm

"Elsődleges a felhasználók, "

Ha elsődleges lenne a felhasználó, akkor egy túlbuzgó gyökér nem kürtölné világgá, hogyan basszanak ki a felhasználóval, már bocs.

És nem, ha esélye sincs a fejlesztőnek, hogy kijavítsa, mielőtt garantáltan mindenki tudni fog a hibáról, az nem jobb, hanem a létező legrosszabb megoldás.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Honnan? És továbbra is kérdem: miért jobb az, hogy egy olyan csoportnak adják oda a hibajelentést, akiknek opcionálisan kurvára semmi köze a rendszerhez cserébe egy halom olyan tagja lehet, akik akár potenciálisan ártani akarnak?

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Hát ahonnan a többiek, persze abban igazat adok neked, hogy vannak olyan helyek, ahol nem triviális a hiba javítása, mert mondjuk többmillió user gépén kell frisítést végrehajtani, ami a legegyszerűbb változtatás esetén is több órát/napot vesz igénybe (ha egyáltalán mindehol települ). Ilyen esetben kártékony az azonnali publikálás. Ahogy ezt a módszert, mint minden mást is, ésszel kell használni (de ez mindenre elmondható, nem lehet a kalapácsot veszélyes fegyvernek kikiáltani, és eliminálni, mert embert lehet vele ölni, mert mivel verjük akkor be a szöget).

-
Változékony Grails alkalmazás konfiguráció facepalm

Off:
(Én lassan úgy érzem, hogy rámférne egy kis információhiány, és vakságban tartás, mert akkor lehet, hogy picit fehérebben látnám a világot, szóval időnként úgy érzem, hogy az információ csak kibaszás ...de ez ide nagyon off és nagyon politikai.)

Ne kattints ide!

Volt mar olyan, hogy egy programom sebezhetosegerol publikus jelentesbol ertesultem. Nem volt nagyobb gaz, mintha elobb nekem szol (olyan is volt) a megtalaloja. Egyreszt ha o megtalalta, mas is megtalalhatta mar, csak nem szolt, raadasul az ilyen bejelentesekben sok esetben ott szokott lenni az is, hogyan lehet enyhiteni a bajon. Es ezt megirja helyettem, teljesen jo. A felhasznalok pontosan ugyanakkor kaptak meg a javitast, mintha elobb nekem szolt volna. Viszont elobb lettek tajekoztatva, es addig tudtak enyhiteni a problemat, vagy lekapcsolni a programot ideiglenesen. Csomo munkat levett a vallamrol.

Raadasul igy sokkal nagyobb a kesztetes, hogy az ember foglalkozzon a problemaval. Plane ha az ember nem egy ember, hanem egy nagyobb ceg. Egy publikus sebezhetoseg nagyon jo utokartya a fejlesztok kezeben, hogy miert kene megis ezt a bugot megjavitani, es securityre tobb energiat forditani. Mert ugye egy cegnel nem mindig a fejlesztok dontik el, hogy merrefele megy a fejlesztes. (Igen, ez rossz igy, de sajnos igy mukodik a vilag jelentos resze.)

--
|8]

Nem ez a gond, hanem az, hogy egy felelőtlen vadbarom miatt olyan kezébe is eljuthat az információ, aki egyrészt rosszindulatúan ki is fogja használni és ha nem tudott volna róla, a büdös életben nem használta volna ki a hibát.

Az a gond, hogy itt egyesek megideologizálják azt, hogy azzal, hogy egy sechole nyilvánosságra kerül, azzal csak jót tesznek, holott valójában onnan kezdve, hogy egy szűk körben lévő információ nagy nyilvánosságot kap, kontrollálhatatlan. És ezzel az userek biztosan szívni fognak (mert vagy potenciálisan áldozatai lehetnek egy támadásnak vagy leálló szolgáltatással találkoznak).

Arról nem beszélve, hogy egy Google esetén több, mint kétséges érvelés az userek védelme, mint érv egy konkurens cég terméke esetén.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

De, pontosan erről van szó. Az egész szál abból indult, hogy a kritikus rendszernél nem lehet full disclosure. Szerintem meg ott van szükség rá igazán, mert kritikus rendszer esetén valószínűleg van a hozzáértő üzemeltetés meg nem spórolták le az egyéb határvédelmi elemeket, így egy ismerté vált, de javítás nélküli 0-day ellen órákon belül lehet védekezni - ha másnem a szolgáltatás ideiglenes lekapcsolásával. Ha viszont 90 - 120 - 400 vagy ki tudja hány napig a gyártó megtartja magának - ami azt jelenti, hogy nem egy ember fog róla tudni, hanem egy team, és amit 1+ ember tud, az már nem titok - azzal a nyilvánosságra kerülésének esélye is exponenciálisan napról napra nő. A vége az lesz, hogy a gyártó még nem javított, de a SilkRoad aktuális reinkarnációján a működő exploitot meg lehet venni párszáz bitcoinért, és az jár ki meg be a rendszeredben, aki csak akar.

Az iráni atomdúsító sem volt neten, aztán mégis, mik nem történtek.

Egyébként meg millió olyan eszköz van, aminek kellhet internet, legyen az orvosok, rendőrök, tűzoltók, közlekedés-irányítás, ilyen-olyan mérőműszerek, stb. stb. stb.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Akkor én, mint a rendszer tulajdonosa, hadd dönthessem el, hogy mit teszek a hiba ellen annak javításáig. A legrosszabb helyzetben akkor vagyok, amikor én nem tudok róla, hogy lyukas a rendszerem, de rengeteg más szereplő meg tudja ezt, mert akkor nem tudok semmi olyan kiegészítő védelmet használni, amí megakadályozza a kompromittálást.

A teljes elhallgatás és az FD között azért van még pár lehetőség. Pláne, hogy arra is egész szép iparág épült ki, ami keresi az eddig ismeretlen hibákat kihasználó támadásokat, így jóval nagyobb az esély arra, hogy az általad vázolt legrosszabb eset bekövetkezzen. Úgy rémlik a Google policyje is olyan, hogy ha a hibát már kihasználják, akkor nem jár a 90 nap.

Amikor az "etikus" hacker nyilvánosságra hozza a hibát, a fejlesztőnek módjában áll reagálni, akár teljes leállással (végtére is hibás a kód, legközelebb nem követik el ezt a hibát). Ez esetben lehet szív a user, de legalább biztonságna tudhatja a dolgait. Ha megtalálja és ad türelmiidőt, akkor a fejlesztőnek szintén van ideje reagálni (hibás a kód, illik javítani), itt még mindig van esély, hogy egy etikátlan hacker is megtalálja a sebezhetőséget, szóval ez egyfajta hamis biztonság. Ha viszont nem hozza nyílvánosságra, nem keresi stb, na arra nem tud reagálni a fejlesztő, a user akkor szívja a legnagyobbat. Ne hidd azt, hogy a fekete kalaposok nem mozgatnak meg minden követ azért, hogy hibát találjanak, és azt valamilyen módon pénzzé konvertálják. Egy dolgot lehet tenni, megelőzni a bajt.

-
Változékony Grails alkalmazás konfiguráció facepalm

"Ez esetben lehet szív a user, de legalább biztonságna tudhatja a dolgait."

Usere 99,9%-át kurvára nem fogja érdekelni se nem értékelni.

"Ez esetben lehet szív a user"

Nem lehet, biztos. És ha mondjuk emiatt az usernek lesz egy _biztos_ bevételkiesése mert mondjuk lelőtted 2 napra a levelezését/webshopját/akármijét és emiatt van neki bevételkiesése, telibe fogja szarni a _lehetséges_ támadást. Vagy enduser oldalról: valami olyan szolgáltatást nem ér el, amiért fizetett, morcos lesz.

"akkor a fejlesztőnek szintén van ideje reagálni"

Akkor rohadtul nem, ha egyből publicba megy a hiba.

"(hibás a kód, illik javítani)"

Igen, illik. Másik oldalról meg vannak hibák, amik nem csak annyi, hogy két sort módosítani kell a rendszerben, hanem mondjuk komplett protokolt, mert koncepcionálisan lett elrontva valami akár tervezéskor, akár későbbi áttervezéskor. És ez halmozottan hátrányos, ha mondjuk sok usernek/rendszernek kell tudnia együttműködni ez idő alatt. Olyankor még a 90 nap is kevés lehet és nem azért, mert hanyag a fejlesztő, hanem mert sok idő minden useren végigvinni a módosítást. Kiváltképp akkor, ha mondjuk te csak egy protokollt és egy szolgáltatást adsz csatlakoznia már az usernek kell hozzá. Ott nem csak arra kell figyelni, hogy te mikor készülsz el a módosítással, hanem, hogy az összes többi user is mikor tud elkészülni vele.

"Ha viszont nem hozza nyílvánosságra"

Miért kell nyilvánosságra hozni? Miért nem a szállítónak és/vagy a fejlesztőnek szól? Komolyan nem értem... ha az ügyviteli rendszerünkkel van valami problémám, nem a hupon keresek rá megoldást, hanem a supportjukon, ha meg nem adnak, ott verem az asztalt.

"itt még mindig van esély, hogy egy etikátlan hacker is megtalálja a sebezhetőséget"

De ember, mikor fogja hamarább megtalálni? Ha ott a hiba valahol elrejtve vagy ha még az orra alá is tolod? Ennyire nem lehet nehéz ezt az apró különbséget megérteni. Igen, fennáll a veszélye, hogy egy blackhat is megtalálja. De mindenképp több, ha a fejlesztőn és a megtalálón kívül még tud más is róla. Ezt miért olyan rohadt nehéz megérteni?

"Egy dolgot lehet tenni, megelőzni a bajt."

Azzal, hogy mindent egyből publikáltatni akarsz, azzal csak tetézed.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Nem fogjuk egymást meggyőzni azthiszem ;), az agyatlanságot semilyen szinten nem támogatom, ahogy fentebb is írtam, vannak szituációk, amikor lehet egy módszert alkalmazni és vannak amikor nem. Szerintem te is egy kicsit sarkosan látod ezt a helyzetet, meg én is, szóval valahol kettönk között van az igazság.

-
Változékony Grails alkalmazás konfiguráció facepalm

"Miért kell nyilvánosságra hozni? Miért nem a szállítónak és/vagy a fejlesztőnek szól? Komolyan nem értem... ha az ügyviteli rendszerünkkel van valami problémám, nem a hupon keresek rá megoldást, hanem a supportjukon, ha meg nem adnak, ott verem az asztalt."

1. Pénz és botrány vezérelt mangement világában élünk.
2. Pl. lehet hogy te "x" pici cég vagy és találsz egy hibát "y" nagy cég termékében. Ő meg mondjuk azt mondja hogy leszarja/majd javítom( (C) Soon) stb. Nem tudsz tenni semmit az általad említett asztal csapkodáson kívül...

Az azért itt a nagy védekezési kísérletedben megvan ugye, hogy a Google akkor kezdett rászívódni a Microsoft sebezhetőségekre, amikor az Operation Aurora keretében egy Microsoft 0day sebezhetőséget kihasználva 2010-ben betörtek hozzájuk és más high profile cégekhez? Hogy a színfalak mögött milyen egyeztetések zajlottak a Microsoft-tal, hogy a Google hány hibát próbált normálisan bejelenteni az senki sem tudja.

A Google lehet, hogy magát és a hozzá hasonló ügyfeleket próbálja védeni, amikor a közléssel a Microsoft reakcióidejét próbálja javítani.

--
trey @ gépház

Ha egyvalaki megtalalta, mas is meg fogja, vagy mar meg is tette, ez nem erv egyik oldal fele sem. Minden erveles ami arra epul, hogy "de igy bunozokhoz is eljuthat!" megbukik ott, hogy mibol gondolod, hogy naluk mar nincs meg regebbota? Mert ha megvan, es nem publikus a sechole, akkor potencialisan MINDEN user sebezheto marad tovabb. Ha nyilvanos, akkor ok maguk tudnak donteni, hogy mit lepjenek: leallitsak, korbevedjek, leszarjak, stb.

End-user kezeben a dontes a usernek jobb, mintha ezt helyette dontik el. Mindig donthet ugy, hogy tesz ra magasrol, es megvarja a vendor fixet. Pont ott van akkor, mintha nem is tudna rola, viszont mas userek donthetnek maskepp. Ha kiveszed a kezukbol ezt az informaciot, akkor senki sem tud maskepp donteni, es az bizony szivas.

--
|8]

( turul16 v | 2015. 01. 13., k – 15:47 )

"koordinált sebezhetőség-közlés" 14 napon belul fixalva.
Ha valami nincs kijavitva 30 napon keresztul miutan a vendor reprodukalni tudta a hibat, azt lehet publikalni :)

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

( BaT | 2015. 01. 13., k – 17:03 )

Valahol a 2. és 3. között. Pl. legyen a közlés ideje relaxálva a hiba súlyosságával, felhasználói érintettséggel, vendor hozzáállással (ugye a konkrét esetben 2 hétről volt szó, ez szerintem vállalható), és legyen egyértelműen közölve a másik féllel, hogy az így kialakított dátumokhoz viszont tartja magát a hiba bejelentője. Tehát azt ne lehessen megtenni, hogy a vendor 3 hónapig nem csinál semmit, majd megkéri a másik felet, hogy még egy hónapig tolja ki a közlés időpontját, de azt igen, hogy egy előzetes vizsgálat után megkéri, hogy a közlés idejét igazítsa a vendor időrendjéhez.

( bucko | 2015. 01. 13., k – 17:05 )

A sebezhető rendszerelemet el kell távolítani.
Úgy sincs rá szükség. :)

( sj | 2015. 01. 13., k – 22:17 )

en ebben hiszek:

- end user oldalrol: asap kozzetetel, amiben erthetoen le van irva a problema, ill. ha lehetseges, valami mitigation, workaround, whatever. Exploit nem kene melle.
- fejleszto oldalrol: asap full disclosure + exploit is (ha van)

Ha lejart a turlemi ido, akkor mehet az FD.

--
"Pont attól akartam megkímélni magam, hogy gondolkodni kelljen ;)" (lajos22)

( wachag | 2015. 01. 14., sze – 09:01 )

Troll:
Attól függ.
Ha bash, openssl és egyéb, nyílt forrású és/vagy Google-höz köthető szoftverekről van szó, akkor az azonnali FD-t tartom jónak. Égjenek csak.
Ha a Microsoftról, Apple-ről van szó, akkor természetesen úgy tartom helyesnek, hogy ők diktálják az időt.

Én legalább nyíltan leírom :-)

( kisg v | 2015. 01. 14., sze – 10:26 )

A fix határidő utáni automata közlésre szavaztam, bár a 90 napot soknak érzem, illetve különböző jellegű sebezhetőségek esetén más-más határidőt tartanék indokoltnak - 90 napnál sehol sem többet.

Az azonnali full disclosure-ral a gondom, hogy azzal a feltételezéssel él, hogy más már biztos megtalálta a hibát, és ki is használja, tehát minél hamarabb megtudja mindenki, hogy sebezhető a rendszer, annál jobb. Ez egyáltalán nem biztos.

1. Ha vannak "in the wild" 0day sebezhetőségek egy adott szoftverhez, egyáltalán nem biztos, hogy pont az köztük van, amit éppen megtaláltunk.

2. A hiba kijavítására az esetek túlnyomó többségében a gyártó a legalkalmasabb - ez még nyílt forrású szoftverek esetében is így van. Ugyanis a gyártónak nem csak a hibát kell javítania, hanem a működési paramétereket is meg kell őriznie. Pl. tegyük fel, hogy a hiba triviális javítása 20%-os teljesítményregressziót okoz, ami miatt egy csomó szolgáltatás, ami használja a szoftverünket le DoS-olódik normál használat mellett. Persze el tudok képzelni olyan esetet, amikor még ezt is be kell(ene) vállalni, olyan szintű a probléma. Sajnos erre sincs általános recept, hogy mi a helyes viselkedés a gyártó részéről.

3. Emberek vagyunk - együtt kell(ene) dolgoznunk, még akkor is, ha a munkaadóink versenytársak. Mindenki követ el hibát, arra kellene koncentrálnunk, hogy a világ szoftvereinek biztonsága összességében egyre jobb legyen. Ehhez mindenek előtt bizalom és kölcsönös tisztelet kell. Ezt nehéz lesz úgy elérni, hogy nyilvánosan újjal mutogatunk azokra, akik éppen hibáztak, majd pedig szinpadiasan bekapcsoljuk a stoppert, hogy "na mennyi idő alatt javítod ki, haver"?

Sokkal nagyobb problémának tartom, hogy a biztonsági hibák javításának jelzésére nincs elfogadott szabvány a verziókövetőkben nyílt forrású projekteknél sem. Sőt: pl. a Linux kernelnél bevallottan obfuszkálják a commit üzeneteket, hogy a közmondásos script kiddie ne tudja őket megtalálni könnyen. Ez ahhoz vezet, hogy nem tudunk tanulni a múltból, és újra meg újra ugyanazokat a hibákat fogjuk elkövetni.

Valahol a Grsecurity környékén olvastam, hogy több tucat biztonsági hiba javítását portolták vissza és jelezték a 2.6.32.y karbantartójának, amiket az egyszerűen nem vett észre, hogy biztonsági hiba, és backportolni kéne, gondolom nem kis részben a fenti "remek" gyakorlat miatt.

( uid_4385 | 2015. 01. 14., sze – 11:03 )

kozhelyszeru dolgok:

1. A hiba nem azert letezik, mert valaki megtalalta (es nem is a megtalalas idopontjatol kezdve).

2. A hibat nem feltalaljak, hanem "implementaljak" es utana felfedezik/kihasznaljak.

En a google fele iranyra szavaztam(lehet, hogy a hataridon roviditenek), de az FD sem rossz valasztas.

Az FD mellett ervkent szolhat az, amit irtatok: le lehet allitani az erintett rendszert,
de van egy eset, amikor ez nem jarhato, ha _nem_ allithatod le (vagy nem azonnal), ekkor FD
eseten rosszabul jarhatsz, mint ha kapsz egy kis idot felkeszulni (vagy megjavitod vagy a leallast keszited elo),
ha meg annyi ido alatt nem tudsz erdemben reagalni, donteni akkor ugyis mindegy...