From: Art on
On Wed, 5 Jul 2006 17:10:23 +0100, "Noel Paton"
<NoelDPspamless(a)crashfixpc.com> wrote:

>While I think of it, Art - what happens if you run Ad-Aware over your JPG
>samples, in ADS-test mode??

Haven't tried it but I will if that mode is available on the free
version or a free-to-try demo.

Art
http://home.epix.net/~artnpeg
From: Art on
On Wed, 5 Jul 2006 20:37:08 +0100, "Noel Paton"
<NoelDPspamless(a)crashfixpc.com> wrote:

>Yup - it's a little hidden, but it's there all right

I don't see anything in AdAware SE about a ADS-Test mode.
Exactly what is it that you're talking about and why do you
think AdAware would be of any use in the case of JPGs
containing appended encrypted code when most av products
aren't even alerting?

Art
http://home.epix.net/~artnpeg
From: Art on
On Wed, 5 Jul 2006 21:45:17 +0100, "Noel Paton"
<NoelDPspamless(a)crashfixpc.com> wrote:

>In Ad-Aware - Scan now
>Scan Mode - Scan Volume for ADS (Alternate Data Streams)

Ok, set it to scan my entire drive. No alerts.

>Back in Dec/January, when the WMF exploits initially reared their head, one
>distinguishing feature of infected files was that they all showed positive
>on testing for ADS (even when tested in Win9x, IIRC) using Ad-Aware.
>It was an effective discovery tool before the AV's caught up (and
>incidentally demonstrated why Win9x wasn't vulnerable to that particular
>exploit).

Interesting. I missed that tidbit :)

Art
http://home.epix.net/~artnpeg
From: Christopher P. Winter on
On Wed, 05 Jul 2006 20:07:54 GMT, Art <null(a)zilch.com> wrote:

>On Wed, 5 Jul 2006 15:37:36 -0400, "edgewalker" <null(a)null.invalid>
>wrote:
>>
>>So where's the "need" for jpg scanning?
>
>I've already explained that in my other posts in this thread.
>
>>I can see there would be a need
>>to detect a program that attempts to use jpg data as code, but the need
>>for scanning data files for possible 'data as code' inclusions escapes me.
>
>Your attitude and opinion escapes me.
>
>>Aside from just a mental exercise, and in the process learning more about
>>the jpeg specs - I think you're wasting time. Any data filetype can contain
>>data destined to be used as code by a nefarious trojan.
>
>That why container scanning is important. In practicing safe hex, I
>don't rely on some single realtime av. That's far too risky, and in
>this particular case it's exceptionally risky for reasons I've pointed
>out. I want my scanners to detect malicious code during on-demand
>scans of various containers, and in compressed and packed files.
>

I'm an infrequent visitor here. Let me see if I understand your concern.
You're saying that the malicious code could "lie doggo" in JPEG image files
on someone's machine until an apparently innocuous .exe was inadvertently
downloaded and executed? (By "apparently innocuous" I mean one that
anti-malware programs don't detect.)

It may be that the action of automatically opening the JPEG is something that
can be consistently detected and blocked, in which case malicious code in
JPEGs (or any other data files) might become moot.

I say "might be" because of watermarks. Now, I don't know much about how
watermarks work, but I do know they are supposed to be immune to image
manipulation. If they can be, so can the malware code. Also, the action of a
legitimate watermark reader might be hard to distinguish from that of a
malware activator.

Bottom line: I think your concern is valid, but I also think that coning up
with a real-world solution will be a very thorny problem.
From: edgewalker on

"Christopher P. Winter" <chrisw20(a)chrisw20.best.vwh.net> wrote in message news:jtukb2pl9o62p98quvefk4jsaeoar78mf7(a)4ax.com...

> It may be that the action of automatically opening the JPEG is something that
> can be consistently detected and blocked, in which case malicious code in
> JPEGs (or any other data files) might become moot.

I can see only rare instances where the companion executable wouldn't be able to
just carry any 'other' malicious code within itself rather than to store that code in
some companion data filetype. Couple that with the fact that "any" filetype can
contain data that will later represent malicious code when read by a companion
executable programmed for that purpose. The companion executable could even
be the decryptor of encrypted data leaving you no way to detect the data companion
as having malicious content.

I came to the conclusion that Art wants to detect this "on-demand" just for the
sake of completeness when scanning incoming data filetypes. That's okay with
me, but there are so many ways that malware writers can get around detectability
in data filetypes that I think it is not worthwhile.

> I say "might be" because of watermarks. Now, I don't know much about how
> watermarks work, but I do know they are supposed to be immune to image
> manipulation. If they can be, so can the malware code. Also, the action of a
> legitimate watermark reader might be hard to distinguish from that of a
> malware activator.

You hit that grey area like is it a remote administration tool or a remote access
trojan. The same exact program could be either, depending on circumstances.
Detection for some kinds of trojans are on a first come first served basis. Any
application that executes on your machine and gets data to be interpreted and
executed as code (like Java) cannot be judged as malware on that basis alone.
(maybe they should be though).

What about an batch that changes your very own batch files to malware
by changing paths from your cleanup.bat (deletes temp files) to delete files
in directories you wanted preserved? Gee, now you'll have to detect your
very own batch files as malicious because of some future malware that may
use some code from them to do bad things.