Is security software becoming a security risk?

Security researchers believe that file-parsing bugs in security software could become a big problem

A funny quote:

Don't buy eEye digital software

 

This is really getting ridiculous, now we have zero day bugs in security software, waiting to be exploited. I wonder if HIPS will be able to protect you from this stuff.

 

I wonder which application will be able to protect us from 0-day exploits on HIPS
We'll have really difficult times ahead:
- Insecure designs (Windows).
- Sloppy coding.
- Complex file formats which might carry executable code (data isn't data anymore).
- Deeper integration between the Web (Web 2.0/3.0) and the desktop.
- Lots of gadgets with Internet access.
- Ignorant users.
- Money-driven malware industry (an arms race between blackhats and security vendors)
I will only accept TEXT files

 

As for HIPS and other forms of heuristic detection/prevention, I'm reminded of an argument in one of the Pink Panther films.

"That's so obvious, it's gotta be a trap."

"Don't be ridiculous, it's so obvious they'll want us to think that and therefore it can't be a trap."

 

HIPS is security software itself isn't it? So it can be exploited same as any security software.

I don't know why you think HIPS is so special it is immune

 

Sure not, they might haven even more bugs n flaws.

 

That's why I use Rollback Intrusion Prevention System (R.I.P.S.), where security softwares have a second place, because they can't be trusted. I try to think years ahead.

 

HIPS can be at least a partial solution, but that depends on how the problem gets approached. Conventional HIPS can provide a lot of protection, IF the HIPS, your other security apps, and your system are all configured to support an effective security policy. Just adding HIPS to an existing security-ware collection isn't going to fix anything.

There's always been bugs in security software. Norton's been exploited more than once, as have others. Any software that's in common usage is targeted. Security software is no different. The internet is a different reality than it used to be. There are no truly safe sites, filetypes, or formats one can open or visit without some amount of risk. Security apps are also evolving. What isn't evolving enough is how security is approached. It is no longer possible to identify every threat or bit of malicious code in real time by analyzing it with a piece of software, aka the AV. People need to get past the idea of allowing code to run whenever an AV doesn't find a problem with it, hoping that the rest of their security apps can recognize, block, isolate, etc any and all malicious activity performed by the code the user allowed in the first place. It's that default-permit policy of both AVs and users that's the problem.
Rick

 

Well... "Instead of blocking particular attack techniques, certain kinds of HIPS focuses on attack objectives such as taking control of a PC, stealing data, breaking system integrity etc. By this approach, certain kinds of HIPS prevents all attacks that involve damage, e.g. malicious software,viruses, trojans, spyware, software vulnerabilities (buffer overflow, privilege escalation, etc.), mis-configuration and unknown attacks based on "zero-days" vectors, e.g. GeSWall has been stopping Windows Metafile exploits."

Thats what certain kinds of HIPS are supposed to do. If they can't be shutdown, sensors broken or made stagnant then I think We'll be Ok. Plus what Eric Albert said helps. Of course I wouldn't know all the technicalities.

Is that "Rest In Peace Security-troubles" ?
I like that. Still have to prevent leaks and then use the types of apps. you do if anything goes wrong.

 

RoolBack software might have similar bugs as security software. The only thing is that malware writers will not care to exploit such bugs as input will be more will less output for them duye to a small no of total users. Same is true of non- mainstream security software n HIPS. So don,t think RIP better than HIPS in this regard.

 

You are right. Each software is safe to use, until it becomes a target of the bad guys. All Operating Systems and softwares have that in common.

I use FDISR, because it's the most brilliant and reliable ISR-software, ever developped and even the most recent ISR-softwares are toys compared with the much older FDISR.
You don't learn softwares, like FDISR, by talking/reading about it or by using it during a trial period of 15 days, you have to use FDISR for a long period and learn how to use it efficiently. If I compare my first usage of FDISR with my actual usage of FDISR alot has been changed between March 2006 and today.

The first thing I did was separating my system from my data, because I knew in advance that my data would be a constant obstacle for what I was planning to do with my system partition. So I stored all my precious data without any exception on a second harddisk and my system partition was finally data-free.

Then I created an off-line snapshot without internet connection and that's where I work and do my hobbies.
Then I created an on-line snapshot with internet connection and that's where I go on-line and do all my experiments.
Then I frooze my on-line snapshot and installed only security softwares to stop the execution of malware as much as possible.
Then I finally found a solution to protect my second 'data' harddisk : lock it, which I do when I boot in my on-line snapshot.

Although my on-line snapshot is protected by 4 security softwares, I don't trust them. So I asked myself how serious it would be if a malware bypasses my security :
1. A very destructive malware would destroy my system partition and all snapshots, but not my data partition.
That's not a disaster, that's only irritating and can be fixed in 9 minuts.
Not even ONE scanner can scan my computer in 9 minuts, it needs 20-30 minuts.

2. Most malware aren't destructive, they want something from me : personal data, money, mislead me, ... whatever.
That's not a disaster, because I isolate these malware in my system partition and they don't have access to my locked data partition.
So what are these malware going to do in my system partition ? There is nothing but Windows and Applications.
They go crazy, because there is no water, no food, no furniture to do their evil job.
A simple boot-to-restore and all these malware are dead in less than 2 minuts, including the damage they caused.

Simple ISR-softwares, like DeepFreeze, Returnil, ... can do this also, but nothing more than that. FDISR is different, because FDISR is brilliant.
So I use FDISR also for other major tasks, like cleaning jobs :
- registry cleaning
- history cleaning
- any cleaning of intermediate superfluous objects that were created by any software, while it was doing its job.
- uninstalling softwares, better than any existing uninstaller software

FDISR cleans all that in one single hit and very safely, no human mistakes and COMPLETE.
All my snapshots have still a volume = volume of installation : clean registry, clean Windows folders and software folders. Other users have a bunch of softwares to accomplish this and are still not sure that everything is cleaned, because cleaning tools don't know EVERY software.

FDISR is also able to store ANY situation of my system partition, which is ideal for tests and experiments.
FDISR is also my SECOND backup/restore.

Is there something safer than FDISR ? Yes, Image Backup (ShadowProtect).
FDISR gets all the punches, because it is constantly on-line and confronted with malware, new softwares, ...

Image Backup has no such problems and needs only 3 things :
- a Recovery CD
- an external harddisk
- an image
What can go wrong with these 3 simple things, which are off-line all the time ? NOTHING.

Malware writers aren't interested in FDISR, the software hasn't users enough and FDISR is terminated and will disappear somewhere in the future, because HDS isn't smart enough, that's why their RollbackRx had so many troubles.

BTW R.I.P.S. doesn't exist, it's my sense of humor, that created this, because it also means :

I don't care about all these abbreviations, I don't work with software names,
I work with philosophies, theories, software functions, features, combinations and my own ideas, based on analytical and logical thinking.
Nobody has to do like me or even believe me, it's my computer and I'm just telling Wilders how I do it.
I'm not an expert in anything, so don't even trust me, it's not even my job, just a hobby.

But the results are there and my computer is a paradise, which is of course also boring. That's why I use my frozen on-line 'garbage' snapshot to make it more exciting.

 

Yes I know, was just making a joke, however, a tool like CMG might be able to prevent buffer overflows in security tools, not?

 

Who will prevent buffer overflows in CMG?

 

Well, I would like to know if it´s as easy to exploit HIPS as it is to exploit scanners.

 

Plague in (security) software drivers

 

No, it's not as easy. Scanners can be exploited by taking advantage of the way they parse or analyze a file. Conventional HIPS doesn't analyze files. The parsing code used by scanners isn't present in HIPS. It checks the signature and location of a process against those stored in its ruleset to verify that it is what it's supposed to be.

The basic principles behind HIPS would make it much harder to exploit without user interaction than an AV. Conventional HIPS blocks processes that aren't specifically allowed. AVs block what is known to be malicious. The big difference is in how the unknown is handled. An AV would allow the unknown exploit code to run while HIPS blocks the unknown, or prompts the user.

It's difficult to be specific without an actual exploit. My best guess is that the HIPS would intercept the initial launch of the exploit code, putting the decision in the users hands. If the circumstances are sufficient to coerce a user into allowing that code to run, then the HIPS (and anything else) could be exploited. With a strong ruleset and a user that will say "NO", conventional HIPS would be very difficult to exploit.
Rick

 

HIPS doesn't parse/unpack/analyze files, but they place hooks in the SSDT and other places. I can image a situation when some file initiates execution sending malformed parameters causing the HIPS to crash/terminate.

 

Are you referring to interaction with a legitimate file or a malicious file designed to have that effect on HIPS software? The first would be a bug that needs fixing. The second would indicate that the system has already been compromised, either before the HIPS was installed, or the user allowed the activity responsible for that file.
Rick

 

I'm referring to this Since I don't know the inner workings of Windows, I can only speculate that there's a time between the double-clicking of a file and a HIPS prompt asking what to do with it (allow/block/create rule).
Free feel to correct me if I'm wrong.
Obviously, allowing execution means that you've lost half the game at least (you'll have to rely on your HIPS features from now)

 

