From: Art on
On Sat, 24 Jun 2006 07:52:45 +0100, James Egan <jegan(a)jegan.com>
wrote:

>On Thu, 22 Jun 2006 22:51:00 GMT, Art <null(a)zilch.com> wrote:
>
>>I'm puzzled that only two products alert on the JPEGS
>>even though many alert on the (apparently)
>>companion malware. I would think it important to
>>alert on the JPEGS as a warning to users to get rid
>>of them.
>
>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.

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
From: David H. Lipman on
From: "Art" <null(a)zilch.com>

| On Sat, 24 Jun 2006 07:52:45 +0100, James Egan <jegan(a)jegan.com>
| wrote:

>>On Thu, 22 Jun 2006 22:51:00 GMT, Art <null(a)zilch.com> wrote:

>>>I'm puzzled that only two products alert on the JPEGS
>>>even though many alert on the (apparently)
>>>companion malware. I would think it important to
>>>alert on the JPEGS as a warning to users to get rid
>>>of them.

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

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

--
Dave
http://www.claymania.com/removal-trojan-adware.html
http://www.ik-cs.com/got-a-virus.htm


From: James Egan on
On Sat, 24 Jun 2006 12:19:06 GMT, Art <null(a)zilch.com> wrote:

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

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.


>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. That's what needs
to be detected and stopped.


<snip>
>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.
>

Unless a joke program like Data Stash that I mentioned earlier is
used, then it's not going to be feasible.


Jim.

From: Art on
On Sat, 24 Jun 2006 19:13:20 +0100, James Egan <jegan(a)jegan.com>
wrote:

>On Sat, 24 Jun 2006 12:19:06 GMT, Art <null(a)zilch.com> wrote:
>
>>
>>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.
>
>That's not the same though. If (say) a least significant bit method is
>used to hide the malware,

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.

>That's what needs
>to be detected and stopped.

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.

><snip>
>>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.
>>
>
>Unless a joke program like Data Stash that I mentioned earlier is
>used, then it's not going to be feasible.

If it's not feasible, how do you explain the detections by Bit
Defender and Symantec?

Art
http://home.epix.net/~artnpeg
From: Art on
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