Quanto è sicuro compilare un pezzo di codice sorgente da uno sconosciuto casuale? [chiuso]

Supponiamo che stia rivedendo il codice inviato dai candidati per dimostrare le loro competenze. Chiaramente non voglio eseguire eseguibili che inviano. Non così chiaramente preferirei non eseguire il risultato della compilazione del loro codice (solo per esempio, Java consente di nascondere il codice eseguibile nei commenti ).

Che ne dici di compilare il loro codice? Voglio eventuali avvisi del compilatore, ma se il loro codice contiene sequenze di caratteri intelligenti che sfruttano il mio compilatore e il mio compilatore compromette la mia macchina?

Quando ho Google per "vulnerabilità del compilatore", le hit che ottengo riguardano tutte le ottimizzazioni del compilatore e l'emissione del codice e se il codice emesso è sicuro come dovrebbe essere il codice sorgente originale.

I compilatori vengono in genere convalidati per garantire che non compromettano la macchina dell'utente durante la compilazione di un pezzo di codice intelligente? Quanto è sicuro compilare un pezzo di codice da uno sconosciuto?

Dipende.

Questo pezzo di makefile potrebbe cancellare la tua home directory:

all:
    rm -rf ~

Quindi, se è necessario utilizzare uno strumento (come cmake o makefile system), non è sicuro. Dipende da quanto sia dannoso il programmatore.

Dall'altro lato, i compilatori sono programmati da persone, quindi hanno bug. Quindi, forse potrebbe essere possibile che qualcuno abbia trovato un modo per eseguire codice dannoso durante la compilazione.

Come suggerito nei commenti, se vuoi essere sicuro che non ci siano cose divertenti sulla tua macchina, usa una macchina virtuale.

