Nasty propaganda by "security tool" providers

Hi,

while my simple and harmless PoC codes how to ignore "Personal
Firewalls" already are found as "viruses" by many virus scanners,
now my tool "Shutdown Windows' services" is found as
"SPR/Tool.KillService" virus by AntiVir. A tool, which has nothing to do
with a virus, and improves security on a Windows 2000 or Windows XP host
before SP2.

The reason, why this is done, should be obvious. Just think twice.

I'm wondering, wether one at all could trust in AntiVir any more. How
many other things this tool is "detecting" because of political reasons,
ignoring the needs of the user?

Yours,
VB.
--
Ich würde schätzen, dass ca. 87% aller spontanen Schätzungen völlig für
den Arsch sind.

Ralph Angenendt in debate@ccc.de

Re: Nasty propaganda by "security tool" providers

Post removed (X-No-Archive: yes)

Re: Nasty propaganda by "security tool" providers

Volker Birk wrote:
> Hi,
>
> while my simple and harmless PoC codes how to ignore "Personal
> Firewalls" already are found as "viruses" by many virus scanners,
> now my tool "Shutdown Windows' services" is found as
> "SPR/Tool.KillService" virus by AntiVir. A tool, which has nothing to do
> with a virus, and improves security on a Windows 2000 or Windows XP host
> before SP2.
>
> The reason, why this is done, should be obvious. Just think twice.
>
> I'm wondering, wether one at all could trust in AntiVir any more. How
> many other things this tool is "detecting" because of political reasons,
> ignoring the needs of the user?

McAfee detects Nmap, but doesn't detect McAfee PortScan.

KAV detects a simple Batch to remove the Win16 subsystem as
Generic/Batch.Del.

Many detect browser exploits, but of course only the PoCs. Evil guys
just encode and obfuscate it beyond detection.

They all detect Nuke Random Life Generator generically, but inserting
1000 NOPs between each instruction and UPXing the binary makes it
undetectable.

Well, what are you complaining? We know that AVs are just generic
snakeoil, having long surpassed their time of effectiveness.

Re: Nasty propaganda by "security tool" providers

Sebastian Gottschalk wrote:
> > I'm wondering, wether one at all could trust in AntiVir any more. How
> > many other things this tool is "detecting" because of political reasons,
> > ignoring the needs of the user?
> McAfee detects Nmap, but doesn't detect McAfee PortScan.

OK, I seem to be in respectable society ;-)

> KAV detects a simple Batch to remove the Win16 subsystem as
> Generic/Batch.Del.
> Many detect browser exploits, but of course only the PoCs. Evil guys
> just encode and obfuscate it beyond detection.
> They all detect Nuke Random Life Generator generically, but inserting
> 1000 NOPs between each instruction and UPXing the binary makes it
> undetectable.
> Well, what are you complaining? We know that AVs are just generic
> snakeoil, having long surpassed their time of effectiveness.

Unbelievable. Maybe we should have a serious talk about the virus
scanner implementations on the market.

Yours,
VB.
--
Ich würde schätzen, dass ca. 87% aller spontanen Schätzungen völlig für
den Arsch sind.

Ralph Angenendt in debate@ccc.de

Re: Nasty propaganda by "security tool" providers

Post removed (X-No-Archive: yes)

Re: Nasty propaganda by "security tool" providers

On Sat, 05 Aug 2006 18:34:31 GMT, Leythos wrote:

>If you have a POC that works, then you already know that it mimics
>malware and should be detected just like Malware.

Of course it should'nt. Only malware should be detected as malware.
Please check the defintion of malware
http://en.wikipedia.org/wiki/Malware and see if that description fits
a PoC.

It also does'nt make sense that Volkers PoC is detected as malware by
21 out of 27 engines at Virustotal.com while at the same time only 5
out of 27 detect Steves LeakTest 1.2 as malware.

/B. Nice

Re: Nasty propaganda by "security tool" providers

Post removed (X-No-Archive: yes)

Re: Nasty propaganda by "security tool" providers

On Sat, 05 Aug 2006 21:21:00 GMT, Leythos wrote:

>In article ,
>b__nice@hotmail.com says...
>> On Sat, 05 Aug 2006 18:34:31 GMT, Leythos wrote:
>>
>> >If you have a POC that works, then you already know that it mimics
>> >malware and should be detected just like Malware.
>>
>> Of course it should'nt. Only malware should be detected as malware.
>> Please check the defintion of malware
>> http://en.wikipedia.org/wiki/Malware and see if that description fits
>> a PoC.

You did'nt address whether a PoC fits the definition of malware.

>> It also does'nt make sense that Volkers PoC is detected as malware by
>> 21 out of 27 engines at Virustotal.com while at the same time only 5
>> out of 27 detect Steves LeakTest 1.2 as malware.
>
>Sure it does, VB is nothing to people outside his little world, they are
>not targeting him or his code, he's not worth their time/effort.

Are you saying that whether a PoC is taken seriously depends more on
the author than on the code itself?

>What you need to consider is this: If a POC is to work, it has to use
>the same methods as what you're trying to prove - so, that means that if
>his POC is going to work, it's got to act/emulate the actions of
>malware. While his POC is not malicious, if it was to really work it
>would have to emulate the actual malware functions.

To what extent does'nt it do that? - Or are you saying that it
actually has to do something malicious to be considered a PoC for
malware?

>So, it being detected means that he's got the right idea, about how the
>actual malware works, but what he's failed to address is that his POC is
>worthless on a properly configured computer.

What do you mean by "properly configured computer"?

Re: Nasty propaganda by "security tool" providers

B. Nice wrote:

>> So, it being detected means that he's got the right idea, about how the
>> actual malware works, but what he's failed to address is that his POC is
>> worthless on a properly configured computer.
>
> What do you mean by "properly configured computer"?

Please add at least a smilie when you know that he doesn't know an answer.

Anyway, even that has been discussed: Any security-related software
should, if it has to open windows, explicitly catch and ignore all
unknown messages. Microsoft could probably change DefaultWinProc(), but
it would be risky in terms of breaking applications. Nothing of this is
in your hand if you don't have the source code and didn't compile it
yourself, and I've never seen any software where this behaviour could be
optionally enabled by configuration.

Re: Nasty propaganda by "security tool" providers

Post removed (X-No-Archive: yes)

Re: Nasty propaganda by "security tool" providers

Post removed (X-No-Archive: yes)

Re: Nasty propaganda by "security tool" providers

On Sat, 05 Aug 2006 23:07:51 GMT, Leythos wrote:



>> You did'nt address whether a PoC fits the definition of malware.
>
>Yes, I did, clearly.

No. You were stating an opinion: "If the POC acts and has a function
like malware, then it clearly should be detected as malware."
That's the same as saying: "If you look like a thief, then you should
also be labelled as one".
Let's instead look at the definition from wikipedia: "Malware is
software designed to infiltrate or damage a computer system, without
the owner's informed consent". Since that obviously does not match a
PoC, a PoC cannot be considered malware and therefore obviously should
not be detected as such.

>> >> It also does'nt make sense that Volkers PoC is detected as malware by
>> >> 21 out of 27 engines at Virustotal.com while at the same time only 5
>> >> out of 27 detect Steves LeakTest 1.2 as malware.
>> >
>> >Sure it does, VB is nothing to people outside his little world, they are
>> >not targeting him or his code, he's not worth their time/effort.
>>
>> Are you saying that whether a PoC is taken seriously depends more on
>> the author than on the code itself?
>
>No, I'm saying that the POC failes on a properly configured machine,
>that the POC is just BS and FUD, because if you were to properly setup
>your machine like MS recommends the POC would fail.

My view is from the Jim Novice / Joe Average point of view. You cannot
expect a non-techie home user to consider things like that. If
personal firewall vendors cannot provide "install-and-forget" security
as they claim on an "out-of-the-box" windows, then they are not
providing what they claim. Nowhere on their web-sites do I see
something like: "You need to also configure your windows according to
the MS recommendations. Otherwise we cannot protect you".
Therefore Volkers PoC is perfectly valid.

Re: Nasty propaganda by "security tool" providers

Post removed (X-No-Archive: yes)

Re: Nasty propaganda by "security tool" providers

On Sun, 06 Aug 2006 00:29:32 +0200, Sebastian Gottschalk
wrote:

>B. Nice wrote:
>
>>> So, it being detected means that he's got the right idea, about how the
>>> actual malware works, but what he's failed to address is that his POC is
>>> worthless on a properly configured computer.
>>
>> What do you mean by "properly configured computer"?
>
>Please add at least a smilie when you know that he doesn't know an answer.

Well, I'm actually just trying to understand Leythos' opinion.

>Anyway, even that has been discussed: Any security-related software
>should, if it has to open windows, explicitly catch and ignore all
>unknown messages. Microsoft could probably change DefaultWinProc(), but
>it would be risky in terms of breaking applications. Nothing of this is
>in your hand if you don't have the source code and didn't compile it
>yourself, and I've never seen any software where this behaviour could be
>optionally enabled by configuration.

Thank you for your comments.

Re: Nasty propaganda by "security tool" providers

Post removed (X-No-Archive: yes)

Re: Nasty propaganda by "security tool" providers

On Sun, 06 Aug 2006 00:23:22 GMT, Leythos wrote:

>In article <42dad25f1fd211c4fkk9elq91070h60o6j@4ax.com>,
>b__nice@hotmail.com says...
>> On Sun, 06 Aug 2006 00:29:32 +0200, Sebastian Gottschalk
>> wrote:
>>
>> >B. Nice wrote:
>> >
>> >>> So, it being detected means that he's got the right idea, about how the
>> >>> actual malware works, but what he's failed to address is that his POC is
>> >>> worthless on a properly configured computer.
>> >>
>> >> What do you mean by "properly configured computer"?
>> >
>> >Please add at least a smilie when you know that he doesn't know an answer.
>>
>> Well, I'm actually just trying to understand Leythos' opinion.
>
>That's what bothers them - if you reason it out yourself and see that
>anything that exploits a hole SHOULD be detected and blocked (AV,
>Firewall, etc..) then you will understand that VB is just complaining to
>get sympathy, not because anyone or anything is really out to get him.

Sorry, but you will never be able to convince me that code doing
nothing malicious should be detected as malware. We will just have to
agree to disagree on that.

BTW, I don't think "they" (whoever that is) care too much about what
opinions I might form.

Re: Nasty propaganda by "security tool" providers

Post removed (X-No-Archive: yes)

Re: Nasty propaganda by "security tool" providers

B. Nice wrote:

>> That's what bothers them - if you reason it out yourself and see that
>> anything that exploits a hole SHOULD be detected and blocked (AV,
>> Firewall, etc..) then you will understand that VB is just complaining to
>> get sympathy, not because anyone or anything is really out to get him.

There is no hole. It is simply a design decision that, when ignored to
far, might lead to problems.

> Sorry, but you will never be able to convince me that code doing
> nothing malicious should be detected as malware.

What about "RiskWare"? Yes, I know, this is also commonly misunderstood
and politically instrumented, but that's also why detection of such is
usually optional.

However, there's no reason why Volker's tool should be declared as
"Security/Privacy Risk", whereas it's more likely the contrary.

Re: Nasty propaganda by "security tool" providers

Post removed (X-No-Archive: yes)

Re: Nasty propaganda by "security tool" providers

On Sun, 06 Aug 2006 02:10:39 GMT, Leythos wrote:

>In article <4jl18eF8d1orU2@news.dfncis.de>, seppi@seppig.de says...
>> However, there's no reason why Volker's tool should be declared as
>> "Security/Privacy Risk", whereas it's more likely the contrary.
>
>It his tool is using the same exploit then it should be detected or the
>anti-malware tools are not doing their job. Why is this so hard for you
>to understand?

Why is it so hard for you to understand that the intention makes all
the difference?

You are basically saying, that if a malware uses a specific technique
for malicious purposes, then every other program using the same
technique should also be considered malware.

Re: Nasty propaganda by "security tool" providers

Post removed (X-No-Archive: yes)

Re: Nasty propaganda by "security tool" providers

B. Nice wrote:
> On Sun, 06 Aug 2006 02:10:39 GMT, Leythos wrote:
>
>> In article <4jl18eF8d1orU2@news.dfncis.de>, seppi@seppig.de says...
>>> However, there's no reason why Volker's tool should be declared as
>>> "Security/Privacy Risk", whereas it's more likely the contrary.
>> It his tool is using the same exploit then it should be detected or the
>> anti-malware tools are not doing their job. Why is this so hard for you
>> to understand?
>
> Why is it so hard for you to understand that the intention makes all
> the difference?
>
> You are basically saying, that if a malware uses a specific technique
> for malicious purposes, then every other program using the same
> technique should also be considered malware.

I'm looking forward to format.exe, cmd.exe and explorer.exe being
detected by Leythos AntiVirus 1.0

Re: Nasty propaganda by "security tool" providers

On Sun, 06 Aug 2006 03:39:17 GMT, Leythos wrote:

>In article <5mmad258of9nogs0q876d10t0ig2l5crcs@4ax.com>,
>b__nice@hotmail.com says...
>> On Sun, 06 Aug 2006 02:10:39 GMT, Leythos wrote:
>>
>> >In article <4jl18eF8d1orU2@news.dfncis.de>, seppi@seppig.de says...
>> >> However, there's no reason why Volker's tool should be declared as
>> >> "Security/Privacy Risk", whereas it's more likely the contrary.
>> >
>> >It his tool is using the same exploit then it should be detected or the
>> >anti-malware tools are not doing their job. Why is this so hard for you
>> >to understand?
>>
>> Why is it so hard for you to understand that the intention makes all
>> the difference?
>
>I do understand. Why is it so hard for you to understand that antivirus
>software doesn't understand things like INTENTION.

Of course it does'nt. But humans do. And humans can whitelist specific
programs with specific signatures when those are determined to be
false positives. That is the conclusion one must draw from the
thorough discussion about this topic already made in the beginning of
June between Jason Edwards and yourself in the thread "The coalition
against personal firewalls".

>I personally don't care, that seems to be your comprehension problem. VB
>complained that AV was targeting his POC samples, and it wasn't
>targeting HIS anything, it was targeting something that uses an exploit.
>
>> You are basically saying, that if a malware uses a specific technique
>> for malicious purposes, then every other program using the same
>> technique should also be considered malware.
>
>Yes, if something uses an EXPLOIT it should be considered malware by
>AV/detection tools. If the hole/exploit was a proper method it would not
>be called an Exploit, would it.

Your problem is that a windows API function is neither a hole nor an
exploit
http://en.wikipedia.org/wiki/Exploit_(computer_security)

Re: Nasty propaganda by "security tool" providers

B. Nice wrote:

> Your problem is that a windows API function is neither a hole nor an
> exploit

Better: A proper use of the API. There are cases where calling an API
can exploit an improper configuration. Well, doesn't apply here.

Re: Nasty propaganda by "security tool" providers

On Sun, 06 Aug 2006 09:33:34 +0200, Sebastian Gottschalk
wrote:

>B. Nice wrote:
>
>> Your problem is that a windows API function is neither a hole nor an
>> exploit
>
>Better: A proper use of the API. There are cases where calling an API
>can exploit an improper configuration.

Okay. But in that case the calling code and not the API would be
considered the exploit, right?

>Well, doesn't apply here.

No :-)

Re: Nasty propaganda by "security tool" providers

Post removed (X-No-Archive: yes)

Re: Nasty propaganda by "security tool" providers

Post removed (X-No-Archive: yes)

Re: Nasty propaganda by "security tool" providers

Post removed (X-No-Archive: yes)

Re: Nasty propaganda by "security tool" providers

On Sun, 06 Aug 2006 11:02:34 GMT, Leythos wrote:



>I think you misunderstand the idea of automatic updates, pushing out
>detection methods, etc... The vendors that make software that protect
>your computer create a detection rule that looks for something trying to
>access an exploit,

Fine. Now here are some *facts* for you:

I downloaded the *source code* of Volkers PoC and compiled my own
version. The *only thing* I changed was to point the URL to my own
web-site instead of to Volkers. The rest of the code remained 100%
unchanged.

I ran it - it worked - and my NOD32 anti-virus that would bark heavily
at volkers code kept silent. And so did each and every 27 engines at
virustotal.com when I uploaded it for test. So much for your
"detection rules".

It seems like the only one misunderstanding something here is you.

>or something that uses a code snipped that tries to
>use the exploit - they don't really care about who wrote it or why, just
>that it's a hole, as identified by the community, and should be detected
>because it's not a proper access method.

Who says this particular method is not a proper access method? Do you
have any references that inter-process communication on windows is
improper?



>> Your problem is that a windows API function is neither a hole nor an
>> exploit
>> http://en.wikipedia.org/wiki/Exploit_(computer_security)
>
>And your problem is that you don't seem to grasp that it doesn't make a
>difference what it is or what moon it comes from, it's strictly based on
>what it tries to do. If I write program X that makes use of an
>"EXPLOIT" then I'm not coding my program properly and with good security
>in mind, that means my program is making use of the SAME attack method
>as a malware has been shown to use. My program, when accessing the
>exploit, access it the same way that a malware does. It doesn't matter
>if my program produces food for the hungry, gives money to the poor, all
>that matters is that the programs uses a known exploit path, and since
>it does, it should be detected as a threat by all known anti-malware
>tools.

Well, as I explained to you in this specific case, it is'nt detected.

And you continue using the term "exploit" in a wrong way.

Re: Nasty propaganda by "security tool" providers

Post removed (X-No-Archive: yes)

Re: Nasty propaganda by "security tool" providers

On Sun, 06 Aug 2006 00:14:02 GMT, Leythos wrote:

>If you patch the box, then configure it for high security as documented
>on MS's site,

Please provide a link so that we know what we are talking about.

>and make all the normal adjustments that an educated
>person could make,

Please state what these adjustments are or provide a link so we know
what we are talking about.

>the POC will fail. No third party software needed.

Re: Nasty propaganda by "security tool" providers

B. Nice wrote:
> On Sun, 06 Aug 2006 00:14:02 GMT, Leythos wrote:
>
>> If you patch the box, then configure it for high security as documented
>> on MS's site,
>
> Please provide a link so that we know what we are talking about.

I've read "Threats and Countermeasures: Security Settings in
Windows Server 2003 and Windows XP" and "Windows Server 2003 Security
Guide" and I'm also pretty sure that these are the only relevant
documentations - and none of them even particularly mentioned the
Windows Messages IPC concept. You can find something about it at MSDN
and Sysinternals, but this is just about the implementation and the usage.

>> and make all the normal adjustments that an educated
>> person could make,
>
> Please state what these adjustments are or provide a link so we know
> what we are talking about.

Don't mind, they don't exist.

>> the POC will fail. No third party software needed.

Ha, I'd like to see.

Re: Nasty propaganda by "security tool" providers

Post removed (X-No-Archive: yes)

Re: Nasty propaganda by "security tool" providers

On Sun, 06 Aug 2006 21:42:24 GMT, Leythos wrote:

>Please look on the MS site for how to secure your computer, there are
>numerous documents, to many for me to care to list or find for you. All
>you have to do is care enough to take the time.

Huh?? - And this is what you claimed earlier that even a Jim Novice
should be able to do?????

>So, are we done with the idea that anything that exploits a hole should
>be seen as malware by AV/malware detection tools?

No. Because that opinion is flawed.

Re: Nasty propaganda by "security tool" providers

Post removed (X-No-Archive: yes)

Re: Nasty propaganda by "security tool" providers

B. Nice wrote:
> On Sun, 06 Aug 2006 21:42:24 GMT, Leythos wrote:
>
>> Please look on the MS site for how to secure your computer, there are
>> numerous documents, to many for me to care to list or find for you. All
>> you have to do is care enough to take the time.
>
> Huh?? - And this is what you claimed earlier that even a Jim Novice
> should be able to do?????

Would you please stop confusing him with facts? :-)

>> So, are we done with the idea that anything that exploits a hole should
>> be seen as malware by AV/malware detection tools?
>
> No. Because that opinion is flawed.

You're understating. Such an idea is simply stupid, as misconfiguration
/ insecure defaults can be a security hole as well. What about detecting
cmd.exe? It allows deletion of critical files when improper ACLs are
applied, which happens quite frequently when running certain so-called
security software.

Re: Nasty propaganda by "security tool" providers

On Sun, 06 Aug 2006 15:47:07 GMT, Leythos wrote:



>> I downloaded the *source code* of Volkers PoC and compiled my own
>> version. The *only thing* I changed was to point the URL to my own
>> web-site instead of to Volkers. The rest of the code remained 100%
>> unchanged.
>>
>> I ran it - it worked - and my NOD32 anti-virus that would bark heavily
>> at volkers code kept silent. And so did each and every 27 engines at
>> virustotal.com when I uploaded it for test. So much for your
>> "detection rules".
>>
>> It seems like the only one misunderstanding something here is you.
>
>Great, it's good that you did this, now you're starting to see how
>things work and how detection can work or fail.

Well, I kinda knew that already. It was done more to provide solid
proof that your understanding of how brilliant these anti-virus
engines work may not be correct. I was surprised however, that not one
single engine spotted the socalled "malicious" code. I would even say,
it disproves your claim that these engines look specifically for code
using this particular method. And if they do, they are certainly not
reliable.

>My position doesn't change on this, it still makes sense.

It seems like you have become resistant to facts ;-)

>> >or something that uses a code snipped that tries to
>> >use the exploit - they don't really care about who wrote it or why, just
>> >that it's a hole, as identified by the community, and should be detected
>> >because it's not a proper access method.
>>
>> Who says this particular method is not a proper access method? Do you
>> have any references that inter-process communication on windows is
>> improper?
>>
>>
>
>The vendor that makes the detection methods determines what is and is
>not acceptable and they base this on the attack methods used by malware.

I wonder if you have actually considered what Volkers PoC does. It
uses a legitimate way of communicating within windows. And it is close
to impossible for anti-malware to determine if what is going on is
malicious or not. Therefore you simply cannot say that if a program
uses that method it is malware by definition.



>> Well, as I explained to you in this specific case, it is'nt detected.
>
>Great for you, well, not really, it could be a problem with NOD,

Unlikely. It is normally considered among the best, and it did'nt calm
down until I removed Volkers POC code from my hard drive.

>it could be a problem in that once you compiled it, that you changed it
>enough (as the complier) that the detection method was no longer valid,
>or any number of other reasons.

It does'nt really matter, does it? Bottom line is, no engine was able
to detect the "malicious" code. End of story.

>Don't get personal, it's a technical issue and you keep trying to make
>it personal.

Not deliberately, but I see what you mean, so point taken.

>> And you continue using the term "exploit" in a wrong way.
>
>http://en.wikipedia.org/wiki/Exploit_(computer_security)
>
>What did I say about getting personal - the proper description for the
>POC is a application/code that takes advantage of an Exploit. I've
>included a link to wiki for you so that you don't have to take my word
>for it,

I wonder what point you are trying to make by providing the exact same
link that I already gave you earlier.....

> it's quite clear what an Exploit is, and the POC does take
>advantage of an Exploitable flaw.

When reading your posts I get the impression that you are confusing
the term exploit with vulnerability. An exploit is the code, data
chunk or command sequence used to take advantage of a vulnerability,
not the vulnerability itself.

>Now some FACTS for you too:
>
>1) A POC, for an Exploit, must access the exploitable method or it
>doesn't prove anything.

And Volkers POC does that. So your point is?

>2) AV detection tools have many methods used to detect malware, some are
>by signature, some look in memory, setc.... You can search out the rest
>if you really care.

I don't doubt that. I don't see the relevance, though.

>3) In general you can take the source code for malware, modify it, yet
>leave it so that it still does the same thing, but has a different
>signature or some other feel and it would possibly fail to be detected.

Obviously yes. As I proved to you. What's your point?

>4) VB (not specific to VB) is not important enough or cared about by the
>AV vendors for them to take the time to track down his POC's and create
>definitions to detect them.

If you say so...

>5) There have been instances where a program has had the same signature
>as malware while not being the intended malware to be detected and been
>improperly detected as the malware.

Most likely. But why is that relevant in this connection?

>6) Nothing you've said changes the fact that to create a POC code that
>shows an exploitable hole in something (to show it being taken advantage
>of), that it must at least access the same exploit path, and this has
>nothing to do with what it does once it exploits the path.

You already said that in point 1)

And I still disagree.

>You can try and argue all you want, but it won't change the above 6
>items, they are as written in stone.

Yes, I am beginning to understand that arguments won't change
anything, so let's just leave it there.

BTW, your 6 items "written in stone" are'nt true just because you say
they are.

Re: Nasty propaganda by "security tool" providers

On Sun, 06 Aug 2006 22:05:09 GMT, Leythos wrote:

>In article <1jocd2ldvvjoj2uh22tc3b3jmc4gbn8cul@4ax.com>,
>b__nice@hotmail.com says...
>> On Sun, 06 Aug 2006 21:42:24 GMT, Leythos wrote:
>>
>> >Please look on the MS site for how to secure your computer, there are
>> >numerous documents, to many for me to care to list or find for you. All
>> >you have to do is care enough to take the time.
>>
>> Huh?? - And this is what you claimed earlier that even a Jim Novice
>> should be able to do?????
>
>Sure, all you have to do is be able to read - but I don't really expect
>you to do it (like Sebastian), you'll run from it so that you can claim
>I'm full of crap.

I would normally not use that kind of wording, no.

> In reality you only have the truth to learn, it's
>there for you, you just have to be ready to learn that you're wrong -
>the truth is not about who's side, right/wrong, it's absolute. If you
>configure your machine properly, without any third party tools, VB's POC
>for browser hijacking does not work, clear, simple, and you can actually
>find it if you care enough.

But you obviously won't help me, so you don't give me many reasons to
take you seriously.

>If Joe Novice can't read, they sure won't see this message, and if they
>don't care, well, that leave them stuck like you guys.
>
>> >So, are we done with the idea that anything that exploits a hole should
>> >be seen as malware by AV/malware detection tools?
>>
>> No. Because that opinion is flawed.
>
>How is it flawed, I've been trying to see it your way, but there is no
>logic in your opinion. Please state something of fact that shows why a
>code using an exploit should not be classified as malware.

