Malware Triangle

[Max Mustermann]

[snip LOTS of pointless arguing]

Um, excuse me, but could we PLEASE get off of the bickering over
terminology and BACK to the subject of identifying, stopping, and defending
against actual Malware.... REGARDLESS of it's form or format?

Thanks!

~~~~~~~~~~~~~~~~~~~~~
This message was posted via one or more anonymous remailing services.
The original sender is unknown. Any address shown in the From header
is unverified. You need a valid hashcash token to post to groups other
than alt.test and alt.anonymous.messages. Visit www.panta-rhei.dyndns.org
for abuse and hashcash info.

 

[Leythos]

I'm not "blaming" either HTML or the application that renders it; I'm
just asserting that HTML is not safe, and that a page of HTML (or an
HTML email message) can be malware.

If you continue with your idea that HTML is a threat because it's part
of the malware (which indicates program/script/language), then you must
include ASCII TEXT files also. I can embed the same scripts that you are
concerned about in an ASCII Text file, and although, like in HTML, they
do nothing, that have same exposure as HTML with programming scripts
embedded.

What all this means is that if you use an application to view the
contents of anything, if that application has flaws, then it's the
application that is at fault, not the content.

 

[Richard S. Westmoreland]

no, they are not... html documents are not programs, therefore they are
not software...

Would you say that all software = programs?

Rick

 

[Richard S. Westmoreland]

You've got to look at it like this - HTML is not a program and can NOT
execute any code on a person's computer. The Browser or other HTML
reader parses the ASCII TEXT in what ever format the browser determines
it needs too. This means that the HTML is not the problem, it's the
flaws in the Browser/other program that are a the risk.

Should we classify the exploitable programs as MalWare? I'm sure some
people already consider Internet Explorer and Outlook Express as malware...

Rick

 

[Richard S. Westmoreland]

[snip LOTS of pointless arguing]

Um, excuse me, but could we PLEASE get off of the bickering over
terminology and BACK to the subject of identifying, stopping, and defending
against actual Malware.... REGARDLESS of it's form or format?

I don't mind the bickering, but I don't think anyone in this thread will be
changing their mind any time soon.

I could call this the "Malicious Stuff Triangle", but some may even disagree
that spam is considered malicious.

Let's not forget how costly spam is to the enterprise - image links in html
emails will identify the user and machine and verify that they received the
email - all email is somewhere around 70% spam now - spammers aren't just
sending out bulk advertisements, they're trying to trick the user into
opening them now... and so on. And then you have the risk of blocking the
good stuff (which is time sensitive). If anyone here has ever managed
antispam for a large company then you know what I'm talking about.

Rick

 

[Leythos]

Should we classify the exploitable programs as MalWare? I'm sure some
people already consider Internet Explorer and Outlook Express as malware...

Malware is something that you don't intend or know you've installed.
Flawed products like IE/OE are no more malware than the C++ IDE or
DreamWeaver MX product. Flawed applications would be listed under
applications, not malware.

Malware is something that does some bad thing to your system, and IE/OE
do not directly do anything bad to your computer. As an application,
they can pose a thread only due to poorly coded functions.

 

[Leythos]

[snip LOTS of pointless arguing]

Um, excuse me, but could we PLEASE get off of the bickering over
terminology and BACK to the subject of identifying, stopping, and defending
against actual Malware.... REGARDLESS of it's form or format?

I don't mind the bickering, but I don't think anyone in this thread will be
changing their mind any time soon.

I could call this the "Malicious Stuff Triangle", but some may even disagree
that spam is considered malicious.

Let's not forget how costly spam is to the enterprise - image links in html
emails will identify the user and machine and verify that they received the
email - all email is somewhere around 70% spam now - spammers aren't just
sending out bulk advertisements, they're trying to trick the user into
opening them now... and so on. And then you have the risk of blocking the
good stuff (which is time sensitive). If anyone here has ever managed
antispam for a large company then you know what I'm talking about.