Sono abbastanza sicuro che da qualche parte nel business ci siano alcuni ragazzi intelligenti che hanno già creato un tale hack per un linguaggio specifico e una versione del compilatore. Il mio posto preferito in cui cercare qualcosa del genere sarebbe probabilmente il concorso internazionale Obfuscated C - (non so se c'è qualcosa di paragonabile a Java). Tuttavia, in realtà, quanto in alto considera il rischio, ipotizzato

• il candidato fa un'impressione plausibile su di te e vuole davvero il lavoro presso la tua azienda (e non una causa legale)

• il ragazzo non sa quante revisioni vengono fatte al tuo

• lui / lei non sa quale versione esatta del compilatore stai usando

• non sa se usi un ambiente virtuale o un compilatore online, solo per sicurezza

• non si accettano programmi troppo grandi per essere esaminati in modo efficace

• non compili nulla che ti sembri sospetto

• non ci sono molte persone al mondo che in realtà sanno come eseguire tecnicamente tale compito (e cercare da soli su Google non ti darà un "riferimento rapido" o tutorial su questo, come hai già scoperto da solo).

Quindi, sebbene la compilazione non sia "totalmente sicura" in teoria, IMHO in realtà il rischio è estremamente basso che il tuo "compilatore venga sviluppato".

Dobbiamo distinguere diversi casi:

1. Un bug nel compilatore. Come ogni programma complesso, un compilatore potrebbe avere dei bug e uno di questi potrebbe essere sfruttabile.
2. Un cavallo di Troia. L'attaccante potrebbe farti eseguire un codice arbitrario come parte del processo di compilazione. A Makefile, a build.xml, uno configurescript di shell ecc. Tecnicamente, ciò non è dovuto alla compilazione del codice dell'attaccante, ma piuttosto alla configurazione dell'ambiente di compilazione.
3. Lingue che consentono l'esecuzione di codice arbitrario in fase di compilazione. Il linguaggio macro di Scala è Scala, il linguaggio macro di Common Lisp è Common Lisp, il linguaggio macro di Template Haskell è Haskell. Scala ha anche plugin di compilazione, che sono di nuovo codice Scala arbitrario che viene eseguito in fase di compilazione. F # ha provider di tipi.
4. Lingue che consentono il calcolo di Turing al momento della compilazione. I sistemi di tipi di Scala e Haskell sono completi di Turing, così come i modelli di C ++. Puoi fare in modo che il compilatore esegua il calcolo di Turing arbitrario in fase di compilazione, incluso ma non limitato a loop infiniti. Nota che Turing-complete significa solo che puoi calcolare ogni funzione calcolabile di Turing, non significa che puoi accedere al filesystem o qualcosa del genere. Ma puoi creare un programma che richiederà infinitamente tempo per essere compilato.
5. Tempi di compilazione molto lunghi. Ad esempio, le regole di C # per la risoluzione del sovraccarico sono così complesse che è possibile codificare qualsiasi problema 3-SAT come risoluzione del sovraccarico C #. 3-SAT è, ovviamente, notoriamente NP completo. In altre parole, secondo le nostre attuali conoscenze, è impossibile trovare un algoritmo efficiente per la risoluzione del sovraccarico in C #. Non puoi fare in modo che la compilazione richieda infinitamente tempo, ma non ci vuole un grande programma per far sì che la compilazione richieda più tempo della vita dell'universo, che è praticamente la stessa cosa.

# 4. e # 5. si tradurrà al massimo in una negazione del servizio. In pratica, i compilatori C ++ e Scala limitano la quantità di ricorsione che è possibile eseguire, in modo che non sia effettivamente possibile scrivere un ciclo infinito. In Scala, questo è solo un vincolo di implementazione, ma in C ++ è esplicitamente consentito dalle specifiche, credo.

# 2. è tecnicamente fuori dalla portata della domanda perché la domanda riguardava la compilazione del codice che non lo eseguiva (OTOH, c'è la profonda domanda filosofica: se il controllo del tipo di un programma Haskell può eseguire arbitraria computazione di Turing, è quella compilazione o l'esecuzione di un programma?)

# 1. è improbabile. Da un lato, i compilatori di produzione sono molto complessi, quindi la probabilità di bug è alta. D'altra parte, sono rigorosamente testati, dopo tutto, gestire con garbo input mal formati fa parte della descrizione del lavoro di un compilatore. Anche se non vengono testati, saranno comunque bombardati da codice mal formato ... basta guardare alcune domande StackOverflow per esempi di ciò che le persone spazzatura lanciano ai loro compilatori!

Questo ci lascia con 3. Alcuni compilatori possono limitare il tipo di accesso che il codice temporale di compilazione ha al sistema, ma per alcuni dei casi d'uso, è inevitabile avere pieno accesso. Lo scopo dei provider di tipi di F #, ad esempio, è "falsare" tipi sintetici per dati il ​​cui sistema di tipi non corrisponde a quelli di F #, in modo da poter interagire, per esempio, con un servizio Web che ha uno schema WSDL in un tipo fortemente tipizzato moda. Tuttavia, per fare ciò, il provider del tipo deve avere accesso alla risorsa dello schema WSDL sul filesystem o sul web, quindi deve avere accesso al filesystem e alla rete.

Quindi è sicuro? Tecnicamente no. È rischioso? Non proprio.

Non dovrebbe esserci alcun rischio semplicemente compilando il codice. In teoria potrebbe esserci un bug nel compilatore di cui un abile hacker potrebbe trarre vantaggio ma che sembra estremamente improbabile.

Ricorda che l' edificio potrebbe non essere sicuro. Ad esempio, in C # 'build event' consente di specificare righe di comando arbitrarie da eseguire prima e dopo la costruzione, il che è ovviamente pericoloso e molto più facile da sfruttare rispetto ai buffer overflow nel codice del compilatore.

Invece di speculare, in realtà mi sono preso la briga di fare qualche ricerca su questo argomento prima di rispondere, andando alla risorsa più autorevole a cui potrei pensare ( CVE Dettagli ). Questo elenco completo di exploit di sicurezza divulgati pubblicamente è probabilmente il migliore che si possa fare per valutare i livelli di minaccia di vari tipi di software.

Ovviamente non ho impiegato molto tempo a leggere tutto il materiale disponibile, ma ho selezionato alcuni compilatori, IDE ed editor di testo "primari" per elaborare una valutazione delle minacce di esempio. Se sei seriamente intenzionato a eseguire qualsiasi software, dovresti almeno vedere quali sono le minacce là fuori. Si noti inoltre che il software più vecchio è generalmente più potente del software più recente, quindi eseguire l'ultimo di tutto ciò che si esegue è l'ideale.

Innanzitutto, possiamo dare un'occhiata a vari editor di testo. Sembra che i migliori editor siano i più semplici. Vi se stai usando una shell Linux o Blocco note se sei in Windows. Qualcosa senza capacità di formattazione, nessuna analisi, solo visualizzazione diretta dei dati e interruzione automatica dell'analisi se un singolo carattere è al di fuori dello schema di codifica corrente. Anche Notepad ++ ha avuto una manciata di vulnerabilità. Evitare qualsiasi cosa complessa quando si visualizzano file non attendibili.

In secondo luogo, possiamo esaminare gli IDE. Se si sceglie di aprire il file in un IDE, è necessario tenere presente che alcuni IDE hanno segnalato bug. Apparentemente Visual Studio ha avuto exploit disponibili attraverso il meccanismo delle estensioni, quindi l'apertura di una soluzione potrebbe essere problematica. Evitare gli IDE evita un'intera classe di problemi tra te e il codice non attendibile. Attaccare con VI sembra molto più sicuro.

Terzo, possiamo guardare ai compilatori reali. Ne ho sfogliati alcuni, tra cui Adobe, Microsoft, Java e C / C ++ di GNU, e ho scoperto che in generale, compilare il codice (e persino costruire , assumendo che non sia un make-file personalizzato) è relativamente sicuro, ma ognuno di quei compilatori lo fa o lo fa hanno exploit di sicurezza che potrebbero derivare dall'esecuzione effettiva dei file binari compilati. In altre parole, non potevano prendere il controllo del sistema semplicemente compilando, ma potevano eseguire il codice.

Quindi, in conclusione, supponendo che il metodo di consegna non abbia già dirottato il tuo sistema (ad esempio, il tuo client di posta elettronica è stato violato o l'unità USB in cui è stato infettato ...), probabilmente leggere il codice sorgente e compilare il codice sorgente è sicuro . Effettuando la ricerca del tuo software specifico, potresti renderlo ancora più sicuro, ad esempio, convalidare il file si trova nella tabella codici corretta, ecc. L'esecuzione del codice dovrebbe essere eseguita solo su hardware che semplicemente non ti interessa. Non una macchina virtuale, ma un intero computer fisicamente diverso, senza accesso alla rete e senza file sensibili o dispositivi esterni. Anche se pensi di aver compreso il codice, una semplice ricerca mostra che anche i compilatori hanno dei bug che potrebbero consentire a un exploit nascosto di overflow del buffer di sgattaiolare da dietro ed eseguire codice arbitrario, ma solo se scegli dieseguire o eseguire il debug del programma. La compilazione effettiva dovrebbe essere sicura.

Bene, vorrei iniziare con "rivedere il loro codice". Perché è necessario eseguire effettivamente il codice?

A parte questo, ci sono molti compilatori online in cui puoi semplicemente inserire il codice, compilare e / o eseguirlo. Puoi renderlo un requisito: si compila in questo e quel compilatore online.

Ecco un esempio di una pagina con compilatori online: compilatori online

Il codice per la revisione per un colloquio di lavoro non dovrebbe essere così grande da non capire cosa sta succedendo.

I compilatori vengono in genere convalidati per garantire che non generino il computer dell'utente durante la compilazione di un codice intelligente?

In generale sono troppo complessi e spesso scritti usando linguaggi in cui non è pratico dimostrare questa proprietà.

Forse non con questo intento specifico, ma la nozione di compilatori di test fuzz è almeno nota ( LLVM ora può eseguire il test fuzz stesso ). I test intesi a rilevare input che causano arresti anomali del compilatore a causa di errori del compilatore tenderanno anche a evidenziare difetti sfruttabili.

Naturalmente dovresti verificare se il compilatore specifico che ti interessa è testato o fuzz-test per trovare potenziali arresti anomali e se i bug così trovati sono effettivamente corretti. La regola empirica è che se ci sono arresti anomali peggiori delle eccezioni di memoria non rilevate, quindi senza indagare ulteriormente i dettagli devi considerare una seria possibilità che possano essere sfruttati in exploit.

Quanto è sicuro compilare un pezzo di codice da uno sconosciuto?

Sfortunatamente, quanto è lungo un pezzo di corda. In linea di principio, l'e-mail potrebbe sfruttare il tuo client di posta oppure il codice sorgente potrebbe sfruttare l'editor di testo o il controllo, prima ancora che raggiunga il tuo compilatore. Il suggerimento di Sebastian nei commenti di usare un compilatore online è piuttosto buono, ma ovviamente il codice deve essere in una forma accettata dal compilatore.

Qualsiasi linguaggio o compilatore con funzionalità per l'esecuzione in fase di compilazione del codice generale è ovviamente altamente sospetto. I modelli C ++ sono funzionalmente completi ma non hanno (previsto) l'accesso al sistema, quindi sono relativamente a basso rischio. BЈовић menziona makecome estremamente rischioso (poiché sta eseguendo il codice dello sconosciuto, è solo che il codice sembra essere scritto nella makelingua, non in C ++). Se il compilatore verrà eseguito, systemti troverai nella stessa barca. Lavoravo con un assemblatore che, se ricordo bene, poteva eseguire arbitrariamente l'esecuzione di codice in fase di compilazione. Era destinato al calcolo delle tabelle di ricerca, ma non credo che nulla ti abbia impedito di effettuare chiamate di sistema.

In pratica , se il codice mi sembra OK e penso di capirlo, lo considererei un rischio estremamente basso di compilarlo, un rischio molto più basso rispetto a dire "navigare in Internet con un browser bloccato". Faccio cose più rischiose di routine sulla mia macchina per uso generico, ma molte di esse non farebbero ad esempio all'interno di un laboratorio di virus o su un server critico. Se il codice ha un aspetto divertente o evidentemente offuscato, allora potrei non rischiare di compilarlo perché, a parte il rischio che potrebbe contenere un exploit nascosto nella spazzatura illeggibile, è un codice di immondizia. Il codice subdolo è difficile ma possibile. Il codice subdolo che utilizza la macchina tramite un exploit del compilatore deve contenere un payload eseguibile non banale, quindi è estremamente difficile.

Se vuoi approfondire ulteriormente questo, prova a chiedere alle persone che ospitano compilatori online. Se non è stato fatto a loro allora (escludendo che tu venga all'attenzione dell'NSA o equivalente) puoi ragionevolmente presumere che non ti sarà fatto. Hanno fatto uno sforzo per far funzionare il loro compilatore in un sandbox adeguato, che potrebbe essere più sforzo di quello che sei disposto a fare, ma potrebbero almeno essere in grado di dirti con quale frequenza quel sandbox li salva problemi.

Anche se questo è generalmente un problema, penso che il problema sia inesistente a causa dell'installazione.

Il richiedente ti ha inviato del codice sorgente. Come o perché è successo?

Beh, ovviamente ci sono solo tre possibilità:

1. Hai assegnato al candidato un incarico per risolvere un particolare problema (ben definito) per valutare le sue capacità.
2. Il richiedente vuole mostrare qualcosa di interessante che ha scritto.
3. Il richiedente è un coglione o una spia o una persona altrimenti maliziosa e non è effettivamente interessato ad essere assunto. Tutto quello che spera è che tu sia abbastanza stupido da eseguire il suo codice.

Circa 2) e 3)

