Ouch. To make things even worse, the executable 'kaspersky_tcpip_fix.exe' to fix the problem is (1) not delivered over HTTPS and (2) not signed by Kaspersky (it is unsigned). So not only are you unable to receive an authenticated update to your antivirus database to fix the problem because your network is down, but you have no assurances that the offline tool provided to you to fix the problem actually came from Kaspersky.
Even without any specific tool, you can observe the "Properties" of the binaries from Explorer and see the signature of the files that are signed. And when the fix isn't signed, of course, nothing can be checked.
Actually windows does these checks automatically and replaces system files with signs of corruption/bad cert. You can force this check by using System File Checker tool in cmd:
sfc /scannow
I'm fairly good at distinguishing between what's a virus and what's not a virus. 99% of things are in the latter category care of fairly non-dubious web surfing habits.
The last time I got a virus was sometime back when Vista was the new kid on the block. I was searching high and low for a keygen for a really obscure program and I thought I'd finally found one.
Windows Defender was all up in my face like "don't run this, it's a virus!" and I was like "damnit Windows Defender, I want this key" so I ran it.
Lesson learned. Viruses don't infect PCs. People infect PCs.
Agreed, don't run AV at all. It is always fun to take something from metasploit, see that is detected by most AVs - change one or two strings that are obvious choices for signatures and watch detection rates drop to close to 0. Even behavioral or heuristic detection is absurd sometimes (IE is writing into the process memory of notepad? Probably fine). It is a really tough problem to solve, to be fair to AV vendors.
Dumb question: since modern CPUs and operating systems support virtual memory, shouldn't it be impossible for processes to access memory of other processes, since processes no longer have to deal with shared memory?
...unless you're alluding to security exploits that manage to subvert that mechanism.
I think the answer here is compatibility.
But we finally are in a turning point. OSX's new apps and windows metro apps are sandboxed.
But until running mostly apps becomes the norm in a desktop system beware that not having admin privileges doesn't not mean you can NOT: load programs at startup, read most of registry settings, passwords, read memory of/close programs of same sec level. A malware doesnt need admin rights to do evil.
Still I believe AV products are useless even for inexperienced users.
In the end, instead of using debug features, the files could be altered before starting a process. Programs on the same user account have no protection from each other, and windows isn't going to give you a false sense of security.
If you want apps to be blocked from touching each other, they need individual user accounts or equivalent. Operating systems for phones do this, but this kind of system hasn't been ported to a normal desktop.
I've checked, and current versions of MSE will detect this in time, but it's fast approaching the point where Windows will be running in a snapshotted VM with no network access.
Nah. It seems to stop even the sleaziest sites (not that I would know... hah). Jokes aside, one of the major reasons for introducing click to play was to keep those drive-by Java exploits from happening. Not much point if the website can disable click to play :)
It's odd that they don't have a database of "known good" files taken from a clean install of each OS they support that they test against before releasing an update.
Probably because the risk low, and it would require a good deal of work to maintain such a database. You'd have to keep it updated after every patch, a system may get a different version of the patch based on what is installed on the OS etc.
Not much more work than any decent administrator has to do if he controls the updates to his own network. Note that even if you don't have in the database "all files ever" every entry lessens your chances of false positives. Actually I can't imagine that they can do their business while not having such databases.
This has happened multiple times to multiple vendors – so it's not clear that the risk is actually low and the resulting database is also useful for catching malware which attempts to replace system files.
As for different versions, it doesn't seem like this should be a significant challenge to an organization which already has to maintain a test OS farm. The process of updating after a release is mostly automatic and if this acted solely as a guard against false positives, the consequences of missing a patch permutation are the current status quo.
Having a version for every patch would be difficult, but the base level of {XP,Vista,7,8}{32-bit,64-bit}{RTM,SP1,SP2,...} should safeguard the majority of your users.
I'd guess that the majority of users have automatic Windows Update turned on, since that's the default setting and what Microsoft recommends. The only people who have the base level of Microsoft operating systems (or don't apply patches between service packs) are the ones who are so clueless about security that they're not likely to have gone out of their way to install a third-party anti-virus tool.
If they assume that most users apply all "critical" Windows updates in the order that they're pushed, the anti-virus vendor could snapshot their reference PCs before each update and record the hashes of all Windows files. It's possible to determine which updates have already been installed on a machine (there's an option for this in the control panel, and the information is probably stored in the registry).
And it's almost trivial to add new entries after each update. I can't imagine they don't have it, but I can imagine that they didn't use it this time ("check takes too much time, let's just ship it").
Still not quite as bad as when McAfee DAT 5958 misidentified svchost.exe (the parent process for all DLL-based services) on XP as malicious (and succesfully deleted it!) ... As you can imagine, this didn't go over well. I remember our shop being very glad we were on a delayed deployment for their DATs.
A very similar thing happened at a company I worked at, where a consulting company that I couldn't stand and recommended against had just replaced a few departments worth of workstations with XP and about 2 weeks later they were all stuck in reboot loops because the AV was flagging some system file...
You'd think that McAfee developers would be smart enough to hard-code a list of essential system files into their AV such that it will at least prompt you to get an install disk so it can replace them instead of just deleting them if it suspects they're infected.
For bonus points, make the software realize that even if the file on the CD looks infected, it isn't actually infected, so make that file's SHA-256 sum a 'known good' profile. (If the file on the actual install CD really is infected, that falls into the category of "Problems The AV Can't Solve". At that point, the OS itself is controlled by Malign Forces Working To Destroy You and the game is over.)
For extra special bonus points, code compressed copies of those essential files into the AV software itself, so they can be replaced on the fly without prompting anyone. They can be updated along with the malware profile data, if they ever need to be.
1. Most consumer-grade machines don't come with install disks.
2. You can't put compressed copies of essential files into the AV software itself for a couple for a couple of reasons:
- Microsoft will sue you for distributing their intellectual property without permission (and is not likely to grant such permission, since they can't control the quality of the third-party software).
- These files are not static: they could have been modified by any Windows update, and might be dependent on other updated files.
Keeping track of the hashes of "known good" files might work, but you'd have to account for files that were modified by Microsoft patches.
Wouldn't it be good enough to assume that any file with a valid Microsoft signature is safe? If Microsoft's signing system is compromised (which IIRC sort of happened once when a key issued for signing network credentials could also sign binaries, possibly used in nation-state malware?), you'll have bigger issues than antivirus software deleting essential system files.
For those that are curious, you can use a tool distributed by Microsoft called Sigcheck to display signature information (http://technet.microsoft.com/en-us/sysinternals/bb897441.asp...).