Naturally the bugs cannot be fixed in otherwise perfectly functioning older versions necessitating you send them $$$ for an upgrade. Sometimes I think that the software makers themselves let these vulnerabilities "accidently" slip out when sales are slow for the latest version.

 

I don't see how such a file could potentially exploit HIPS unless the user chose to run it. If the file inquestion is an executable, it will need permission to run, assuming of course that the user doesn't have any "allow anything" rules in place for whatever its parent process would be. I can't comment regarding other HIPS software, but with SSM free, under "advanced properties" for application rules, there's an option that "allows this process to execute any unclassified program". When enabled, it allows that process to launch any other process that isn't specifically blocked, including the unknown. A very dangerous option to use, but I can easily imagine some users choosing that option to get rid of the prompts.

If it's an altered system or application file such as a DLL, malicious code has already been allowed to run and the system is already at least partially exploited.

In the time period you describe, from clicking on something until you see a prompt, there's a lot of activity. On my 98 box, I started up Sysinternals Filemon and monitored the activity of SSM when I clicked on a link to an executable for which I had no rule. There were 230 separate events directly related to SSM free in that 2 second time frame. HIPS basically inserts itself into the command paths, intercepts the commands and processes them based on its rules. Commands for permitted activities are sent to their original destination. When the activity is not permitted, such as launching an unknown executable, the process that would be used to launch it is denied access.