Il rischio principale è distinguere tra 2) e 3). È molto probabile che se qualunque cosa abbia scritto valga la pena guardare , è qualcosa che puoi ottenere il codice sorgente per online (da una fonte "neutra") e che potresti anche avere familiarità con te, o è qualcosa che in realtà non indossi non voglio guardare perché violeresti la proprietà intellettuale di un concorrente (ex datore di lavoro). Quest'ultimo significherebbe che non vorrai assumere quella persona comunque.
Se riesci a ottenere la fonte online, fallo. Se riesci a verificare il contributo del richiedente a un software noto (incluso il software proprietario) con il suo nome da qualche parte nei titoli di coda, fallo.
In ogni altro caso, ignora semplicemente tutto ciò che ti ha inviato. Non vale la pena guardare, o illegale o ad alto rischio.

Circa 1)

Il richiedente ti ha inviato qualcosa perché gli hai assegnato un incarico. Se hai qualche competenza (che presumo tu faccia!), Quindi per un tipico incarico di programmazione (... che hai anche scelto te stesso!), Sarai in grado di dire se è una soluzione plausibile che sembra funzionare guardando il codice sorgente per meno di 30 secondi (più probabilmente 10 secondi).

Se non riesci a dire che il programma probabilmente funzionerà (o che cosa sta facendo) entro 30 secondi, colui che lo ha scritto non è il tipo di persona che vuoi assumere, fullstop. Vuoi persone che scrivono codice che altri umani possano capire e mantenere. Non vuoi qualcuno che sta cercando di diventare furbo con te, né qualcuno che vince regolarmente il contest offuscato C. Non importa nemmeno se il programma funziona. Non appena un'altra persona non riesce a capire il codice, non "funziona" mai.
Se il programma sembra che probabilmente funzionerà, ma trovi tutto ciò che sembra "strano" (diciamo, sequenze di escape Unicode Java, valori letterali di stringhe C ++, elementi che sembrano trigraphs, qualunque cosa), considera l'assegnazione come "fail", sposta al prossimo richiedente. Non è necessario includere qualcosa di simile nel 99% di tutti i programmi (e, sicuramente, non nel tuo compito - dovrei sperare). Quindi se trovi qualcosa di "strano" come quello, il candidato non è qualcuno che vorresti assumere.

