Su un sistema POSIX, esiste la possibilità per un file che non è eseguibile e di sola lettura (ovvero con una modalità 444) per eseguire codice dannoso su una macchina?
Se sì, puoi spiegare come farebbe così?
Sì, qualcosa deve solo eseguirlo. Il flag X suggerisce alla shell che può essere eseguito direttamente, ma ciò non impedisce ad altri programmi di eseguirlo se sanno come.
Ad esempio, se hai un file a.sh che non è eseguibile nella shell, puoi eseguirlo chiamando bash a.sh (che dice esplicitamente a bash di eseguirlo). Se hai un file non eseguibile a.py , puoi eseguirlo chiamando python a.py . Immagino che ci sia anche un modo per dire al sistema operativo di eseguire un file ELF binario, ma non conosco il comando a mano.
Ci sono anche un'intera classe di cose che non richiedono di fare nulla in particolare per farlo eseguire codice dannoso. I file PDF e Adobe Flash in particolare hanno avuto alcuni buchi ben noti che hanno permesso il semplice atto di leggere un file per eseguire codice dannoso. Ci sono anche alcuni file che, in posti specifici, possono essere eseguiti automaticamente (specialmente su Windows). Inoltre, se il file è compresso, potrebbe contenere un virus buffer-overflow per il decompressore. Il file potrebbe anche essere ancora più dannoso, sfruttando un bug ancora sconosciuto nel file system o qualcos'altro veramente di basso livello.
Conclusione: l'unico modo per garantire che qualcosa non infetti il tuo computer è di non fare mai niente con niente.
Supponiamo di avere il file myscript che contiene quanto segue:
#!/bin/bash
echo "Hello, World!"
Se rendi questo file eseguibile ed eseguilo con ./myscript, il kernel vedrà che i primi due byte sono #!, il che significa che è un file di script. Il kernel utilizzerà quindi il resto della riga come interprete e passerà il file come primo argomento. Quindi, esegue:
/bin/bash myscript
e bash legge il file ed esegue i comandi che contiene. un altro modo di eseguire un file senza eseguire bit set è:
#. myscript
un punto seguito da uno spazio e poi il nome del file.
Quindi, per bash (o qualsiasi interprete richiesto dallo script) per "eseguire" lo script, deve solo essere in grado di leggere il file.
Quindi, per gli script, il bit di esecuzione rende solo un po 'più comodo eseguirlo. Finché bash è eseguibile, puoi sempre eseguire bash con il file di script come argomento
Questo può essere vero non solo con script come gli altri esempi mostrati su tutte le risposte. Fondamentalmente, se il software che legge un file ha un bug, ogni file è un vettore per l'esecuzione di codice dannoso, utilizzando una vasta gamma di tecniche (overflow, corruzione di mem, esecuzione arbitraria di software ...). Esempi:
Un file in sé potrebbe non essere pericoloso stando seduto lì. Ma a seconda del programma cercherà di leggerlo, potrebbe causare problemi. Inoltre, se il file può essere letto, può essere copiato. Quindi potrebbe essere copiato e rinominato in un file eseguibile.
Quindi dici che stai usando DOS / Windows e hai un file something.txt e lo copi in un file chiamato something.bat ora puoi eseguirlo.
Se hai detto un file HTML (o contenuto HTML) puoi caricarlo nel tuo browser e se il tuo browser ha una vulnerabilità in Javascript quel programma può causare danni.
In teoria se il file è appena seduto potrebbe essere ancora pericoloso, se in qualche modo la tabella di allocazione dei file (FAT) per il file system ha alcuni problemi e sta eseguendo un programma, a causa di una frammentazione inappropriata potrebbe passare a dove si trova il tuo file dannoso ed esegui tale codice. Questo tipo di azioni su alcuni sistemi operativi può essere eseguito tramite un buffer overflow.
Sì, puoi. L'esempio classico per i binari consiste nell'utilizzare l'interprete ELF come nell'esempio seguente.
$ cp /bin/ls /tmp/ls
$ chmod a-x /tmp/ls
$ /lib/ld-linux.so.2 /tmp/ls
O per i sistemi x86-64:
$ /lib64/ld-linux-x86-64.so.2 /tmp/ls
Lo stesso vale per gli script di shell.
$ echo "#!/bin/bash" > /tmp/hello
$ echo "echo 'hello world" >> /tmp/hello
$ bash /tmp/hello
Questi sono esempi di base quando abbiamo un nuovo auditor o risk manager o addetto alla sicurezza che pensa che dobbiamo riordinare le cose. La risoluzione è quella di seguire il percorso di SELinux su sistemi Linux in quanto limita anche altri percorsi di escalation come altri hanno già menzionato.