Slashdot Mirror
How Good is Antivirus Software at Protecting Itself? (tomsguide.com)
An anonymous reader writes: Earlier this week, AV-TEST evaluated 19 security suites and found that only three of them seemed to be well protected from savvy potential hackers. First, some context about the tests: The first test measured how well each program uses address space layout randomization (ASLR) and data execution prevention (DEP). Briefly, ASLR randomizes a computer's memory allocation, making it harder for an attacker to target a particular process in a program; DEP is a Windows protocol that designates some memory as non-executable space (other operating systems do this under different names), making it harder (or impossible) for unauthorized programs to run in that space. The second test measured whether the AV programs digitally signed their software-update files. Signing is a way of determining a file's origin and authenticity; unsigned files could be more easily substituted with malicious ones. The final test was the simplest, and determined whether an AV manufacturers delivered its software updates via the encrypted HTTPS web protocol. Lack of encryption makes it easy for an attacker to stage a man-in-the-middle attack by intercepting the data transmission, altering the data and then sending the data back on its way. Of the 19 programs tested, only three succeeded on all counts: Bitdefender Internet Security 2017, ESET Internet Security 10 and Kaspersky Internet Security 17.0. It's difficult to rank the rest of the programs, as each one succeeded and failed to varying degrees.
I use Windows Defender Antivirus. It's helping to protect my Win 10 pc even now.
Forcing DEP on is trivial. No major program for Windows fails with DEP enabled. What "advanced development practices" are you imagining?
The one that supports viruses.
Came here to say this same thing.
None of those things matter at all if you've already got a process running on the system and are looking for ways to shut down the AV.
That's (a small) part of why I don't employ them.
Next question?
True Dat!
I tried installing Skype for Business but no matter what I try it won't run.
"A person is smart. People are dumb, panicky dangerous animals and you know it." - K
Except it doesn't protect you from Microsoft viruses
It does matter... if every windows user switched to {pick an operating system} overnight it wouldn't be long before it would be a cat and mouse game of who can find an exploit first the people patching or the people writing malicious software. It doesn't matter how secure you think it is when there is money to be made and the os with the most installs has it people will find a way. Android is quickly turning into swiss cheese just like windows.
That's strange. That is the solution that is in the box for the foreseable future.
Is updated the same way the rest of the OS is updated... Say what you want about forced updates and restarts, but if you do not trust the update mechanism (signeage of files + Method of delivery) of the OS itself, no ammount of 3rd party AV will do you any good.
I wonder how it stacks up on ASLR and DEP... but anyhow, I usae a Mac with BootCamp, so no big dealio
*** Suerte a todos y Feliz dia!
Any operating systems written in Ada? (Of course, all the libraries and applications would have to be written in B&D languages, too.)
"I don't know, therefore Aliens" Wafflebox1
I might intercept HTTP requests to install signed patch 1.4.8 and return signed patch 1.1.1 (a downgrade to a version with a known vulnerability) instead of the requested file.
This sounds insanely stupid.
Most patch and definition files include dates and/or versions, which are part of the signed files. You cannot simply send a version 1.1 patch rebadged as 1.4 to a 1.2 client and expect it to install. Changing the version invalidates the signature.
Long story short, I think there's still a role for HTTPS even when you're checking for patch signatures.
There is no discernible benefit unless the developer/vendor is a total moron. Digital signatures ensure the contents have no been tampered with---and that is from the date the files are signed until the present, not just while they are being transferred.
Maybe they get some bonus points if they use HTTPS, but they straight up fail if they do not digitally sign all updates.
The original article was written by some numbskull who obviously never worked a day in information security.
---
According to the latest ruleset, this post should be modded as Vorpal Flamebait +5.
Question: Why does Microsoft keep rewriting their software and perpetually adding vulnerabilities instead of perfecting code?
Answer: Money.
Solution: Don't use Microsoft products.
Anons need not reply. Questions end with a question mark.
There is no perfect anti-virus program. The only thing that comes close is using a sandbox and you religiously do all of your online stuff in that sandbox. You preferably use a sandbox with a golden recovery point or use a program like Deep Freeze which resets your session upon reboot or uncontrolled power down. I prefer just using Virtualbox and an OS that run within it. You can recover your golden setpoint within 10 seconds (no joke). This protection scheme alone will not protect against keyloggers though. :)
HTTPS will keep a client from pulling updates from the wrong server.
Assuming of course that your HTTPS client properly validates the server's HTTPS certificate. This includes not only checking that the subject name of the certificate matches the DNS name you are connecting to, but also needs to include validating the cryptographic chain up to a well known trusted root Certificate Authority, and examining Certificate Revocation Lists to ensure that the CRL is current and doesn't contain a record indicating that the certificate has been revoked. Many systems do not fully ensure a valid HTTPS session, in specific many do not do CRL checking as it takes time.
While ensuring that the update has been properly signed reduces the likelihood that HTTPS has been unknowingly compromised, you still have to make sure that the signature process of the signed update is cryptographically valid as well.
If you are already compromised, all bets are off as you cannot be assured that your list of trusted CAs (which are the base of HTTPS security), whatever you are basing the signing of your updates on, and the very code that is validating everything is still doing its job.
>> many do not do CRL checking
True - that's an ongoing blind spot in the security community. Those of us who work with long-lived and signed "web authentication tokens" are currently dealing with similar issues: once they are out in the wild, a lot of "performance-optimized" (highly scalable due to no central check-in/bottleneck) servers will continue to accept tokens that should have been revoked hours or days ago. (The tokens are accepted because they were signed by a trusted source and no check for revocation is done.)
... but rating them on their use of ASLR is worse than the problem:
https://forums.grsecurity.net/...
Find someone who's done some real security analysis, don't see if they bought the snake oil.
For more information, click on This Google Doc that explains how.
-- Tigger warning: This post may contain tiggers! --
Craft an HTML file to exploit a javascript vulnerability that will make your perfectly valid browser executable execute arbitrary code, perhaps?
No change to executable files = virus.
I knew BitDefender were on to something good.
They offer a free version and even the full version has near-negligible impact on performance.
And it was one of only three that passed all tests.
Kriston
HTTPS will keep a client from pulling updates from the wrong server.
No it doesn't. You put too much faith in HTTPS.
The default HTTPS providers on most operating systems only verify that the provided origin server certificate chain has been signed by a known trusted root and that the valid-from and valid-to dates are current. CRL checks are off by default because they require extra network traffic (which generally occurs over HTTP - go figure).
The above behaviours are required for man-in-the-middle re-encrypting proxy appliances, like those from Blue Coat Systems, Inc., to work correctly in corporate environments.
Any additional checks are up to individual applications, such as confirming that the trusted root is one that you expected (not BCSI), or that the origin certificate thumbprint is what you expected, etc.
Any of them. Far too much security software is secure by executive fiat rather than practice. AV software is full of vulns due to the ton of file formats it has to be able to parse, firewalls have hardcoded default passwords and backdoors, IDSes have buffer overflows, etc. It is the way of things.