E
edgewalker
Art said:
Yes, it's sad.
I don't think they should alert, but they should include them in verification
and cleanup. Alerts should be for threats.
Yes, it's sad.
I don't think they should alert, but they should include them in verification
and cleanup. Alerts should be for threats.
E
edgewalker
[interesting, but snipped anyway]
My take on this is that the jpg's are indeed trojans, but only in the presence
of the executable malware companion. That companion is the threat. The
obfuscated code could be any filetype at all and the code encrypted as well
as steganogrified - then where are you. I don't think the industry would want
to add technology to find hidden code when the hidden code can be so easily
encrypted anyway. To stop a threat, cut off its head. Deal with the jpg's as
part of the verification process (to get exact identification of variant) and to
help with cleanup. It doesn't need to produce an alert.
....any more than "Eddie lives...etc... does
My take on this is that the jpg's are indeed trojans, but only in the presence
of the executable malware companion. That companion is the threat. The
obfuscated code could be any filetype at all and the code encrypted as well
as steganogrified - then where are you. I don't think the industry would want
to add technology to find hidden code when the hidden code can be so easily
encrypted anyway. To stop a threat, cut off its head. Deal with the jpg's as
part of the verification process (to get exact identification of variant) and to
help with cleanup. It doesn't need to produce an alert.
....any more than "Eddie lives...etc... does
D
David H. Lipman
From: "edgewalker" <[email protected]>
|
|
| [interesting, but snipped anyway]
|
| My take on this is that the jpg's are indeed trojans, but only in the presence
| of the executable malware companion. That companion is the threat. The
| obfuscated code could be any filetype at all and the code encrypted as well
| as steganogrified - then where are you. I don't think the industry would want
| to add technology to find hidden code when the hidden code can be so easily
| encrypted anyway. To stop a threat, cut off its head. Deal with the jpg's as
| part of the verification process (to get exact identification of variant) and to
| help with cleanup. It doesn't need to produce an alert.
|
| ...any more than "Eddie lives...etc... does
|
I agree. This goes back to the experimental, demonstration, infector called W32/PerRun --
http://vil.nai.com/vil/content/v_99522.htm ~ 4 years ago. While steganography was not
mentioned in conjunction with this I knew it would eventually be used. Here we are, 4 years
later, and we have active Trojans using the technology.
BTW, the source, the Russian Mob !
|
|
| [interesting, but snipped anyway]
|
| My take on this is that the jpg's are indeed trojans, but only in the presence
| of the executable malware companion. That companion is the threat. The
| obfuscated code could be any filetype at all and the code encrypted as well
| as steganogrified - then where are you. I don't think the industry would want
| to add technology to find hidden code when the hidden code can be so easily
| encrypted anyway. To stop a threat, cut off its head. Deal with the jpg's as
| part of the verification process (to get exact identification of variant) and to
| help with cleanup. It doesn't need to produce an alert.
|
| ...any more than "Eddie lives...etc... does
|
I agree. This goes back to the experimental, demonstration, infector called W32/PerRun --
http://vil.nai.com/vil/content/v_99522.htm ~ 4 years ago. While steganography was not
mentioned in conjunction with this I knew it would eventually be used. Here we are, 4 years
later, and we have active Trojans using the technology.
BTW, the source, the Russian Mob !
D
Dustin Cook
4Q said:
How exactly is this a good example tho? The user had to rename it to
get it to execute.
Art is suggesting the jpegs themselves should be detected and removed,
because they pose a danger. I maintain that without win32.exe, they are
harmless.
I've acquired a sample of them, and I'm not sure if I will add them to
bughunter or not... I'm really not keen on the idea of scanning
jpegs...
It's a very sad state if his ITW thing went anyplace.
G
GEO Me
The latest version of Bagle was formed by two files inside the ZIP
file, one an EXE and one a DLL. Looking at the DLL with Notepad I
noticed that it was nothing but ASCII characters:
'ucrjsyfzimaepnc.....'
Geo
J
James Egan
Seems like a lot of effort for very little gain to me. There are too
many proprietary steganography techniques to cover to make it a
worthwhile venture given that the likelihood of the hidden malware
ever being executed is close to zero.
If it's created by a joke steganography program like Data Stash which
purports to use blowfish encryption but in fact just stores the hidden
file as a plain zip appended at the end then it might cause a few
scanners to alert regardless of any steganography functionality.
Jim.
A
Art
1. "Too many" or "potentially endless" considerations haven't
prevented vendors from doing a partial job at least of handling
various runtime packers and file compression (archiving) methods
when scanning on-demand. New packers are created
specially to confuse av, yet vendors like Kaspersky have clearly
attempted to keep up with them. Kaspersky and some others
have also pursued extraction and "scanning within" installation
and setup .EXE files even though that puts them in the position
of having to keep up with new installers as time goes on.
Now, if you want to argue that all of the above is unnecessary
because realtime scanning will/should eventually catch the
malware when run, that's a different matter and a different
argument. But I see no difference between making on-demand
scanning attempts at some of the JPG (and other) files in
circulation and making attempts at other "containers".
2. Your statement that the probability of the malware being
executed is zero is nonsense no matter how you look at it. Even
without the presence of a current companion, a new and
currently "unknown" companion could cnceivably get past av
scanners and run the code embedded in the JPGs. The JPGs
are a threat as long as they are on a PC. In fact, this sort of
thing may well be a part of the plan of the bad guys. Now,
it may be that realtime scanners will be smart enough to figure out
which file contains the embedded code that a day zero companion
runs, but I doubt it. So the damn JPGs could just sit there
undetected forever, endlessly used by new and "unknown"
companions. Some will argue that this boils down to nothing
more or less than _any_ day zero problem and av only need
be concerned with detecting companion malware which they
view as the _real_ and _only_ culprits. I would argue as (1.)
(above) and say that it's worthwhile IMO to make attempts
at alerting on files containing embedded malicious code if it's
feasible to do so, in as many cases as possible. And if JPG
embedded code is completely ignored by analysts, that begs
the question of whether or not realtime scanners will catch
the "unknown" code when it _ is_ run by a companion.
There's no way around analyzing the embedded code and
providing at least realtime detection in all cases when it's
feasible to do so in a scanner.
That's why I'm so interested in hearing back from Kaspersky,
though I'm not optimistic about receiving a "policy statement"
from most of their analysts or even from Eugene
I'm justhoping that I can "read between the lines" and deduce a
current policy on detecting embedded malicous code in
such files as I submitted. Based on their past history of not
shying away from "container" challenges, it will be interesting
to find out what they, in particular, plan to do. It's going on
two days now, and I've not yet heard back.
Art
http://home.epix.net/~artnpeg
D
David H. Lipman
From: "Art" <[email protected]>
| 1. "Too many" or "potentially endless" considerations haven't
| prevented vendors from doing a partial job at least of handling
| various runtime packers and file compression (archiving) methods
| when scanning on-demand. New packers are created
| specially to confuse av, yet vendors like Kaspersky have clearly
| attempted to keep up with them. Kaspersky and some others
| have also pursued extraction and "scanning within" installation
| and setup .EXE files even though that puts them in the position
| of having to keep up with new installers as time goes on.
| Now, if you want to argue that all of the above is unnecessary
| because realtime scanning will/should eventually catch the
| malware when run, that's a different matter and a different
| argument. But I see no difference between making on-demand
| scanning attempts at some of the JPG (and other) files in
| circulation and making attempts at other "containers".
| 2. Your statement that the probability of the malware being
| executed is zero is nonsense no matter how you look at it. Even
| without the presence of a current companion, a new and
| currently "unknown" companion could cnceivably get past av
| scanners and run the code embedded in the JPGs. The JPGs
| are a threat as long as they are on a PC. In fact, this sort of
| thing may well be a part of the plan of the bad guys. Now,
| it may be that realtime scanners will be smart enough to figure out
| which file contains the embedded code that a day zero companion
| runs, but I doubt it. So the damn JPGs could just sit there
| undetected forever, endlessly used by new and "unknown"
| companions. Some will argue that this boils down to nothing
| more or less than _any_ day zero problem and av only need
| be concerned with detecting companion malware which they
| view as the _real_ and _only_ culprits. I would argue as (1.)
| (above) and say that it's worthwhile IMO to make attempts
| at alerting on files containing embedded malicious code if it's
| feasible to do so, in as many cases as possible. And if JPG
| embedded code is completely ignored by analysts, that begs
| the question of whether or not realtime scanners will catch
| the "unknown" code when it _ is_ run by a companion.
| There's no way around analyzing the embedded code and
| providing at least realtime detection in all cases when it's
| feasible to do so in a scanner.
| That's why I'm so interested in hearing back from Kaspersky,
| though I'm not optimistic about receiving a "policy statement"
| from most of their analysts or even from Eugene I'm just
| hoping that I can "read between the lines" and deduce a
| current policy on detecting embedded malicous code in
| such files as I submitted. Based on their past history of not
| shying away from "container" challenges, it will be interesting
| to find out what they, in particular, plan to do. It's going on
| two days now, and I've not yet heard back.
| Art
| http://home.epix.net/~artnpeg
I haven't heard back from Kaspersky as well and I submitted the samples before you did.
| 1. "Too many" or "potentially endless" considerations haven't
| prevented vendors from doing a partial job at least of handling
| various runtime packers and file compression (archiving) methods
| when scanning on-demand. New packers are created
| specially to confuse av, yet vendors like Kaspersky have clearly
| attempted to keep up with them. Kaspersky and some others
| have also pursued extraction and "scanning within" installation
| and setup .EXE files even though that puts them in the position
| of having to keep up with new installers as time goes on.
| Now, if you want to argue that all of the above is unnecessary
| because realtime scanning will/should eventually catch the
| malware when run, that's a different matter and a different
| argument. But I see no difference between making on-demand
| scanning attempts at some of the JPG (and other) files in
| circulation and making attempts at other "containers".
| 2. Your statement that the probability of the malware being
| executed is zero is nonsense no matter how you look at it. Even
| without the presence of a current companion, a new and
| currently "unknown" companion could cnceivably get past av
| scanners and run the code embedded in the JPGs. The JPGs
| are a threat as long as they are on a PC. In fact, this sort of
| thing may well be a part of the plan of the bad guys. Now,
| it may be that realtime scanners will be smart enough to figure out
| which file contains the embedded code that a day zero companion
| runs, but I doubt it. So the damn JPGs could just sit there
| undetected forever, endlessly used by new and "unknown"
| companions. Some will argue that this boils down to nothing
| more or less than _any_ day zero problem and av only need
| be concerned with detecting companion malware which they
| view as the _real_ and _only_ culprits. I would argue as (1.)
| (above) and say that it's worthwhile IMO to make attempts
| at alerting on files containing embedded malicious code if it's
| feasible to do so, in as many cases as possible. And if JPG
| embedded code is completely ignored by analysts, that begs
| the question of whether or not realtime scanners will catch
| the "unknown" code when it _ is_ run by a companion.
| There's no way around analyzing the embedded code and
| providing at least realtime detection in all cases when it's
| feasible to do so in a scanner.
| That's why I'm so interested in hearing back from Kaspersky,
| though I'm not optimistic about receiving a "policy statement"
| from most of their analysts or even from Eugene
I'm just| hoping that I can "read between the lines" and deduce a
| current policy on detecting embedded malicous code in
| such files as I submitted. Based on their past history of not
| shying away from "container" challenges, it will be interesting
| to find out what they, in particular, plan to do. It's going on
| two days now, and I've not yet heard back.
| Art
| http://home.epix.net/~artnpeg
I haven't heard back from Kaspersky as well and I submitted the samples before you did.
J
James Egan
That's not the same though. If (say) a least significant bit method is
used to hide the malware, any detection would be dependent on the
image containing the malware and not just the malware itself. So if
someone got a (separate) infection which wrote a malware program to
the least significant bits of all the jpg's (over a minimum size to
suit the malware) on a particular machine then by the same reasoning,
all the av vendors would have to add detection for all these images to
their list since they are infected and already in the wild. There
could be gazillions of detections needed for one piece of malware.
Then it's not the jpg which gets executed. It's the "unknown"
companion which just slipped past your av scanner. That's what needs
to be detected and stopped.
Unless a joke program like Data Stash that I mentioned earlier is
used, then it's not going to be feasible.
Jim.
A
Art
I don't know what you mean by "least significant bit method". If we
can stick with the subject JPGs for the time being, clearly the
malware isn't hidden at all.
Well, I suppose I could modify the JPGs I have slightly and see if Bit
Defender and Symantec quit alerting on them.
Huh? They both execute. The companion causes the code in the
JPG to run.
I've already addresed and answered that. Sure the companions
must be stopped and that's what the vendors are addressing.
But day zero companions will/may run the code in the JPGs so
the JPGs must be detected as well.
If it's not feasible, how do you explain the detections by Bit
Defender and Symantec?
Art
http://home.epix.net/~artnpeg
A
Art
Now Fortinet can be added to the short list of vendors
alerting on the JPG files:
NT1.JPG Possible Tjreat (05993)
NT2.JPG Possibe Threat (05994)
NT3.JPG Possible Threat (05995)
Art
http://home.epix.net/~artnpeg
alerting on the JPG files:
NT1.JPG Possible Tjreat (05993)
NT2.JPG Possibe Threat (05994)
NT3.JPG Possible Threat (05995)
Art
http://home.epix.net/~artnpeg
B
B. R. 'BeAr' Ederson
If known malicious code is deliberately excluded from detection when
placed within non-executable data, the release of trigger programs
will become some kind of sport, the AV vendors will lose every now
and then. Moreover, if "appropriate" pictures are selected for the
code injection, they will spread like fire and last forever. :-(
Therefore, I generally agree with you. To limit the necessary sigs
and detection algorithms, spreading and dangerousness should be
taken into account. As every computer already contains a lot of
code which *can* be exploited for malicious actions, the specifics
of the steganographic hidden code are decisive, IMHO.
BeAr
J
James Egan
I meant a technique which mixes the data in with the image causing
changes which aren't very noticeable to the eye rather than appending
the whole of the (malware) data before some beginning of file marker
or after an end of file marker. Such a technique is more pertinent to
bitmaps where the least significant bit in a 24 bit pixel can be
easily altered to something else (to store the malware) without
radically altering the colour of the pixel. With (lossy) jpg's it
wouldn't be so simple of course but will nonetheless be possible to
some degree.
The malware is probably all together as a comment at the beginning or
at the end after the end of file marker so altering the image itself
wouldn't make any difference.
I meant it's not feasible generally if some serious steganography prog
has been used to create the image. Remember that as well as
discovering that there is a hidden file within an image, the av also
has to determine that the hidden file is malware which will likely
involve breaking some serious encryption.
Adding detection for non serious stuff like the frog jpegs shouldn't
be difficult, but there could also be any number of infected images on
the same computer which are undetectable. Therefore the emphasis must
surely be placed on detecting and stopping the companion needed to
activate the malware.
Jim.
A
Art
Do av really have to determine that a "diddled with" JPG contains
encrypted "information" and be able to deal with decrypting it? Or is
it sufficient to recognize that something is definitely unusual for a
otherwise recognizable JPG format?
Why couldn't ISP email scanner/blockers treat such animals as
exceptions and pass them on to the users with a warning message
to the effect that something "fishy" has been detected? That way,
the few users exchanging legit altered JPGs could deal with the issue
by passing on a MD5 in the message body, passwords for the zips, etc.
Users not expecting a "fishy" JPG have been duly warned and if they
have half a brain they simply delete the attackment.
Similarly, all av could treat such JPGs as a exception and simply
issue a "something's fishy" warning to users. In fact, I suspect
a very strong warning might be legitimately issued, but I might
be overly optimistic about the definiteness of the determination.
Art
http://home.epix.net/~artnpeg
BTW, we've limited the discussion to JPGs because of the actual
sample malware I discussed, but we're really talking about
multimedia files and other "data" files as well.
D
Dustin Cook
Art said:
How would AV know if it's diddled or not? The whole point behind the
process is to alter only enough bits spread thruout the file to store
your data, for all intents and purposes, it's video data... Nothing but
a few bytes here and there altered... hardly noticable...
P
Phil Weldon
'Art' wrote, in part:
| Well, I suppose I could modify the JPGs I have slightly and see if Bit
| Defender and Symantec quit alerting on them.
_____
Try an image editor and change the overall 'brightness by 1%. That should
destroy any executable hidden in a .jpg image.
Phil Weldon
..
|
| I don't know what you mean by "least significant bit method". If we
| can stick with the subject JPGs for the time being, clearly the
| malware isn't hidden at all.
|
| >any detection would be dependent on the
| >image containing the malware and not just the malware itself.
|
| Well, I suppose I could modify the JPGs I have slightly and see if Bit
| Defender and Symantec quit alerting on them.
|
| >>2. Your statement that the probability of the malware being
| >>executed is zero is nonsense no matter how you look at it. Even
| >>without the presence of a current companion, a new and
| >>currently "unknown" companion could cnceivably get past av
| >>scanners and run the code embedded in the JPGs.
|
| >Then it's not the jpg which gets executed. It's the "unknown"
| >companion which just slipped past your av scanner.
|
| Huh? They both execute. The companion causes the code in the
| JPG to run.
|
..
|
| If it's not feasible, how do you explain the detections by Bit
| Defender and Symantec?
|
| Art
| http://home.epix.net/~artnpeg
| Well, I suppose I could modify the JPGs I have slightly and see if Bit
| Defender and Symantec quit alerting on them.
_____
Try an image editor and change the overall 'brightness by 1%. That should
destroy any executable hidden in a .jpg image.
Phil Weldon
..
|
| I don't know what you mean by "least significant bit method". If we
| can stick with the subject JPGs for the time being, clearly the
| malware isn't hidden at all.
|
| >any detection would be dependent on the
| >image containing the malware and not just the malware itself.
|
| Well, I suppose I could modify the JPGs I have slightly and see if Bit
| Defender and Symantec quit alerting on them.
|
| >>2. Your statement that the probability of the malware being
| >>executed is zero is nonsense no matter how you look at it. Even
| >>without the presence of a current companion, a new and
| >>currently "unknown" companion could cnceivably get past av
| >>scanners and run the code embedded in the JPGs.
|
| >Then it's not the jpg which gets executed. It's the "unknown"
| >companion which just slipped past your av scanner.
|
| Huh? They both execute. The companion causes the code in the
| JPG to run.
|
..
|
| If it's not feasible, how do you explain the detections by Bit
| Defender and Symantec?
|
| Art
| http://home.epix.net/~artnpeg
A
Art
A downloader Trojan (for example) in just a few bytes? I was thinking
in terms of otherwise unused space and a fairly large # of bytes. I
don't know if it's practical to alter the large # of bytes for complex
Trojans in the actual image data without very noticeable picture
distortions (noisy images). Guess it's time to really study the
subject rather than just glossing over a article or two on picture
image steganography
Art
http://home.epix.net/~artnpeg
A
Art
Now, there's some thinking outside the box! Let's say that such a
minor and unobjectionable modification to color, brightness, contrast,
etc., is a sure-fire way to destroy the code. Call your invention a
"malware scrubber for JPGs" and peddle it
Or maybe av productscould incorportate a scrubber feature whereby with user permission
all JPGs on all drives are found and scrubbed. Anyone with legit
JPG steganogrphy files could keep them on removeable media for
safety from the scrubbing operation.
Art
http://home.epix.net/~artnpeg
P
Phil Weldon
'Art' wrote, in part:
| Now, there's some thinking outside the box! Let's say that such a
| minor and unobjectionable modification to color, brightness, contrast,
| etc., is a sure-fire way to destroy the code.
_____
JPEG compression is 'lossy'; the image cannot be restored to the original
quality, as are other compression standards, including MPEGx, MP3, and WMF.
Think about the steganographic possibilities with MPG2 files!
Ultimately, I think the cost of defense against steganographic content is
not bearable for any but the most critical applications (and that is likely
to be hidden data, not executables.) The defense will be blocking the
decoder malware.
Consider the possibilities of broadband MPG2 content distributed on the
Internet. MPG2 compression has more dimensions than JPEG because time is
involved. More than one 'frame' of information is necessary to reconstruct
any one displayable frame. Steganography with MPEG2, for example, could
include information from more than one frame that must be combined to
retrieve the hidden message. At a certain level of complexity the
processing power to even find a recognizable signature would be prohibitive,
especially since it would have to be done in real time. Some frames could
contain information that the decoder malware could use to find the real
message. That could go to arbitrary levels - easy for the decoder malware,
very difficult to defend against. This could lead to an arms race with
offense being much cheaper than defense - a $50,000 anti-tank missile
destroys a $3,000,000 tank; a $1,000,000 missile destroys a $1,000,000,000
ship.
Analog broadcast television (and videotapes) have long had hidden
information in the vertical blanking interval. NTSC television, for
example, has 525 lines, but 42 lines are hidden, and have no picture
content. A number of these lines are available for switching signals, test
signals, closed captioning, auxiliary data services ( and other, covert uses
I am sure.)
Phil Weldon
| On Sun, 25 Jun 2006 01:25:38 GMT, "Phil Weldon"
|
| >'Art' wrote, in part:
| >| Well, I suppose I could modify the JPGs I have slightly and see if Bit
| >| Defender and Symantec quit alerting on them.
| >_____
| >
| >Try an image editor and change the overall 'brightness by 1%. That
should
| >destroy any executable hidden in a .jpg image.
|
| Now, there's some thinking outside the box! Let's say that such a
| minor and unobjectionable modification to color, brightness, contrast,
| etc., is a sure-fire way to destroy the code. Call your invention a
| "malware scrubber for JPGs" and peddle it Or maybe av products
| could incorportate a scrubber feature whereby with user permission
| all JPGs on all drives are found and scrubbed. Anyone with legit
| JPG steganogrphy files could keep them on removeable media for
| safety from the scrubbing operation.
|
| Art
| http://home.epix.net/~artnpeg
|
|
| Now, there's some thinking outside the box! Let's say that such a
| minor and unobjectionable modification to color, brightness, contrast,
| etc., is a sure-fire way to destroy the code.
_____
JPEG compression is 'lossy'; the image cannot be restored to the original
quality, as are other compression standards, including MPEGx, MP3, and WMF.
Think about the steganographic possibilities with MPG2 files!
Ultimately, I think the cost of defense against steganographic content is
not bearable for any but the most critical applications (and that is likely
to be hidden data, not executables.) The defense will be blocking the
decoder malware.
Consider the possibilities of broadband MPG2 content distributed on the
Internet. MPG2 compression has more dimensions than JPEG because time is
involved. More than one 'frame' of information is necessary to reconstruct
any one displayable frame. Steganography with MPEG2, for example, could
include information from more than one frame that must be combined to
retrieve the hidden message. At a certain level of complexity the
processing power to even find a recognizable signature would be prohibitive,
especially since it would have to be done in real time. Some frames could
contain information that the decoder malware could use to find the real
message. That could go to arbitrary levels - easy for the decoder malware,
very difficult to defend against. This could lead to an arms race with
offense being much cheaper than defense - a $50,000 anti-tank missile
destroys a $3,000,000 tank; a $1,000,000 missile destroys a $1,000,000,000
ship.
Analog broadcast television (and videotapes) have long had hidden
information in the vertical blanking interval. NTSC television, for
example, has 525 lines, but 42 lines are hidden, and have no picture
content. A number of these lines are available for switching signals, test
signals, closed captioning, auxiliary data services ( and other, covert uses
I am sure.)
Phil Weldon
| On Sun, 25 Jun 2006 01:25:38 GMT, "Phil Weldon"
|
| >'Art' wrote, in part:
| >| Well, I suppose I could modify the JPGs I have slightly and see if Bit
| >| Defender and Symantec quit alerting on them.
| >_____
| >
| >Try an image editor and change the overall 'brightness by 1%. That
should
| >destroy any executable hidden in a .jpg image.
|
| Now, there's some thinking outside the box! Let's say that such a
| minor and unobjectionable modification to color, brightness, contrast,
| etc., is a sure-fire way to destroy the code. Call your invention a
| "malware scrubber for JPGs" and peddle it
Or maybe av products| could incorportate a scrubber feature whereby with user permission
| all JPGs on all drives are found and scrubbed. Anyone with legit
| JPG steganogrphy files could keep them on removeable media for
| safety from the scrubbing operation.
|
| Art
| http://home.epix.net/~artnpeg
|
|
B
B. R. 'BeAr' Ederson
Not necessarily so. The reason for significant changes within the picture
would be the compression by another algorithm and/or another compression
factor rather than the overall brightness change.
If you try your suggestion on an image twice in a row to ensure the same
compression settings, you'll find large portions of the images 2 and 3
unchanged. Most of the data may shift position. But a trigger program
can look for code snippets to get the offset of the malicious code. It
doesn't need to depend on exact positions. If AV programs always used
brightness changes to "disinfect" *.jpg files, virus writers would just
place the code in the chrominance part of the data stream. (Luminance
and chrominance are compressed separately in *jpg files.)
Moreover, all JFIF (JPEG File Interchange Format) files comprise of
several data blocks/streams. Besides using IPTC/EXIF metadata fields
it may be not to hard a task to construct blocks neither visible nor
changed by usual picture handling. That's the kind of pictures Art
targets when he talks about heuristic detection of suspicious files.
(If I get him right.) I, too, would be glad, if AV programs would
issue a warning about data files containing seemingly executable
code within text header fields or additional data streams.
Btw.: There is currently some research on the topic, how data of
pictures has to be manufactured to survive lossy transformation:
http://research.binghamton.edu/faculty/fridrich/fridrich.htm
Though the focus of the research of Jessica Fridrich is detecting
the original source (camera) of a picture (and the like), it
inevitably also shows, where to "best" hide information...
BeAr