Question:
Si je connais l'architecture CPU d'une cible, puis-je envoyer des instructions intégrées dans une image?
Faminha102
2018-10-29 06:47:57 UTC
view on stackexchange narkive permalink

Puis-je envoyer des instructions intégrées dans une image à une cible, si je connais son architecture CPU?

Copie possible de [Un logiciel malveillant peut-il être attaché à une image?] (Https://security.stackexchange.com/questions/55061/can-malware-be-attached-to-an-image)
Sûr que vous pouvez.Mais ça ne va pas les exécuter.En fait, la plupart des octets sont des instructions CPU valides.
bien sûr, il suffit d'écrire alors sur un morceau de papier et de prendre une photo ... :)
Notez qu'il existe des formats d'image qui reposent explicitement sur "l'exécution de code arbitraire" (principalement de l'ancienne époque où la compatibilité et la sauvegarde de la mémoire et du processeur étaient plus importantes que la sécurisation des images).Le plus notable est probablement WMF, où la fonctionnalité était très raisonnable et sûre dans l'implémentation d'origine, mais la sécurité a été perdue lors du portage du code de Windows 3.0 (16 bits) vers Windows NT (32 bits, et uniquement sur x86).C'était donc l'un des rares cas où, par exemple,Windows 98 (bureau) était plus sûr que Windows NT (serveur / professionnel) :)
Les [vulnérabilités] (https://docs.microsoft.com/en-us/security-updates/vulnerabilityresearchadvisories/2012/msvr12-004) ont-elles conduit à poser cette question?
Bien sûr, vous pouvez, et pour toute autre forme de média aussi.Vous feriez donc mieux de faire confiance à votre visionneuse multimédia pour ne pas avoir de bogues ou de "fonctionnalités" inattendues.
Sept réponses:
Antzi
2018-10-29 13:42:48 UTC
view on stackexchange narkive permalink

D'autres réponses donnent une bonne explication technique, mais laissez-moi essayer avec une analogie:

Veuillez envoyer votre numéro de carte de crédit à scam@example.com

  • L'avez-vous lu?

  • L'avez-vous 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.

Ce n'est pas la meilleure analogie, car en tant qu'êtres humains, nous pouvons nous arrêter et décider si quelque chose est une bonne idée, mais un ordinateur ne le peut pas.L'ordinateur doit "décider" avant de démarrer.
+1 pour avoir essayé d'expliquer par analogie.Ce n'est pas parce que je * lis * un ensemble d'instructions que je les * fais * réellement.
@CaptainMan c'est une très bonne analogie.Cela ne me surprendrait pas beaucoup si après un certain nombre d'années "scam@scammer.org" ne recevait pas les numéros de carte de crédit b / c de cette publication.
Quelle est la prochaine étape?Cela fait près de 8 heures que j'ai posté et je n'ai toujours pas eu de réponse.
@emory Pensez-vous vraiment que quelqu'un qui sait assez bien lire l'anglais pour trouver cette page et lire cette phrase ne comprendra pas le contexte dans lequel elle est publiée, au point où ils le confondent avec des instructions à exécuter?
@Adonalsium Oui, je pense qu'avec suffisamment de lecteurs, c'est inévitable.En fait, nous sommes amenés à croire que cela s'est déjà produit.
@CaptainMan Et c'est là que la validation d'entrée, la vérification des limites, la séparation des données et de la mémoire d'instructions, les stratégies de protection de la mémoire, etc. entrent en jeu.Vous avez regardé le message et avez décidé qu'il n'était pas prudent de suivre les instructions.Tout ce qui précède donne au processeur ou au système d'exploitation la possibilité de prendre cette décision.
On vous dit de copier l'écriture du morceau de papier sur un autre morceau de papier.Le journal dit "Veuillez envoyer votre numéro de carte de crédit ...".Vous êtes parfaitement capable de traiter ces instructions (en particulier, de les copier), sans les exécuter.Ce n'est pas différent que si le journal disait "erwcwmexrnwem, cwtuvklewer".
Pour compléter l'analogie, supposons que l'escroc parvienne à intégrer l'instruction dans une lettre qui semble être envoyée par la banque.Maintenant, le message se trouve dans une zone marquée comme "instructions" et sera exécuté.
@emory - apparemment "scammer.org" est à vendre, vous pouvez donc acheter le domaine et attendre de voir ce qui se passe si vous le souhaitez.:)
@Jules c'est une arnaque :)
@Adonalsium Pour la perspective, il est courant pour ceux qui dirigent une arnaque nigériane de * continuer * de se désigner comme étant un prince du Nigéria, même si le nom est synonyme d'escroquerie.On pense que cela fonctionne comme une sorte de filtre: seuls les plus crédules répondront encore à un prince du Nigéria.Les e-mails en masse sont bon marché, mais le reste du processus est effectué par un être humain.Le fait qu'ils continuent à utiliser ce surnom plutôt que d'évoluer * fortement * laisse entendre que suffisamment de gens tombent pour que cette escroquerie en vaille la peine.
@CaptainMan Nous n'évitons pas d'envoyer un email parce que nous nous sommes arrêtés et avons décidé si c'était une bonne idée ou non.Tout comme un ordinateur peut choisir de rendre les données lisibles ou exécutables en fonction du contexte, nous pouvons faire de même.Nous lisons cette arnaque dans un contexte informatif, pas dans le contexte d'un ordre que nous devons suivre.
@CortAmmon IIRC, ce sont surtout les personnes âgées qui tombent dans la démence qui font confiance à des courriels comme ça ... ce qui le rend encore plus sale.Quoi qu'il en soit, c'est un problème de confiance, pas un problème de compréhension en lecture.
@forest oui.Ne pas tomber dans le piège parce que nous comprenons que les instructions seraient votre travail antivirus.
"Tout le monde se tient debout! J'ai la photo d'un pistolet et je n'ai pas peur de l'utiliser!":-P
Une meilleure analogie serait «Voulez-vous sortir avec moi?% § ~ ÍŠ [carte de crédit pickpocket]».
L'analogie est inexacte car les e-mails sont couramment utilisés pour envoyer des instructions.Une image avec des opcodes n'est pas du tout vue par le CPU comme un ensemble d'instructions.
yshavit
2018-10-29 11:28:01 UTC
view on stackexchange narkive permalink

Les instructions du processeur sont données dans ce que l'on appelle des opcodes, et vous avez raison de dire que ceux-ci vivent en mémoire tout comme votre image. Cependant, ils vivent dans des "zones" de mémoire conceptuellement différentes.

Par exemple, vous pouvez 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 en donner à notre exemple des opcodes: l'opcode "read" prend un opérande pour savoir où stocker l'octet qu'il lit, et celui "add" prend trois opérandes: deux pour où lire ses entrées , et un pour savoir où écrire le résultat. 

  0x01 a1 // lire un octet dans l'emplacement mémoire 0xa10x01 a2 // lire un octet dans l'emplacement mémoire 0xa20x02 a1 a2 a3 // lire les octets aux emplacements 0xa1 et 0xa2, ajoutez-les, // et écrivez le résultat à l'emplacement 0xa3

Ceci est typique du fonctionnement de beaucoup d'instructions: la plupart d'entre elles ne fonctionnent que sur des données en mémoire , et certains d'entre eux mettent en mémoire de nouvelles données du monde extérieur (de la lecture de stdin, dans cet exemple, ou de la lecture d'un fichier ou d'une interface réseau).

S'il est vrai que les instructions et les données ils fonctionnent tous les 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. Lorsqu'ils échouent, vous pouvez en fait charger des données dans l'espace d'exécution, et c'est un grave bogue de sécurité. Les débordements de tampon sont probablement l'exemple le plus célèbre d'un tel bogue. Mais à part ce genre de bogues, vous pouvez essentiellement considérer l'espace de données et l'espace d'exécution comme étant des morceaux séparés de CPU.

Dans un ordinateur jouet, en utilisant l'exemple ci-dessus, la mémoire peut ressembler à quelque chose comme : 

  (loc) | Initial | Après l'op 1 | Après l'op 2 | Après l'opération 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 vers le prochain opcode qui sera exécuté. La colonne la plus à gauche spécifie l'emplacement 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 vrai ordinateur, la mémoire peut être entrelacée - vous n'aurez pas juste un morceau d'instructions et un morceau de tout le reste. devrait être assez bon pour cette 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 de 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 faire le calcul des nombres.

Donc, pour revenir à votre exemple: les données dans votre jpeg seront chargés dans la mémoire par des opcodes, et seront manipulés par des opcodes, mais ne seront pas chargés 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 d'opcode, ce que le CPU exécute; ils étaient uniquement dans la zone de lecture et d'écriture des opcodes. Sauf si vous avez trouvé un bogue (comme un dépassement de tampon) qui vous permet d'écrire des données dans cet espace d'opcode, vos instructions ne seront pas exécutées; ce ne seront que les données manipulées par l'exécution du programme.

Votre réponse est au mieux partiellement correcte.Hormis la simplification selon laquelle toutes les données doivent résider sur la «pile», il est faux de supposer que la manipulation des données sur la pile ne peut pas être utilisée pour l'exécution de code arbitraire.
@JimmyB Il dit littéralement que c'est une grande simplification, et la question ne parle pas d'exploits, mais simplement d'insérer du code dans une image.La réponse explique en termes simples pourquoi le code inséré dans une image ne s'exécute pas simplement.
@Blackhawk: Presque tout est faux dans la pile.C'est en quelque sorte vaguement similaire à la façon dont les architectures [stack machine] (https://en.wikipedia.org/wiki/Stack_machine) fonctionnent, mais la plupart des ordinateurs modernes n'utilisent pas une architecture de machine à pile, et même les machines à pile utilisent la pile commeune terre d'attente temporaire pour les entrées et sorties d'instructions, pas comme où toutes les données sont conservées.(La pile d'appels utilisée dans les architectures informatiques modernes est une chose différente, et cette pile ne fonctionne pas non plus comme cette réponse le décrit.)
De plus, les débordements de tampon écrasent généralement des choses comme les adresses de retour, pas la mémoire exécutable.
Bien que la partie «pas à moins que vous n'exploitiez un bogue» soit correcte, cette réponse contient beaucoup de détails inutiles et * faux * qui la rendent plus informative pour un lecteur inexpérimenté, mais rend en fait la réponse pire que la courte mais correcteréponses qui n'ont pas été acceptées.
@user2357112 Je m'efforçais de proposer une petite «machine virtuelle jouet», mais je pense que vous avez raison de dire que cela a trop sacrifié et n'a pas simplifié assez.Je me suis débarrassé des mentions de la pile.Laissez-moi savoir ce que vous pensez.
(J'ai omis les discussions sur les registres et autres, cependant - je ne pense pas qu'ils ajouteraient grand-chose à ce que le PO demande.)
Que dirait von Neumann?
Il serait probablement beaucoup plus simple de dire "Les données ne sont exécutées que si le registre IP est changé en l'adresse des données en mémoire" que de parcourir tout cela.
@forest Je pense que cela fonctionnerait principalement si quelqu'un avait déjà beaucoup de ces connaissances.J'essayais de cibler quelqu'un qui comprend que le programme vit dans la mémoire, tout comme les données d'image, mais qui ne comprend pas comment elles restent distinctes.Personnellement, je trouve utile de donner un exemple concret mais simplifié, même si je comprends vraiment que d'autres pensent que cela ne fonctionne pas.:)
@Blackhawk C'est "preuve d'autorité", ce qui précède est "mensonges racontés aux enfants".Les mensonges racontés aux enfants ont de la valeur.
Il devrait y avoir un bouton pour le déplacer vers le chat, si vous voulez le faire.
@yshavit Je pense que vous devriez supprimer la déclaration "S'il est vrai que les instructions et les données sur lesquelles elles opèrent sont toutes deux en mémoire, elles sont dans différentes parties de la mémoire."car il est au mieux trompeur et au pire tout simplement faux.
@JimmyJames Ils sont dans des lieux conceptuels différents.Il est vrai que les deux espaces sont physiquement intercalés, mais le point que j'essayais de faire comprendre est qu'ils sont traités comme différents, et en fait, lorsqu'ils ne sont pas traités accidentellement comme différents, c'est un bug.Que pensez-vous de l'adapter à "ils sont dans des parties conceptuellement distinctes de la mémoire"?
@yshavit Mieux?C'est un concept difficile à expliquer sans comprendre la manière dont le code machine s'exécute.La façon succincte que je dirais est quelque chose comme: "les données ne s'exécutent comme des instructions que lorsqu'un processus en cours les interprète de cette façon."
Mais les systèmes modernes sont l'architecture Von Neumann, pas l'architecture Harvard, donc ce n'est rien d'autre qu'un bit d'exécution qui détermine si une page est exécutable, pas où elle vit en mémoire (en ignorant le fait que les processeurs x86 sont Harvard en interne, avec L1d et L1i séparéscaches).
@forest: x86 a un i-cache cohérent (contrairement à de nombreuses autres architectures qui nécessitent des insns de vidage / synchronisation explicites avant de pouvoir exécuter de manière fiable des octets de code machine nouvellement stockés), donc à partir d'un logiciel PoV moderne x86 est pur von Neumann.[Observation d'instructions obsolètes sur x86 avec code auto-modifiable] (https://stackoverflow.com/q/17395557).Et BTW, les caches L1 divisés pour un espace d'adressage unifié sont généralement décrits comme une architecture Harvard modifiée, de la variété presque von Neumann.https://en.wikipedia.org/wiki/Modified_Harvard_architecture#Split-cache_(or_almost-von-Neumann)_architecture
@PeterCordes Oui, je sais que c'est une architecture Harvard modifiée, mais c'est invisible pour l'ISA.
@forest: oui, invisible dans l'ISA, c'est exactement ce que je disais aussi.:) (Eh bien, techniquement, sur papier, x86 est autorisé à exécuter des instructions obsolètes jusqu'à ce qu'une jmp / branche, mais les implémentations matérielles réelles choisissent d'être plus fortes que l'ISA papier parce que c'est en fait plus facile que d'être * exactement * aussi fort que la spécification mais jamais plus faible. C'est sur cela que porte la réponse d'Andy Glew aux questions et réponses liées. (Andy était l'un des architectes du P6 d'Intel). De plus, dans votre commentaire précédent, vous avez omis le "Modifié", et je me sentais pédant.: P Non modifiéHarvard implique des espaces d'adressage séparés.
Joseph Sible-Reinstate Monica
2018-10-29 06:51:35 UTC
view on stackexchange narkive permalink

Pouvez-vous les envoyer? Oui bien sûr. Assemblez-les et collez-les quelque part dans le fichier image.

La cible les exécutera-t-elle? Non, à moins que vous n'ayez déjà le contrôle sur la cible (et que vous puissiez donc y mettre un programme pour les lire et les exécuter), ou que vous trouviez un exploit dans une visionneuse d'images et que l'image s'y charge.

Le processeur ne devrait-il pas exécuter les instructions en ouvrant uniquement l'image?
Non, pourquoi le ferait-il?
Parce que le processeur devrait traiter ces informations, d'après ce que je comprends.
Le traitement des octets de données est différent de l'exécution de ces octets.L'un n'implique pas l'autre.
Tout n'est-il pas des octets à la fin?
Oui, mais certains octets sont exécutés et certains sont simplement traités comme des données.
Je vois, et juste pour que je puisse comprendre cela: qui est responsable de cela?le système d'exploitation qui traite les fichiers jpg comme des données, au lieu d'exécutables?
@Faminha102 Si vous marchiez dehors et que vous tombiez sur un morceau de papier avec des instructions dessus, suivriez-vous ces instructions?Probablement pas.Vous pouvez toujours lire et comprendre ces instructions, mais vous n'agissez pas en conséquence parce que vous savez qu'elles ne vous sont pas destinées.Une idée similaire s'applique ici.
@Faminha102: Tout comme dans l'analogie de tlng05, tout dépend du contexte défini par le code en cours d'exécution.Si le programme lisant un fichier exécute des instructions qui interpréteront son contenu comme une matrice de points de couleur et afficheront l’image résultante, c’est ce qui se passera (ou le programme peut échouer sur des données mal formées);si le programme exécute des instructions qui interpréteront les données du fichier comme d’autres instructions et les exécuteront, c’est ce qui se passera (à moins que, encore une fois, la séquence d’instructions résultante ne soit mal formée).
@Faminha102 oui, si un fichier est déterminé comme exécutable ou non dépend entièrement du système d'exploitation.Les fichiers sont interprétés par des programmes et vous pouvez avoir un fichier qui est interprété de plusieurs manières.Un exemple courant est celui des programmes d'installation qui peuvent être exécutés en tant que programmes ou ouverts en tant que fichiers ZIP.
Certains octets sont donnés à l'ordinateur pour s'exécuter.D'autres ne le sont pas.C'est vraiment aussi simple que ça.Si vous placez vos octets dans un fichier exécutable et que vous persuadez l'utilisateur de l'ordinateur de l'exécuter, le système d'exploitation passera ces octets au processeur pour exécution et c'est parti.Si c'est le cas pour les images JPEG, quelque chose ne va vraiment pas.
L'idée fausse ici peut provenir de l'observation selon laquelle un double-clic sur une image * affiche * ("démarre") l'image, tout comme un double-clic sur un exécutable démarre l'exécutable.
En réalité, ce qui se passe lorsque vous double-cliquez sur une image, c'est que votre système d'exploitation exécute l'exécutable associé à ce type de fichier particulier, en fonction de l'extension du fichier, et transmet simplement le chemin d'accès au fichier en argument.
@Faminha102 Si cela aide, les octets d'image ne sont pas simplement introduits dans le CPU.Si le CPU reçoit un ensemble ou des octets lui demandant de faire quelque chose, il lira un par un ces octets d'instructions et fera ce qu'il lui a demandé.Dans le cas du chargement d'une image, il peut commencer par copier chaque octet de l'image du disque vers la mémoire.Les octets d'image ne passeront pas par le processeur.Le disque sera invité à charger chaque octet d'image sur le bus, puis la mémoire recevra l'instruction de charger les octets à partir du bus.C'est une simplification grossière, bien sûr, mais j'espère que cela aide à comprendre l'idée générale.
Cela ne devrait pas, bien sûr, mais il y avait (il y a?) Des [vulnérabilités] (https://docs.microsoft.com/en-us/security-updates/vulnerabilityresearchadvisories/2012/msvr12-004) qui peuvent provoquer un JPEGêtre éxecuté.Pourquoi diable vous écrivez une bibliothèque d'images d'une manière qui peut causer cela me dépasse, cependant.
Robyn
2018-10-29 15:50:02 UTC
view on stackexchange narkive permalink

Vous pourriez si votre cible utilisait une version d'Internet Explorer antérieure à août 2005 pour afficher un JPG. Ou s'ils allaient ouvrir un PNG dans Windows Media Player sur Windows 98 sans aucune mise à jour de sécurité installée. Et ainsi de suite.

Il y avait beaucoup d'anciens logiciels qui avaient des bogues où, si vous faisiez un fichier image dans lequel la première partie du fichier image mentait outrageusement sur la taille et l'emplacement du pixel données dans le fichier, le logiciel pourrait faire quelque chose de mal et sauter accidentellement au code à la mauvaise adresse ou écrire les données du fichier à 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 faire cela avec les versions plus récentes d'Internet Explorer, ou 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 actuels ont mis en place des mesures de protection pour rendre difficile (mais pas complètement impossible) de réaliser quelque chose de vraiment mauvais si vous trouvez une nouvelle façon de pirater un programme en utilisant une méthode comme celle-ci. Des zones de mémoire peuvent être définies pour qu'elles ne puissent pas ê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 mémoire imprévisibles, il n'est donc pas simple pour un code malveillant de les trouver et de les utiliser.

Plus de détails: https://security.stackexchange.com/questions/97856/can-simply-decompressing-a-jpeg-image-trigger-an-exploit
L'éminent blogueur allemand [Felix von Leitner] (https://blog.fefe.de/) insiste souvent sur le fait que, paradoxalement, * les antivirus * exposent d'énormes surfaces d'attaque car ils doivent pouvoir ouvrir tous les formats de fichiers tout en s'exécutant avec un maximum de droits.Vous n'avez donc même pas besoin d'ouvrir le JPEG;cela peut être suffisant si votre programme antivirus tente de le scanner en arrière-plan.
Exactement.Les fichiers JPEG ont très certainement des ordinateurs infectés.Une recherche Google à l'instant pour * jpeg malware * a renvoyé [ce site l'expliquant] (https://www.bullguard.com/blog/2018/01/jpeg-files-and-malware).
Des vulnérabilités dans certains logiciels existaient au moins aussi récemment qu'en 2012: https://docs.microsoft.com/en-us/security-updates/vulnerabilityresearchadvisories/2012/msvr12-004
Daisetsu
2018-10-29 06:55:30 UTC
view on stackexchange narkive permalink

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 masque que des informations, ce n'est pas le cas. exécuter toutes les instructions.

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 du fichier.

Dans ce cas, le rare cas où une image pourrait entraîner l'exécution de code est s'il y avait un bogue dans le logiciel qui a rendu l'image à partir du 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.

Intéressant.Donc, avec les PDF, ça irait, c'est ce que vous dites?
Les PDF ont plus de fonctionnalités, ils peuvent être interactifs, charger des ressources externes, incorporer d'autres fichiers, etc. Ils ne sont cependant pas aussi dangereux que les fichiers Word / Execl.
Pouvez-vous en dire plus?
Elaborer plus sur quoi?Une attaque de style cheval de Troie repose sur un fichier d'aspect innocent qui contient soit une charge utile malveillante (macros de mots, fichiers exécutables, javascript) OU est lu par un analyseur vulnérable.Ce deuxième cas est assez rare et attire beaucoup d'attention car il affecterait tant de gens.Il y a un exemple que vous connaissez probablement, qui est Flash.Flash a des mises à jour de sécurité constantes, car il essaie de faire tellement, il existe de nombreuses façons de créer un fichier qui entraîne (parfois) l'exécution de code arbitraire.
@Faminha102 PDF est différent car le format de fichier PDF moderne est conçu pour exécuter du javascript intégré (similaire à la façon dont les fichiers HTML le font).Mais l'utilisateur doit ouvrir le fichier PDF
_ "Les fichiers image tels que les fichiers JPEG n'exécutent pas de code" _: Je trouve cela un peu imprécis.Même la plupart des fichiers exécutables n'exécutent pas de code, ils sont en cours d'exécution.
@phresnel est correct.Vous pourriez probablement créer un fichier qui, lorsqu'il est ouvert en tant qu'image JPEG, affiche une image (moche) et lorsqu'il est exécuté en tant que code, fait quelque chose de malveillant.
Pour développer le commentaire d'@phresnel, * aucun * fichier n'exécute du code, les programmes exécutent du code.Les systèmes d'exploitation ont des programmes associés aux extensions de fichiers.Lorsque vous double-cliquez sur un fichier, le programme associé à cette extension de fichier est exécuté et ce programme ouvrira ensuite le fichier.Si vous ouvrez un fichier avec un programme qui ne fait que restituer des images, aucun code du fichier ne sera exécuté, quel que soit son contenu.
@Captian Man, pour qu'un fichier s'exécute directement (sans être invoqué par un autre processus qui interpréterait ses instructions) un programme doit être un exécutable binaire (binaire ELF pour Linux, PE pour Windows).Vous ne pouvez pas simplement prendre un binaire et créer un fichier JPEG valide.Les en-têtes d'un JPEG et d'un PE / ELF ne sont pas alignés.
@Daisetsu: Mais si vous avez un programme amusant "JpegExecuter" qui charge les JPEG en mémoire et interprète les couleurs comme des instructions, alors ce fichier peut être exécuté.Tout comme je peux exécuter des binaires Windows au format .COM ou .EXE sur une machine Linux, étant donné un programme amusant nommé Wine.Ou .NET.Non exécutable sans hôte.Cette discussion peut devenir énorme, en fait;que signifie réellement «exécuter un fichier directement»?Même le format binaire (probablement) le plus brut .COM doit d'abord être chargé avant d'être interprété par le CPU et digéré en microcode.
Btw, http://www.dangermouse.net/esoteric/piet/samples.html
@phresnel tout le monde peut écrire un programme pour interpréter un fichier d'une manière non conforme aux normes de format (JPEG).Mais ce n'est pas un cas réaliste.La question portait sur les fichiers JPEG normaux, rendus obstinément par des programmes graphiques normaux.
Oui, mais cela ne rend pas «les fichiers JPEG n'exécutent pas de code» plus précis que «les fichiers EXE n'exécutent pas de code».
rackandboneman
2018-10-30 17:39:35 UTC
view on stackexchange narkive permalink

Vous pouvez, SI vous savez également quelle pile logicielle touchera l'image du côté récepteur, ET SI il y a des vulnérabilités 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 de lecteur JPEG exacte sur un fichier JPEG mal formé d'une manière qu'il copiera les données du fichier image où ces données n'appartiennent pas (par exemple, en plus des variables qui contiennent des informations de flux de contrôle du programme telles que des pointeurs de fonction ou des adresses de retour), et si les contre-mesures au niveau du système d'exploitation ou du matériel (par exemple DEP) ne s'arrêtent pas que de se produire, il y a une chance réaliste. De telles vulnérabilités ont existé (et existent dans les anciennes) implémentations du monde réel.

John U
2018-11-01 19:48:36 UTC
view on stackexchange narkive permalink

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 pouvoir 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 & afficher un JPEG n'essaiera pas d'exécuter l'une des données du fichier, seulement le lire et le traiter - et s'il rencontre des données non-jpeg de manière inattendue, 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 (par exemple) en essayant de charger automatiquement les pièces jointes aux e-mails d'affichage d'& , créez des formats de document qui peuvent 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 (masquant la dernière partie .exe) les gens voir file.jpg et cliquer dessus, ce qui oblige le système d'exploitation à l'exécuter.

C'est la différence entre lire un livre et agir o ut le contenu du livre - si le livre dit "va frapper quelqu'un", vous n'allez pas le faire, parce que les mots (données) dans le livre ne contrôlent pas votre cerveau même si votre cerveau traite ces données.



ⓘ
Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 4.0 sous laquelle il est distribué.
Loading...