Quanti dettagli da pubblicizzare quando un fornitore di software aggiusta e fornisce un avviso? [chiuso]

Il modo "normale" di fare le cose è:

1. Chiunque trovi la falla contatta il venditore.
2. Il venditore crea la patch e la pubblica, spingendola ai clienti con una descrizione vaga ma spaventosa ("risolve un difetto che consente l'esecuzione di codice in modalità remota").
3. Alcune settimane più tardi , i dettagli sono pubblicati. Se tutto è andato bene, lo scopritore iniziale effettua la pubblicazione, in pieno accordo con il venditore, in modo da attribuire i crediti dovuti; e il venditore aggiunge un collegamento ai dettagli della pubblicazione nella propria documentazione.

Ad esempio, questo è quello che è successo con il difetto correlato a SSL "CRIME": i produttori di browser sono stati avvisati con diverse settimane di anticipo e hanno inviato patch. Occasionalmente, la descrizione vaga può essere sufficiente per alcune persone per indovina cosa sta succedendo qualche giorno prima della pubblicazione effettiva. La danza è una questione di delicatezza, specialmente con il software opensource, perché la patch codice sorgente è spesso abbastanza rivelatrice circa la natura esatta del problema.

Un lato psicologico del problema è che i cacciatori di vulnerabilità sono una folla difficile che può reagire, a volte, in modi emotivi un po 'scaldati, se ritengono che i venditori non reagiscano in modo appropriato o abbastanza veloce. I produttori di software preferiscono di solito mantenere segreti i difetti, ma se devono accettare la pubblicazione, allora, almeno, preferiscono avere un avvertimento in anticipo. Il baratto di "crediti dovuti per preavviso preventivo" è un accordo che ha un'alta probabilità di convincere la maggior parte dei cacciatori di bug non a spingere immediatamente l'exploit sui canali pubblici, quindi i produttori di software supporteranno questo "modo normale" ".

In definitiva , quando la polvere si è stabilizzata, tutti i dettagli dovrebbero essere pubblicati, perché la divulgazione completa è una grande base per la fiducia.

L'osservazione principale che farei su questo è che se qualcuno è in grado di scrivere codice di exploit per gestire molti di questi difetti, è anche probabile che sia in grado di analizzare la patch stessa per identificare il difetto. Conoscere i dettagli di dove esiste un difetto e anche il modo in cui generalmente funziona il difetto non dà necessariamente molto da fare per implementarlo.

È ancora necessario analizzare il sistema in questione e capire come dovrebbe essere implementato un exploit. Questo è lo stesso set di competenze necessario per analizzare cosa sta cambiando una patch e rimuove tutto il rumore, quindi il rischio di divulgazione pubblica di un bel po 'di dettagli probabilmente non è male purché non sia sufficiente per fare un lavoro sfruttare senza quella serie di abilità.

Detto questo, questo varia in base al tipo di vulnerabilità. Se esiste una vulnerabilità di SQL injection ad esempio, è molto più facile sfruttarla piuttosto che dire un overflow del buffer. Quindi, anche la natura della vulnerabilità deve essere presa in considerazione.

La chiave è fornire informazioni sufficienti che gli utenti comprendano la loro esposizione e possano prendere misure appropriate mentre cercano anche di non dare a un aggressore intelligente più dettagli su come implementare un attacco di lavoro che la patch stessa darebbe loro .