I did. And it was very logical. You just chose to neglict it. I see no
reason to argue further.

Re: Nasty propaganda by "security tool" providers

Leythos wrote:
> So, are we done with the idea that anything that exploits a hole should
> be seen as malware by AV/malware detection tools?
>

Far be it for me, a mere newbie in this group, to interject on this
rather lengthy flamewar, but I cannot resist. Leythos, do you even
have a clue how the majority of AV vendors code their detectors? I'm
guessing no, because if you did then you would understand that by
detecting POC code, they are most often doing nothing to detect any
other code *which actually does something malicious* that is based
on the POC code. You also seem to have forgotten that POC code by
definition does not do anything malicious, just shows that someone
else could do something malicious using the same vulnerability.
Granted, there are a few AV vendors that do heuristic based matching,
but most have signatures on the code they investigated in their labs.
These signatures rarely detect anything other than that one instance
of code. Recompile it with different compilation options or change a
little bit of code (like you'd have to do to make it do something
malicious) and the signature for the POC will fail to detect the new
derivative code.

For the signature based folks, all they're doing by detecting the POC
code is inflating their detection numbers. It is the rare vendor that
will actually detect any real malicious code that uses the same
exploit as the POC by detecting the POC. Most will never detect
anything but the original POC and are just using it to bump up their
number of detected "virii" so they look good to the less informed
masses. They could code up signatures for everything in the Nessus
vulnerability scanner and say "Look! We detect 10,000 more virii than
our competitors. Aren't we just the bestest AV vendor in the whole
wide world? Buy us!" and the average Joe would lap it up like a kitten.
Are they helping the average Joe be more secure? Nope. Just giving him
a nice false sense of security.

So no, POC should not be seen as malware by AV/malware detection tools
unless they are one of those rare vendors which use heuristic based
detection methods that would detect other code (even completely novel
code) that uses the same vulnerability/exploit. Any AV/malware tool
that uses just plain signatures should not detect non-malicious code
even if it does use an exploit (eg POC code) if the signature would
not detect malicious code that uses the same exploit. It's humans
coding up the signature database. I would hope the humans have enough
sense to be able to differentiate malicious from non-malicious and
only put the malicious code in their signature database. But being
that it is humans doing this, I understand the base human urge to
throw all the code in there, malicious or no, just to inflate the
database size and be able to get more money out of people. Greed can
never be forgotten when dealing with humans.

Re: Nasty propaganda by "security tool" providers

Post removed (X-No-Archive: yes)

Re: Nasty propaganda by "security tool" providers

Post removed (X-No-Archive: yes)

Re: Nasty propaganda by "security tool" providers

Post removed (X-No-Archive: yes)

Re: Nasty propaganda by "security tool" providers

On Mon, 07 Aug 2006 00:05:10 +0200, Sebastian Gottschalk
wrote:

>B. Nice wrote:
>> On Sun, 06 Aug 2006 21:42:24 GMT, Leythos wrote:
>>
>>> Please look on the MS site for how to secure your computer, there are
>>> numerous documents, to many for me to care to list or find for you. All
>>> you have to do is care enough to take the time.
>>
>> Huh?? - And this is what you claimed earlier that even a Jim Novice
>> should be able to do?????
>
>Would you please stop confusing him with facts? :-)

I better make a full stop :-)

>>> So, are we done with the idea that anything that exploits a hole should
>>> be seen as malware by AV/malware detection tools?
>>
>> No. Because that opinion is flawed.
>
>You're understating. Such an idea is simply stupid, as misconfiguration
>/ insecure defaults can be a security hole as well. What about detecting
>cmd.exe? It allows deletion of critical files when improper ACLs are
>applied, which happens quite frequently when running certain so-called
>security software.

Re: Nasty propaganda by "security tool" providers

Leythos wrote:
> In article ,
> fishlover@nospam.invalid says...
>> So no, POC should not be seen as malware by AV/malware detection tools
>> unless they are one of those rare vendors which use heuristic based
>> detection methods that would detect other code (even completely novel
>> code) that uses the same vulnerability/exploit.
>
> So, what your entire reply boils down to is that if vendors detect it by
> any means, other than a specific signature, that it could be malware,
> but, because the author didn't mean it to be malware, that it should not
> be detected as such.
>

Great attempt at spin, but no, that is not what I said. What I said is
if (and ONLY if) the vendor has a way to detect the exploitation of a
vulnerability in a general sense (aka heuristic based detection), then
developing a detector based off POC is fine. They are using the POC to
codify the method by which an exploit works, ie to detect the whole
class of code that uses this exploit method. I explicitly said that
this type of detection is extremely rare and not what most vendors do.

Further, I explicitly said that vendors who use POC code for anything
but generic class-based detection are basically blowing smoke. There
is no need to have a signature for POC code because it is not malicious.
Having a signature for POC code does not protect against any actual
malicious code that uses the same exploit as the POC code. It is a
false sense of security to have POC signatures. It's more a greedy
marketting ploy (our database is bigger than yours), than a sound
security decision.

> How does any part of what you said in your post differ from what I've
> been trying to get him to understand - you just agreed with my entire
> stance in this thread.
>

Because in my post, I make the distinction between the various methods
vendors use to code their detectors. There is the rare vendor that
does more than a basic signature of the binary code. Those vendors
can find use out of POC code. But the majority of the vendors just do
signatures. For those vendors, having a signature for POC code is a
complete waste of time and does nothing to improve the security of
the system. It's just an artificial way for them to inflate their
database size and blow smoke at the uninformed. You on the other hand
lump all methods together and cannot distinguish between garbage and
actual useful detection methods.

I have not agreed with you at all. In actuality, I was trying to
politely call you uninformed. Thanks for reinforcing that by showing
you have no concept of the different methods of detection and how
POC can be useful to one method while being completely useless to
another (most common) method.

Re: Nasty propaganda by "security tool" providers

Post removed (X-No-Archive: yes)

Re: Nasty propaganda by "security tool" providers

On Mon, 07 Aug 2006 01:44:08 GMT, Leythos wrote:


>I agree with the above, but, I would expect that the POC just got caught
>by trying to detect the "Method" that the POC uses, not the actual POC
>itself.

You should'nt expect or assume. You should look at the facts.

The facts tell us that when compiled with slight changes it is no
longer detected.

This means 1 of 2 things:

1) Anti-virus engines do not detect "by method"

or

2) Anti-virus engines do detect "by method" but are highly unreliable.

In both cases it's useless.

Re: Nasty propaganda by "security tool" providers

Post removed (X-No-Archive: yes)

Re: Nasty propaganda by "security tool" providers

Leythos wrote:
> In article ,
> b__nice@hotmail.com says...
> > On Sat, 05 Aug 2006 18:34:31 GMT, Leythos wrote:
> >
> > >If you have a POC that works, then you already know that it mimics
> > >malware and should be detected just like Malware.
> >
> > Of course it should'nt. Only malware should be detected as malware.
> > Please check the defintion of malware
> > http://en.wikipedia.org/wiki/Malware and see if that description fits
> > a PoC.
> >
> > It also does'nt make sense that Volkers PoC is detected as malware by
> > 21 out of 27 engines at Virustotal.com while at the same time only 5
> > out of 27 detect Steves LeakTest 1.2 as malware.
>
> Sure it does, VB is nothing to people outside his little world, they are
> not targeting him or his code, he's not worth their time/effort.
>
> What you need to consider is this: If a POC is to work, it has to use
> the same methods as what you're trying to prove - so, that means that if
> his POC is going to work, it's got to act/emulate the actions of
> malware. While his POC is not malicious, if it was to really work it
> would have to emulate the actual malware functions.
>



> So, it being detected means that he's got the right idea, about how the
> actual malware works, but what he's failed to address is that his POC is
> worthless on a properly configured computer.
>
> --

But VB's shutdown windows servers code is not to demonstrate how
malware works.
Not to prove a concept. It's to secure a computer.
I think it's only reasonable that if VB submits it to an AV firm they
should whitelist it.

