Si je connais l'architecture CPU d'une cible, puis-je envoyer des instructions intégrées dans une image?
Puis-je envoyer des instructions intégrées dans une image à une cible, si je connais son architecture CPU?
Les instructions du processeur sont données dans ce qu'on appelle opcodes , et vous avez raison de dire que celles-ci vivent en mémoire tout comme votre image. Ils vivent cependant dans des "zones" de mémoire conceptuellement différentes.
Par exemple, vous pourriez imaginer un opcode "read" (0x01) qui lit un octet d'entrée depuis stdin et le place quelque part, et un autre opérande "add" (0x02) qui ajoute deux octets. Certains opcodes peuvent prendre des arguments, nous allons donc donner quelques exemples de nos opcodes: l'opcode "read" prend un opérande pour où stocker l'octet qu'il lit, et le "add" on prend trois opérandes: deux pour où lire ses entrées et une pour où écrire le résultat.
0x01 a1 // read a byte to memory location 0xa1
0x01 a2 // read a byte to memory location 0xa2
0x02 a1 a2 a3 // read the bytes at locations 0xa1 and 0xa2, add them,
// and write the result to location 0xa3
Cela est typique du fonctionnement de nombreuses instructions: la plupart d'entre elles fonctionnent uniquement sur des données en mémoire, et certaines d'entre elles mettent de nouvelles données en mémoire du monde extérieur (en lisant stdin, dans cet exemple, ou en lisant un fichier ou interface réseau).
S'il est vrai que les instructions et les données sur lesquelles elles opèrent sont toutes deux en mémoire, le programme exécutera uniquement les instructions. C'est le travail du CPU, du système d'exploitation et du programme de s'assurer que cela se produit. En cas d'échec, vous pouvez en fait charger des données dans l'espace d'exécution, et c'est un grave bogue de sécurité. Buffer overflows sont probablement l'exemple le plus célèbre d'un tel bug. Mais à part ces types de bogues, vous pouvez essentiellement considérer l'espace de données et l'espace d'exécution comme des blocs de CPU séparés.
Dans un ordinateur jouet, en utilisant l'exemple ci-dessus, la mémoire peut ressembler à:
(loc) | Initial | After op 1 | After op 2 | After op 3 |
0x00 | *01 a1 | 01 a1 | 01 a1 | 01 a1 |
0x02 | 01 a2 | *01 a2 | 01 a2 | 01 a2 |
0x04 | 02 a1 a2 a3 | 02 a1 a2 a3 | *02 a1 a2 a3 | 02 a1 a2 a3 |
0x08 | 99 | 99 | 99 | *99 |
...
0xa1 | 00 | 03 | 03 | 03 |
0xa2 | 00 | 00 | 04 | 04 |
0xa3 | 00 | 00 | 00 | 07 |
Dans cet exemple, l'astérisque (*) pointe sur le prochain opcode qui sera exécuté. La colonne la plus à gauche spécifie l'emplacement de mémoire de départ pour cette ligne. Ainsi, par exemple, la deuxième ligne nous montre deux octets de mémoire (avec les valeurs 01 et a2) aux emplacements 0x02 (explicitement dans la colonne de gauche) et 0x03.
(Veuillez comprendre que tout cela est une grande simplification. Par exemple, dans un véritable ordinateur, la mémoire peut être entrelacée - vous n'aurez pas seulement un bloc d'instructions et un bloc de tout le reste. Ce qui précède devrait être assez bon pour cela réponse, cependant.)
Notez que lorsque nous exécutons le programme, la mémoire dans les zones 0xa1 - 0xa3 change, mais pas la mémoire dans 0x00 - 0x08. Les données dans 0x00 - 0x08 sont l'exécutable de notre programme, tandis que la mémoire dans les zones 0xa1 - 0xa3 est la mémoire que le programme utilise pour effectuer le calcul des nombres.
Donc, pour revenir à votre exemple: les données de votre jpeg seront chargées dans la mémoire par des opcodes, et seront manipulées par des opcodes, mais ne seront pas chargées dans leur même zone en mémoire. Dans l'exemple ci-dessus, les deux valeurs 0x03 et 0x04 n'étaient jamais dans la zone opcode, ce que le CPU exécute; ils n'étaient que dans la zone de lecture et d'écriture des opcodes. Sauf si vous avez trouvé un bogue (comme un débordement de tampon) qui vous permettait d'écrire des données dans cet espace opcode, vos instructions ne seront pas exécutées; ce ne seront que les données qui seront manipulées par l'exécution du programme.
D'autres réponses donnent une bonne explication technique mais permettez-moi d'essayer avec une analogie:
Veuillez envoyer votre numéro de carte de crédit à [email protected]
Est-ce que vous l'avez vu?
L'AS-tu fait?
C'est plus ou moins la même chose pour votre CPU. Lire quelque chose n'est pas la même chose que l'exécuter.
Pouvez-vous les envoyer? Oui bien sûr. Il suffit de les assembler et de les coller quelque part dans le fichier image.
La cible les exécutera-t-elle? Non, sauf si vous avez déjà le contrôle sur la cible (et pouvez donc y placer un programme pour les lire et les exécuter), ou si vous trouvez un exploit dans une visionneuse d'images et que vous chargez l'image dedans.
Vous pourriez, si votre cible utilisait une version d'Internet Explorer antérieure à août 2005, afficher un JPG. Ou s'ils allaient ouvrir un PNG dans Windows Media Player sur Windows 98 sans mise à jour de sécurité installée. Etc.
Il y avait beaucoup d'anciens logiciels qui avaient des bugs où, si vous créiez un fichier image dans lequel la première partie du fichier image mentait outrageusement sur la taille et l'emplacement des données de pixels dans le fichier, le logiciel pouvait faire quelque chose de mal et sauter accidentellement au code à la mauvaise adresse ou écrire des données à partir du fichier dans un endroit où le code du programme devrait être. Je me souviens que l'un de ces hacks impliquait un fichier dont l'en-tête affirmait que l'image avait une taille négative. Vous ne pouvez probablement pas le faire avec des versions plus récentes d'Internet Explorer ou d'Edge, car tout le monde connaît le problème maintenant et Microsoft a fait de son mieux pour le résoudre.
Les systèmes d'exploitation d'aujourd'hui ont mis en place des mesures de protection pour rendre difficile (mais pas complètement impossible) tout ce qui est vraiment mauvais si vous trouvez une nouvelle façon de pirater un programme en utilisant une méthode comme celle-ci. Les zones de mémoire peuvent être définies pour ne pas pouvoir être exécutées. Les programmes ont des espaces d'adressage virtuels séparés afin qu'ils ne puissent pas accéder accidentellement à la mémoire de l'autre. Certains composants du système d'exploitation sont chargés à des emplacements de mémoire imprévisibles, il n'est donc pas simple pour un code malveillant de les trouver et de les utiliser.
Non. Les fichiers image tels que les fichiers JPEG n'exécutent pas de code, ils sont simplement rendus et affichés.
Si vous souhaitez masquer certaines informations dans un fichier appelé stéganographie, mais qui ne cache que des informations, il n'exécute aucune instruction.
Pour qu'un fichier exécute du code, il doit être un exécutable ou être exécuté par un autre programme qui lit le fichier, puis exécute les commandes dans le fichier.
Dans ce cas, le cas rare où une image pourrait entraîner l'exécution de code est s'il y avait un bogue dans le logiciel qui rendait l'image basée sur le fichier. Cela s'est produit dans le passé, mais c'est extrêmement rare. À toutes fins pratiques, une image ne peut pas exécuter d'instructions.
Ce n'est bien sûr pas le cas pour les PDF, Adobe Flash, etc.
Vous pouvez, SI vous savez également quelle pile logicielle touchera l'image du côté récepteur, ET SI il y a des failles de sécurité non résolues dans cette pile logicielle.
Le simple fait de mettre les instructions dans le fichier JPEG ne fait rien.
Cependant, s'il existe un moyen connu de faire planter une certaine implémentation exacte du lecteur JPEG sur un fichier JPEG mal formé de manière à ce qu'il copie les données du fichier image où ces données n'appartiennent pas (comme, au-dessus des variables qui contiennent le programme contrôler les informations de flux comme les pointeurs de fonction ou les adresses de retour), et si les contre-mesures au niveau du système d'exploitation ou du matériel (par exemple DEP) ne l'empêchent pas de se produire, il y a une chance réaliste. Ces vulnérabilités ont existé (et existent déjà dans les anciennes) implémentations du monde réel.
La version courte est non, car les ordinateurs (DEVRAIENT) connaître la différence entre les données et les instructions. Le pire que vous DEVRIEZ être capable de faire avec un JPEG est quelque chose comme une bombe Zip ou quelque chose qui bloque certaines routines de décompression JPEG. Un programme pour charger et afficher un fichier JPEG n'essayera pas d'exécuter les données du fichier, il suffit de le lire et de le traiter - et s'il frappe des données inattendues non jpeg, il s'arrêtera ou plantera, ou affichera simplement un image vraiment foirée.
TOUTEFOIS, parfois (je vous regarde, Microsoft), les gens essaient d'écrire des logiciels utiles qui peuvent être vulnérables en essayant (par exemple) de charger et d'afficher automatiquement les pièces jointes des e-mails, de créer des formats de document pouvant contenir des scripts/macros, etc. . et c'est là qu'un fichier malveillant peut causer des dommages.
L'exemple classique (et maintenant, espérons-le, défunt/protégé contre) est les pièces jointes aux e-mails appelées quelque chose comme .jpg.exe où le fichier est vraiment un exécutable et Windows le traitera comme tel, mais parce que Windows cache l'extension (cachant la dernière partie .exe), les gens voient file.jpg et cliquez dessus, ce qui oblige le système d'exploitation à l'exécuter.
C'est la différence entre la lecture d'un livre et la mise en scène du contenu du livre - si le livre dit "allez frapper quelqu'un", vous n'allez pas le faire, car les mots (données) du livre ne contrôlent même pas votre cerveau bien que votre cerveau traite ces données.