instsrv.exe and srvany.exe are *not* spyware

G

Gippledocks

So I'm running with the v5685 (28th Jan) definitions.
Still srvany.exe and instsrv.exe from the W2K Res Kit are
flagged as high level threats with the advice 'This is a
very high risk threat and should be removed immediately as
to prevent harm to your computer or your privacy.' and
'Remove' is offered as the default action. Lucky I know
better. These are as false a positive as ever could be.

If a spyware uses a legitimate program to install itself,
then the definitions should have a signature for what gets
installed, not what installs it.

It's basic errors like this that stop MS's antispyware
being a 'fit and forget' product, and it's 'fit and forget'
that opens up the mass market. The antivirus vendors
figured that out years ago.

(warning - the next paragraph invovles gratituous use of
sarcasm)

On the other hand maybe the product should operate on the
precautionary principle. The description for these false
positives says 'This file is also commonly used by a number
of known Trojans and could be currently used in a malicious
manner.'. If that's the criterion (that is: spyware
installers are in scope), then lets add IE, the kernel and
the whole shooting match to the definitions too.
 
B

Bill Sanderson

Part of the difficulty of this tool is the "labelling" involved. I've seen
the descriptions of just these two tools posted, and I think they are pretty
accurate. The descriptions do not use the term spyware. They do emphasize
the fact that there is no way for Microsoft Antispyware to know whether the
code is there with the cognizance of the user, or is unknown to the user,
and additionally, even if the code is known, whether it is also being made
use of by other code to do things the user does not intend.

That potential for abuse is enough for me to say take that stuff off my
machine if I am not using it this week. If I need it again next week, I can
put it back--I know where to find it.

And, of course, no Remote Administration Tool is spyware either. <G>

I'm in favor of calling all this stuff out to the user and letting them make
the call--and I fail to see why that's an issue with these two tools in
particular--which are going to be installed and used by knowledgable folks,
right?
 
A

Alexander Suhovey

Bill Sanderson said:
Part of the difficulty of this tool is the "labelling" involved. I've
seen the descriptions of just these two tools posted, and I think they
are pretty accurate. The descriptions do not use the term spyware. They
do emphasize the fact that there is no way for Microsoft Antispyware to
know whether the code is there with the cognizance of the user, or is
unknown to the user, and additionally, even if the code is known, whether
it is also being made use of by other code to do things the user does not
intend.
That potential for abuse is enough for me to say take that stuff off my
machine if I am not using it this week. If I need it again next week, I
can put it back--I know where to find it.

And, of course, no Remote Administration Tool is spyware either. <G>

I'm in favor of calling all this stuff out to the user and letting them
make the call--and I fail to see why that's an issue with these two tools
in particular--which are going to be installed and used by knowledgable
folks, right?
[...]