If a computer runs no services, then I wouldn't necessarily say that a
properly configured computer would need a firewall. (I guess though,
there's risk of an exploit perhaps not "installing a service", but
running a server, even from a limited account? if true, that may be a
criticism of VB's prob)

VB doesn't have as large a user base as Gibson, I wouldn't say VB is in
his own world. He is on usenet, opening himself and his ideas to
discussion.

Gibson is a conman or more specifically, a confidence trickster, who
really does run his own little world, where he by his own admition
intentionally launches his "propaganda campaigns" which hit users as
well as technical people looking to further their knowledge.

Re: Nasty propaganda by "security tool" providers

Leythos wrote:
[deleted]

> I don't understand why you guys get bent out of shape when a POC that
> proves and exploit path is actually detected as malware - the point was
> to show that an exploit path exists and it's the exploit path that is
> being detected.

The point is that, as *proven* by B. Nice, "the exploit path" was/is
NOT detected. What *was* detected was *VB's code*.

When B. Nice changed the URL and recompiled the code, it was NOT
detected by *any* of the *twenty seven* engines.

That clearly proves that VB's code was targeted/detected and NOT "the
exploit path". I.e. as far as security/protection is concerned, the
'detection' is completely useless.

Melissa explained things very clearly: The 'engines' clearly used
signatures for 'detection', not heuristics, i.e. they 'detected'
*specific code* (i.e. VB's in this case), NOT "the exploit path".

There is NO way you can explain away the fact that ALL engines failed,
if they *did* use heuristic based matching (or other similarly advanced
methods) instead of signatures.

I.e. B. Nice test proved that the engines did use signatures and hence
were bound to fail to detect any new uses of "the exploit path".

So IMO it's really moot whether or not you think that VB's PoC code is
'malware' or not, the 'AV' software, all 27 of them, was proven to be
totally useless and VB's code was needlessly smeared in the process.

So please remind us *who* (other than the AV vendors) exactly did gain
anything by all of this? Surely not Joe User and surely not VB.

[deleted]

Re: Nasty propaganda by "security tool" providers

Post removed (X-No-Archive: yes)

Re: Nasty propaganda by "security tool" providers

Post removed (X-No-Archive: yes)

Re: Nasty propaganda by "security tool" providers

Leythos wrote:
> In article <44d74b16$0$94577$dbd41001@news.wanadoo.nl>,
> this@ddress.is.invalid says...
> > So IMO it's really moot whether or not you think that VB's PoC code is
> > 'malware' or not, the 'AV' software, all 27 of them, was proven to be
> > totally useless and VB's code was needlessly smeared in the process.
>
> Nothing has changed, and I have clearly not said, not anywhere, that
> VB's code is malware. I do not believe it is malware. My stating that
> it's not malware doesn't mean, if it acts like malware, that it should
> not be detected as malware.
>
> Until we know why/how it was detected we will not have any factual
> information to base a reason on.

We *do* have "factual information". You just chose to silently snip
and ignore it.

> Certainly we can not suggest, with any factual credibility, that it was
> strictly a target by any vendor because it's "VB's code". This is the
> entire point of what I have been saying. I do not believe that VB is
> important enough to any vendor for them to take the time to specifically
> target his code.

I don't think that anyone has said that they targetted VB's code
*because* it was his code, i.e. something like a personal vendetta. What
was said, and *proven*, that they *did* target his code. I.e. VB's code
was detected, B. Nice's code was not detected by any of the 27 engines.

[More silent snipping noted.]

Re: Nasty propaganda by "security tool" providers

Leythos wrote:
[deleted]

> Maybe you should consider what the code does and not listen to hype. If
> the program can stop services, as many malware do, then it could be
> considered malware itself. What if a person, without understanding, gets
> sent the exe in a email and told to run it (like many of the Zipped exes
> that contain malware) and it bombs their server - would that not be
> considered the same?
>
> I'm not saying that anything VB produces is malware, I'm suggesting that
> you look at what malware IS and what things that people code can do, and
> if they fit the same mold, stopping services, trying to exploit a hole
> in IE, etc.. Then, like it or not, they should be detected too.

So is msconfig.exe "malware"? If not, why not?

Is a patch to/for msconfig.exe "malware"? If not, why not?

Is a services-management utility written by
"malware"? Why (not)?

Is a 'freeware' services-management utility "malware"? Why (not)?

Is a open-source services-management utility "malware"? Why (not)?

Etc., ad infinitum.

I.e. what you were saying is that one should not judge "malware" on
intent or/and author, but that is *exactly* what you *are* doing.

[deleted]

Re: Nasty propaganda by "security tool" providers

Leythos wrote:
> In article <1154958873.168655.243770@m79g2000cwm.googlegroups.com>,
> q_q_anonymous@yahoo.co.uk says...
> >
> > Leythos wrote:
> > > In article ,

> > > So, it being detected means that he's got the right idea, about how the
> > > actual malware works, but what he's failed to address is that his POC is
> > > worthless on a properly configured computer.
> > >
> > > --
> >
> > But VB's shutdown windows servers code is not to demonstrate how
> > malware works. Not to prove a concept. It's to secure a computer.
> > I think it's only reasonable that if VB submits it to an AV firm they
> > should whitelist it.
>
> Maybe you should consider what the code does and not listen to hype. If
> the program can stop services, as many malware do, then it could be
> considered malware itself. What if a person, without understanding, gets
> sent the exe in a email and told to run it (like many of the Zipped exes
> that contain malware) and it bombs their server - would that not be
> considered the same?
>

then the same applies to some sysinternals programs, like the one that
runs commands on other machines.
the same applies to any easy to set up ftp server program.

VB's program asks the user.

> I'm not saying that anything VB produces is malware, I'm suggesting that
> you look at what malware IS and what things that people code can do, and
> if they fit the same mold, stopping services, trying to exploit a hole
> in IE, etc.. Then, like it or not, they should be detected too.
>

or starting a service - malware sometimes does that too.

I think it's fine for the AV or malware detector's algorithm to detect
is as malware, but it should be whitelisted.

> > If a computer runs no services, then I wouldn't necessarily say that a
> > properly configured computer would need a firewall. (I guess though,
> > there's risk of an exploit perhaps not "installing a service", but
> > running a server, even from a limited account? if true, that may be a
> > criticism of VB's prob)
>
> This is a distraction and has nothing to do with the fact that something
> that stops services on a computer could be considered malware.
>

What about Gibson's "Shoot the messenger" ? (to stop the messenger
service). Should that be malware or whitelisted?

> > VB doesn't have as large a user base as Gibson, I wouldn't say VB is in
> > his own world. He is on usenet, opening himself and his ideas to
> > discussion.
>
> As far as I can tell, he's just the same as you or me, another person
> posting to Usenet with his own ideas/ideals. Nothing more, nothing less.
>

That's a lot more than Gibson.

My point in bringing up Gibson, is that you effectively said that
Gibson is well known and VB is in his own little world.

It'd have been more accurate to just say that Gibson has a larger user
base.


> The point is that if a POC works to prove something about malware or if
> it performs actions like malware would, then it should be detected as
> malware.

but didn't you defend that Gibson's leaktest shouldn't be detected as
malware?

I think VB should be able to submit his program to be whitelisted.

>
> If you want to stop services you don't need an POC sample to do it, just
> stop them yourself, every OS has that ability.
>


I havent' tried VB's code recently. But, I did once try to stop all
services - as an experiment, I think I couldn't find a way to stop the
one on port 135 - RPC.

I probably wouldn't want to do that, maybe i'd lose connectivity or
something. And I don't know if VB's code stops that one.

Re: Nasty propaganda by "security tool" providers

Post removed (X-No-Archive: yes)

Re: Nasty propaganda by "security tool" providers

q_q_anonymous@yahoo.co.uk wrote:
> I havent' tried VB's code recently. But, I did once try to stop all
> services - as an experiment, I think I couldn't find a way to stop the
> one on port 135 - RPC.
> I probably wouldn't want to do that, maybe i'd lose connectivity or
> something. And I don't know if VB's code stops that one.

It does. Just have a look on the source code of "Shutdown Windows'
services":

http://www.dingens.org/win32sec-en-src.zip

Yours,
VB.
--
Ich würde schätzen, dass ca. 87% aller spontanen Schätzungen völlig für
den Arsch sind.

Ralph Angenendt in debate@ccc.de

Re: Nasty propaganda by "security tool" providers

Post removed (X-No-Archive: yes)

Re: Nasty propaganda by "security tool" providers

On Mon, 07 Aug 2006 14:28:00 GMT, Leythos wrote:

>Nothing has changed, and I have clearly not said, not anywhere, that
>VB's code is malware. I do not believe it is malware. My stating that
>it's not malware doesn't mean, if it acts like malware, that it should
>not be detected as malware.

Okay. One final attempt then:

"POC code does not fit the definition of malware"
which means
"POC code is not malware"
which leads to
"POC code should not be detected as malware"

Please state precisely where and why I am wrong.

Re: Nasty propaganda by "security tool" providers

Post removed (X-No-Archive: yes)

Re: Nasty propaganda by "security tool" providers

On Mon, 07 Aug 2006 15:42:44 GMT, Leythos wrote:



>And how does a coder get their programs whitelisted? Does it just
>automagically happen that a persons code appears in a crystal ball and
>is then excluded? I would think that if you want your code, which has
>malware like qualities, excluded, that you should submit it to vendors
>BEFORE you release it to the public.

Nonsense. The anti-virus companies claiming to be able to detect
malware must of course prove that they are right. It can never be my
job as a coder to kindly ask anti-virus companies to whitelist my
code.

Re: Nasty propaganda by "security tool" providers

Post removed (X-No-Archive: yes)

Re: Nasty propaganda by "security tool" providers

On Mon, 07 Aug 2006 16:21:56 GMT, Leythos wrote:

>In article ,
>b__nice@hotmail.com says...
>> On Mon, 07 Aug 2006 15:42:44 GMT, Leythos wrote:
>>
>>
>>
>> >And how does a coder get their programs whitelisted? Does it just
>> >automagically happen that a persons code appears in a crystal ball and
>> >is then excluded? I would think that if you want your code, which has
>> >malware like qualities, excluded, that you should submit it to vendors
>> >BEFORE you release it to the public.
>>
>> Nonsense. The anti-virus companies claiming to be able to detect
>> malware must of course prove that they are right. It can never be my
>> job as a coder to kindly ask anti-virus companies to whitelist my
>> code.
>
>Why?

Why should I even care? - They are just companies. They are no
authorities in any way.

Re: Nasty propaganda by "security tool" providers

Post removed (X-No-Archive: yes)

Re: Nasty propaganda by "security tool" providers

Post removed (X-No-Archive: yes)

Re: Nasty propaganda by "security tool" providers

>Leythos wrote:

> > I think VB should be able to submit his program to be whitelisted.
>
> I agree, always have, as should any coder that develops something that
> is not malware but acts like malware.
>
> Why didn't he do it to start with?
>

I think that it's forgivable that the anti-malware thought VB's
software was malware.

once VB notified them that it isn't, it is then unacceptable for the
anti-malware company to say they're intentionally detecting it.

i'm sure VB only threatened them with a lawyer and a deadline when they
were not co-operating i.e. showed no interest in correcting their
program in the next release.

Re: Nasty propaganda by "security tool" providers

Post removed (X-No-Archive: yes)

Re: Nasty propaganda by "security tool" providers

Leythos wrote:

[deleted]
> Now, ask yourself why their (sysinternals) programs are not detected as
> malware and how they got excluded. Now ask VB if he submitted his code
> to the anti-malware vendors BEFORE he released it, so that it could be
> excluded - I've not seen that asked/answered yet.

[deleted]

> And how does a coder get their programs whitelisted? Does it just
> automagically happen that a persons code appears in a crystal ball and
> is then excluded? I would think that if you want your code, which has
> malware like qualities, excluded, that you should submit it to vendors
> BEFORE you release it to the public.

You are turning things around! As has been *proven*, VB's code was
detected by signature, i.e. they (the AV vendors) *knew* the author, had
*access* to the *source code* and *knew* (read: should have known) the
non-malicious intent. *They* should have whitelisted the code, but they
failed to do so. So *they* are the parties to blame.

Does each and every author of a supposedly (by you) 'dangerous' piece
of software have to prove to the almighty AV vendors "No Sir, I'm
innocent, really I am!"? I hope you realize how utterly silly such a
position is.

[deleted]

Re: Nasty propaganda by "security tool" providers

Leythos wrote:
> In article <44d758cb$0$49538$dbd4f001@news.wanadoo.nl>,
> this@ddress.is.invalid says...
> > Leythos wrote:
> > [deleted]
> >
> > > Maybe you should consider what the code does and not listen to hype. If
> > > the program can stop services, as many malware do, then it could be
> > > considered malware itself. What if a person, without understanding, gets
> > > sent the exe in a email and told to run it (like many of the Zipped exes
> > > that contain malware) and it bombs their server - would that not be
> > > considered the same?
> > >
> > > I'm not saying that anything VB produces is malware, I'm suggesting that
> > > you look at what malware IS and what things that people code can do, and
> > > if they fit the same mold, stopping services, trying to exploit a hole
> > > in IE, etc.. Then, like it or not, they should be detected too.
> >
> > So is msconfig.exe "malware"? If not, why not?
> >
> > Is a patch to/for msconfig.exe "malware"? If not, why not?
> >
> > Is a services-management utility written by
> > "malware"? Why (not)?
> >
> > Is a 'freeware' services-management utility "malware"? Why (not)?
> >
> > Is a open-source services-management utility "malware"? Why (not)?
> >
> > Etc., ad infinitum.

Your failure to provide answers to specific questions is, again, duly
noted.

> > I.e. what you were saying is that one should not judge "malware" on
> > intent or/and author, but that is *exactly* what you *are* doing.
> >
> > [deleted]
>
> I'm not basing anything on "Intent"

Yes, you are. Some ware is goodware by *your* 'rules', while other
ware is "malware" by *your* 'rules'. Consistency apparently has nothing
to do with which falls in which category.

> and I have no idea why his code was detected, only speculation based
> on the information we had at the time.

No speculation, but proof. That said proof conflicts with your
opinion/bias doesn't make it any less proof.

> Now, do we know which POC sample that B.Nice modified and then
> submitted?

Yes, he said so. Google is your friend/enemy.

> So far I've not ignored anything, just looking at facts only.

Re: Nasty propaganda by "security tool" providers

Post removed (X-No-Archive: yes)

Re: Nasty propaganda by "security tool" providers

Post removed (X-No-Archive: yes)

Re: Nasty propaganda by "security tool" providers

On Mon, 07 Aug 2006 16:44:14 GMT, Leythos wrote:

>You just can't get your thoughts in one place. First you complain that
>the code is detected as malware and it must be some grand conspiracy
>against VB, then, when presented with why, and also see their response
>in another thread from VB, you ignore it, then you ignore the basics of
>what is malware and everything else.

Lots of words without content.

>Now you want to know why you should care that a product developed and
>released that mimics some malware should not have been submitted to the
>AV vendors to whitelist it?

Because the onus of proof is not on me. It's on them!

>As yourself this - if you don't care about the companies that classed it
>as malware, then why did you bother with this thread?

You simply don't understand. What I should'nt care about is contacting
them.

Re: Nasty propaganda by "security tool" providers

Post removed (X-No-Archive: yes)

Re: Nasty propaganda by "security tool" providers

Leythos wrote:
> In article <44d7795e$0$25041$dbd4d001@news.wanadoo.nl>,
> this@ddress.is.invalid says...
> > Leythos wrote:
> > > In article <44d758cb$0$49538$dbd4f001@news.wanadoo.nl>,
> > > this@ddress.is.invalid says...
> > > > Leythos wrote:
> > > > [deleted]
> > > >
> > > > > Maybe you should consider what the code does and not listen to hype. If
> > > > > the program can stop services, as many malware do, then it could be
> > > > > considered malware itself. What if a person, without understanding, gets
> > > > > sent the exe in a email and told to run it (like many of the Zipped exes
> > > > > that contain malware) and it bombs their server - would that not be
> > > > > considered the same?
> > > > >
> > > > > I'm not saying that anything VB produces is malware, I'm suggesting that
> > > > > you look at what malware IS and what things that people code can do, and
> > > > > if they fit the same mold, stopping services, trying to exploit a hole
> > > > > in IE, etc.. Then, like it or not, they should be detected too.
> > > >
> > > > So is msconfig.exe "malware"? If not, why not?
> > > >
> > > > Is a patch to/for msconfig.exe "malware"? If not, why not?
> > > >
> > > > Is a services-management utility written by
> > > > "malware"? Why (not)?
> > > >
> > > > Is a 'freeware' services-management utility "malware"? Why (not)?
> > > >
> > > > Is a open-source services-management utility "malware"? Why (not)?
> > > >
> > > > Etc., ad infinitum.
> >
> > Your failure to provide answers to specific questions is, again, duly
> > noted.
> >
> > > > I.e. what you were saying is that one should not judge "malware" on
> > > > intent or/and author, but that is *exactly* what you *are* doing.
> > > >
> > > > [deleted]
> > >
> > > I'm not basing anything on "Intent"
> >
> > Yes, you are. Some ware is goodware by *your* 'rules', while other
> > ware is "malware" by *your* 'rules'. Consistency apparently has nothing
> > to do with which falls in which category.
>
> I've made every attempt to get people to understand that it doesn't
> matter what the "Intent" of the code is, only if it has malware like
> actions/functions. Intent does not matter, only what it can/could do.

Dodging specific questions, again and again, is by no means "every
attempt to get people to understand".

> > > and I have no idea why his code was detected, only speculation based
> > > on the information we had at the time.
> >
> > No speculation, but proof. That said proof conflicts with your
> > opinion/bias doesn't make it any less proof.
>
> Sure, if we don't have facts then people arguing with me can't really
> state anything other than Opinion. An opinion is not a fact. A fact is
> real and can be measured - that fact is that no-one knew why his code
> was detected, no one was willing to think about why, only rant that
> because it was VB's code that it could not be malware and that it should
> not be detected as malware.

But we *did/do* have facts, as I *explained* in detail in my *very
first* response, so please cut this "opinion" non-sense.

> > > Now, do we know which POC sample that B.Nice modified and then
> > > submitted?
> >
> > Yes, he said so. Google is your friend/enemy.
>
> Yep, I found it, but, it doesn't change the facts at all.
>
> > > So far I've not ignored anything, just looking at facts only.
>
> Look at the facts, not rantings, tell me what you see as Facts, I've
> already stated what I consider fact, now you try.

I told you (what I see as) the facts. In my very first response. You
ignoring them doesn't change them in any way.

Re: Nasty propaganda by "security tool" providers

On Mon, 07 Aug 2006 17:06:34 GMT, Leythos wrote:

>In article ,
>b__nice@hotmail.com says...
>> On Sat, 05 Aug 2006 18:34:31 GMT, Leythos wrote:
>>
>> >If you have a POC that works, then you already know that it mimics
>> >malware and should be detected just like Malware.
>>
>> Of course it should'nt. Only malware should be detected as malware.
>> Please check the defintion of malware
>> http://en.wikipedia.org/wiki/Malware and see if that description fits
>> a PoC.
>
>And what makes a program that stops services malware or good? Intent is
>impossible to detect by programs, it takes a human to determine intent.

Agreed. And that is exactly what they should do instead of letting
their defective software make false claims.

>So, since the program acts as some malware would, it seems logical to
>detect it as such.

Nonsense.

>> It also does'nt make sense that Volkers PoC is detected as malware by
>> 21 out of 27 engines at Virustotal.com while at the same time only 5
>> out of 27 detect Steves LeakTest 1.2 as malware.
>
>Sure it does, you just need to stop thinking it's related to VB.
>
>The code is detected because it mimics some form of malware. If VB
>really cared he would have submitted it to the vendors for testing and
>approval before turning it out to the public.

That's your opinion.

>If 21 of 27 detect it as malware then you need to start thinking about
>WHY instead of thinking "Poor VB, he's being targeted". It's not about
>VB, he's not important enough to target.
>
>It's really simple, if it acts like malware then it should properly be
>detected as malware. If the author doesn't want something marked as
>malware that acts like malware then THE AUTHOR needs to take steps to
>make sure that it's not seen as malware.

Nonsense. Anti-virus vendors need to make sure their products are not
defective and that they they don't detect non-malicious code as
malware.

>It really is that simple.

No.

Re: Nasty propaganda by "security tool" providers

Post removed (X-No-Archive: yes)

Re: Nasty propaganda by "security tool" providers

Leythos wrote:
> In article <44d777c5$0$98638$dbd4d001@news.wanadoo.nl>,
> this@ddress.is.invalid says...
> > Leythos wrote:
> >
> > [deleted]
> > > Now, ask yourself why their (sysinternals) programs are not detected as
> > > malware and how they got excluded. Now ask VB if he submitted his code
> > > to the anti-malware vendors BEFORE he released it, so that it could be
> > > excluded - I've not seen that asked/answered yet.
> >
> > [deleted]
> >
> > > And how does a coder get their programs whitelisted? Does it just
> > > automagically happen that a persons code appears in a crystal ball and
> > > is then excluded? I would think that if you want your code, which has
> > > malware like qualities, excluded, that you should submit it to vendors
> > > BEFORE you release it to the public.
> >
> > You are turning things around! As has been *proven*, VB's code was
> > detected by signature, i.e. they (the AV vendors) *knew* the author, had
> > *access* to the *source code* and *knew* (read: should have known) the
> > non-malicious intent. *They* should have whitelisted the code, but they
> > failed to do so. So *they* are the parties to blame.
>
> Read the translated email, it does not say they knew of him or his code
> or intent. It says they will work with VB to change the status to
> "Security Privacy Risk", which seems to fit the classification.

You are confusing two pieces of code. Not that it really matters as
your position can hardly become any weaker than it already is.

In the case were discussing here, they *did* know him because the
URL to his site was in the bloody code.

I don't know about the other case (the services-terminating one), but
I assume that code also contains his contact details.

So let me ask another specific question, and please don't dodge this
one:

If (supposedly malicious/malware) code contains contact details, do
you agree that it's the AV vendors responsibility to contact the author/
vendor (if needed) and not the other way around?

> Radmin is also detected as malware on just about every AV product, but
> it's a quality/good tool that is not really malware either.
>
> I don't see any indication that they actually targeted VB's code as "his
> code", they targeted a code that has malware functions.

The facts (i.e. B Nice's tests) prove you wrong. Their mail proves you
wrong.

> > Does each and every author of a supposedly (by you) 'dangerous' piece
> > of software have to prove to the almighty AV vendors "No Sir, I'm
> > innocent, really I am!"? I hope you realize how utterly silly such a
> > position is.
>
> And what separates a malware author from a good author? Care to clearly
> define that so that there are never any mistakes by the definition?

Innocent until proven guilty? "Why did you steal that computer on which
you were typing your response?" Etc.

> If a programs acts like malware, well it should be flagged, simple,
> easy, not hard to understand.

So answer the specic questions I asked (about msconfig, updates to it,
etc.).

> Read their response to VB again - and translate it so that you get the
> meaning from them and not VB's rant.

Again, that's the other case, but:

Contrary to you, I have no problem taking what VB says the message
says as the truth and do understand German.

Re: Nasty propaganda by "security tool" providers

Post removed (X-No-Archive: yes)

Re: Nasty propaganda by "security tool" providers

On Mon, 07 Aug 2006 17:55:00 GMT, Leythos wrote:

>In article ,
>b__nice@hotmail.com says...
>> On Mon, 07 Aug 2006 16:44:14 GMT, Leythos wrote:
>>
>> >You just can't get your thoughts in one place. First you complain that
>> >the code is detected as malware and it must be some grand conspiracy
>> >against VB, then, when presented with why, and also see their response
>> >in another thread from VB, you ignore it, then you ignore the basics of
>> >what is malware and everything else.
>>
>> Lots of words without content.
>
>I'm not sure how you can miss that something that acts like malware
>should be flagged as malware or at the very least as suspect.

That's your opinion. And that's all it is. Just an opinion. My opinion
is different. So we disagree.

>> >Now you want to know why you should care that a product developed and
>> >released that mimics some malware should not have been submitted to the
>> >AV vendors to whitelist it?
>>
>> Because the onus of proof is not on me. It's on them!
>
>No, the onus of proof is on the coder. Code that can perform malicious
>actions should be considered malicious until proven otherwise.

That's your opinion. And that's all it is. Just an opinion. My opinion
is different. So we disagree.

>> >As yourself this - if you don't care about the companies that classed it
>> >as malware, then why did you bother with this thread?
>>
>> You simply don't understand. What I should'nt care about is contacting
>> them.
>
>You are correct in "I shouldn't care about contacting them", and you
>shouldn't, VB should contact them, as he's already done, to get an
>understanding of why and to see if he can get off the list.

This discussion leads us nowhere.

Re: Nasty propaganda by "security tool" providers

Post removed (X-No-Archive: yes)

Re: Nasty propaganda by "security tool" providers

Post removed (X-No-Archive: yes)

Re: Nasty propaganda by "security tool" providers

q_q_anonymous@yahoo.co.uk wrote:
> I think that it's forgivable that the anti-malware thought VB's
> software was malware.
> once VB notified them that it isn't, it is then unacceptable for the
> anti-malware company to say they're intentionally detecting it.
> i'm sure VB only threatened them with a lawyer and a deadline when they
> were not co-operating i.e. showed no interest in correcting their
> program in the next release.

You can bet on it.

Yours,
VB.
--
Ich würde schätzen, dass ca. 87% aller spontanen Schätzungen völlig für
den Arsch sind.

Ralph Angenendt in debate@ccc.de

Re: Nasty propaganda by "security tool" providers

Frank Slootweg wrote:
> I don't know about the other case (the services-terminating one), but
> I assume that code also contains his contact details.

Yes, it does.

Yours,
VB.
--
Ich würde schätzen, dass ca. 87% aller spontanen Schätzungen völlig für
den Arsch sind.

Ralph Angenendt in debate@ccc.de

Re: Nasty propaganda by "security tool" providers

On Mon, 07 Aug 2006 17:45:12 GMT, Leythos wrote:

[snip]
>Sure, if we don't have facts then people arguing with me can't really
>state anything other than Opinion. An opinion is not a fact. A fact is
>real and can be measured - that fact is that no-one knew why his code
>was detected, no one was willing to think about why, only rant that
>because it was VB's code that it could not be malware and that it should
>not be detected as malware.
[snip]

>Look at the facts, not rantings, tell me what you see as Facts, I've
>already stated what I consider fact, now you try.


'None of the above changes the fact that VB's POC samples were not
targeted because they were his, they were targeted because of the way
the use an exploit path.'

Message-ID:


Geo

Re: Nasty propaganda by "security tool" providers

Leythos wrote:
> In article <44d77f4c$0$8497$dbd43001@news.wanadoo.nl>,
> this@ddress.is.invalid says...
> > I told you (what I see as) the facts. In my very first response. You
> > ignoring them doesn't change them in any way.
>
> I'm still waiting for something that has the appearance of facts to show
> why VB's code was detected, we still don't know, and I've not seen any
> factual information to show why.

We, i.e. people other than you, are not discussing/questioning/
the why. What we *are* discussing is the *fact* that it *is*
detected, while it shouldn't be, at least not without inspecting the
code and contacting the author. The AV vendor failed that essential
requirement.

Re: Nasty propaganda by "security tool" providers

Leythos wrote:
> In article <44d7831d$0$2275$dbd43001@news.wanadoo.nl>,
> this@ddress.is.invalid says...
> > Leythos wrote:
> > > In article <44d777c5$0$98638$dbd4d001@news.wanadoo.nl>,
> > > this@ddress.is.invalid says...
> > > > Leythos wrote:
> > > >
> > > > [deleted]
> > > > > Now, ask yourself why their (sysinternals) programs are not detected as
> > > > > malware and how they got excluded. Now ask VB if he submitted his code
> > > > > to the anti-malware vendors BEFORE he released it, so that it could be
> > > > > excluded - I've not seen that asked/answered yet.
> > > >
> > > > [deleted]
> > > >
> > > > > And how does a coder get their programs whitelisted? Does it just
> > > > > automagically happen that a persons code appears in a crystal ball and
> > > > > is then excluded? I would think that if you want your code, which has
> > > > > malware like qualities, excluded, that you should submit it to vendors
> > > > > BEFORE you release it to the public.
> > > >
> > > > You are turning things around! As has been *proven*, VB's code was
> > > > detected by signature, i.e. they (the AV vendors) *knew* the author, had
> > > > *access* to the *source code* and *knew* (read: should have known) the
> > > > non-malicious intent. *They* should have whitelisted the code, but they
> > > > failed to do so. So *they* are the parties to blame.
> > >
> > > Read the translated email, it does not say they knew of him or his code
> > > or intent. It says they will work with VB to change the status to
> > > "Security Privacy Risk", which seems to fit the classification.
> >
> > You are confusing two pieces of code. Not that it really matters as
> > your position can hardly become any weaker than it already is.
> >
> > In the case were discussing here, they *did* know him because the
> > URL to his site was in the bloody code.
> >
> > I don't know about the other case (the services-terminating one), but
> > I assume that code also contains his contact details.
> >
> > So let me ask another specific question, and please don't dodge this
> > one:
> >
> > If (supposedly malicious/malware) code contains contact details, do
> > you agree that it's the AV vendors responsibility to contact the author/
> > vendor (if needed) and not the other way around?
>
> I do not believe it is the responsibility of the AV vendors to contact
> all authors of suspected malware to determine the "Intenet". I do not
> believe the intended use of a software makes any difference.

OK. You have finally answered a specific question and stated you
opinion.

Now we can only agree to disagree. I.e. I, and several others in this
thread, think your opinion is wrong, as it is blaming the victim. But
you're entitled to your opinion.

[(Repeated) Refusal to accept facts deleted.]

> > > > Does each and every author of a supposedly (by you) 'dangerous' piece
> > > > of software have to prove to the almighty AV vendors "No Sir, I'm
> > > > innocent, really I am!"? I hope you realize how utterly silly such a
> > > > position is.
> > >
> > > And what separates a malware author from a good author? Care to clearly
> > > define that so that there are never any mistakes by the definition?
> >
> > Innocent until proven guilty? "Why did you steal that computer on which
> > you were typing your response?" Etc.
>
> If the code can be used to harm a system, how is it innocent?

Please stay with the program, will you? The topic of *this* thread is
VB's PoC code, NOT his services-terminating utility. So how is his PoC
code in any way malicious/non-innocent? I.e. it *does* not "harm a
system" and *can* not "harm a system".

> > > If a programs acts like malware, well it should be flagged, simple,
> > > easy, not hard to understand.
> >
> > So answer the specic questions I asked (about msconfig, updates to it,
> > etc.).
>
> The programs are signed, many of them, or distributed from the OS
> vendor, I see no reason to suspect them, as they are part of the OS.
> Much like I don't suspect other OS specific software as malware. What I
> download from MS or from Redhat is suspected as being clean/good, what I
> download from xyz.com claiming to be msconfig is assumed to be suspect.

So you trust MS and basically nobody else. I suspected as much. Anyway,
that's again your opinion, to which you're entitled, and with which I
mostly disagree (i.e. I do not fully trust MS and I do not mistrust
everybody else per definition).

> > > Read their response to VB again - and translate it so that you get the
> > > meaning from them and not VB's rant.
> >
> > Again, that's the other case, but:
> >
> > Contrary to you, I have no problem taking what VB says the message
> > says as the truth and do understand German.
>
> Not knowing VB myself, and knowing how Usenet presents, I see no reason
> to trust anyone posting anything. I always check for myself. I also
> don't speak/read german, so that's why I used TWO translation services.

You do not "check for yourself", you refuse facts and information
which don't suit your apparent agenda and in the process you
misrepresent them.

Re: Nasty propaganda by "security tool" providers

Leythos wrote:
> In article ,
> b__nice@hotmail.com says...
> > >It's really simple, if it acts like malware then it should properly be
> > >detected as malware. If the author doesn't want something marked as
> > >malware that acts like malware then THE AUTHOR needs to take steps to
> > >make sure that it's not seen as malware.
> >
> > Nonsense. Anti-virus vendors need to make sure their products are not
> > defective and that they they don't detect non-malicious code as
> > malware.
>
> Can the code in question disable services on a PC?
>
> Was the code digitally signed or downloadable from the OS vendor?
>
> Do any malware act like the code in question?
>
> Answers as follows: Yes, NO, Yes.
>
> Seems that it could easily be considered malware.
>
> --
>

let's us get one nitty gritty point clear.

do you consider it malware?

BTW, the issue wasn't that they mistook it. The issue is that they
refuse to correct their software in the next release.

Re: Nasty propaganda by "security tool" providers

on 8/7/2006 10:58 AM Frank Slootweg said the following:
>
>>
>>>> So far I've not ignored anything, just looking at facts only.
>> Look at the facts, not rantings, tell me what you see as Facts, I've
>> already stated what I consider fact, now you try.
>
> I told you (what I see as) the facts. In my very first response. You
> ignoring them doesn't change them in any way.

Ok, I don't really have any expertise in this, and just read out of
interest. I do know a little about the scientific method, however, and
may see why this is such a hair ball.

IIRC, the post you are talking about said this:

"
The point is that, as *proven* by B. Nice, "the exploit path" was/is
NOT detected. What *was* detected was *VB's code*.

When B. Nice changed the URL and recompiled the code, it was NOT
detected by *any* of the *twenty seven* engines.
"

Which leads me to my first point. Scientific discovery is not
accompanied by shouts of "Eureka! I have found it!" Rather, it is quiet
mutterings of "WTF? It shouldn't have done that . . ."

" That clearly proves that VB's code was targeted/detected and NOT "the
exploit path". I.e. as far as security/protection is concerned, the
'detection' is completely useless."

Ok, it proves that two different compilations gave different results.
Yes, VB's was detected and the other not. So why? Some possible
hypotheses: 1) There was an error in compiling B Nice's version, so it
was not functional. 2) The history in the world of the two is different
in some way. 3) there is some other difference that is, as yet,
unexplained.

