A good false positive from KAV?

[Howard Harris]

Apparently only KAV and a-v based on the KAV engine such as eScan AntiVirus
Toolkit Utility identify the AP4.jpg file
http://slashdot.org/comments.pl?sid=122855&cid=10327905 recently released
as an apparent demonstration of how to exploit the issues addressed by
MS04-028 - Buffer Overrun in JPEG Processing (GDI+) as an infected file,
infected by "Exploit.IE.Crashsos" Virus.

There is an interesting discussion on the file in question AP4.jpg in
rec.photo.digital, with the following being perhaps the most relevant
observation:

"I just build the 6a JPEG library from the IJG sources and ran it on the
AP4.jpg image through a debugger. The offending code writes data to a
non-allocated buffer. I.e it writes to a pointer pointing out in space.
That is NOT a buffer overrun issue.
Moreover, what is written is the output from the inverse DCT. That is NOT
executable code from an untrusted source. Hence it is not a security
issue."

The following link is to the message from which I have quoted.

http://groups.google.com/[email protected]


Is this, then, a case of a good false positive? I think I would prefer my
a-v programme to alert me to a file that is intended to crash IE, rather
than to apply an abstract principle and not warn me at all that anything is
untoward. The former may violate purist a-v detecting principles, but is it
not better than the latter which just stands by unmoved while my browser
crashes?

 

[Miles Fromier]

Apparently only KAV and a-v based on the KAV engine such as eScan AntiVirus
Toolkit Utility identify the AP4.jpg file
http://slashdot.org/comments.pl?sid=122855&cid=10327905 recently released
as an apparent demonstration of how to exploit the issues addressed by
MS04-028 - Buffer Overrun in JPEG Processing (GDI+) as an infected file,
infected by "Exploit.IE.Crashsos" Virus.

There is an interesting discussion on the file in question AP4.jpg in
rec.photo.digital, with the following being perhaps the most relevant
observation:

"I just build the 6a JPEG library from the IJG sources and ran it on the
AP4.jpg image through a debugger. The offending code writes data to a
non-allocated buffer. I.e it writes to a pointer pointing out in space.
That is NOT a buffer overrun issue.
Moreover, what is written is the output from the inverse DCT. That is NOT
executable code from an untrusted source. Hence it is not a security
issue."

The following link is to the message from which I have quoted.

http://groups.google.com/[email protected]


Is this, then, a case of a good false positive? I think I would prefer my
a-v programme to alert me to a file that is intended to crash IE, rather
than to apply an abstract principle and not warn me at all that anything is
untoward. The former may violate purist a-v detecting principles, but is it
not better than the latter which just stands by unmoved while my browser
crashes?

If the file causes (or would cause) a crash, then it is a denial of service trojan and should be detected by software that
claims to detect non replicating (trojan?) malware. Trojans are not necessarily viruses despite what some expert sources
would have you believe.

From http://www.microsoft.com/technet/security/topics/virus/malware.mspx

"Trojan Horses can be a bigger problem than other types of viruses as they are design[ed] to be destructive or disruptive [...]..."

I'm sure the author of this piece (he posts here sometimes, no?) really does know the difference.

And from many of the AV virus description pages trojans are listed as viruses with the "subtype" of trojan for example
http://www.sophos.com/virusinfo/analyses/trojagobota.html which makes no mention of recursive replication and also this
http://www.sophos.com/virusinfo/analyses/index_st_trojan.html where you can list viruses by "type" which includes
many non-viral malware types - and even joke programs. In an effort to avoid confusing people - they confuse terms.

 

[xmp]

I haven't looked at all the code floating around, but the one on k-otik
is intentionally broken, it's simply a PoC (proof of concept):

"Shellcode and valid addresses have been removed."
"You non-kiddies out there are smart enough to fill in the blanks"

Um, no, it is a true positive.

I think I would prefer my


If the file causes (or would cause) a crash, then it is a denial of service trojan and should be detected by software that
claims to detect non replicating (trojan?) malware. Trojans are not necessarily viruses despite what some expert sources
would have you believe.

Exactly. In this case it's a vulnerability in the way jpeg's are
handled. Not much different than AVG and others, which flag on various
malicious javascript. The malicious component is that you can bind a
shell to port, download a trojan, etc.

michael

 

[xmp]

Is this, then, a case of a good false positive? I think I would prefer my
a-v programme to alert me to a file that is intended to crash IE, rather
than to apply an abstract principle and not warn me at all that anything is
untoward. The former may violate purist a-v detecting principles, but is it
not better than the latter which just stands by unmoved while my browser
crashes?

Do you really want your AV to look through the shellcode to determine if
it's a bind shell, trojan download, etc? Do you have any idea how much
CPU that would take? If anything, that's the domain of NIDS or NIPS.
Do you understand the ramifications of complexity theory, NP
Completeness, and the Halting Problem?

It flags it because it's an exploit.

michael