it-swarm-eu.dev

Sistemi open source e chiusi

La mia comprensione è che sistemi open source sono comunemente ritenuti più sicuri di sistemi open source .

Le ragioni per adottare un approccio, o una combinazione di questi, includono: norme culturali, finanziarie, posizionamento legale, sicurezza nazionale, ecc., Tutte in qualche modo correlate alla visione della cultura sull'effetto di avere quel sistema aperto o chiuso.

Una delle preoccupazioni principali è la sicurezza. Una posizione comune contro i sistemi open source è che un utente malintenzionato potrebbe sfruttare la debolezza all'interno del sistema, se noto. Una posizione comune contro i sistemi a fonte chiusa è che la mancanza di consapevolezza è nella migliore delle ipotesi una debole misura di sicurezza; comunemente indicato come sicurezza attraverso l'oscurità .

La domanda è: i sistemi open source sono in media migliori per la sicurezza rispetto ai sistemi chiusi? Se possibile, si prega di citare l'analisi nel maggior numero di settori possibili, ad esempio: software , militare , mercati finanziari , ecc.

Questa domanda era Domanda sulla sicurezza IT della settimana .
Leggi il 25 maggio 2012 post di blog per maggiori dettagli o invia il tuo Domanda della settimana.

53
blunders

L'idea che il software open source sia intrinsecamente più sicura del software closed source - o l'idea opposta - non ha senso. E quando le persone dicono qualcosa del genere spesso è solo FUD e non fa avanzare significativamente la discussione.

Per ragionare su questo devi limitare la discussione a un progetto specifico. Un software che graffia un prurito specifico, viene creato da un team specificato e ha un pubblico di destinazione ben definito. Per un caso così specifico, può essere possibile ragionare sul fatto che l'open source o la closed source servano meglio il progetto.

Il problema con il pitching di tutte le implementazioni "open source" rispetto a tutte le "closed source" è che non si sta solo confrontando le licenze. In pratica, open source è favorito dagli sforzi volontari indispensabili e la fonte chiusa è più comune negli sforzi commerciali. Quindi stiamo effettivamente confrontando:

  • Licenze.
  • Accesso al codice sorgente.
  • Molto diversi strutture di incentivazione , a scopo di lucro rispetto per divertimento.
  • Situazioni di responsabilità legale molto diverse.
  • Dimensioni della squadra e competenze della squadra diverse e selvaggiamente variabili.
  • eccetera.

Tentare di giudicare come tutto ciò funzioni per la sicurezza di tutto il software rilasciato come open/closed source non funziona. Diventa una dichiarazione di opinione, non un fatto.

50
Jesper M

Mantenuto il software è più sicuro del software che non lo è. Lo sforzo di manutenzione è, ovviamente, relativo alla complessità di detto software e al numero (e abilità) delle persone che lo stanno guardando. La teoria alla base della sicurezza dei sistemi open source è che ci sono "molti occhi" che guardano al codice sorgente. Ma questo dipende molto dalla popolarità del sistema.

Ad esempio, nel 2008 sono stati scoperti in OpenSSL numerosi buffer overflow , alcuni dei quali hanno portato all'esecuzione di codice in modalità remota. Questi bug erano nel codice da diversi anni. Quindi, sebbene OpenSSL fosse opensource e aveva una base di utenti sostanziale (questa è, dopotutto, la principale libreria SSL utilizzata per i siti Web HTTPS), il numero e l'abilità dei revisori del codice sorgente non erano sufficienti per superare la complessità intrinseca della decodifica ASN.1 (la parte di OpenSSL in cui si nascondono i bug) e del codice sorgente OpenSSL (francamente, questo non è il codice sorgente C più leggibile mai).

I sistemi a sorgente chiuso hanno, in media, molte meno persone che devono fare domande e risposte. Tuttavia, molti sistemi chiusi hanno pagato sviluppatori e tester, che possono impegnarsi a tempo pieno nel lavoro. Questo non è proprio inerente alla domanda di apertura/chiusura; alcune aziende impiegano persone per sviluppare sistemi open source e, presumibilmente, si potrebbe produrre un software open source gratuitamente (questo è relativamente comune nel caso di "freewares" per Windows). Tuttavia, esiste ancora una forte correlazione tra l'aver pagato i tester e l'essere fonte chiusa (la correlazione non implica la causalità, ma ciò non significa che le correlazioni debbano essere ignorate).

D'altra parte, essere di origine chiusa rende più facile nascondere i problemi di sicurezza, che è male, ovviamente.