Assuming that #1 does not apply, (in other words, both versions have
equivalent function) then the facts suggestthat the AV engines did not
detect either one via heuristics.

If neither was detected via heuristics, then it makes complete sense
that B Nice's was not detected. It had never been "in the wild" and
given it's history, could have never been a signature generated. So,
how does that history differ from VB's?

One hypothesis is that when the PoC was known to AV companies, it's
signature was added to detection databases to poke a stick in VB's eye.
(That's what I assume is meant by use of the term "Targeted".) This
assumes that the process that AV companies use to relies on human
interaction to ID virii and that adding VB's was an intentional act.

A Second hypothesis is as Melissa suggested, AV companies, when
presented with a PoC, will routinely add it to their detection files to
boost their statistics. This hypothesis does not necessarily assume
human interaction. But it is assumed that the reason that harmless code
is still listed is to impress joe sixpack.

No third hypothesis has been presented. Here's one, with no data no
experiments, no nothing . . .

AV companies know that the most sophisticated heuristics can find some
virii. They don't enable it on their commercial product, because it
consumes too many resources to be useful if you want to do anything else
with it. However, in their research labs, they automatically run any
code that they acquire (regardless of the myriad methods of acquiring
it) through such a process. That process, unable to identify VB's code
as harmless, did ID it as using a vulnerability and therefore added it
automatically to their signature database.

How would this hypothesis be tested? Well, you could do exactly the
same thing that VB did with B Nice's code. In other words, allow it to
acquire the same "world experience" Then what happens? If the code had
the same "world experience", with the only exception that _________ .
Fill in the blank with the fact you want to test. If you don't do this,
then you really have proved nothing.

Re: Nasty propaganda by "security tool" providers

on 8/7/2006 10:46 AM B. Nice said the following:
> On Mon, 07 Aug 2006 16:44:14 GMT, Leythos wrote:
>
>> You just can't get your thoughts in one place. First you complain that
>> the code is detected as malware and it must be some grand conspiracy
>> against VB, then, when presented with why, and also see their response
>> in another thread from VB, you ignore it, then you ignore the basics of
>> what is malware and everything else.
>
> Lots of words without content.
>
>> Now you want to know why you should care that a product developed and
>> released that mimics some malware should not have been submitted to the
>> AV vendors to whitelist it?
>
> Because the onus of proof is not on me. It's on them!

I come to an intersection. I see that I have the right of way and that
the fellow coming the other way does not see me and is not going to
stop. The onus to stop is on him, if there is a crash it is his fault
so I proceed . . . All very true, but it's my sheet metal that's busted
(and maybe my wetware!)

Yea AV vendors should get it right. But if you don't want them to hurt
you, you might want to toot your horn or flash your lights before they
run you down.

Re: Nasty propaganda by "security tool" providers

Post removed (X-No-Archive: yes)

Re: Nasty propaganda by "security tool" providers

Post removed (X-No-Archive: yes)

Re: Nasty propaganda by "security tool" providers

John Hyde wrote:
> AV companies know that the most sophisticated heuristics can find some
> virii. They don't enable it on their commercial product, because it
> consumes too many resources to be useful if you want to do anything else
> with it. However, in their research labs, they automatically run any
> code that they acquire (regardless of the myriad methods of acquiring
> it) through such a process. That process, unable to identify VB's code
> as harmless, did ID it as using a vulnerability and therefore added it
> automatically to their signature database.

This is a hpothesis about _why_ the PoC codes are listed, not _how_
they're detected.

Yours,
VB.
--
Ich würde schätzen, dass ca. 87% aller spontanen Schätzungen völlig für
den Arsch sind.

Ralph Angenendt in debate@ccc.de

Re: Nasty propaganda by "security tool" providers

On Tue, 08 Aug 2006 01:55:20 GMT, Leythos wrote:

>I do not consider it malware, but I think it should properly be defined,
>as the av vendors have, as risk ware. It has the "Potential" to cause
>problems.

If that is to be taken literally then I know a lot of security
products (e.g. personal firewalls, anti-spyware and anti-virus
products) that should also be detected as risk ware :-)

