Un po 'strano, ma: è un rischio di negazione del servizio o potenziale divulgazione di informazioni.

Poiché il preprocessore di C includerà allegramente qualsiasi file specificato in una direttiva #include , qualcuno può #include "../../../../. ./../../../../../dev/zero " e il preprocessore proverà a leggere fino alla fine di / dev / zero (buona fortuna ).

Allo stesso modo, specialmente se permetti alle persone di vedere l'output dei loro tentativi di compilazione, qualcuno potrebbe provare a includere vari file che possono o meno essere presenti sul tuo sistema, e potrebbe imparare cose sulla tua macchina. In combinazione con un uso intelligente di #pragma poison , potrebbero persino imparare cose sul contenuto del file anche se non fornisci messaggi di errore completi.

Relativamente, i pragmi possono alterare molti comportamenti di preprocessore, compilatore o linker e sono specificati nei file sorgente. probabilmente non ce n'è uno che permetta a qualcuno di fare qualcosa come specificare il nome del file di output o qualcosa del genere, ma se c'è, potrebbe essere abusato per sovrascrivere i file sensibili o farsi eseguire (scrivendo in cron o simili). Potrebbe esserci qualcosa di altrettanto pericoloso. Dovresti davvero stare attento alla compilazione di codice non affidabile.

Compiler bombs

C è un linguaggio molto potente e alcune delle cose terribili che puoi farci potrebbero scioccarti. Ad esempio, puoi creare un programma C a 16 byte che impiega 27 minuti per essere compilato e, quando finalmente finisce, viene compilato in un 16 Gigabyte file eseguibile. E questo utilizza solo 16 byte. Quando prendi in considerazione il preprocessore e file di codice sorgente più grandi, sono sicuro che potresti creare bombe del compilatore molto più grandi.

Ciò significa che chiunque abbia accesso al tuo server potrebbe effettivamente eseguire un DoS attacco al tuo server. Per essere onesti, questo è significativamente meno pericoloso che avere qualcuno che abusa di una vulnerabilità nel compilatore o includere file sensibili per ottenere informazioni sul tuo server (come hanno parlato gli altri risponditori).

Ma è ancora un altro possibile fastidio che incontrerai durante la compilazione di codice arbitrario. Sono sicuro che potresti impostare un limite di tempo su tutte le build e assicurarti di non memorizzare mai i file binari. Anche se, ovviamente, devi ancora tenerlo su disco mentre viene creato , quindi se qualcuno ipoteticamente creasse una bomba del compilatore più grande del tuo disco rigido, saresti nei guai (se lasci che la build finitura).

@ AndréBorie è corretto. I compilatori e la configurazione corrispondente non saranno ben controllati per i problemi di sicurezza, quindi in generale non dovresti compilare codice non affidabile.

Il rischio è che venga sfruttato un overflow del buffer o qualche tipo di vulnerabilità di esecuzione della libreria, e il l'aggressore ottiene l'accesso all'account utente (si spera non root !) che ha eseguito il compilatore. Anche un hack non di root è serio nella maggior parte dei casi. Questo potrebbe essere elaborato in una domanda separata.

La creazione di una VM è una buona soluzione, per contenere eventuali potenziali exploit in modo che non possano danneggiare il resto dell'applicazione.

È la cosa migliore per avere un modello di VM Linux che puoi avviare secondo necessità con un ambiente di compilazione pulito.

Idealmente dovresti buttarlo via dopo ogni utilizzo, ma questo potrebbe non essere strettamente necessario. Se si isola abbastanza bene la VM e si disinfettano adeguatamente i dati di risposta dalla VM, cosa che si dovrebbe fare comunque; allora il peggio che un hack potrebbe fare è DoS o creare tempi di compilazione falsi. Questi non sono problemi seri da soli; almeno non così grave come l'accesso al resto della tua applicazione.

Tuttavia, il ripristino della VM dopo ogni utilizzo (cioè invece che quotidianamente) fornisce un ambiente più stabile in generale e può migliorare la sicurezza in certi edge casi.

Alcuni sistemi operativi forniscono contenitori come alternativa alle VM. Questo può essere un approccio più snello, ma si applicano gli stessi principi.

Sì, è pericoloso: ma come si dice è possibile. Sono l'autore e il manutentore dei compilatori online su https://gcc.godbolt.org/ e ho trovato abbastanza fattibile renderlo sicuro usando una combinazione di:

• L'intero sito viene eseguito su un'istanza VM con pochi permessi per fare qualsiasi cosa. La rete è fortemente limitata con solo la porta 80 visibile e ssh abilitato solo dagli IP autorizzati (il mio).
• Ogni istanza di compilazione viene eseguita all'interno di un contenitore Docker usa e getta con ancora meno autorizzazioni
• Il compilatore viene eseguito da uno script che imposta tutti i limiti del processo (memoria, tempo della CPU, ecc.) A limiti bassi per prevenire bombe di codice.
• Il compilatore viene eseguito con un LD_PRELOAD wrapper ( fonte qui) che impedisce al compilatore di aprire file non inclusi in una whitelist esplicita. Questo gli impedisce di leggere / etc / passwd o altre cose simili (non che questo aiuterebbe più di tanto).
• Di solito analizzo le opzioni della riga di comando e non eseguo il compilatore se c'è qualcosa di particolarmente sospetto. Questa non è una vera protezione; solo un modo per dare un messaggio di errore "seriamente, non provare questo" invece di LD_PRELOAD che rileva un cattivo comportamento.

L'intera fonte è su GitHub, così come la fonte delle immagini del contenitore docker e dei compilatori e simili.

Ho scritto un post sul blog che spiega come viene eseguito anche l'intero setup.

Non si vorrebbe eseguire il compilatore come root, anche se l'ho visto accadere per ragioni di "facilità e comodità". Sarebbe fin troppo facile per un utente malintenzionato includere qualcosa del tipo:

  #include "../../../../etc/passwd"#include" ../. ./../../etc/shadow"

e recuperare il contenuto di questi file come parte del messaggio di errore del compilatore.

Anche i compilatori sono programmi come ogni altra cosa, e avranno i loro bug che potrebbero essere vulnerabili, sarebbe tutto troppo facile per qualcuno semplicemente confondere i programmi C e causare problemi.

La maggior parte della sicurezza delle applicazioni si concentrerà prima di tutto sulla convalida dell'input, sfortunatamente la definizione di un input "sicuro e valido" per un compilatore C è probabilmente all'altezza del problema in termini di difficoltà :)

Se consenti a un utente di fornire un archivio contenente il codice puoi avere problemi, non esattamente con il compilatore ma con il linker che usa;)

ld segue i collegamenti simbolici se puntano a un file che non esiste. Ciò significa che se compili test.c sull'output a.out ma hai già un collegamento simbolico chiamato a.out nella tua directory che punta a un file non esistente, l'eseguibile compilato verrà scritto nella posizione che punta al file (con la limitazione dei diritti dell'utente).

In pratica un attaccante potrebbe, ad esempio, includere una stringa contenente una chiave ssh pubblica nel suo codice e fornire un collegamento simbolico denominato a.out a ~ / .ssh / authorized_keys . Se quel file non esiste già, questo permette all'attaccante di piantare la sua chiave ssh nella macchina di destinazione permettendogli l'accesso esterno senza dover decifrare alcuna password.