There are other scenarios in which exploit code could be run. It would depend greatly on the rules in place and what form the exploit takes. If the HIPS rules don't limit the activities of Windows Scripting Host, it could potentially be used. In the "Other anti-malware software" forum, there'a a thread about a system shutdown simulator. A method like that could be used to shut down the security apps, then perform the malicious activity if it could be done without the user having to allow it first. I have seen at least one legitimate app, badly coded, that interfered with system shutdown in almost the exact same manner. If it's running and the user tries to reboot, the shutdown process fails when it reaches that app, with some security apps shutting down before it does. Except for incidents like these, IMO it would be very difficult to exploit HIPS without some interaction from the user. The vendors have worked hard to make them difficult to kill, thanks largely to users falling for social engineering tricks that make the methods possible in the first place.

Rick

 

There's lots of legitimate bugs as well. In some cases though, I'm very inclined to agree. With at least one corporation that makes operating systems, that's a common excuse used (and misused) to further a policy of planned obsolescense.
Rick

 

Security software have always been a security risk.
Scanners with false positives are risky for average users.
HIPS with multiple choice questions are risky for average users.
I couldn't try Behaviour blockers yet, but I don't expect much from them either.
The more complicated security softwares are, the more bugs they can have.

 

And therein lies the purpose for duplicating/imaging apps. HIPS have made tremendous strides as have sandboxes, virtualizers, and at least one trustworthy ISR, there will never be one single reliable automated security app to safeguard Windows because that would end all other vendors and close up most all the global labs who been tasked with developing their little part of stop-gap measure products.

XP security vendors have proven the most innovative of all as well as creative contributors to Windows swiss-cheese systems and they done a remarkable service to us the end users as well as our enterprise counterparts who seek to reap the highest measure of protections from those inventions.