Re: Nasty propaganda by "security tool" providers

On Mon, 07 Aug 2006 18:31:01 -0700, John Hyde
wrote:

>on 8/7/2006 10:46 AM B. Nice said the following:
>> On Mon, 07 Aug 2006 16:44:14 GMT, Leythos wrote:
>>
>>> You just can't get your thoughts in one place. First you complain that
>>> the code is detected as malware and it must be some grand conspiracy
>>> against VB, then, when presented with why, and also see their response
>>> in another thread from VB, you ignore it, then you ignore the basics of
>>> what is malware and everything else.
>>
>> Lots of words without content.
>>
>>> Now you want to know why you should care that a product developed and
>>> released that mimics some malware should not have been submitted to the
>>> AV vendors to whitelist it?
>>
>> Because the onus of proof is not on me. It's on them!
>
>I come to an intersection. I see that I have the right of way and that
>the fellow coming the other way does not see me and is not going to
>stop. The onus to stop is on him, if there is a crash it is his fault
>so I proceed . . . All very true, but it's my sheet metal that's busted
>(and maybe my wetware!)

If you want to use an analogy like that - then please make sure it
matches. What happens here is:
The anti-virus companies are saying: "We drive like we want to, and we
make the rules about what is right and what is wrong as we go along
(1). So if you want to pass an intersection at a certain time, you
better tell us beforehand".

That does'nt really make sense, does it?

>Yea AV vendors should get it right. But if you don't want them to hurt
>you, you might want to toot your horn or flash your lights before they
>run you down.

Maybe you should just come up with a better anology ;-)

---
(1) Leythos actually defends that position.

Re: Nasty propaganda by "security tool" providers

On Mon, 07 Aug 2006 18:23:35 -0700, John Hyde
wrote:



>Ok, it proves that two different compilations gave different results.
>Yes, VB's was detected and the other not. So why? Some possible
>hypotheses:

>1) There was an error in compiling B Nice's version, so it
>was not functional.

It worked in the same way as Volkers code when I ran it, so what do
you mean by "not functional"?

>2) The history in the world of the two is different
>in some way.

Yes, that's possible.

>3) there is some other difference that is, as yet,
>unexplained.

Yes, that's possible.

>Assuming that #1 does not apply, (in other words, both versions have
>equivalent function) then the facts suggestthat the AV engines did not
>detect either one via heuristics.

Agree.



>No third hypothesis has been presented. Here's one, with no data no
>experiments, no nothing . . .
>
>AV companies know that the most sophisticated heuristics can find some
>virii. They don't enable it on their commercial product, because it
>consumes too many resources to be useful if you want to do anything else
>with it. However, in their research labs, they automatically run any
>code that they acquire (regardless of the myriad methods of acquiring
>it) through such a process. That process, unable to identify VB's code
>as harmless, did ID it as using a vulnerability and therefore added it
>automatically to their signature database.

Yes, that's a possibility. Since I submitted it to virustotal.com, I
assume it is made available to the antivirus companies for further
checking (at least it seems like you have to explicitly tell them if
you do NOT want that to happen).
Therefore I will continue to check it from time to time to see if my
"clean bill of health" changes. Since the filename of my executable
starts with "Breakout" it should at least get some attention if
presented to human eyes :-)

Anyway, my test still showed that a slight change in the executable
(and remember I did not change any *functional* code, just a data
string) bypassed the engines. And since it's no problem for viruses to
make slight changes to themselves when spreading, I would say there is
a high level of certainty that these engines do not provide good
protection if your third hypothesis is correct.

Re: Nasty propaganda by "security tool" providers

B. Nice wrote:
> Anyway, my test still showed that a slight change in the executable
> (and remember I did not change any *functional* code, just a data
> string) bypassed the engines.

Really, this proofs one of those two:

- either they're NOT testing using "general" detection heuristics, but
with a special signature

- or they're testing with "general" detection heuristics, and the
implementations all are totally b0rken, and so equivalent to the
testing with special signatures for detecting special code, because
a very simple modification and recompile is enough to "hide"

