R
Roger Wilco
Art said:
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.
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 thought of that too, that is why I suggested the AV application could
offer to package a copy of the suspect for submission.
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 "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.