If you use MS Outlook 2003 and updates it will not download the images
that track you, and spam is completely out of hand.

I have three different anti-spam methods on our Exchange servers and it
takes about 4 hours a month to tweak them.

 

[Leythos]

HTML isn't a threat. Malicious HTML is a threat.

Images aren't a threat. JPEG's using the GDI+ exploit are threats.

Executables aren't a threat. Self replicating executables with a time bomb
are a threat.

Emails aren't a threat. 10,000 emails in a day aren't a threat. 10,000
emails in a day when your mailbox can only hold 1000 emails is a threat.

I don't know what the argument is about?

You need to separate the delivery method from the result - the malicious
HTML is something of a misnomer - HTML, of any type is not malicious,
it's only ASCII, the content in the HTML is not malicious, it's the flaw
in the browser that is a problem. Many browsers don't have a problem
with what IE does, so it's an IE problem, not an HTML problem.

I suppose, based on your argument, if I had a 30MB email limit and
customers sent me 100MB of email, I should feed threatened by them?

 

[Richard S. Westmoreland]

If you continue with your idea that HTML is a threat because it's part
of the malware (which indicates program/script/language), then you must
include ASCII TEXT files also. I can embed the same scripts that you are
concerned about in an ASCII Text file, and although, like in HTML, they
do nothing, that have same exposure as HTML with programming scripts
embedded.

HTML isn't a threat. Malicious HTML is a threat.

Images aren't a threat. JPEG's using the GDI+ exploit are threats.

Executables aren't a threat. Self replicating executables with a time bomb
are a threat.

Emails aren't a threat. 10,000 emails in a day aren't a threat. 10,000
emails in a day when your mailbox can only hold 1000 emails is a threat.

I don't know what the argument is about?

Rick

 

[Richard S. Westmoreland]

You need to separate the delivery method from the result - the malicious
HTML is something of a misnomer - HTML, of any type is not malicious,
it's only ASCII, the content in the HTML is not malicious, it's the flaw
in the browser that is a problem. Many browsers don't have a problem
with what IE does, so it's an IE problem, not an HTML problem.

I suppose, based on your argument, if I had a 30MB email limit and
customers sent me 100MB of email, I should feed threatened by them?

I would consider that a threat to the Availability of incoming email, yes.
I wouldn't call it spam though unless it was unsolicited. My wife keeps
forwarding me goofy chainletters and a few with large images did put my
mailbox over the limit once, so I may very well put "Wives" on the Triangle.
;-)

I agree with what you are saying, it's all very good points. If I send you
an html email, that contains instructions that takes advantage of an exploit
in IE, and the result is some damage to your data or privacy, would you
agree that in one way or another my intent was malicious, and my email to
you was a threat? How would you classify this scenario?

 

[Leythos]

I agree with what you are saying, it's all very good points. If I send you
an html email, that contains instructions that takes advantage of an exploit
in IE, and the result is some damage to your data or privacy, would you
agree that in one way or another my intent was malicious, and my email to
you was a threat? How would you classify this scenario?

