The other answers mostly talk about attaching arbitrary code to images via steganographic techniques, but that's not very interesting since it requires that the user be complicit in extracting and executing that. The user could just execute malicious code directly if that's their goal.

Really you're interested in whether there's a possibility of unexpected, arbitrary code execution when viewing an image. And yes, there is such a possibility of an attacker constructing a malicious image (or something that claims to be an image) that targets specific image viewing implementations with known flaws. For example, if an image viewer allocates a buffer and computes the necessary buffer size from a naive width * height * bytes_per_pixel calculation, a malicious image could report dimensions sufficiently large to cause the above calculation to overflow, then causing the viewer to allocate a smaller buffer than expected, then allowing for a buffer overflow attack when data is read into it.

Specific examples:

• http://technet.microsoft.com/en-us/security/bulletin/ms05-009
• http://technet.microsoft.com/en-us/security/bulletin/ms04-028
• http://www.adobe.com/support/security/bulletins/apsb11-22.html
• https://www.mozilla.org/security/announce/2012/mfsa2012-92.html
• http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-1205
• http://en.wikipedia.org/wiki/Windows_Metafile_vulnerability

In general, these sorts of things are difficult to protect against. Some things you can do:

• Keep your systems and applications updated.
• Enable DEP.
• Enable ASLR if possible.
• Avoid running programs with administrative privileges.
• On Windows, Microsoft's EMET could also provide some protection.

Yes, there are ways to 'exploit' buffer overflows.

Sometimes the code may need to be executed via a separate script, and in theory you could assemble a virus from multiple images that contained code hidden within the picture using stenography but there are easier ways.

Basically many computer systems expected images to comply with the exact specification for the type and the failed to correctly range check the formats/parameters being passed.

By 'engineering' an image so that externally it looks like it complies but internally it does not, it was to be possible to trigger stack corruption/buffer overflows that would allow code hidden in an image to be executed under the authority of the user.

But note that this does not ONLY apply to images, it can apply to ANY file, take a look at the recent RTF exploit in MS word.

Sie können Dateien / Programme / alles jederzeit im "Slack Space" einer Datei verstecken. Anschließend können Sie später ein Skript ausführen, um das zu extrahieren und / oder zu kompilieren, was Sie versteckt haben. Beispielsweise können Sie eine schädliche ausführbare Datei (oder ein kleineres Skript) in mehrere Bilder auf einer Website einbetten. Wenn ein Benutzer die Website besucht, lädt er die Bilder herunter.

Erfahren Sie hier mehr über Slack Space: http://www.computerhope.com/jargon/s/slack-space.htm und spielen Sie selbst damit herum, indem Sie sich a schnappen Hex-Editor ( http://mh-nexus.de/en/hxd/) und herumspielen.

For pretty much any file format, the programs who read it might have some bugs exploitable by a maliciously crafted file.

It can happen (and has happened) also for images; but it'd generally be limited to a single particular program (or library) reading it, not a general "image with malware" that attacks all such programs.

Even text files aren't theoretically safe if the programs try to do something interesting with them. A sql injection in a blog comment post is essentially "malware attached to text"; there was a vulnerability in Python allowing crash (=denial of service) by submitting malicious text data and claiming that it's in UTF-7 encoding, exploiting a bug in that decoder; and there exist attacks based on breaking XML parsers by, again, malicious near-text data.

Yes, it is possible to hide malware in an image. It is not very common attack at all but recently it seems that malware authors start hiding malware inside images.

Malware analysis is not my thing. if you want more information search for "Steganography Malware".

One advice is do not open emails from untrusted/unknown source.

Exploits are just that, exploits. Someone finds a vulnerability in some widely used code, and then sets out to set the stage for that vulnerability to do its thing. Let's pretend for example someone out there figured out that some widely-used email client has a bug that leads to a buffer overflow in some specific circumstance. If enough malformed data is fed into the buffer, it overruns onto the stack. Now you can take an image, malformed exactly like it needs to be to cause the buffer overflow, embed into it some malware, and pad the end of the data with a bunch of NOPs and then a clever small assembly routine that get dumped on the stack, which when run points directly to the malware that is already loaded in memory in the image buffer. All a user has to do to get infected is have the malformed image be displayed in the vulnerable application. This is a more common channel of attack in highly specific zero-day exploits.

Remedies to these problems are fortunately easy to apply. Configure the machines to only allow plain-text messages. Make sure you use only well maintained software and apply all updates automatically.

Es gibt Programme, die als Binder bezeichnet werden und normalerweise eine ausführbare Datei an ein Image anhängen. In Bildern gefundene Malware sind in der Regel RATs (Remote Administration Tools), bei denen es sich um Skid-Inhalte handelt, mit denen einige Skids auf Ihren Computer zugreifen. Normalerweise wird dies jedoch nur auf Websites verwendet, auf denen geile Idioten mit diesen Skids sprechen und die Skids so tun, als wären sie ein Mädchen, und ihnen sagen, sie sollen ein Bild herunterladen. Persönlich denke ich, dass es viel bessere Möglichkeiten gibt, Dinge zu verbreiten. Auch die meisten Antivirenprogramme sollten diese "Bindungen" erkennen, selbst wenn das Virus FUD ist (vollständig unentdeckt).

Bei einfachen Textnachrichten wird keines der potenziell gefährlichen oder versteckten Skripte interpretiert oder ausgeführt, wenn der E-Mail-Client nur einfachen Text liest. Es ist nur eine Zeichenfolge für den E-Mail-Client.

Es gibt ein Beispiel für eine hier beschriebene Sicherheitsanfälligkeit - vollständige Codeausführung auf Windows-Systemen, wenn Javascript aktiviert war => SVG SNAFU.

Info:

Joshua Yabut, ein anderer Forscher, der auch den Code analysierte, sagte Ars, er nutze einen sogenannten Use-After-Free-Fehler, bei dem JavaScript aktiviert werden muss auf dem anfälligen Computer. Yabut fuhr fort, der Code sei "100% effektiv für die Remotecodeausführung auf Windows-Systemen". Der Exploit-Code, fügte der Forscher hinzu, passt den Speicherort der Nutzdaten basierend auf der ausgenutzten Version von Firefox an. Die Versionen reichen von 41 bis 50, wobei Version 45 ESR die Version ist, die von der neuesten Version des Tor-Browsers verwendet wird. Die Anpassungen sind ein Hinweis darauf, dass die Personen, die den Angriff entwickelt haben, ihn ausgiebig getestet haben, um sicherzustellen, dass er auf mehreren Versionen von Firefox funktioniert. Der Exploit ruft direkt kernel32.dll auf, einen Kernbestandteil des Windows-Betriebssystems. Quelle