Se il codice supera quel primo triage, potresti voler passare altri 2-3 minuti a guardarlo più a fondo. Se sei ancora soddisfatto di ciò che vedi dopo, puoi eseguirlo attraverso un analizzatore statico e compilarlo in una macchina virtuale con un livello di avviso elevato.

Ciò dovrebbe far emergere problemi che potresti aver perso durante la lettura della fonte (come invocare comportamenti indefiniti o restringere la conversione).
La compilazione ti dirà innanzitutto se il richiedente ha la necessaria diligenza e attenzione ai dettagli, non tanto se ha abilità di programmazione. Proprio come scrivere correttamente il nome del datore di lavoro sulla tua domanda e controllare l'ortografia del tuo CV prima di consegnarlo, è consigliabile assicurarsi che qualsiasi codice sorgente consegni sia compilato senza errori (e preferibilmente senza avvisi). Se qualcuno non riesce a farlo, non vuoi assumerlo.

Il rischio che accadano cose malvagie a questo punto (sfruttando il compilatore e uscendo dalla VM) è trascurabile, visto che hai già eseguito un controllo di plausibilità sul codice. Non succederà.

Se la possibilità ti preoccupa, prendi una macchina più vecchia (non ce ne sono molti in giro?), Installa la versione corrente di Linux e del compilatore & c, copia il codice sorgente su di essa, scollega il cavo di rete (o disattiva WiFi ) e compila. Se succede qualcosa di brutto, non influenzerà * nient'altro.