I would consider it a "exploit", something that is done to an
application. The email you send, the actual contents, are only a threat
to the application that it targets, not to anything else. While your
email is malicious in nature, and the content can take advantage of the
email readers flaws (if I'm using the email app you target), the fact
that the email is HTML based has no effect on it being malicious.

Web browsing and email reading, when exposed to APPLICATION exploits, do
not make the content a program/language/etc... In the old days, people
that wrote C/C++ code could overflow (as they can now too) a buffer and
cause all sorts of problems for an application - that did not make the
stream being sent to the buffer malicious, it means that the lamer that
coded the application didn't have an understanding of the methods and
inner working of the tools he was using to design the application. In
this case, a string of 800000000 "Z" characters would be considered
malicious to some applications if I followed your logic.

Now, your intent, in sending a crafted email to take advantage of an
exploit, would be considered malicious regardless of the email client,
not it would only impact the intended application in most cases.

So, what it comes down to is not really something like HTML, but the
script embedded in it (which is not HTML), and the parsing engines
ability to safely handle the embedded script.

So, we're back to "Exploits" and not malware when it comes to HTML
transport for compromising systems.


BTW, I force RTF mode on all email users, they can't even select HTML as
the output format. I also filter all email for anything other than HTML
and even attachments of scripting/programming types.

 

[Richard S. Westmoreland]

If you use MS Outlook 2003 and updates it will not download the images
that track you, and spam is completely out of hand.

I have three different anti-spam methods on our Exchange servers and it
takes about 4 hours a month to tweak them.

SP2 for WinXP seems to be doing the same thing.

Have you looked at the statistics to see on average how much email you're
stopping compared to email allowed through? I know that we get so much that
if I moved our antispam from the dedicated appliance to the Exchange server,
the server would be dead within minutes.

 

[Richard S. Westmoreland]

Malware is something that does some bad thing to your system,

You may have already commented on this earlier in the thread - but would you
classify a JPEG using the GDI+ exploit as malware?

If not, would you classify a VBS script as malware?

Would you classify a Macro (virus?) as malware?

Rick

 

[Leythos]

SP2 for WinXP seems to be doing the same thing.

Have you looked at the statistics to see on average how much email you're
stopping compared to email allowed through? I know that we get so much that
if I moved our antispam from the dedicated appliance to the Exchange server,
the server would be dead within minutes.

The RBL list blocks about 28000 email a month, and the spam filters hit
about 850 per day, but we're a small org. I have a couple clients that
have their own email servers using the Symantec Mail Security 4.5
version, it's catching most, and they have a higher volume than we do.

 

[Leythos]

You may have already commented on this earlier in the thread - but would you
classify a JPEG using the GDI+ exploit as malware?

No, I classify it as an Exploit.

If not, would you classify a VBS script as malware?

VBS is a programming language that does not take advantage of an
Exploit, it an run on the OS without exploiting anything.

Would you classify a Macro (virus?) as malware?

A macro is the same as a VBS, it's a script that executes based on the
installed OS and applications, it's not an exploit, it's a program code
that is run my the OS or application that it's launched from.

There is no difference between Malware and a Program, only the intent.

 

[Jack]

If you continue with your idea that HTML is a threat because it's
part of the malware (which indicates program/script/language), then
you must include ASCII TEXT files also. I can embed the same scripts
that you are concerned about in an ASCII Text file, and although,
like in HTML, they do nothing, that have same exposure as HTML with
programming scripts embedded.

Oh, goodness. Do please read the posts that you reply to. And don't
assume that all plain text is ASCII-encoded!

I imagine that there is some conceivable vulnerability that could be
exploited by a textfile (although I'm not aware of one); I have however
cited to you two exploits currently in the wild, to which current
versions of IE are vulnerable, that rely on nothing more than HTML. No
scripting, no CSS, no embedded objects.

What all this means is that if you use an application to view the
contents of anything, if that application has flaws, then it's the
application that is at fault, not the content.

You are quibbling about irrelevant semantic details. Read my post please!

All complex software likely has weaknesses. If a page of HTML is
deliberately constructed to attack a vulnerability in a rendering
engine, then that HTML is malicious. Whether it's '*ware' or not, in
your lexicon, is neither here nor there. The fact remains that a page of
HTML can so be constructed, and such pages have appeared in the wild on
websites and in emails.

Email is safest with HTML rendition disabled.

Do you disagree? Or is it your position that because HTML is
indistinguishable from plain text, HTML is exactly as safe as plain
text? Are you familiar with the way that browsers and email clients are
expected to deal with the Content-type: header? Does your OS launch HTML
pages with a text-editor, or something?

 

[Leythos]

Email is safest with HTML rendition disabled.

Do you disagree? Or is it your position that because HTML is
indistinguishable from plain text, HTML is exactly as safe as plain
text? Are you familiar with the way that browsers and email clients are
expected to deal with the Content-type: header? Does your OS launch HTML
pages with a text-editor, or something?

In the way that I view it, you are mixing two things and not just
looking at one.

I don't like HTML email because of the exploits that are available in
the application that some users choose to use. This does not make HTML
itself malicious, only the scripting embedded in it, and the intent. If
the exploit was not available, the embedded script would be of no
consequence.

Actually, you can configure XP to open an HTML file in any application
you want, Word, NotePad, DreamWeaver, IE, FireFox, VS.Net IDE, etc...

look at it from this angle, since the Exploit we're talking about is
something that impacts Outlook/OE and IE, do you see MS sending out
service patches for HTML to the world? No, they are patching exploits in
the applications. You could click on a link on the web that takes you
directly to the script, without ANY HTML IN THE LINK, and it would run
the script if you didn't have a secure browser. Now, take the script of
of the HTML, try the same thing, nothing to worry about. HTML is only
what get's blamed, it's the script and the exploit in the browser. In
the case of an IFRAME exploit, again, it's an exploit, not a flaw in
HTML.

 

[Richard S. Westmoreland]

So, what it comes down to is not really something like HTML, but the
script embedded in it (which is not HTML), and the parsing engines
ability to safely handle the embedded script.

So, we're back to "Exploits" and not malware when it comes to HTML
transport for compromising systems.

I don't really care about the HTML, I think someone else in the thread
steered the debate in that direction. If I sent you an email written out of
EBCDIC and for whatever reason it caused a problem on your system that I
intended, then that email is a threat, right? (regardless of the "is data
malware" debate)

BTW, I force RTF mode on all email users, they can't even select HTML as
the output format. I also filter all email for anything other than HTML
and even attachments of scripting/programming types.

Yes that is good advice. I block every attachment that can execute even
though our antispam is running antivirus.

Rick

 

[Jack]

You need to separate the delivery method from the result - the
malicious HTML is something of a misnomer - HTML, of any type is not
malicious, it's only ASCII,

Ever heard of UTF-8?

the content in the HTML is not malicious, it's the flaw in the
browser that is a problem.

The flaw in the browser isn't 'malicious'; it's the HTML author that is
malicious, if you want to get persnickety about silly details. But on
that basis, 'malware' is a word with no referent at all. The term
obviously means "software constructed with malicious intent". If you
want to say that HTML can't be software, and therefore can't be malware,
because malware is software, software means programs, and HTML can't be
a program, then you have your head stuck in a place where heads don't
belong.

Many browsers don't have a problem with what IE does, so it's an IE
problem, not an HTML problem.

It's not an HTML problem. Nobody said it was. Nor is it an IE problem,
from a general perspective; the problem is that HTML email requires a
rendering engine to be invoked, which introduces the possibility of all
kinds of security threats that do not arise with text/plain.

I suppose, based on your argument, if I had a 30MB email limit and
customers sent me 100MB of email, I should feed threatened by them?

How you 'feed' isn't my concern; nor is how you feel. Your claim that
HTML is as safe as text/plain is just wrong though, and you know it.

 

[Leythos]

So it's not IE or OE that is the malware; and it's not the HTML in the
web-page or email message that is the malware; so how was your system
attacked?

I've been working/programming since 76 and never experienced a
compromised system or virus on any computers/networks I've maintained,
so I don't have any idea why you are asking me about attacked?

You need to separate "malware" from "Exploit". Malware is something that
was created with the intent to add/modify/delete something on a users
system without their expressed permission. HTML can't execute anything
without the help of the browser or email client that is flawed, and then
it's not HTML that's the problem, it's the scripts/code embedded in the
HTML that is not HTML that's the problem.