Esistono esempi di sistemi sia open che closed source, con molti o pochissimi problemi di sicurezza. I sistemi operativi opensource * BSD ( FreeBSD , NetBSD e OpenBSD e pochi altri) hanno un'ottima reputazione in termini di sicurezza. Lo stesso vale per Solaris, anche quando era un sistema operativo a sorgente chiuso. D'altra parte, Windows ha (avuto) una terribile reputazione in materia.

Riepilogo: a mio avviso, l'idea "opensource implica sicurezza" è sopravvalutata. Ciò che è importante è il tempo (e l'abilità) dedicato al monitoraggio e alla risoluzione dei problemi di sicurezza, e questo è per lo più ortogonale alla questione dell'apertura della fonte. Comunque, non vuoi solo un sistema sicuro, ma vuoi anche un sistema che hai positivamente conosci per essere sicuro (non essere rapinato è importante, ma essere in grado dormire anche di notte). Per quel ruolo, i sistemi opensource hanno un leggero vantaggio: è più facile essere convinti che non ci sia una falla di sicurezza deliberatamente nascosta quando il sistema è opensource. Ma la fiducia è una cosa fluttuante, come è stato dimostrato con la recente tragicommedia intorno alla presunte backdoor in OpenBSD (per quanto ne so, si è rivelata un'aringa rossa, ma, concettualmente, non posso essere certo a meno che non controlli il codice da solo).

37
Thomas Pornin

Penso che la versione più semplice e più semplice di questa sia un'ingegneria del software. Di solito l'argomento segue: il software open source è più sicuro perché puoi vedere l'origine !

Hai le conoscenze di ingegneria del software per capire il kernel dall'alto in basso? Certo, puoi guardare un simile driver, ma hai una conoscenza completa di ciò che sta per dire davvero "ah sì, ci deve essere un bug lì"?

Ecco un esempio interessante: non molto tempo fa un bug di dereference con puntatore nullo è apparso in uno dei kernel beta che era una cosa abbastanza grande, scoperto dal ragazzo da grsecurity (patch PaX):

È stato introdotto in un pezzo di codice come questo:

pointer = struct->otherptr;

if ( pointer == NULL )
{
    /* error handling */
}

/* code continues, dereferencing that pointer
   which with the check optimised out, can be NULL. Problem. */

e il pointer == NULL check è stato ottimizzato dal compilatore, giustamente - dal momento che un puntatore null non può essere fatto riferimento a una struttura contenente membri, non ha senso che il puntatore nella funzione sia mai nullo. Il compilatore rimuove quindi il controllo che lo sviluppatore si aspettava fosse lì.

Tuttavia, concordemente, il codice sorgente di un progetto così ampio può sembrare corretto, ma in realtà non lo è.

Il problema è il livello di conoscenza necessario qui. Non solo devi avere una discreta familiarità con (in questo caso) C, Assembly, il particolare sottosistema del kernel, tutto ciò che accompagna lo sviluppo di kernel, ma devi anche capire cosa sta facendo il tuo compilatore.

Non fraintendetemi, concordo con Linus sul fatto che con abbastanza occhi, tutti gli insetti sono superficiali. Il problema è la conoscenza nel cervello dietro gli occhi. Se stai pagando 30 bambini maghi per sviluppare il tuo prodotto ma il tuo progetto open source ha solo 5 persone che hanno una conoscenza reale della base di codice, allora chiaramente la versione di codice chiuso ha una maggiore probabilità di meno bug, assumendo una complessità relativamente simile .

Chiaramente, questo è anche per ogni dato progetto transitorio nel tempo, come discute Thomas Pornin.

Aggiornamento modificato per rimuovere i riferimenti a gcc errato, in quanto non lo era.

17
user2213

Penso che le premesse che la maggior parte usano per distinguere tra chiuso e open source siano piuttosto ben definite. Molti di questi sono elencati qui, entrambi hanno i loro sostenitori. Non sorprende che i fautori di Closed Source siano quelli che lo vendono. I sostenitori dell'open source lo hanno anche reso un affare bello e ordinato (oltre ad alcuni che lo hanno assunto come una religione).

Il movimento Pro Open Source parla delle basi e quando si tratta di sicurezza in generale ecco i punti che si adattano maggiormente alla discussione:

  1. La premessa della personalizzazione
  2. La premessa della gestione delle licenze
  3. La premessa del formato aperto
  4. La premessa di Many Eyes
  5. La premessa della correzione rapida

