Est-il possible pour un fichier non exécutable et en lecture seule d'exécuter du code malveillant?
Sur un système POSIX, existe-t-il une possibilité pour un fichier non exécutable et en lecture seule (aka avec un mode 444) d'exécuter du code malveillant sur une machine?
Si oui, pouvez-vous expliquer comment cela se ferait?
Oui, il suffit de l'exécuter. L'indicateur X indique au shell qu'il peut être exécuté directement, mais cela n'empêche pas d'autres programmes de l'exécuter s'ils savent comment.
Par exemple, si vous avez un fichier a.sh qui n'est pas exécutable sur le Shell, vous pouvez l'exécuter en appelant bash a.sh (qui indique explicitement à bash de l'exécuter). Si vous avez un fichier non exécutable a.py, vous pouvez l'exécuter en appelant python a.py. J'imagine qu'il y a aussi un moyen de dire au système d'exploitation d'exécuter un fichier ELF binaire, mais je ne connais pas la commande à la main.
Il existe également toute une classe de choses qui ne vous obligent à rien en particulier pour lui faire exécuter du code malveillant. Les PDF et les fichiers Adobe Flash en particulier ont connu des trous bien connus qui permettaient au simple fait de lire un fichier d'exécuter du code malveillant. Il existe également des fichiers qui, à des endroits spécifiques, sont exécutés automatiquement (en particulier sous Windows). De plus, si le fichier est compressé, il peut contenir un virus de débordement de tampon pour le décompresseur. Le fichier peut également être encore plus malveillant, profitant d'un bogue encore inconnu dans le système de fichiers ou de quelque chose de très bas niveau.
Conclusion: la seule façon de garantir que quelque chose n'infectera pas votre ordinateur est de ne rien faire avec quoi que ce soit.
Disons que vous avez le fichier myscript contenant les éléments suivants:
#!/bin/bash
echo "Hello, World!"
Si vous rendez ce fichier exécutable et l'exécutez avec ./myscript, le noyau verra que les deux premiers octets sont # !, ce qui signifie que c'est un fichier de script. Le noyau utilisera alors le reste de la ligne comme interpréteur et passera le fichier comme premier argument. Donc, ça tourne:
/bin/bash myscript
et bash lit le fichier et exécute les commandes qu'il contient. une autre façon d'exécuter un fichier sans exécuter le bit est:
#. myscript
un point suivi d'un espace puis du nom du fichier.
Ainsi, pour que bash (ou tout autre interpréteur requis par votre script) "exécute" le script, il suffit de pouvoir lire le fichier.
Donc, pour les scripts, le bit d'exécution le rend juste un peu plus pratique pour l'exécuter. Tant que bash est exécutable, vous pouvez toujours exécuter bash avec le fichier de script comme argument
Cela peut être vrai non seulement avec des scripts comme les autres exemples présentés dans toutes les réponses. Fondamentalement, si le logiciel qui lit un fichier a un bug, chaque fichier est un vecteur d'exécution de code malveillant, utilisant une assez large gamme de techniques (débordement, corruption de mémoire, exécution de logiciel arbitraire ...). Exemples:
- Exploit.Win32.AdobeReader.K - Ce fichier PDF PDF malveillant profite d'une vulnérabilité ( CVE-2007-502 ) sur l'URI gestion des fichiers PDF. Cette vulnérabilité affecte IE7, Adobe Acrobat et Adobe Reader sur certaines plates-formes.
- Zero Day QuickTime mvhd - La faille spécifique existe dans l'atome 'mvhd'. En fournissant une version et des indicateurs mal formés, un attaquant est en mesure de créer une corruption de mémoire contrôlable et de déclencher une opération d'écriture arbitraire. En exploitant cela, un attaquant pourrait exécuter du code dans le contexte de l'utilisateur actuel. CVE-2014-4979
Un fichier lui-même peut ne pas être dangereux simplement assis là. Mais selon le programme que vous essayez de le lire, cela pourrait causer des problèmes. De plus, si le fichier peut être lu, il peut être copié. Il pourrait donc être copié et renommé dans un fichier exécutable.
Supposons donc que vous utilisez DOS/Windows et que vous avez un fichier quelque chose.txt et que vous le copiez dans un fichier appelé quelque chose.bat, vous pouvez maintenant l'exécuter.
Si vous avez dit un fichier HTML (ou du contenu html) vous pouvez le charger dans votre navigateur et si votre navigateur a une vulnérabilité en Javascript ce programme peut nuire.
En théorie, si le fichier est juste assis là, il pourrait être encore dangereux, si, d'une manière ou d'une autre, la table d'allocation de fichiers (FAT) pour le système de fichiers a des problèmes et exécute un programme, puis en raison d'une fragmentation incorrecte, il pourrait sauter là où votre malware fichier est et exécutez ce code. Ce type d'actions sur certains systèmes d'exploitation peut être effectué via un dépassement de tampon.
Oui, vous pouvez. L'exemple classique pour les binaires est d'utiliser l'interpréteur ELF comme dans l'exemple ci-dessous.
$ cp /bin/ls /tmp/ls
$ chmod a-x /tmp/ls
$ /lib/ld-linux.so.2 /tmp/ls
Ou pour les systèmes x86-64:
$ /lib64/ld-linux-x86-64.so.2 /tmp/ls
Il en va de même pour les scripts Shell.
$ echo "#!/bin/bash" > /tmp/hello
$ echo "echo 'hello world" >> /tmp/hello
$ bash /tmp/hello
Ce sont des exemples de base lorsque nous avons un nouvel auditeur, un gestionnaire des risques ou un responsable de la sécurité qui pense que nous devons ranger les choses. La résolution consiste à suivre le chemin de SELinux sur les systèmes Linux car il restreint également les autres chemins d'escalade comme d'autres l'ont également mentionné.