E per i malware nel Makefile, eseguilo con il flag -n (IIRC, RTMF) per vedere cosa farà senza farlo realmente.

* A meno che, naturalmente, il programmatore non abbia codificato il malware in modo che attenda una riconnessione, ma in tal caso a) pulire la macchina; e b) inoltrare il curriculum del ragazzo all'NSA, perché è sprecato nel mondo commerciale :-)

La linea di fondo è che non v'è il rischio. Il rischio è abbastanza piccolo come notano altre risposte, ma esiste un rischio. Ciò significa che è necessario porre due domande:

1. Cosa posso fare per mitigare il rischio?
2. Il rischio è abbastanza alto da potermi preoccupare?

Il secondo è quello che hai posto qui in questa domanda, ma è l'obiettivo sbagliato per questo caso particolare. La risposta per mitigare il rischio è chiara e facilmente disponibile: non compilare il codice sul tuo computer . Hai due modi ovvi per compilarlo senza usare la tua macchina:

1. Utilizzare una macchina virtuale (come sottolineato immediatamente da @FlorianMargaine nei commenti). È sufficiente snapshot prima di compilare e quindi ripristinare l'istantanea al termine.
2. Utilizzare un servizio ospitato (come un compilatore online).

Questi modi per mitigare il rischio sono così evidenti, economici e facilmente accessibili che non vale la pena dedicare molto tempo a cercare di analizzare l'entità del rischio. Basta fare uno di loro e finirlo.

