Domanda:
Come faccio a sapere che un software fa solo ciò che afferma l'autore?
user3533
2013-02-07 03:08:39 UTC
view on stackexchange narkive permalink

Senza essere un programmatore o un esperto di computer, come faccio a sapere se un particolare programma o qualsiasi parte di software in generale non ha funzioni indesiderate nascoste che compromettono la privacy e la sicurezza?

Molti dei commenti sono giusti. Inoltre, se il software viene eseguito su una macchina * nix o bsd, è possibile inserire una traccia sul software e osservare la funzionalità di basso livello (ovvero ciò che il sistema chiama fa).
Se fossi un esperto di programmazione, potresti utilizzare l'analisi statica. Fondamentalmente decompilare il programma usando IDAPro e vedere una mappa di tutte le API di sistema chiamate ovvero quelle che potrebbero causare danni. Oltre a questo puoi vedere se l'app sta aprendo le porte che dovrebbe o sta effettuando telefonate a casa utilizzando un firewall.
Se un particolare software afferma di non fare esattamente nulla, allora questo problema è facile.
-1
In generale, non puoi sapere che un software fa solo ciò che afferma l'autore. Tuttavia, per rispondere alla tua domanda specifica: come posso sapere se un particolare programma ha nascosto funzioni indesiderate che compromettono la privacy e la sicurezza? Installa questo software su un computer totalmente scollegato - niente internet, wifi, lan, ecc. Usa questo computer solo per eseguire questo programma. Se sono presenti funzioni indesiderate nascoste che tentano di compromettere la privacy e la sicurezza, non funzioneranno.
Questa preoccupazione è uno dei motivi per cui alcune persone scelgono il software Open Source. Se qualcuno può leggere il codice sorgente, hai molte più possibilità di sapere se il programma fa qualcosa di indesiderato.
A proposito, qualcuno ricorda quei veri "virus" informatici dell'era pre-Internet? - Alterebbero i file eseguibili trovati sul computer della vittima, iniettandovi il proprio codice. Questo è un altro caso in cui nessuno può fare affermazioni sul comportamento dei programmi, anche se sono stati costruiti in modo pulito da un codice sorgente affidabile.
Sette risposte:
Tom Leek
2013-02-07 03:39:59 UTC
view on stackexchange narkive permalink

Puoi sapere se alcuni software fanno solo ciò che annuncia allo stesso modo in cui puoi sapere se il cibo che ti servono nei ristoranti è avvelenato o meno. In parole semplici, non puoi, ma la società ha escogitato vari schemi per affrontare il problema:

  • Puoi ascoltare amici e critici per sapere se il cibo in un determinato ristorante ha una buona reputazione oppure no.
  • Puoi prelevare un campione e inviarlo a un laboratorio che cercherà molte (ma non tutte) sostanze velenose conosciute.
  • Puoi chiedere gentilmente se puoi osservare il cuoco mentre prepara i piatti.
  • Il cuoco ha un interesse commerciale acquisito nel fatto che il suo cliente sia soddisfatto della qualità del cibo, e la felicità include, in particolare, non essere morto.
  • La società punisce gli avvelenatori con la massima severità e di solito si può presumere che il cuoco lo sappia.
  • Hai sempre la possibilità estrema di non mangiare lì se sei troppo preoccupato.

Tutto ciò può essere trasposto direttamente nel mondo del software. Metodi estremi per accertare la qualità del software e l'aderenza al suo comportamento pubblicato includono cose molto costose e noiose come Common Criteria che si riducono, fondamentalmente, a sapere chi ha realizzato il programma e con quali strumenti.