Quindi suddividendolo per premessa, penso che gli ultimi due siano stati coperti in modo piuttosto succinto da altri qui, quindi li lascerò in pace.

  1. La premessa per la personalizzazione
    Per quanto riguarda la sicurezza, la premessa di personalizzazione offre alle aziende che adottano il software la possibilità di costruire controlli di sicurezza aggiuntivi su una piattaforma esistente senza dover ottenere una licenza o convincere un fornitore a risolvere qualcosa di proprio. Autorizza le organizzazioni che hanno bisogno o vedono un divario per aumentare la sicurezza complessiva di un prodotto. SELinux è un esempio perfetto, puoi ringraziare il NSA per averlo restituito alla comunità.

  2. Premessa di gestione delle licenze
    Spesso si afferma che se si utilizzano le tecnologie F/OSS non è necessario gestire le licenze tecnologiche con terze parti (o se lo si fa è molto meno.), E questo può essere vero per essere completamente aperto Ecosistemi di origine. Ma molte licenze (in particolare la GPL) impongono requisiti ai distributori e la maggior parte degli ambienti del mondo reale sono miscele eterogenee di tecnologie chiuse e open source. Quindi, sebbene alla fine riduca la spesa del software, la disponibilità della fonte può portare alcune aziende a violare le licenze OSS mantenendo la fonte privata quando hanno l'obbligo di rilasciare la fonte. Ciò può in definitiva trasformare la premessa della gestione delle licenze in una responsabilità (che è l'argomento di origine chiusa contro licenze come la GPL.)

  3. The Open Format Premise
    Questo è grande e con cui tendo ad essere d'accordo, quindi terrò breve per non predicare. Tra 30 anni voglio essere in grado di aprire un file che ho scritto. Se il file è "protetto" usando i controlli DRM proprietari e il software a cui devo accedervi non viene più venduto, la difficoltà di accedere al mio contenuto ha aumentato drammaticamente. Se esiste un formato utilizzato per creare il mio documento che è aperto e disponibile in un prodotto open source di 30 anni fa, sono probabilmente in grado di trovarlo e legalmente di usarlo. Alcune compagnie stanno saltando sul carro della band "Open Formats" senza saltare sul carro della band Open Source, quindi questa discussione credo sia piuttosto valida.

C'è una premessa Sesto che non ho elencato, perché non è ben discusso. Tendo a rimanere bloccato su di esso (chiamarlo paranoia.) Penso che la sesta premessa sia la piuma nel cappuccio dei dipartimenti di difesa di tutto il mondo. È stato spiegato al mondo quando una parte della fonte di Windows 2000 è trapelata.

Il presupposto della responsabilità da fonte chiusa
Se una società ha prodotto una libreria di codice sorgente chiusa o API attraverso più versioni nel corso dei decenni, piccoli gruppi di persone hanno avuto accesso a tale fonte durante la sua produzione. Alcuni di questi sono gruppi di controllo di terze parti e sviluppatori che sono passati ad altre società/governi. Se tale codice è sufficientemente statico, per mantenere la compatibilità come una premessa per i benefici di origine chiusa, alcune carenze possono rimanere senza preavviso per molti anni. Coloro che hanno accesso a quella fonte chiusa hanno la libertà di eseguire strumenti di analisi del codice contro di essa per studiare queste debolezze, i repository di bug di quei negozi di sviluppo software sono pieni di bug "minori" che potrebbero portare a exploit. Tutte queste informazioni sono disponibili per molti individui interni.

Gli aggressori lo sanno e vogliono queste informazioni per se stessi. Questo pone un obiettivo gigante sull'infrastruttura interna della tua azienda se sei uno di questi negozi. E così com'è, i tuoi processi di sviluppo diventano una responsabilità per la sicurezza. Se la tua azienda è abbastanza grande e la tua base di codice abbastanza ben distribuita, puoi persino essere un obiettivo per gli sforzi di infiltrazione umana. A questo punto la tecnica di Charlie Miller: corrompere uno sviluppatore con abbastanza soldi e ti scriverà un bug non rilevabile diventa una possibilità distinta.

Ciò non significa che non entri nei prodotti OSS allo stesso modo. Significa solo che hai una serie di dati, quindi una volta rilasciati, puoi esporre i punti deboli nella tua base di installazione. Mantenerlo privato ha creato un debito di codifica nei confronti dei sistemi installati dai clienti che non è possibile rimborsare immediatamente.

13
Ori

Ti consigliamo di guardare questi documenti:

Il risultato è che aprire o chiudere è equivalente a seconda di quanti test vengono eseguiti su di essi. E per "test" non intendo cosa fa il tuo "tester" medio di droni aziendali, ma piuttosto come l'esperienza sul campo.

3
Bruce Ediger

Siamo onesti qui, quando qualcuno afferma che l'open source è più sicuro di quello chiuso, si stanno generalizzando su ciò che accade oggi nei sistemi operativi server/desktop, come Linux (open source) rispetto a Mac/Windows (proprietario, chiuso).

