Prev: What is happening to WinClam?
Next: hotfixq0306270.exe
From: * * Chas on 6 Sep 2005 02:03

"David H. Lipman" <DLipman~nospam~@Verizon.Net> wrote in message
news:jm3Te.5064$Di4.958(a)trnddc07...
| From: "Morgan Ohlson" <morgan.ohlson(a)comhem.se>
|
|
| |
| | For the paying conumer that is not really acceptable. The antivirus
is an
| | assurance to have a working pc... reaching the internet for news,
debate and
| | as a essential office tool.
| |
| | A future virus-scanner must... constantly identify almost all
existing
| | virus. Only a free scanner can be accepted to perform less then
"close to
| | perfect".
| |
| | Morgan O.
|
| No !
|
| You put too much emphasis on the software. The most effective and
powertool is the user !
|
| One *must* practice Safe Hex and not just rely on software.
|
| --
| Dave

I've never seen any AV product that gives advice or help to users on how
to avoid malware problems!

Chas.


From: Morgan Ohlson on 6 Sep 2005 07:25
On Mon, 5 Sep 2005 13:13:14 -0700, * * Chas wrote:

> "Buffalo" <eric(nospam)@nada.com.invalid> wrote in message
> news:CpmdnbgiC6ue64HeRVn-2A(a)comcast.com...
>| Check here for some interesting results:
>| http://www.av-comparatives.org/
>|
>| It seems that in the Feb and Aug 05 On-demand comparative, Norton
> Anti-Virus is
>| second in detection, just behind Kaspersky.
>| Those who use the others, and swear by them, should also check out
> that site.
>| How the heck did Norton get up so high?
>| One answer is their latest engine is better. AFAIK, Norton's
> 2002,3,and 4's
>| engines don't do as well.
>| Any other ideas?
>|
>
> One issue that needs to be considered is how much does an AV program
> affect your system's performance.

Whats the problem?

>
> No AV product is ever going to be 100% full proof and detect every virus
> all of the time.

No, but if one scanner leaves you with 1 virus on hdd and the other leave 10
Which IS ACTUALLY THE CASE!!!

....it's hell of a difference.

> Malware is developed faster than protective measures.

So we have to pay mor fýr better scanners.

> The most realistic solution is to practice Safe Hex, pick a product or
> products that you have FAITH in and hope for the best.

Surely it improves more then a little.

> Computer users most at risk to malware are those clueless folks who
> indiscriminately surf the web, D/L all kinds of junk and open E-mail
> attachments etc. without any idea of the potential consequences.

....and above that never wash.

> With the exception of mass attacks by a new threat, most people who
> practice Safe Hex are at a very low risk of catching some kind of
> malware.


1. Safe Hex... very good precation. Probably pays well!!!

2. But, if and when you get any of the nasty plagues a very efficient virus
scanner is needed.

1 and 2 doesn't exclude each other... just make things easier depending on
situation.

Morgan O.
From: Pete on 6 Sep 2005 15:41
"I did not inhale."
"It depends on what you mean by 'is'."


From: Roger Wilco on 7 Sep 2005 11:25

"Art" <null(a)zilch.com> wrote in message
news:13lph1lripacsunp9qh6mlel7v77l635sm(a)4ax.com...
> On Mon, 5 Sep 2005 18:57:15 -0400, "Roger Wilco"
> <yesman(a)yourservice.invalid> wrote:

> >As far as the 'protection' angle goes, it is sufficient to have high
> >accuracy in 'detection'. The accuracy in 'identification' is somewhat
> >less important. You need correct identification for correct removal,
but
> >removal is not a preventative measure. If you use AV as a recovery
from
> >infection tool, you have already lost the battle that AV was designed
to
> >help with - prevention.

I should add that AV gave up on their original idea - the idea that a
world of users capable of correctly implementing on-demand scanning as
part of safe practice was possible - and decided on automatic
intervention by on-access scanning. Now with that as the norm, the
software developers think it is a good idea to use application
extensions to allow mobile code to be automatically installed and
executed without the user having any point to intervene. This makes
on-access scanning of executables almost mandatory and yet still
inadequate because of automatic de-archiving and executing of content
within an already active process.

> >I know that I'm 'preaching to the choir' regarding you Art, but since
AV
> >has tacitly admitted defeat in prevention and focussed on cleanup and
> >on-access scanning instead - it only then becomes important to
correctly
> >identify malware locally with a scanner. Why couldn't the
identification
> >of malware samples be done as a web application? Wouldn't doing so
> >reduce the number of definitions needed by the local AV program? The
> >local AV could detect a malware sample and offer to submit it to
further
> >analysis or package a copy of it for you to send.
> >
> >...but I digress...
> >
> >Identification is not needed in order for an AV scanner to say "you
> >probably don't want to execute this program".
>
> I was not looking at this from the POV of prevention but from the POV
> of a user who gets a vague detection report.