Visual Studio ti avverte effettivamente se apri un progetto da una posizione non attendibile (ad esempio, scaricato, o condivisione di rete).

Un esempio di come questo potrebbe essere sfruttato sarebbe con un progetto WPF: è possibile fare riferimento a classi .NET da XAML e fornire IntelliSense, carichi VS ed eseguire le classi di riferimento in fase di progettazione.

Ciò significa che un utente malintenzionato può rilasciare una DLL dannosa nella directory bin, sostituire il codice sorgente con uno non dannoso e, in fase di progettazione, viene eseguita la DLL. Dopo il tuo primo build, ogni traccia del binario dannoso è sparita.

Quindi, anche se tutto il codice fornito è "pulito", il compilatore è privo di bug e, ovviamente, non si esegue mai manualmente alcun .EXE fornito, il codice dannoso potrebbe comunque essere eseguito in background. (Per essere al sicuro da quell'attacco specifico, puoi semplicemente assicurarti che NON ci siano binari nella struttura di directory prima di aprire la soluzione. VS ti chiederà quindi di creare la soluzione prima di fornire IntelliSense in fase di progettazione.)

Vettori simili probabilmente esistono con altre lingue / sistemi operativi.

Lettura del codice sorgente: totalmente sicuro. Compilazione del codice sorgente: totalmente sicuro. Eseguire binari compilati: beh ... dipende.

La compilazione è solo il computer che legge il codice sorgente e scrive il suo equivalente in forma binaria. Dopo la compilazione, hai solo 2 documenti: uno leggibile dall'uomo e un altro leggibile dal computer. A meno che tu non riesca a leggere (cioè eseguire) il secondo documento, il computer non accadrà nulla.

Penso che tu sia preoccupato per uno dei due gusti:

• malware sofisticato e basato sugli exploit : improbabile, soprattutto perché sono rivolti a hardware e / o software molto specifici e [in base alla tua domanda] il tuo aggressore probabilmente non ha quel livello di conoscenza del sistema.
• cose che rovinano con il tuo ambiente : direttive di scherzi dannosi (ad es. eliminazione della tua home directory) o direttive sconsiderate / incompetenti che cambiano il comportamento del tuo sistema (ad es. riscrittura delle variabili di ambiente PATH o LIBRARY)

Alcune persone hanno suggerito macchine virtuali o vecchi sistemi, ma offro una soluzione molto più semplice: compilare come utente diverso con autorizzazioni ridotte / diverse . Molto più semplice della configurazione di una macchina virtuale o di un computer dedicato.

Se nell'improbabile persino che il tuo sistema sia sfruttato da exploit in fase di compilazione, ripristina dai backup (hai quelli, giusto?).