Viruses embedded in HTML?
Dave T
on this topic.
I'm investigating ways to secure our network a bit better. Currently, we
use Trend's product to block attachments in incoming emails. Since I don't
want to trust that they'll always have the latest "signatures" for new
viruses, we also block all executable attachments.
Now, I'm wondering if we need to do more. I'm wondering if we need to do
something to block viruses inside HTML, both in HTML emails, and in HTML
pages visited via a browser. Isn't it true that VBScript and JScript in an
HTML page can contain harmful code?
So, we're considering installing Trend's Virus Wall product. Does anyone
know anything about that? I'm a bit loathe to install a proxy server on our
lan - yet another point of failure. I'd rather just have something that
would disable all scripting calls that do things like write to the hard
drive, but allow calls that are simply providing dynamic content/rich UI on
a web page. Isn't there something that works like that?
Thanks!
- dave
Mark W. Brouwer
Dave T wrote:
>
> Sorry if this is a FAQ - I searched this NG and couldn't find any discussion
> on this topic.
>
> I'm investigating ways to secure our network a bit better. Currently, we
> use Trend's product to block attachments in incoming emails. Since I don't
> want to trust that they'll always have the latest "signatures" for new
> viruses, we also block all executable attachments.
Executable attachments means extensions '.vbs' '.shs', '.scr', '.chm'
'.bat'
and '.exe' for starters?
> Now, I'm wondering if we need to do more. I'm wondering if we need to do
> something to block viruses inside HTML, both in HTML emails, and in HTML
> pages visited via a browser. Isn't it true that VBScript and JScript in an
> HTML page can contain harmful code?
And ActiveX, Java Applets, ...
>
> So, we're considering installing Trend's Virus Wall product. Does anyone
> know anything about that? I'm a bit loathe to install a proxy server on our
> lan - yet another point of failure. I'd rather just have something that
> would disable all scripting calls that do things like write to the hard
> drive, but allow calls that are simply providing dynamic content/rich UI on
> a web page. Isn't there something that works like that?
Well, i'm testing a bit of beta software (2 months+) that's either
allow/monitor/block
any executables, ActiveX, scripts and Java Applets. Saved me a few times
from unattended
registry actions (home page changes). Downside is that there's no
exception possible.
It's all or nothing.
Don't know if there's a script blocker that will let you allow to view
content on a
web page and blocks malicious code. Come to think of it, i can't see the
purpose of
such a program. How to determine which code is malicious and which not?
That's the whole sherade of viruses; innocent programs carrying
malicious code.
> Thanks!
>
> - dave
Read up on practicing Safe Hex
http://claymania.com/safe-hex.html
--
Mark W. Brouwer,
Netherlands.
Email not correct due to SPAM.
Please remove WODKA to reply.
-----------------------------------------
Home Page : Virus or Hoax ?
Got Infected? Need info? Search and find!
-----------------------------------------
http://virusall.com
-----------------------------------------
Lee Higdon
"Dave T" <d...@eliassenxx.com> wrote in message
news:sWi48.58302$tx7.2567249992@newssvr15.news.prodigy.com...
AnalogX Script Defender. It's free and it works.
--
Peace,
Lee Higdon
Dave T
Thanks for the link to Script Defender. I came across this before in some
searching. Correct me if I'm wrong, but isn't this just protecting you from
executing scripts sent as attachments in emails? If so, I'm already safe
against that - I block all executable attachments (such as vbs files, etc.)
I'm looking to block scripts embedded inside HTML itself, but only the *bad*
ones.
Dave:
Maybe you're right - that it's not possible to allow only *good* code. But,
maybe you're wrong. Seems like you could have something parse HTML before
it got to the browser, and flag any iffy code. If you removed all calls to
code that wrote to the hard drive directly, then you'd go a long ways
towards blocking anything bad from happening. Kind of like the "sandbox"
concept for the Java interpreter - Java code can only do harmless things
like writing to the screen, getting keyboard input. Anything potentially
harmful is caught by the interpreter - no?
In any case, what are other people doing? Isn't most everyone currently
wide-open to the next generation of viruses that will come embedded inside
HTML?
- Dave
Alfred Wallace
Maybe you are using Trend ScanMail for Exchange, if it's true you can
activate the "Enable message body in MAPI mode" in the 3.5x version.
If your version is SMEX 3.7/3.8, you have the same option.
You can also use ISVW 3.52 for you Inbound/Outbound e-mail because this
product will scan your Html virus in your e-mails, no problem for this.
For the moment, HTML viruses are not really dangerous, NIMDA, BADTRANS,
etc.. are more dangerous.
Don't worry about Html viruses but maybe next year...
Fred.
"Dave T" <d...@eliassenxx.com> a écrit dans le message de news:
sWi48.58302$tx7.2567249992@newssvr15.news.prodigy.com...
Lee Higdon
> Lee:
>
> Thanks for the link to Script Defender. I came across this before in some
> searching. Correct me if I'm wrong, but isn't this just protecting you
from
> executing scripts sent as attachments in emails? If so, I'm already safe
> against that - I block all executable attachments (such as vbs files,
etc.)
>
> I'm looking to block scripts embedded inside HTML itself, but only the
*bad*
> ones.
>
applying just to attachments? I'll have to do some further checking.
Quote:
I'm sure that by now everyone has heard about email viruses; most people
probably have either experienced one themselves or know someone who has. The
latest batch of viruses have become more adept than ever at getting people
to execute them unintentionally - that's where AnalogX Script Defender comes
in!
AnalogX Script Defender will intercept any request to execute the most
common scripting types used in virus attacks, such as Visual Basic Scripting
(.VBS), Java Script (.JS), etc and can even be configured to intercept new
script extensions as needed! It's very simple to use and helps to ensure
that you do not inadvertently run a script no matter what email program you
use, or even if you get it via another method.
Unquote.
--
Peace,
Lee Higdon
Dave T
So, the "Enable message body in MAPI" mode will allow it to scan HTML
emails? I'll look into that.
In any case, it still seems like we need ISVW, for viruses in pages visited
directly from a browser.
My question remains, though, as to whether or not Trend is intelligently
parsing the scripts embedded in the HTML messages, or if it is finding
viruses based on signatures. If it's the latter, I don't have too much
confidence in its effectiveness. Do you agree?
Finally, what do you mean by "next year"? 2003? Why don't you think HTML
viruses will be coming out sooner?
- Dave
Dave T
Yes, that's what I saw too. I would interpret that to mean that it is
blocking attachments. .VBS and .JS are file extensions. Scripting code
embedded inside HTML isn't a file, there's no attachment. To protect
against that, the virus-checker would have to sit in front of the browser,
like a proxy server does.
- Dave
Nick FitzGerald
Indeed. I agree with Dave's reading of that page. It seems even clearer
when you read the 'version changes" at the end of the page:
1.02 Added .SHS to extensions list
1.01 Fixed new extensions not being intercepted
1.00 Initial Release
Now, the flip side of this is that, to date, most HTML embedded script
viruses and Trojans have dropped other scripting-based files which would
(well, "should" -- I'm assuming it works as decribed) be blocked by
ScriptDefender. However, these viruses need not, necessarily, work that
way so any current efficacy ScriptDefender has is (largely) due to an
accident of history and should not be taken as indicative of its likely
future usefulness.
--
Nick FitzGerald
Nick FitzGerald
> I'm investigating ways to secure our network a bit better. Currently, we
> use Trend's product to block attachments in incoming emails. Since I don't
> want to trust that they'll always have the latest "signatures" for new
> viruses, we also block all executable attachments.
>
> Now, I'm wondering if we need to do more. I'm wondering if we need to do
> something to block viruses inside HTML, both in HTML emails, and in HTML
> pages visited via a browser. Isn't it true that VBScript and JScript in an
> HTML page can contain harmful code?
It is, and despite some "optimism" expressed by another respondent that
"HTML viruses" won't be a problem until "next year", I'd be more cautious.
Some virus writers are clearly showing interest in "useful" security
vulnerabilities, such as those that give the ability to write to a
(potential) victim's local drive, and even "better" (from the malware
author's view) those that allow running of arbitrary code.
> So, we're considering installing Trend's Virus Wall product. Does anyone
> know anything about that? I'm a bit loathe to install a proxy server on our
> lan - yet another point of failure. I'd rather just have something that
> would disable all scripting calls that do things like write to the hard
> drive, but allow calls that are simply providing dynamic content/rich UI on
> a web page. Isn't there something that works like that?
Let me see -- you reject a proxy-based solution as "yet another point of
failure" but want extra code to put on your workstations? Uless you have
only one workstation, doesn't that increase the potential points of failure
considerably more than a proxy-based solution?
Anyway, Alladin's eSafe and Finjan's SurfinShield and SurfinGate product
lines provide this form of protection (or, at least, they claim to).
You should consider them carefully though -- in the past some very
simple tricks have been shown to subvert various of their claimed
"protections" (e.g. things as trivial as using "<<script>" as the "open
script" tag, which IE (arguably incorrectly) accepts, sails (sailed?)
past various on-the-fly script blockers).
--
Nick FitzGerald
Nick FitzGerald
> Dave, there is no such thing as "bad" scripting. Scripting is like the
> alphabet. You can create poetry or swear words with it. Only after you hear it
> will you alone be able to decide whether it is "bad" or not.
In context though, there is "bad" scripting. Dave is specifically worried
about HTML-embedded scripts that can (or perhaps "may" is better) have
access to the local filesystem of his users when the HTML in question is
viewed as a web page or read as an Email message. In that context (that
of system admins specifying what is and is not "acceptable" behaviour on
and/or with the machines they administer) Dave deciding that "viewing HTML
causing reading or writing to the file system is bad" is an entirely
appropriate (and, IMNSHO, prudent) position.
> These virus scanners are essentially useless. All they will do is "flag"
> something they know. Something they have been instructed to separate.
> Certainly they can be engaged for overkill where they mere mention of the
> word .exe in a plain text message will trigger them to "flag" it as a virus.
>
> Junk. Money making garbage.
If it were that easy, I'm sure you'd have made a fortune from developing
and selling one. As you haven't *and* it's patently obvious that few
others have followed that trail to easy riches and fame, I guess your
opinion about such things is not worth much...
--
Nick FitzGerald
Alfalfa
> something to block viruses inside HTML, both in HTML emails, and in HTML
> pages visited via a browser. Isn't it true that VBScript and JScript in
an
> HTML page can contain harmful code?
To minimize your exposure to "HTML" based viruses, there products as NAI
Webshield/GroupShield and surely others that scan the body of the e-mail
message and if it known (virus defs.) it should act upon it.
> So, we're considering installing Trend's Virus Wall product. Does anyone
> know anything about that? I'm a bit loathe to install a proxy server on
our
> lan - yet another point of failure. I'd rather just have something that
> would disable all scripting calls that do things like write to the hard
> drive, but allow calls that are simply providing dynamic content/rich UI
on
> a web page. Isn't there something that works like that?
There are no magic answers for the future. Heuristic code that examines,
parses content could possible help in the near future.
HTH
> Thanks!
>
> - dave
>
>
Robert Moir
But,
> maybe you're wrong. Seems like you could have something parse HTML before
> it got to the browser, and flag any iffy code.
Then you are asking the user to make a judgement call. Something that we
might all be comfy with here, but could you ask your parents / young kids /
CEO "who can barely run Outlook or whatever and hit "send and recieve"
without help" to make that judgement call? Didn't think so.
Then theres the matter of intention - I don't think this is in any way an
optimal way of doing business myself but perhaps you meant to send a user a
script that manipulates stuff that most people would consider "dodgy".
Perhaps you want someone you trust to email you that script they wrote for
deleting and recreating partitions on your disk.
> In any case, what are other people doing? Isn't most everyone currently
> wide-open to the next generation of viruses that will come embedded inside
> HTML?
I deal with this by blocking html email at the gateway because I find that
people who know me or who I'd want to speak to are smart enough to know that
if I open my email program its to read mail, and if I wanted to read html
I'd open my web browser. Cuts down on spam and salesdrones at work, too.
Robert Moir
"Jack" <756373323...@756373.636F6D.747> wrote in message
news:X8y48.39881$I8.75...@news4.rdc1.on.home.com...
> >Nick FitzGerald
>
> Here's an idea why don't you write a book for free "how to harden your
system
> or corporate network without expensive anti virus products"
>
> You'd make a fortune.
You must be new here?
I don't agree with everything Nick writes (though I agree with a lot), which
is fine I'm sure because I don't expect he agrees with everything I writes,
but as it happens, he could be said to have written the book, and certainly
he could be said to have edited the magazine.
Nick FitzGerald
> To minimize your exposure to "HTML" based viruses, there products as NAI
> Webshield/GroupShield and surely others that scan the body of the e-mail
> message and if it known (virus defs.) it should act upon it.
He already has s/w doing that for Email -- he was asking about doing it
for web pages as well...
> > So, we're considering installing Trend's Virus Wall product. Does anyone
> > know anything about that? I'm a bit loathe to install a proxy server on
> our
> > lan - yet another point of failure. I'd rather just have something that
> > would disable all scripting calls that do things like write to the hard
> > drive, but allow calls that are simply providing dynamic content/rich UI
> on
> > a web page. Isn't there something that works like that?
>
> There are no magic answers for the future. Heuristic code that examines,
> parses content could possible help in the near future.
I'd not stake much hope in heuristics (of the type current AV s/w tends
to use) being able to "fix" this problem. Detecting and junking most
HTML-embedded scripting is pretty easily doable, but that's not what the
poster is asking for. He is aware that the *type of scripting* built
into the web browser he presumably "must" use allows for much more than
it should; much more than is "needed" for enabling safe "interactivity"
in web pages (which, after all, should be "just data"). What he is
asking for is a form of sandboxing for such scripts, as he wants to
ensure his users can navigate the web (all those $%&*^#(*& braindead
"web designers" who can't code HTML for shit and "must" use their
overblown tools "to fully express our true, creative abilities" while
simultaneously requiring the use of ever more of the worse security
flaws built into HTML scripting languages) yet be safe from the exiguous
security concerns of the morons who design so much of "the modern
Internet experience". To that end, he was asking for something that can
selectively strip "bad" code from scripts (or "bad" scripts from pages)
and only leave (relatively) "safe" code to run on his users' machines.
The problem that poses for any "unknown script" detector reduces to the
infamous halting problem and, as anyone who has read along here for long
enough knows, that is intractible (in finite time on computers of the
sort we are interested in using that are Turing machines). In practice,
however, it could probably be done by implementing full JScript and
VBScript parsers and (probably) partial interpreters because the object
model in which those scripting engines work allows the scripts to write
back, not only to the "document" that is being parsed and "executed" for
"display", but to the script itself. A heuristic "bad script detector"
thus has to be able to deal with self-modifying code and, as using self-
modification for code obscuration (and thus providing a small element of
"intellectual rights protection") has been rather widely encouraged (no
prizes for guessing by whom...) then arbitrarily deciding "self-
modifying script == bad" will likely break your users' ability to
"properly" browse some "quite innocuous" sites.
Of course, MS and others (don't entirely blame MS for this -- it was the
"weenie engineers" at Netscape who started this whole screwed up pile of
shite) could have made it much easier by thinking for a few minutes, way
back at the beginning of the whole idea of adding the ability to embed
scripting into HTML "data", about the security implications of it all.
Actually, they did (at least the MS ones) but instead of taking a
cautious approach ("let's implement the barest of functionality paying
special attention to ensuring that 'rogue' actions such as reading and/or
writing arbitrary local files and bigger security risks are not supported
at all") they decided "we've already got JScript and VBScript and it
would be much easier and quicker just to get a few of our super-talented
engineers to take them and build 'Internet security zones' around them to
control the use of their more worrying functions, and actually, wouldn't
it be so cool and useful to be able to have system administration and
update functions right inside the web browser for use on local networks
where all that security stuff doesn't matter?".
And MS *still* wonders why the rest of the sane computing world says that
Redmond has no idea of "how to do security"...
--
Nick FitzGerald
Dave T
here it is again:
I've been away from this thread over the weekend. I see there's been a lot
of discussion. Thanks for all the replies!
Nick - you are correct in your summary about what I want. I'd like to
"sandbox" the activex and jscript scripts embedded in web pages my employees
view. If the script blocker errs on the side of being too conservative,
that's fine. In the unlikely case that the user cares about having blocked
scripts run, I'm sure a sys admin would be able to bring up the page for the
user.
Regarding the "single point of failure" of a proxy server, what I meant was
that if the proxy server goes down, everyone loses web access. What I had
in mind was something that either hooked into or replaced the script parsers
built into the browser. I suppose that would be a bit of a pain to install
and maintain, though. If a proxy server did what I want, that would be
fine.
I am still a little unclear as to the availability of what I want. Is it
correct that Trend's viruswall only blocks based on "signatures"? I think
we're agreed that that isn't the optimal approach. Nick - are you saying
that Alladin's and Finjan's products do what I want?
Thanks again.
- Dave