I'd say, the first, because the second implies the additional assumption
of the very unlikely conincidence of detecting the original version at
all (Occam's razor). Anyways, assuming the second case, we can say:

About breakout.c:

The second would imply totally incompetence of the programmers at the
"security companies", too, because it's very easy to create such a
heuristics - just search on multiple library calls of FindWindow or
FindWindowEx followed by PostMessage and SendMessage. I did nothing to
hide this (i.e. loading functions dynamically for requiring runtime
checking or something like that).

About "Shutdown Windows' servers":

The second would imply totally incompetence of the programmers at the
"security companies", too, because it's very easy to create such a
heuristics - just search on calls to OpenSCManager followed by calls
to OpenService and ChangeServiceConfig. I did nothing to hide this (i.e.
loading functions dynamically for requiring runtime checking or
something like that).

As a conclusion, I'd say, that very likely they're checking with special
signatures for my PoC codes as well as for "Shutdown Windows' services".

It is very unlikely, that they're detecting them because of heuristics,
and if so, then they have to be totally incompetent.

Yours,
VB.
--
Ich würde schätzen, dass ca. 87% aller spontanen Schätzungen völlig für
den Arsch sind.

Ralph Angenendt in debate@ccc.de

Re: Nasty propaganda by "security tool" providers

Leythos wrote:
> Read it again, you have completely agreed with what I said. Read exactly
> what I've said, not taking anything other than what I said, and you will
> see that you and I really do agree.
>

I think I know who I do and do not agree with. I do not agree with you.
The others have summarized nicely why it is very logical to conclude
that the vendors in question are doing signature based detection and
have no reason to include any POC code, regardless of who wrote it. All
I see happening here is a lot of selective reading and spin on your
part Leythos. Are you the sort of person who cannot admit when he/she
is mistaken?

Re: Nasty propaganda by "security tool" providers

Leythos wrote:
> I've made every attempt to get people to understand that it doesn't
> matter what the "Intent" of the code is, only if it has malware like
> actions/functions. Intent does not matter, only what it can/could do.
>

By that criteria, pretty much every single action you take on a computer
could be considered "malware" because it could be used by some theoretical
actual malware to compromise a machine. Playing WoW? Well, you've opened
a network port. You must be malware. Installing a service pack? You're
overwriting system files. Must be malware. Turning off some unneeded
services or adding new ones? Oops, also something malware might do. Sorry
Hal, I can't let you do that.... And I could go on ad naseum. The point
being that there are humans behind the AV tools. These humans should be
evaluating intent. There's no way to distinguish "admin tool", "game",
"service pack", etc from malware otherwise. They all use the same basic
"actions/functions". If you blacklisted every possible function a piece
of malware would take... well there's an old joke about the perfectly
secured computer sitting unconnected in the closet that comes to mind.

Re: Nasty propaganda by "security tool" providers

B. Nice wrote:
> Anyway, my test still showed that a slight change in the executable
> (and remember I did not change any *functional* code, just a data
> string) bypassed the engines. And since it's no problem for viruses to
> make slight changes to themselves when spreading, I would say there is
> a high level of certainty that these engines do not provide good
> protection if your third hypothesis is correct.

I'll let you in on a little industry secret... signatures are just easier
to compute and check currently. And it is socially acceptable to have a
little turn-around time before a new variant is detected by the AV tools
so there is no market pressure to develop better detectors. There are some
doing heuristic detection or protocol based inspection, but these have
limited applicability ATM. There's plenty of academic work on how to
develop generic signatures from a single attack instance, how to detect
previously unseen attacks and so forth. But for the time being, they are
not really commercially viable. I should know, half of my dissertation
was on the topic of detecting novel or variant attacks.

Re: Nasty propaganda by "security tool" providers

Leythos wrote:
> In article ,
> b__nice@hotmail.com says...
>>
>> Nonsense. Anti-virus vendors need to make sure their products are not
>> defective and that they they don't detect non-malicious code as
>> malware.
>
> Can the code in question disable services on a PC?
>
> Was the code digitally signed or downloadable from the OS vendor?
>
> Do any malware act like the code in question?
>
> Answers as follows: Yes, NO, Yes.
>
> Seems that it could easily be considered malware.
>

Disabling services? A neutral task that is done by both malware and
admin tools.

Signed by OS vendor? It's not their code. Why would they sign it?

Acts like malware? See first. Not an activity exclusive to malware.

Seems to me it's something a human would mark as "I should look into
that and see what it does". An expert can do so personally. An average
Joe is expecting experts at the AV company to do that. If the AV
company only applied your criteria, then they are not applying expert
knowledge to evaluate the code. They are at best making a crude cut.
I suppose the root of this flamewar is some of us think making a
crude cut is not good enough and the vendors should exercise more
diligence while you seem to think a crude cut is good enough.

Re: Nasty propaganda by "security tool" providers

On Tue, 08 Aug 2006 11:09:40 GMT, Melissa
wrote:

>B. Nice wrote:
>> Anyway, my test still showed that a slight change in the executable
>> (and remember I did not change any *functional* code, just a data
>> string) bypassed the engines. And since it's no problem for viruses to
>> make slight changes to themselves when spreading, I would say there is
>> a high level of certainty that these engines do not provide good
>> protection if your third hypothesis is correct.
>
>I'll let you in on a little industry secret... signatures are just easier
>to compute and check currently. And it is socially acceptable to have a
>little turn-around time before a new variant is detected by the AV tools
>so there is no market pressure to develop better detectors. There are some
>doing heuristic detection or protocol based inspection, but these have
>limited applicability ATM. There's plenty of academic work on how to
>develop generic signatures from a single attack instance, how to detect
>previously unseen attacks and so forth. But for the time being, they are
>not really commercially viable. I should know, half of my dissertation
>was on the topic of detecting novel or variant attacks.

Thank you for your comments. It seems like the industry secret has
just become less secret :-)

Re: Nasty propaganda by "security tool" providers

Leythos wrote:


> The first post was from VB stating:
>
> -- test of VB's initial post --
> while my simple and harmless PoC codes how to ignore "Personal
> Firewalls" already are found as "viruses" by many virus scanners,
> now my tool "Shutdown Windows' services" is found as
> "SPR/Tool.KillService" virus by AntiVir. A tool, which has nothing to do
> with a virus, and improves security on a Windows 2000 or Windows XP host
> before SP2.
>
> The reason, why this is done, should be obvious. Just think twice.
>
> I'm wondering, wether one at all could trust in AntiVir any more. How
> many other things this tool is "detecting" because of political reasons,
> ignoring the needs of the user?
> -- end of VB's initial post --
>
> Nowhere in the post does it indicate the vendor has refused anything.
>
> Nowhere in the post does it indicate that VB contacted them and got a
> response.
>
> VB clearly tries to imply that the AV vendor targeted him personally,
> not the application based on it's functions/purpose.
>
> As we've seen in the two threads, the following:
>
> 21 av detection engines, according to b.nice, detected VB's code as some
> form of risk.
>
> None of the av vendors have posted or given reason as to why the
> consider it a risk.
>
> As description of the code, shuts down windows services, indicates it
> does the same thing as many malware, regardless of intenet of the
> author.
>
> One AV vendor has changed their classification and is going to list it
> as a Risk instead of SPR.
>
> So, what are we left with:
>
> Did all 21 vendors decided to go after VB personally, not because of the
> code, but, because it came from VB? I seriously don't think that they
> did, he's an unknown and not worth the cost of looking for him.
>
> Did all 21 vendors give anyone a reason for marking it as a risk? Not
> that I've seen anywhere in the thread.
>
> We don't have a single factual bit of info as to why the code was
> identified as a Risk.
>
> If you've got something to factually dispute these statements, please
> post so that I can see where I missed something in these facts.
>
> --
>

it's what they omitted that is so revealing.

VB informed them that their program mistakenly identified his program
as malware, and that theirs should be corrected.

They did not say that they would fix their program - on the contrary,
they justified it. Meaning, They're saying they won't.


can you imagine if their software flagged a new MS program (that used
the same technique) as malware and they didn't correct it.?

their refusal has no technical justification, because their software is
meant to identify malware, and possible malware. Not things that are
implemented a bit like malware but most certainly are not malware.
Technically, they can excempt VB's program.


So what is the reason? If not technical, then I think it must be
political, what other possibility is there?

Re: Nasty propaganda by "security tool" providers

Post removed (X-No-Archive: yes)

Re: Nasty propaganda by "security tool" providers

Post removed (X-No-Archive: yes)

Re: Nasty propaganda by "security tool" providers

Post removed (X-No-Archive: yes)

Re: Nasty propaganda by "security tool" providers

Post removed (X-No-Archive: yes)

Re: Nasty propaganda by "security tool" providers

Post removed (X-No-Archive: yes)

Re: Nasty propaganda by "security tool" providers

Leythos wrote:
> In article <1155037949.113461.240220@h48g2000cwc.googlegroups.com>,
> q_q_anonymous@yahoo.co.uk says...
> >
> > Leythos wrote:
> >
> >
> > > The first post was from VB stating:
> > >
> > > -- test of VB's initial post --
> > > while my simple and harmless PoC codes how to ignore "Personal
> > > Firewalls" already are found as "viruses" by many virus scanners,
> > > now my tool "Shutdown Windows' services" is found as
> > > "SPR/Tool.KillService" virus by AntiVir. A tool, which has nothing to do
> > > with a virus, and improves security on a Windows 2000 or Windows XP host
> > > before SP2.
> > >
> > > The reason, why this is done, should be obvious. Just think twice.
> > >
> > > I'm wondering, wether one at all could trust in AntiVir any more. How
> > > many other things this tool is "detecting" because of political reasons,
> > > ignoring the needs of the user?
> > > -- end of VB's initial post --
> > >
> > > Nowhere in the post does it indicate the vendor has refused anything.
> > >
> > > Nowhere in the post does it indicate that VB contacted them and got a
> > > response.
> > >
> > > VB clearly tries to imply that the AV vendor targeted him personally,
> > > not the application based on it's functions/purpose.
> > >
> > > As we've seen in the two threads, the following:
> > >
> > > 21 av detection engines, according to b.nice, detected VB's code as some
> > > form of risk.
> > >
> > > None of the av vendors have posted or given reason as to why the
> > > consider it a risk.
> > >
> > > As description of the code, shuts down windows services, indicates it
> > > does the same thing as many malware, regardless of intenet of the
> > > author.
> > >
> > > One AV vendor has changed their classification and is going to list it
> > > as a Risk instead of SPR.
> > >
> > > So, what are we left with:
> > >
> > > Did all 21 vendors decided to go after VB personally, not because of the
> > > code, but, because it came from VB? I seriously don't think that they
> > > did, he's an unknown and not worth the cost of looking for him.
> > >
> > > Did all 21 vendors give anyone a reason for marking it as a risk? Not
> > > that I've seen anywhere in the thread.
> > >
> > > We don't have a single factual bit of info as to why the code was
> > > identified as a Risk.
> > >
> > > If you've got something to factually dispute these statements, please
> > > post so that I can see where I missed something in these facts.
> > >
> > > --
> > >
> >
> > it's what they omitted that is so revealing.
> >
> > VB informed them that their program mistakenly identified his program
> > as malware, and that theirs should be corrected.
> >
> > They did not say that they would fix their program - on the contrary,
> > they justified it. Meaning, They're saying they won't.
>
> Actually, considering how unknown VB is, it's amazing that they decided
> to downgrade it to Risk level. So, they did, it appears, change the
> classification.
>

you think they changed thier classificaiton from definitely malware to
"risk" i.e. "unsure-maybe malware". It's most certainly not malware.

> > can you imagine if their software flagged a new MS program (that used
> > the same technique) as malware and they didn't correct it.?
>
> What about McAfee breaking MS Office with an update, yes, they corrected
> it, but, the detection problem was because of their own doing, not
> because of a change in MS Office.
>
> How about the fact that MS is a known vendor, one that is permitted to
> do anything they want to the system with their apps - so that would mean
> that anything signed by MS should be excluded by av vendors.
>

That is political

To exclude people with a small user base is unethical, only a small
amendment is needed to their program.

> > their refusal has no technical justification, because their software is
> > meant to identify malware, and possible malware. Not things that are
> > implemented a bit like malware but most certainly are not malware.
> > Technically, they can excempt VB's program.
>
> How can you blindly not see it after your statement above - "implemented
> a bit like malware but most certainly not malaware"?
>

because it's irrelevant what the code looks like to an
algorithm/computer program. There are other factors to consider. It's
not malware.

note- I recall reading in this thread that VB's code doesn't even use
an exploit, only what you call an "exploit path" - using a function
legitimately, which malware might exploit or use illegitimately.


> > So what is the reason? If not technical, then I think it must be
> > political, what other possibility is there?
>
> If you and everyone settles on this last question of yours "So what is
> the reason?" things will be a lot easier in here - the simple fact, and
> even you can't miss it, is that no one has any FACTUAL information on
> why they detect it. Until the 21 av vendors tell us, we just wont have
> any factual information as to why.
>
> --

their program is to detect malware, not what is certainly not malware.
+ this malfunction could harm VB.

what reason can you even imagine that'd put them in the right?

let me try to dream one up that'd put them in the right.. Maybe that
they're bogged down by thousands of people asking them to exclude their
program, and they havent' yet included an exception list in their
program, and their one programmer is on holiday at the moment, but
they're doing the best they can , and they apologise for all the
problems caused, and they're bending over backwards /doing all they can
, to fix the problem? They'd have to tell VB that. Even then I
wouldn't say they're in the right, i'd say their business isn't run
very well and they're a bit incompetent!

It's obvious that this malware company hasn't been that
reasonable/co-operative. VB only threatened legal action when they were
being uncooperative.

Re: Nasty propaganda by "security tool" providers

On 8 Aug 2006 11:48:16 +0200, Volker Birk wrote:



>It is very unlikely, that they're detecting them because of heuristics,
>and if so, then they have to be totally incompetent.

I agree to almost all you are saying. There is weighty evidence that
this is actually the case.

However, I also acknowledge that for something to be considered
proven, other possibilities must have been ruled out to a certain
degree.

My test proved that a re-compilation without functional changes led to
the code not being immediately detected.

On that basis I think it is fair to conclude (like you also do) that
IF these engines detect "by method" then they are doing a very lousy
job.

And IF they are doing some sophisticated heuristics tests on code "at
home" and then just distributing the signatures of malware detected
(as suggested by John Hyde) - which is of course a possibility which
cannot be ruled out - I think it is fair to conclude that they are
using a method which is more or less useless towards clever malware.

/B. Nice

Re: Nasty propaganda by "security tool" providers

Leythos wrote:
> If you and everyone settles on this last question of yours "So what is
> the reason?" things will be a lot easier in here - the simple fact, and
> even you can't miss it, is that no one has any FACTUAL information on
> why they detect it. Until the 21 av vendors tell us, we just wont have
> any factual information as to why.
>