Right. But those knowledgable folks are not nesessarily owners of computer
or legitimate users. Right? :)
The idea of antispyware is to identify the behavior of program and compare
it with a set of fingerprints of known spyware activities. With such broad
set of identified activities
(http://support.microsoft.com/default.aspx?scid=kb;en-us;892340) no doubt
that there allways will be a false positives. Because it becomes a false
positive only after user confirmation - "What? How did it get installed to
my comp??" or "Ah, it's ok, don't worry. It is *my* tool". It is a common
problem with spyware because unlike viruses/worms it is a "gray" area. Often
it depends on how and by whom the tool is used .
BTW Symantec products detect remote administration tools as expanded threat
too...
 
B

Bill Sanderson

Alexander Suhovey said:
[...]

Right. But those knowledgable folks are not nesessarily owners of computer
or legitimate users. Right? :)
The idea of antispyware is to identify the behavior of program and compare
it with a set of fingerprints of known spyware activities. With such broad
set of identified activities
(http://support.microsoft.com/default.aspx?scid=kb;en-us;892340) no doubt
that there allways will be a false positives. Because it becomes a false
positive only after user confirmation - "What? How did it get installed to
my comp??" or "Ah, it's ok, don't worry. It is *my* tool". It is a common
problem with spyware because unlike viruses/worms it is a "gray" area.
Often it depends on how and by whom the tool is used .
BTW Symantec products detect remote administration tools as expanded
threat too...
Yes--I absolutely agree--these tools need to be called out--for just the
reasons you mention--it isn't just their intrinsic capabilities, it is
whether they are there with the foreknowledge of the user.
(I was intending to make a joke with the mention of RAT's--I hope that we
all agree that they are a threat, although there are folks posting in these
groups incensed that VNC is detected.)
 
G

Gippledocks

Bill Sanderson said:
Part of the difficulty of this tool is the "labelling" involved. I've
seen the descriptions of just these two tools posted, and I think they
are pretty accurate. The descriptions do not use the term spyware. They
do emphasize the fact that there is no way for Microsoft Antispyware to
know whether the code is there with the cognizance of the user, or is
unknown to the user, and additionally, even if the code is known, whether
it is also being made use of by other code to do things the user does not
intend.
That potential for abuse is enough for me to say take that stuff off my
machine if I am not using it this week. If I need it again next week, I
can put it back--I know where to find it.

And, of course, no Remote Administration Tool is spyware
either. said:
I'm in favor of calling all this stuff out to the user and letting them
make the call--and I fail to see why that's an issue with these two tools
in particular--which are going to be installed and used by knowledgable
folks, right?
[...]

Right. But those knowledgable folks are not nesessarily owners of computer
or legitimate users. Right? :)
The idea of antispyware is to identify the behavior of program and compare
it with a set of fingerprints of known spyware activities. With such broad
set of identified activities
(http://support.microsoft.com/default.aspx?scid=kb;en-us;892340) no doubt
that there allways will be a false positives. Because it becomes a false
positive only after user confirmation - "What? How did it get installed to
my comp??" or "Ah, it's ok, don't worry. It is *my* tool". It is a common
problem with spyware because unlike viruses/worms it is a "gray" area. Often
it depends on how and by whom the tool is used .
BTW Symantec products detect remote administration tools as expanded threat
too...

--
Al


.

Thanks for referencing the scoring criteria. Checking
through, the only one that seems to apply to instsrv and
srvany is 'Security Criteria: Runs malicious or
questionable scripts'. So if that's the operative
criterion, then the scan seems to have missed cmd.exe,
csript.exe, wscript.exe, winword.exe and all the other
standard issue MS programs that run other programs.

So putting the argument in specific terms: if there is
spyware out there that uses srvany in order to execute,
then the signature should identify the spyware, not srvany.

Putting the argument in general terms: if a program uses a
second program in order to execute and the first program is
malign, then the signature must identify the first program
and not the second.
 
A

Alexander Suhovey

Gippledocks said:
[...]

So putting the argument in specific terms: if there is
spyware out there that uses srvany in order to execute,
then the signature should identify the spyware, not srvany.

Putting the argument in general terms: if a program uses a
second program in order to execute and the first program is
malign, then the signature must identify the first program
and not the second.

Note that Bill uses "code", not "program" above. I'm not an virus/spyware
expert, so this is all my IMHO. But as I understand the antispyware
identifies a code in inactive or behavior of active program. So that's what
happened because it is a parts of code of those utilities that is being used
in spyware programs. This is similar to how A/V works - virus definitions
contain code samples as fingerpronts, not program descriptions. So when A/V
or A/S encounters this code it yells.
 
B

Bill Sanderson

Alexander Suhovey said:
Note that Bill uses "code", not "program" above. I'm not an virus/spyware
expert, so this is all my IMHO. But as I understand the antispyware
identifies a code in inactive or behavior of active program. So that's
what happened because it is a parts of code of those utilities that is
being used in spyware programs. This is similar to how A/V works - virus
definitions contain code samples as fingerpronts, not program
descriptions. So when A/V or A/S encounters this code it yells.

You probably shouldn't read too much into my terminology. I'm too much of a
generalist to be sure that I'm being precise at all times. I did mean to be
broad enough to include, say, a .dll which isn't technically an executable
program but is identifiable program code which may be have the ability to
evidence malicious behavior when called by an executable.

Grippledocks - I can't define clearly why these executables are called out
by the program. If the description given doesn't seem sufficient, the
authors are certainly welcome to use the vendor dispute form and get that
listing changed. Since the vendor in question is Microsoft, I suspect they
are well aware of the situation, and have some agreement about how these
items are described.

I'm wondering why this seems such a hot-button issue--you aren't alone--I've
heard the same sort of complaint from a few others. Why shouldn't such
tools presence on the partition be brought to the attention of someone with
the authority to run a scan and view the results?
 
G

Gippledocks

-----Original Message-----
yells.

You probably shouldn't read too much into my terminology. I'm too much of a
generalist to be sure that I'm being precise at all times. I did mean to be
broad enough to include, say, a .dll which isn't technically an executable
program but is identifiable program code which may be have the ability to
evidence malicious behavior when called by an executable.

Grippledocks - I can't define clearly why these executables are called out
by the program. If the description given doesn't seem sufficient, the
authors are certainly welcome to use the vendor dispute form and get that
listing changed. Since the vendor in question is Microsoft, I suspect they
are well aware of the situation, and have some agreement about how these
items are described.

I'm wondering why this seems such a hot-button issue--you aren't alone--I've
heard the same sort of complaint from a few others. Why shouldn't such
tools presence on the partition be brought to the attention of someone with
the authority to run a scan and view the results?

I can't speak for the others, but here's my 2 pennyworth.

First I must say that I am very much in favour of this
beta. The real-time protection in particular is spot on.
I've posted my comments here in a constructive spirit out
of concern that the scan signatures (or maybe the paradigm
behind them) are not up to the same high standard.

Srvany is utterly benign. It's only function is to be
installed as a service in order to execute another program
so that the second program in effect runs as a service.

A signature that identifies a benign program as malign is
either insufficiently specific or else entirely wrong. In
the extreme it may be so deficient as to fail to identify
its intended target at all. Worse still, it trains the
user to ignore warnings (like the boy who cried wolf).
This creates a risk of legitimate alerts being ignored.

A signature system paradigm that allows insufficiently
specific or entirely wrong signatures adds no value,
inspires no confidence and saves no work.

So this is just the sort of thing to weed out during a Beta.

I feel that my position is supported by the behaviour of
Lavasoft Ad-aware and with Spybot Search & Destroy, neither
of which has ever considered srvany to be a threat. Even
the famously alarmist AuditMyPC doesn't regard it as a threat.

I am prepared to concede that our mutual incomprehension
here could be a product of cultural differences in threat
perception or the appropriateness of user intervention
(Ad-aware, Spybot S&D and me all being European, MS being
American), but given MS's long involvement in the global
software market that seems a distant possibility.

I hope this clarifies my position.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top