come può un utente malintenzionato utilizzare un file temporaneo falso per compromettere un programma?

8

Sto prendendo una lezione di sicurezza. Le note di classe dicono che un utente malintenzionato può osservare uno schema nei nomi di file temporanei e quindi creare il proprio file temporaneo per compromettere un programma. Dicono che se un file temporaneo viene creato usando un ID di processo, un utente malintenzionato potrebbe creare un collegamento simbolico ad un file di password con un ID di processo tripwire in modo da rendere il tripwire utilizzare il file di password in un file temporaneo.

In che modo l'utente malintenzionato può utilizzare i file temporanei per compromettere un file di password? O per sfruttare altrimenti un sistema?

    
posta bernie2436 15.04.2013 - 23:38
fonte

3 risposte

5

La prima cosa da considerare è qual è lo scopo del file temporaneo.

Se la temp sta emettendo informazioni utili, un utente malintenzionato potrebbe utilizzarlo per raccogliere informazioni sulla funzionalità di programmi, impostazioni, messaggi di errore, ecc. (a seconda dell'output). L'autore dell'attacco potrebbe essere in grado di fare in modo che un programma dannoso effettui occasionalmente la scansione di tali file cercando determinati modelli da utilizzare nella logica di attacco.

Allo stesso tempo, se il file temporaneo verrà letto, è possibile modificare la logica di input del programma legittimo che non è strettamente bloccato. Ad esempio, se il file temporaneo verrà letto per gli scopi di eval() o se si esegue un'esecuzione di system() , è possibile quindi fare in modo che il programma esegua qualcosa che i privilegi consentiranno al sistema di eseguire, che non sono previsti.

Invece di modificare il file temporaneo che verrà letto, potrebbe essere possibile creare un collegamento simbolico a un altro file che all'utente come utente non può accedere ma che l'applicazione potrebbe avere privilegi da leggere. Se il programma stampa il file temporaneo, potresti esporlo in questo modo. Sembra che l'attacco sia descritto in un'escalation di privilegi, non una modifica diretta al file della password.

Progetto del codice: suggerimenti sulla sicurezza per l'utilizzo di file temporanei nelle applicazioni

If the attacker knows where the application creates its temporary files and can guess the name of the next temporary file, the following attack can be realized:

  • Attacker will put a symbolic link at the temporary file location.
  • The attacker will link the symbolic link to a privileged file.
  • Now, the application will unknowingly write to the privileged file instead of writing to the file in the temp directory.

C'è anche un CWE ( CWE-377: File temporaneo non sicuro ) per questo, vale la pena leggere così come alcune delle relative istanze:

If an attacker pre-creates the file with relaxed access permissions, then data stored in the temporary file by the application may be accessed, modified or corrupted by an attacker. On Unix based systems an even more insidious attack is possible if the attacker pre-creates the file as a link to another important file. Then, if the application truncates or writes data to the file, it may unwittingly perform damaging operations for the attacker. This is an especially serious threat if the program operates with elevated permissions.

    
risposta data 16.04.2013 - 00:46
fonte
3

La possibilità di questo attacco non è qualcosa che è inevitabile nell'uso dei file temporanei. Deriva da un'implementazione non sicura dei file temporanei.

Ad esempio, su un sistema Unix, è possibile aprire un foro se la directory del file temporaneo ha permessi errati. La directory /tmp è condivisa dagli utenti, quindi tutti hanno il permesso di scrittura sulla directory stessa (per poter creare file). Ma viene applicato un permesso speciale "sticky bit" che impedisce agli utenti di eliminare file che non possiedono. Se manca quel bit di autorizzazione, è possibile che un processo dannoso crei un attacco di condizione di competizione: nota che è appena stato creato un file temporaneo e, prima che il processo proprietario possa utilizzarlo, cancella il file e lo sostituisce con il proprio. (Le applicazioni possono verificare la proprietà e le autorizzazioni del file temporaneo appena aperto, ma probabilmente pochi, se non nessuno, danno fastidio, perché i programmi sono scritti in modo che la directory temporanea sia configurata correttamente.)

Se un file temporaneo viene creato con autorizzazioni errate, è possibile accedervi e manometterlo. I programmi che utilizzano file temporanei devono crearli con le autorizzazioni appropriate. Ciò significa che alcune funzioni di manipolazione di file indipendenti dalla piattaforma non possono essere utilizzate. Ad esempio, se utilizziamo la funzione C fopen per creare un file temporaneo, abbiamo un buco di sicurezza, perché fopen non ha alcun parametro per controllare quali autorizzazioni avrà il file. Su un sistema simile a Unix, creerà un file con autorizzazioni liberali (meno solo quelle autorizzazioni rimosse da umask ). Le funzioni della libreria specifiche della piattaforma devono essere utilizzate per la creazione e l'apertura di file temporanei.

Un programma, quando crea un file temporaneo, controlla sempre se quel file non esiste già. Tuttavia, questo controllo deve essere atomico, altrimenti c'è una condizione di competizione tra il controllo che il file non esiste e l'apertura / creazione del file. Quella condizione di competizione non è stata corretta dalle autorizzazioni corrette sulla directory temporanea. Viene risolto utilizzando un'operazione atomica per la creazione del file. Su Unix, il flag O_EXCL viene utilizzato in aggiunta a O_CREAT per chiedere al sistema operativo di fallire la chiamata open se il file esiste già, altrimenti per crearlo. Un potenziale pitall qui sta ospitando la directory di file temporanea su alcuni filesystem di rete che non onora la semantica atomica di O_EXCL .

Naturalmente, i file temporanei non sono protetti contro gli attacchi dallo stesso contesto di sicurezza. (Almeno, non senza l'implementazione di politiche di sicurezza a grana fine nel sistema operativo.) Se un programma dannoso viene eseguito come utente joe aleady, allora quel programma può attaccare i file temporanei creati da programmi eseguiti come joe dell'utente. Per evitare questo tipo di cose, è necessario uno schema di sicurezza più fine dei semplici domini di sicurezza basati sull'account. Ad esempio un sistema di sicurezza con regole come: "solo il% eseguibile% co_de è autorizzato ad accedere a qualsiasi oggetto filesystem il cui percorso corrisponda al modello /bin/foo ".

    
risposta data 16.04.2013 - 03:05
fonte
0

Molti programmi credono implicitamente che ciò che scrivono nei loro file temporanei sia ciò che sarà ancora lì pochi millisecondi o secondi o minuti dopo. Se è possibile prevedere quale nome avrà un file temporaneo, si avrà una migliore possibilità di catturare il file tra la sua creazione e il suo contenuto in fase di lettura, ed è possibile scrivere dati dannosi nel file.

    
risposta data 15.04.2013 - 23:50
fonte

Leggi altre domande sui tag