lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
From: bkfsec at sdf.lonestar.org (bkfsec)
Subject: Multiple AV Vendors ignoring tar.gz archives

James Eaton-Lee wrote:

>First off, thanks for the e-mail! It was well argued, and you obviously
>took a lot of time on it; this is much appreciated. With that, let the
>reply begin..
>  
>
Thanks.  Nah - it took me like 5 minutes to write.  Not a lot of time at 
all.  :)

>
>but the devil is in the detail, especially in this particular case; I've
>read through the documentation (which I happen to have in my office)
>which comes with three extremely common corporate antivirus products
>this afternoon (Norton, CA InnoculateIT, and Sophos SBE), and although
>admittedly I've been busy and I *haven't* read through *every* piece of
>paper and manual which comes with any of them (and I haven't read any of
>the documentation on the vendors websites), I haven't found a single
>paragraph concerning use in this particular manner. 
>  
>
Well, that should be your first hint.  If that type of functionality 
isn't discussed, then what grounds does a person have to think that it 
would be supported? 

Don't get me wrong, it would be nice if the documentation included a 
section that had alternate products that served other functionality, but 
it's not necessary.

>If a particular piece of antivirus software isn't designed for a
>specific role, then vendors need to make this obvious in order that they
>can avoid, as you put it, "misusing the product". Failure to do so is
>the vendor's problem, not the user's. (No, it's not common sense.)
>  
>
No, the distinction between a gateway AV and a desktop AV isn't common 
sense.  I, myself, stumbled on that once a few years ago.  Thankfully, I 
noticed before any damage was done.

Do you know why I stumbled on it?  I didn't do the right research.  
Within 10 seconds (the time it took to do a search on google) I was in 
the process of putting in a purchase req. for a more appropriate package.

I know how easy it is to screw that up.  But, it was my fault - not the 
AV company's fault.  No one likes to put corporate feet to the fire more 
than me, but I just can't do it this time.  There's a point where people 
have to take responsibility for their own actions.  I realize that that 
is counter to corporate culture, but then I've never had much respect 
for corporate culture in the first place.

>Many vendors *expect* their customers to write their own solutions,
>scripts, and hacks based around their software packages - Microsoft have
>one scripting language (vbs) which is really only used to hack
>windows(!). If companies don't extend the same flexibility to their
>product usage as others, they need to make thus abundantly clear.
>  
>
Don't get me wrong at all.  I'm pro-software modification and hacking.  
Misuse of products can lead to very useful results. 

However, don't get pissed off at the company if your misuse of their 
product results in bad things. 


>
>This *IS* a lack of understanding on the part
>of the user, but they are not the expert on viruses, antivirus vendors
>are. 
>
>  
>
Yes, and we're not going to be changing attitudes.  If users knew the 
real threats out there, they'd never plug into the internet.  They'd be 
scared into paralysis.  Therefore, they're not going to listen or 
understand these things because it's not productive for them.

But, I fail to see how this translates to the problem at hand.  The 
average user doesn't understand viruses and AV.  They won't understand 
it.  If the desktop-based AV they buy doesn't detect the malware 
uncompressed, then not detecting it compressed is going to have 0 added 
value for that average user.


>>However, this all comes down to one point: If the AV can detect the 
>>malware uncompressed, but can't detect it compressed, then there's no 
>>problem.  The malware has to be decompressed to be dangerous.  That was 
>>Nick's point and it's 100% correct. 
>>    
>>
>
>Yes and no - if the AV can detect the malware uncompressed, there's less
>of an issue. But the malware really shouldn't make it onto the network
>in the first place - as I pointed out, clients are fallable, servers are
>less so, and therefore security measures should be kept as
>server-orientated as possible if businesses are to have maximum
>security. I think I'm taking the braces and belt line here. 
>  
>
No - you really need a multi-layer solution.  A good security solution 
is neither server-centric nor desktop-centric, it's system-wide.  The 
components depend on each other.  If the gateway AV misses it, I want to 
know that my desktop solution will catch it.  It's best if it never 
makes it onto the network, but if it does, in this case, there won't be 
a problem.

Besides, I don't recall ever saying that gateway AV was a bad thing and 
we've already gone over that this functionality is important for a 
gateway AV system.


>  
>
>>IF your AV software is functioning normally.
>>IF your AV software has proper real-time detection capabilities.
>>IF your AV is properly setup and scans the programs you run at the time 
>>they're read from the HD.
>>IF your AV will detect the malware uncompressed.
>>
>>Then, as should be true for the vast majority of situations out there, 
>>the malware will be caught as it's being extracted from the archive.  
>>Or, barring detection on writes, when it's being executed in the first 
>>place.
>>    
>>
>
>If, If, If. This is a chain argument, and as soon as you break one link
>in a chain argument, the conclusion fails to be valid! I'd far rather
>have a situation where If X then Z, or if Y then Z. Failure of client
>antivirus software should not leave clients open to viruses - without
>compression support (and lots of other things), I believe that under
>certain circumstances, it does.
>  
>
The "ifs" I used above are the default settings that AV systems are 
installed with.  They're set to be on by default.  If any of these "ifs" 
are not met, you won't detect the virus regardless of whether the AV can 
get past the compression or not.


>This is the same argument as before; I know that SMEs shouldn't do this,
>and you know it too - but the fact is that they do. Security
>professionals and vendors need to consider *all* eventualities, and not
>rely on *one* method of doing everything based on the idea that if
>anyone is doing any of this differently, they're wrong and they'll pay
>the price. The job of a security professional isn't to consign companies
>to security hell for political reasons - it's to make that company more
>secure, whether or not they like the way in which they're doing it.
>  
>
Whoa there.  Predicting all eventualities is impossible.  It's not just 
improbable, it's impossible.

We're not talking about a difference in philosophy here.  We're talking 
about a corporation choosing not to deploy a security software that it 
knows it needs because *it* is relying on one method (gateway scanning) 
to carry out its security needs.

And no security product can solve an SMEs problems if they refuse to 
install it.


>>In what situation can you imagine where a person blindly forwards 
>>compressed (unscanned) content to a business partner?
>>    
>>
>
>Virtually every situation. People are stressed, lazy, and ignorant, and
>they forward e-mails to other people *all the time*. 
>
Yes, but how many standard users do you know of who are forwarding unix 
tarballs of financial documents blindly to people on a windows client?  
gzip/bzip2 aren't exactly common windows-based compression utilities.


>But this isn't the
>point - stupidity shouldn't be what causes network security to fall down
>- network security should be *STUPIDITY INDEPENDENT*. This axiom
>capitalised in order to promote my new line of 'Stupidity Independent'
>network appliances and software. (Ok, that was less than funny, but this
>is a long and serious e-mail and it needs punctuating in what has
>otherwise been a rather pompous and arrogant thread in the mailing
>list).
>
>As an example of this point, consider this: Would you make every user on
>your network a Domain Administrator based on the logic that if they
>break anything it's due to stupidity and therefore their problem and not
>yours? Like it or not, this is basically the same logic at work.
>  
>
No, I wouldn't make all users Domain Administrators expressly because 
people are stupid and do stupid things.  People are a part of the 
problem and they are always involved.  There is no such thing as 
stupid-proof technology.

>>This is the wrong way to think about it.
>>
>>The goal of antivirus is, plainly said, to detect and block malware from 
>>running.
>>
>>Preventing business loss is a side-effect of this.  There are many 
>>reasons for keeping malware off of systems, business benefit is only one 
>>of them.
>>    
>>
>
>Companies don't buy software because it's what the IT industry likes,
>beacuse it's commonly deployed, or because it looks nice (usually). The
>fundamental reason for IT upgrades in businesses is because it causes
>the business to run more efficiently. 
>  
>
No No No.

You didn't get my point.  You're thinking about the world from a 
business-centric standpoint.  I'm thinking about the world from a 
reality-centric standpoint.

AV is a tool.  AV's goal is to contain viruses.  It's not to "enhance 
business efficiency".  That is the reason that businesses buy AV, but it 
is not the reason for AVs existance.  AV isn't a bag of magic beans 
which magically enhance business efficiency.  I know you know this, but 
I'm illustrating a point.

If something is wrong with a tool, then that tool has to be fixed.  
That's all there really is to it. 

Business efficiency is not the express goal of AV, and as such, it is 
irrelivent to this conversation.

>My point is, technology is *means*, not an *end*. Following this logic,
>antivirus software is deployed because it provides a palpable benefit,
>and for this reason, the primary goal of antivirus software *is* to
>provide business continuity in the same way that a cleaner mops the
>floors in order to provide business continuity. They simply go about
>their tasks (the means to the end) in a different way in order to do so.
>  
>
And I mop my floor at home to keep it clean.  I keep AV running on my 
computer at home in order to keep people from getting at some of my 
personal information and to save me time so that I don't have to rebuild 
my system.

My motivations are different than a business's.  But, motivation is 
irrelivent here. 

The mop exists and is designed to clean floors.  Any benefits derived as 
a result of that are side-effects.

>  
>
>>A hammer is a hammer.  Its sole intent is to bash things (and, possibly, 
>>pry them out).  It can be used to build houses, but it is not a 
>>house-builder.
>>    
>>
>
>That's a bad example; you've taken one thing which accomplishes one
>thing (antivirus software) and compared it to something which can be
>used for a wide variety of tasks.
>  
>
It's a great example.  AV is a tool.  AV software doesn't secure 
networks just like hammers don't build houses.  People build houses 
using hammers and other tools.  Likewise, people secure networks using 
AV and other tools.

It's a loose analogy, but it's a great one.

>
>Thankyou for your intelligent, considered e-mail! Fundamentally, I think we have the same ideas at work, but with some different experiences; 
>  
>
Likewise, and agreed.  :)

          -Barry



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