All they really need to know is that a file is probably malicious, and
they probaly don't want to allow it to execute. This is an on-access
alert most likely as a result of them trying to do just that. If they
need more information the alerting program could
make the sample ready for submission, or if online could make submission
a point and click operation that they should be able to handle.

> One wonders how effective
> a product can be that can't pinpoint and ID a particular malware and
> variant. What are you supposed to do next when you scan your drive on
> demand and it reports something vague, and it's unable to do anything
> about it? That sucks :)

Sure does - especially if the alert is on an already installed system
hosted malware which necessitates identification for removal.

But even the little information the good AVs offer locally sucks - some
cryptic name that means little to the user. The user is going to have to
get more info from a remote location anyway, so why not offer a
submission service?

It would be interesting to see the difference in size between a good
detector/def set and an identifier/def set - let alone the added code
need to affect a removal once identified. Library files were created to
avoid populating storage with redundant routines that many programs
used, .NET if I understand it correctly makes an application library
available as mobile code. Why not move the identification and removal
software away from the local detection software to avoid populating
user's system with redundant code they may never need?

> I think your web app idea might have some merit, but my first critical
> thought is of the many malwares nowdays for which the user shouldn't
> be on line .... RATs and Worms.

I thought of that too, that is why I suggested the AV application could
offer to package a copy of the suspect for submission.

> And he may need to be in Safe mode
> or using a alternate OS for removal.

The return correspondence from submission could be an identification,
description (for the curious), avoidance measures for the future (user
education*) manual removal method, and auto-removal tool for that
malware and would all still fit on a floppy - if they still use those
old things anymore :))

> But think it and work it through
> some more and then elaborate :)

Thinking doesn't come as easily as it used to :)

> The crux of your idea or thought seems to involve the use of a
> hypothetical heuristic-heavy scanner that's "lightweight" in both
> defs and bloat .... that somehow turns over the chore to "something
> else" to determine exactly what it is that it found ... a fp or a
> actual malware ... and pinpoint the malware and its variant. But
> again, that "something else" can't require a connection to the
> internet. Maybe a rf (radio waves) link to that "something else". Who
> knows what might evolve in the future.

The "something else" may be a refrigerator, coffeepot, or toaster by
then. :)

My thought was that there are always other ways to submit suspect
files - someone else's network access or a clean boot w/network access
from the affected machine. Say I've got a AV capable of identifying a
couple hundred thousand malware programs, but all I need is for it to do
is detect 70,000. It alerts me to the existence of a backdoor.dropper in
some file a get from kazaa. I delete it. I don't need to know it was
dropping backdoor.garagedoor.aqz, so I didn't need to have a def that
specifically identified that version of the software unless the
detection was for the active backdoor itself (installed). The truth is,
that I probably don't need the specific identification data or the
accompanying removal data and code for any of the couple hundred
thousand malwares that I never will come in contact with - it just
seemed to me that detection is enough to have locally stored capability
for.

*user education is sadly missing from most AV help these days,
especially locally. Oh, you've got [malware name]- here's a removal
tool - see ya.


From: Art on 7 Sep 2005 11:58
On Wed, 7 Sep 2005 11:25:52 -0400, "Roger Wilco"
<yesman(a)yourservice.invalid> wrote:

<snip>

>My thought was that there are always other ways to submit suspect
>files - someone else's network access or a clean boot w/network access
>from the affected machine. Say I've got a AV capable of identifying a
>couple hundred thousand malware programs, but all I need is for it to do
>is detect 70,000. It alerts me to the existence of a backdoor.dropper in
>some file a get from kazaa. I delete it. I don't need to know it was
>dropping backdoor.garagedoor.aqz, so I didn't need to have a def that
>specifically identified that version of the software unless the
>detection was for the active backdoor itself (installed). The truth is,
>that I probably don't need the specific identification data or the
>accompanying removal data and code for any of the couple hundred
>thousand malwares that I never will come in contact with - it just
>seemed to me that detection is enough to have locally stored capability
>for.

Sorry for the snippage, but I just don't have time to respond to your
long post. I just want to mention in this context that I've not
complelely lost interest in the old idea of developing means of
internet communication via alternate OS. Back in the Win 98 days
the holy grail was a DOS emergency boot disk arrangement that
would download av updates. I notice there's been quite a bit of
evolution in DOS capabilities and available items ... packet drivers
for broadband, etc. Since I'm a "old DOS guy" this sort of thing
intrigues me :)

Art

http://home.epix.net/~artnpeg
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: What is happening to WinClam?
Next: hotfixq0306270.exe