Perché è più probabile che il malware colpisca il secondo e non il primo? Per diversi motivi, per cui penso che il più importante sia il primo (preso in prestito da quest'altra risposta a una domanda contrassegnata come duplicata di questa ):

  1. Il software installato dall'utente nel caso di una distribuzione Linux (o di un altro sistema operativo open source), viene solitamente impacchettato da un'organizzazione centralizzata (ovvero nel caso di Ubuntu, è realizzato da Canonical e ospitato da esso), che ospita file binari compilati da fonti curate/monitorate dalla comunità open source. Ciò significa che la probabilità che l'utente installi software infetto, o la probabilità che la comunità opensource accetti modifiche di codice dannoso, è molto più bassa rispetto al caso di Mac/Windows, dove l'utente installa solitamente software da molti luoghi diversi sul web o da molti fornitori diversi di AppStores. C'è anche il rischio che i server dell'organizzazione (ad es. Canonical) vengano hackerati, ma questo rischio è minore perché questa organizzazione impiega esperti IT di prim'ordine per eseguire i propri server.
  2. Il numero di utenti Linux (o altri SO opensource) è molto più basso rispetto agli utenti Windows/Mac , quindi i creatori di malware preferiscono non indirizzarli (come vantaggio/rapporto costi è inferiore in questo caso).
  3. Linux, essendo solo un kernel, è disponibile in varie distribuzioni tra cui puoi scegliere , quindi i creatori di malware dovrebbero fare uno sforzo maggiore per rendere il loro codice dannoso essere compatibile con molti di essi (quindi il rapporto costi/benefici è inferiore in questo caso).
  4. Le fonti di Linux (o altri sistemi operativi open source) sono aperte a chiunque per vederle/modificarle. Ciò significa che quando viene rilevata una vulnerabilità di sicurezza, chiunque può scrivere una correzione per essa (non esiste un blocco del fornitore, non sei legato a un'organizzazione specifica che devi aspettare, per sviluppare una correzione), quindi in teoria il le patch di sicurezza si verificano prima che nei casi di software proprietario. (Tuttavia, in pratica, di solito non c'è differenza, perché le aziende che gestiscono piattaforme proprietarie come Windows e MacOS, sono grandi aziende che sembrano essere abbastanza competenti.)
0
knocte

L'articolo OpenSource.com di Jim Fruchterman " Il tuo software di sicurezza open source è meno sicuro? " offre un'ottima analogia su come l'open source, nonostante gli aggressori sappiano come funziona, rende il software più sicuro per gli utenti finali :

Pensa alla crittografia come una combinazione bloccata sicura per i tuoi dati. Potresti essere l'unico che ha la combinazione, oppure puoi affidarlo a selezionare pochi associati stretti. L'obiettivo di una cassaforte è impedire a persone non autorizzate di accedere al suo contenuto. Potrebbero essere ladri che tentano di rubare preziose informazioni commerciali, dipendenti che cercano di ottenere informazioni salariali riservate sui loro pari o un truffatore che vuole ottenere informazioni riservate per perpetrare una truffa. In tutti i casi, vuoi la sicurezza per proteggere le tue cose e tenere fuori le persone non autorizzate.

Ora diciamo che sto scegliendo una cassaforte per i miei oggetti di valore. Scelgo Safe Number One pubblicizzato con pareti in acciaio da mezzo pollice, una porta spessa un pollice, sei bulloni di bloccaggio ed è testato da un'agenzia indipendente per confermare che il contenuto sopravviverà per due ore in un incendio? Oppure, scelgo per Safe Number Two, una cassaforte che il venditore dice semplicemente di fidarsi, perché i dettagli di progettazione della cassaforte sono un segreto commerciale? Potrebbe essere sicuro il numero due è realizzato in compensato e lamiera sottile. Oppure, potrebbe essere che è più forte di Safe Number One, ma il punto è che non ne ho idea.

Immagina di avere i piani dettagliati e le specifiche di Safe Number One, sufficienti per creare una copia esatta di quella cassaforte se avessi i materiali e gli strumenti giusti. Ciò rende Safe Number One meno sicuro? No non lo fa. La sicurezza di Safe Number One si basa su due protezioni: la forza del design e la difficoltà di indovinare la mia combinazione. Avere i piani dettagliati aiuta me o gli esperti di sicurezza a determinare quanto sia buono il design. Aiuta a stabilire che la cassaforte non ha difetti di progettazione o una seconda combinazione "backdoor" diversa dalla mia combinazione scelta che apre la cassaforte. Tieni presente che un buon design sicuro consente all'utente di scegliere la propria combinazione in modo casuale. Conoscere il progetto non dovrebbe affatto aiutare un attaccante a indovinare la combinazione casuale di una specifica cassaforte usando quel disegno.

0
Geremia