Risposta alternativa: ogni pezzo di software ha dei bug, quindi è garantito al 100% che non fa esattamente quello che dovrebbe fare. (Questa affermazione include il software che gira nella dozzina di computer piccoli che sono incorporati nella tua auto, tra l'altro.)

Una delle migliori analogie in assoluto
Quello è buono. E anche la risposta alternativa è brillante.
Un punto: un ristorante è piuttosto affermato e di alto profilo, mentre la persona che crea un software potrebbe non esserlo. Alcune persone anonime potrebbero non essere punite se il software è cattivo, né conosci necessariamente la loro reputazione. Se sai chi ha effettivamente realizzato un software e ha una solida reputazione da difendere, _allora_ l'analogia funziona meglio.
L'analogia copre anche questo, @cpast. È più sicuro mangiare in un ristorante famoso e ben recensito piuttosto che acquistare sushi da un venditore ambulante che potrebbe semplicemente scomparire dopo aver venduto accidentalmente del pesce cattivo.
Ci sono anche cose come la specifica formale (puoi leggere la specifica se conosci il linguaggio delle specifiche) e verificare se il pezzo SW è conforme ad essa.
Inoltre, puoi chiedere o cercare la ricetta e preparare il cibo da solo a casa.
Oppure puoi chiedere gli ingredienti e cucinarli da solo (scarica il codice sorgente e compila).
Questa è la tipica risposta a questo tipo di domanda. Non è del tutto vero. Code! = Food perché il language designer sceglie le regole dell'universo. Esempio artificioso: in un linguaggio funzionale puro, so già al 100% con certezza che qualsiasi funzione non può causare effetti collaterali al di fuori dell'utilizzo dello spazio / tempo. "ogni pezzo di software ha dei bug", è falso; la funzione di identità `id: a -> a; id x = x` non ha bug, il tipo da solo è già una prova. So anche che la funzione di aggiunta multi-precisione nell'assembly x64 che ho scritto oggi non ha bug per intuizione: è palesemente ovvio che sia corretta.
Ogni analogia si rompe se guardata troppo da vicino. Ecco come vanno le analogie: illustrano i concetti in modo che la mente umana possa digerirli. Per quanto riguarda la tua funzione, dal momento che l'hardware stesso non è privo di bug ...
Il codice che ho scritto è privo di bug, indipendentemente dal fatto che l'hardware sia privo di bug. Senza fare supposizioni non si può mai "sapere" nulla. Detto questo, non andare avanti e fidarti dell'hardware Intel. Inoltre: "La società punisce gli avvelenatori con la massima severità e di solito si può presumere che il cuoco lo sappia". La società ha punito Debian per il generatore casuale vuln che l'ha effettuato per 2 anni (equivalente a una porta sul retro)? No. Non hanno nemmeno perso la loro credibilità.
@Longpoke forse il codice che hai scritto è privo di bug e forse l'hardware è privo di bug. Il compilatore e / o l'interprete è privo di bug? Indipendentemente dall'utilizzo di spazio / tempo può essere un problema in sé. Immagina che il computer stia eseguendo (a) un sistema di supporto vitale e (b) la tua funzione di identità. LFS ha uno strano bug di concorrenza che non sarebbe mai emerso in un milione di anni, tranne che per forzare l'uso dello spazio / tempo delle funzioni id. La tua funzione id probabilmente ha fatto qualcosa al di là di ciò che hai affermato.
@emory: È facile verificare un'implementazione non ottimizzata di un linguaggio FP. La causa del bug di concorrenza non è "id", il problema è che qualche altra parte del sistema ha un bug di concorrenza. Se ti interessa la sicurezza, verifica l'intero TCB (il che significa che non puoi usare uno stack folle come gcc / * nix / x86) e assicurati che non ci siano tali bug di concorrenza. Detto questo, se questa domanda riguarda solo la verifica del software * nix, la risposta è abbastanza semplice: non puoi. Chiunque dica il contrario sta utilizzando una definizione del settore di "sicuro". Con * nix, intendo BSD, Microsoft, Apple, UNIX, ecc.
"Il cuoco ha un interesse aziendale nel fatto che il suo cliente non sia morto." Giuro, se mai scriverò un libro di testo introduttivo sull'economia aziendale (probabilmente mai, ma ehi), questa frase sarà lì dentro.
Ora ho solo bisogno di inventare una neuro-tossina latente che indurrà il bevitore a riscrivere la sua volontà anche a me poco prima di morire. (Scusa, sono un po 'in viaggio dietro le quinte e questa analogia ne mancava una;))
David Stratton
2013-02-07 03:35:08 UTC
view on stackexchange narkive permalink

Non puoi, almeno non con una precisione del 100%. Parlando come programmatore, è molto facile programmare ciò che voglio, e non è necessariamente solo ciò che viene pubblicizzato.

Non tutte le attività impreviste, tuttavia, sono dannose. Presumo che tu sia preoccupato di più per attività dannose. Anche se non è sempre possibile rilevarlo al 100%, ma c'è speranza.

Puoi utilizzare un software che monitora cose come il traffico di rete, l'attività dei file, ecc., Per trovare indizi che il software si sta comportando in modo imprevisto modo. Ad esempio (e so che questo è solo uno strumento di base) puoi utilizzare Fiddler per vedere se una particolare applicazione accede a Internet tramite http (s). (Sì, so che ci sono strumenti migliori là fuori, però. Fiddler è solo il primo che mi viene in mente.) Su Windows, puoi utilizzare Process Monitor per avere ancora più informazioni. Esistono strumenti simili per altre piattaforme.

Ci sono anche molti altri servizi disponibili da utilizzare che eseguiranno l'analisi per te.

L'analisi dinamica non ti compra nulla. In entrambi i casi sei bloccato con il problema. Una semplice bomba logica scritta da un dodicenne ostacolerà tutti i tipi di analisi dinamica fintanto che il codice è abbastanza denso.
Jeff Ferland
2013-02-07 03:41:27 UTC
view on stackexchange narkive permalink

Soprattutto quando il software diventa più grande e più complicato, diventa impossibile * anche per gli esperti rispondere. In tal senso, la privacy e la sicurezza di un'applicazione vengono gestite al meglio utilizzando i metodi sandbox o controllo dell'accesso obbligatorio. L'idea alla base di questi metodi è che il software viene eseguito in un sistema che controlla ciò che può fare e tu gli permetti di fare solo ciò che ti aspetti che faccia. Fatto correttamente, puoi limitare le possibili connessioni e ricevere una notifica se il programma tenta di accedere a file che non ti aspettavi. È possibile utilizzare metodi molto avanzati per monitorare la memoria o decrittografare il traffico di rete tramite un servizio proxy.

In breve, se non riesci a capire tutto ciò che fa, la risposta è limitare tutto ciò che può fare con qualcosa viene eseguito all'interno di (il sistema operativo).

C'è un asterisco penzolante dopo il tuo "impossibile" ma, di diritto, dovresti citare Donald Knuth e MetaPost qui.
L'asterisco penzolante implica che il tempo non sarebbe infinito, ma troppo dannatamente lungo.
le tipiche sandbox (VM, java, ecc.) / MAC / ACL / DAC ecc. hanno tutte fallito. L'unico modello che so che attualmente è noto per funzionare è il modello di capacità. D'altra parte, se sei bloccato a usare * nix, la tua unica scelta sono davvero le cose che hai menzionato.
@Longpoke SELinux, almeno, controlla ogni chiamata di sistema e quindi include il controllo delle capacità.
@JeffFerland Non sto parlando delle capacità di Linux, sto parlando del modello di capacità.
Mok-Kong Shen
2013-02-07 19:35:15 UTC
view on stackexchange narkive permalink

Nella sua famosa conferenza ACM Turing Award "Reflections on Trusting Trust" (ora quasi esattamente 30 anni fa!) Ken Thompson ha detto "Non puoi fidarti del codice che non hai creato totalmente da solo." In pratica il software commerciale non fa eccezione ad altri prodotti commerciali in quanto quelli di produttori che hanno buoni nomi sul mercato hanno solitamente una maggiore probabilità di essere migliori. Tuttavia non vi è alcuna garanzia assoluta per questo. Decenni fa ho ricevuto dischetti da un noto produttore che aveva un virus. In tal caso, personalmente ritengo che non sia stato un atto doloso di nessuno all'interno dell'azienda, ma che alcuni computer dell'azienda siano stati infettati da virus dall'esterno. Tuttavia, evidentemente non è possibile in generale escludere al 100% la possibilità che le backdoor vengano introdotte nel software da addetti ai lavori dell'azienda, che questo sia noto o meno al suo CEO. Le backdoor potrebbero essere, secondo me, una questione estremamente critica, ora che le guerre cibernetiche si profilano nel mondo. Un'agenzia segreta di un governo potrebbe cioè riuscire in qualche modo (tramite denaro, coersione o persino malware) ad avere tali backdoor impiantate in determinati software che normalmente servono a garantire la sicurezza delle comunicazioni (ad esempio quelle relative alle firme digitali) e che vengono vendute e utilizzati da alcune nazioni straniere non amichevoli o potenzialmente non amichevoli e immediatamente o in momenti successivi appropriati ("bombe a orologeria" ecc.) sfruttano le backdoor per raggiungere i loro obiettivi di interrompere le infrastrutture critiche delle nazioni target, ecc. ecc. Stuxnet, Flame e Gauss sono un paio di nomi che dovrebbero dare alcune indicazioni sulle capacità dei potenziali malfaiteurs.

Estendendo il tuo punto ... Anche se compili da sorgenti che hai scritto tu stesso ... Chi può dire che il compilatore che usi non sta facendo qualcosa di nefasto (supponendo che tu non abbia scritto il compilatore dall'assembly ...)
@Josh: Tutto dipende da quanto è alta la tua puntata. Non solo il software applicativo, ma anche i compilatori, il sistema operativo e il firmware / hardware potrebbero essere potenziali fonti di pericolo. Devi decidere saggiamente quali misure di sicurezza sono necessarie nel tuo caso e quali sono superflue (e assumerti le responsabilità per le omissioni). Nel dicembre 2012 si è tenuta una conferenza DAPRA negli Stati Uniti volta a trovare e chiudere i buchi di malware backdoor nei dispositivi IT commerciali (https://www.fbo.gov/?s=opportunity&mode=form&id=55b80a80971c739699e410584819e767&tab=core&_cview=0). Vedi in particolare la sezione "Sfondo" nel file pdf a cui si collega.
@Josh - Poi c'è l'hardware. Questo è il motivo per cui, per costruire il mio computer, ho iniziato con la sabbia per creare il silicio. Ovviamente non ho ancora ** abbastanza ** finito ...;)
@NathanLong: Secondo le informazioni provenienti dai media normali, almeno un paese sta lavorando per sviluppare i propri chip, puntando così ad essere indipendente dai progetti come quelli di Intel. Immagino però che non so se il problema di sicurezza non possa eventualmente essere anche una motivazione minore per quel progetto.
F. Hauri
2013-02-07 03:43:46 UTC
view on stackexchange narkive permalink

Sfortunatamente, non puoi ...

Dato che un buon programmatore potrebbe essere chiamato wizard dai suoi utenti, un buon trojan lo farebbe completamente falso un ambiente normale per rendere silenziosa la vittima.

Alcuni virus / trojan eseguono una disinfezione del sistema della vittima, al fine di

  • garantire un altro virus non interromperà il suo lavoro
  • assicurati che un antivirus non lo trovi
  • far funzionare correttamente il sistema della vittima per garantire che la vittima rimanga sicura.

Quindi non puoi !! In caso di dubbio consultare !!!!

AJ Henderson
2013-02-07 03:43:59 UTC
view on stackexchange narkive permalink

Alla fine si tratta di fiducia. Ti fidi della reputazione dell'azienda che rilascia il software. Se è open source, viene utilizzato da un numero sufficiente di sviluppatori da sollevare flag in caso di problemi. C'è una certa forza nei numeri poiché è più probabile che un prodotto di uso comune venga sottoposto a ricerche approfondite se è affidabile. A meno che tu non sia molto paranoico, generalmente guardare ciò che la comunità ha da dire su un particolare software è la soluzione migliore, ma ci saranno sempre bug e ci saranno sempre errori.

Si dovrebbe notare ciò che viene comunemente trascurato riguardo al software open source: non ci sono mezzi tecnici che garantiscano che un programma binario / compilato sia stato costruito esattamente dal codice sorgente da cui afferma di essere stato costruito.
@HannoBinder - vero, sebbene tu abbia anche la possibilità di creare la tua versione e sebbene non sia semplice, se ben fatto, dovrebbe essere fattibile per un utente tecnico limitato.
Tim X
2013-02-08 03:36:01 UTC
view on stackexchange narkive permalink

Come sottolineato da altri, non esiste un modo garantito per saperlo. Per la maggior parte del tempo, devi fidarti dell'integrità e della reputazione del venditore. Seguire pratiche sicure, come installare solo software da fonti attendibili può essere d'aiuto, ma proprio come nella vita reale, a volte, ci fidiamo delle persone sbagliate.

Alla fine, penso che dovremmo adottare un certo livello di paranoia. Se installi un'app sul tuo telefono, non limitarti ad accettare o dire di sì quando il sistema operativo del tuo telefono ti informa che il telefono vuole accedere alle tue informazioni private, alla tua posizione, ecc. Chiediti, perché ha bisogno di tale accesso. Se ritieni che l'accesso richiesto dall'applicazione sia giustificato in base a ciò che ti aspetti che faccia, allora dire di sì forse OK. D'altra parte, se sembra richiedere l'accesso a informazioni o servizi che sono ben al di fuori di ciò di cui dovrebbe aver bisogno o di cui dovrebbe essere interessato, sii un po 'sospettoso e consier attentamente prima di dire semplicemente di sì.



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...