Just because you lack the ability to make a logical deduction based on
evidence does not mean there is no factual information. Plenty of factual
information based on actual experiments have been given in this thread.
Plenty of sound deductions based on the results of those experiments have
also been given. The most logical conclusion from all of that has been
that the vendors are using signature detection to detect the specific
compilation of the code that VB has distributed. No heuristics that would
make the use of POC code justified, as you keep arguing. Just good old
basic signatures of the binary code.

That you refuse to accept this as the most plausible explanation and keep
dancing around saying "I won't believe it until the vendors tell me" is
just a logical fallacy being used to prolong this flamewar until you're
the only man left standing (and then you'll probably think you have won).
Because anyone who has half a brain knows the vendors are not going to
reveal exactly how they detect code, even just this one piece of code.
For starters, that would be giving too much of their algorithm away to
competitors. Also, they probably don't care enough about this thread to
invest the time to explain how they detect VB's code.

Even if a 1st year graduate student could deduce their algorithm, there
seems to be this social meme in place that prevents them from confirming
the results. These artificial walls to learning that they put it is why
only half my dissertation is on detection. It's just bloody difficult to
get the data you need to do research without spending a year or more just
negociating the NDA, how much can be published and how much can actually
go in the dissertation. I got sick of it and switched to a big fat juicy
intelligence community contract on vulnerability analysis. At least most
of the folks discovering vulnerabilities believe in disclosure.

Re: Nasty propaganda by "security tool" providers

Post removed (X-No-Archive: yes)

Re: Nasty propaganda by "security tool" providers

on 8/8/2006 2:48 AM Volker Birk said the following:
> B. Nice wrote:
>> Anyway, my test still showed that a slight change in the executable
>> (and remember I did not change any *functional* code, just a data
>> string) bypassed the engines.
>
> Really, this proofs one of those two:
>
> - either they're NOT testing using "general" detection heuristics, but
> with a special signature
>
> - or they're testing with "general" detection heuristics, and the
> implementations all are totally b0rken, and so equivalent to the
> testing with special signatures for detecting special code, because
> a very simple modification and recompile is enough to "hide"
>
> I'd say, the first, because the second implies the additional assumption
> of the very unlikely conincidence of detecting the original version at
> all (Occam's razor). Anyways, assuming the second case, we can say:

Ok, when you say "testing" above are you talking about on the desktop?
in other words, when you use their product on your system? If so then I
agree. The fact that your version was detected and B. Nice's version
was not, strongly suggests either a signature based test or heuristics
that randomly fail. (Obviously useless)

If you are talking about "testing" meaning the process that AV companies
use to scan code and create the signatures that will update the
commercial products, then I disagree. Here's why:

I think we all agree that AV companies use some process to analyze code
and create signature files. Those signatures are used to update the
commercial product. The "process", as far as as I've seen from this
thread, is a complete "Black Box". We know what comes out; signature
updates. And we know what goes in, code gleaned from somewhere. But
what happens in between? No idea.

I think that B. Nice is on the right track here. Since we can't "look
inside" the Black Box, the only thing that can be analyzed is the input.
he is going to follow up on the status of his code and see if it gets
detected later. That would indicate that his code is added to the
signature files.

If his version "ignored today, detected tomorrow" and there is no update
to the desktop detection engine, then I think you have proof of
signature based detection as opposed to broken heuristics on the desktop.

If B Nice's is never detected, you have a start toward understanding
what's happening in the black box. Why just a "start" and not proof?
Because you have to rule out every difference in the "inputs". Not just
the functionality of the code, but also how it was received by the AV
company, what it was accompanied by, etc. Once you establish that the
"world history" or the "life history" of the two versions are
substantially identical, then and only then can you make an educated
guess as to what's going on in the black box.

Volker,would you be willing to post a detailed description of how (to
the best of your knowledge) your code found it's way to the AV companies
that are now detecting that code? B Nice could then post a similar
"resume" for his version and a comparison could be made.

Regards,
Jh

Re: Nasty propaganda by "security tool" providers

on 8/8/2006 4:01 PM B. Nice said the following:
> On 8 Aug 2006 11:48:16 +0200, Volker Birk wrote:
>
>
>
>> It is very unlikely, that they're detecting them because of heuristics,
>> and if so, then they have to be totally incompetent.
>
> I agree to almost all you are saying. There is weighty evidence that
> this is actually the case.
>
> However, I also acknowledge that for something to be considered
> proven, other possibilities must have been ruled out to a certain
> degree.
>
> My test proved that a re-compilation without functional changes led to
> the code not being immediately detected.
>
> On that basis I think it is fair to conclude (like you also do) that
> IF these engines detect "by method" then they are doing a very lousy
> job.
>
> And IF they are doing some sophisticated heuristics tests on code "at
> home" and then just distributing the signatures of malware detected
> (as suggested by John Hyde) - which is of course a possibility which
> cannot be ruled out -

Absolutely, up to this point.

I think it is fair to conclude that they are
> using a method which is more or less useless towards clever malware.
>
> /B. Nice

Well, only when you have confident that both codes have been run through
their detection system. That's the world history or "life history" of
the software. Perhaps the expression CV would work, for "Curriculum Vitae"

Re: Nasty propaganda by "security tool" providers

on 8/8/2006 1:04 AM B. Nice said the following:
> On Mon, 07 Aug 2006 18:31:01 -0700, John Hyde
> wrote:
>
>> on 8/7/2006 10:46 AM B. Nice said the following:
>>> On Mon, 07 Aug 2006 16:44:14 GMT, Leythos wrote:
>>>
>>>> You just can't get your thoughts in one place. First you complain that
>>>> the code is detected as malware and it must be some grand conspiracy
>>>> against VB, then, when presented with why, and also see their response
>>>> in another thread from VB, you ignore it, then you ignore the basics of
>>>> what is malware and everything else.
>>> Lots of words without content.
>>>
>>>> Now you want to know why you should care that a product developed and
>>>> released that mimics some malware should not have been submitted to the
>>>> AV vendors to whitelist it?
>>> Because the onus of proof is not on me. It's on them!
>> I come to an intersection. I see that I have the right of way and that
>> the fellow coming the other way does not see me and is not going to
>> stop. The onus to stop is on him, if there is a crash it is his fault
>> so I proceed . . . All very true, but it's my sheet metal that's busted
>> (and maybe my wetware!)
>
> If you want to use an analogy like that - then please make sure it
> matches. What happens here is:
> The anti-virus companies are saying: "We drive like we want to, and we
> make the rules about what is right and what is wrong as we go along
> (1). So if you want to pass an intersection at a certain time, you
> better tell us beforehand".
>
> That does'nt really make sense, does it?
>
>> Yea AV vendors should get it right. But if you don't want them to hurt
>> you, you might want to toot your horn or flash your lights before they
>> run you down.
>
> Maybe you should just come up with a better anology ;-)

Criminy sakes, you want a decent analogy, you have to give me more time!

Actually, all I was trying to say is this: If I am aware that someone
is likely to do me harm, and I have the means to prevent that harm, I
probably should, regardless of who is right and who is wrong.

Practicality vs. "Rights" That's all.

JH

Re: Nasty propaganda by "security tool" providers

On Wed, 09 Aug 2006 13:31:17 -0700, John Hyde
wrote:



>>> I come to an intersection. I see that I have the right of way and that
>>> the fellow coming the other way does not see me and is not going to
>>> stop. The onus to stop is on him, if there is a crash it is his fault
>>> so I proceed . . . All very true, but it's my sheet metal that's busted
>>> (and maybe my wetware!)
>>
>> If you want to use an analogy like that - then please make sure it
>> matches. What happens here is:
>> The anti-virus companies are saying: "We drive like we want to, and we
>> make the rules about what is right and what is wrong as we go along
>> (1). So if you want to pass an intersection at a certain time, you
>> better tell us beforehand".
>>
>> That does'nt really make sense, does it?
>>
>>> Yea AV vendors should get it right. But if you don't want them to hurt
>>> you, you might want to toot your horn or flash your lights before they
>>> run you down.
>>
>> Maybe you should just come up with a better anology ;-)
>
>Criminy sakes, you want a decent analogy, you have to give me more time!
>
>Actually, all I was trying to say is this: If I am aware that someone
>is likely to do me harm, and I have the means to prevent that harm, I
>probably should, regardless of who is right and who is wrong.
>
>Practicality vs. "Rights" That's all.

I understood that. And my reply was accompanied by a smiley.

I still think my analogy was better than yours, though. ;-) <-smiley

Re: Nasty propaganda by "security tool" providers

on 8/8/2006 6:26 AM Leythos said the following:
> In article <0nfgd2t1ecv3cm3kns1t0pnbooj6q92trl@4ax.com>,
> b__nice@hotmail.com says...
>> On Tue, 08 Aug 2006 01:55:20 GMT, Leythos wrote:
>>
>>> I do not consider it malware, but I think it should properly be defined,
>>> as the av vendors have, as risk ware. It has the "Potential" to cause
>>> problems.
>> If that is to be taken literally then I know a lot of security
>> products (e.g. personal firewalls, anti-spyware and anti-virus
>> products) that should also be detected as risk ware :-)
>
> Yes, and I would be willing to bet that most of them are not detected
> because of reasons that have nothing to do with the name of the coder. I
> would guess it's due to the way they work,

I expect you're right so far

> they company that created
> them, the policy/standing in the community from the vendors, etc...
>

Isn't that the functional equivalent of "name of the coder?" It's not
the actual coder, it's the "boss" but the point remains that this one
would not be because of the code itself.

There's a difference here though. The following statements are similar,
but *not* identical: 1) Lavasoft code is *excluded* from my signatures
because of the "name of the coder." 2) Leythos's code is *included*
because of the "name of the coder."

> My guess would be that this still has nothing to do with VB personally,
> but, it appears we'll never know.
>

Re: Nasty propaganda by "security tool" providers

on 8/9/2006 2:19 PM B. Nice said the following:
> On Wed, 09 Aug 2006 13:31:17 -0700, John Hyde
> wrote:
>
>
>
>>>> I come to an intersection. I see that I have the right of way and that
>>>> the fellow coming the other way does not see me and is not going to
>>>> stop. The onus to stop is on him, if there is a crash it is his fault
>>>> so I proceed . . . All very true, but it's my sheet metal that's busted
>>>> (and maybe my wetware!)
>>> If you want to use an analogy like that - then please make sure it
>>> matches. What happens here is:
>>> The anti-virus companies are saying: "We drive like we want to, and we
>>> make the rules about what is right and what is wrong as we go along
>>> (1). So if you want to pass an intersection at a certain time, you
>>> better tell us beforehand".
>>>
>>> That does'nt really make sense, does it?
>>>
>>>> Yea AV vendors should get it right. But if you don't want them to hurt
>>>> you, you might want to toot your horn or flash your lights before they
>>>> run you down.
>>> Maybe you should just come up with a better anology ;-)
>> Criminy sakes, you want a decent analogy, you have to give me more time!
>>
>> Actually, all I was trying to say is this: If I am aware that someone
>> is likely to do me harm, and I have the means to prevent that harm, I
>> probably should, regardless of who is right and who is wrong.
>>
>> Practicality vs. "Rights" That's all.
>
> I understood that. And my reply was accompanied by a smiley.
>
> I still think my analogy was better than yours, though. ;-) <-smiley

Oh, I know. But there's others in the thread that are on the "rights"
high horse. Don't want to confuse nobody.

BTW, I rarely use the word "criminy" ;-) :-) :-0 :-}

Cheers

Re: Nasty propaganda by "security tool" providers

John Hyde wrote:
> > - either they're NOT testing using "general" detection heuristics, but
> > with a special signature
> > - or they're testing with "general" detection heuristics, and the
> > implementations all are totally b0rken, and so equivalent to the
> > testing with special signatures for detecting special code, because
> > a very simple modification and recompile is enough to "hide"
> > I'd say, the first, because the second implies the additional assumption
> > of the very unlikely conincidence of detecting the original version at
> > all (Occam's razor). Anyways, assuming the second case, we can say:
> Ok, when you say "testing" above are you talking about on the desktop?
> in other words, when you use their product on your system?

I'm assuming, they're using the same detection algorithms everywhere.
Why shouldn't they?

> If you are talking about "testing" meaning the process that AV companies
> use to scan code and create the signatures that will update the
> commercial products, then I disagree.

I'm not talking about how they're creating the signatures.

> Since we can't "look
> inside" the Black Box

Oh, we can. But it's too time consuming to do a reengineering, I think.

> Volker,would you be willing to post a detailed description of how (to
> the best of your knowledge) your code found it's way to the AV companies
> that are now detecting that code?

Avira wrote me, that they're detecting intentionally my tool. Then they
corrected. I think, I can stop speculating now.

Yours,
VB.
--
Ich würde schätzen, dass ca. 87% aller spontanen Schätzungen völlig für
den Arsch sind.

Ralph Angenendt in debate@ccc.de

Re: Nasty propaganda by "security tool" providers

Post removed (X-No-Archive: yes)

Re: Nasty propaganda by "security tool" providers

Post removed (X-No-Archive: yes)