At the risk of sounding all pompous and arrogant...

How do you know your security product isn't rubbish?

All over the place here on Wilders, I see people talking about the use of proprietary software produced by tiny little companies I've never heard of. Toolwiz Timefreeze, Privatefirewall, EXE Radar Pro... And on the list goes.

These are all additional layers of "security" stuff - drivers, services, etc. - that run on top of the existing Windows system. Depending on how well coded they are, they could be helping the situation; or they could be adding exploitable bugs, or bugs that could break your system and cause data loss, or bugs that could result in loss of privacy, or a dozen other nasty sorts of bugs.

How many of these products actually undergo extensive testing by third parties? How many of them are tested - against malware, against fuzzing, and in situations where their drivers might crash something? How many of them get their code bases independently reviewed?

In short: what makes you sure can trust any of these products as much as you can trust Windows itself?

[Disclaimer: I have never worked in Software QA.]

 

Everything in life is based on trust. We trust until something proves otherwise. We trust others' opinions when we can't test/analyze for ourselves.

I'm not sure I would necessarily have more "trust" in Windows than in any other product that I choose to use. For example, you ask:

Consider the vulnerability that the Conficker worm exploited. From Microsoft's Michael Howard:

MS08-067 and the SDL
http://blogs.msdn.com/sdl/archive/2008/10/22/ms08-067.aspx

Nothing can be guaranteed to be totally reliable, as has been demonstrated many times.

Speaking for myself: I make my decisions about security software based on the best conclusions I can determine from the product's reputation and my own testing, when possible. The rest is trust.

regards,

-rich

 

Just my opinion. I think that most of the posters at Wilder's are pro's or at least know their stuff, so if I see a number of posters using a certain product I feel pretty confident at least they have scrutinized it pretty well, and if they're still using it then it's a safe effective app. An example of an app these folks turned me on to was FDISR, the best $69 I ever spent.

 

The only way to determine that is to test it yourself and decide if you like it and if it likes your system. I personally believe there is not an Internet Security Suite or Disk Imaging Software that could not use some serious improvement. At least I am seeing some of the security suites are getting some more minor updates year to year instead of reinventing the thing every year like thy had been doing. Why not keep the same interface for 2 or 3 years and make some tweaks? It was getting so that by the time they were getting the bugs worked out they were dumping next year's new suite on you and it was buggy all over again.

 

Make your self a clean image-collect some malware samples, as much as possiable and test away.If you dont have no samples there is plenty on the www and if you no where to look there easy to find.

 

Far from being ostentatious.

I agree with your orginal Post #1 consummately, thus is why I am an firm believer of preserving the virginity of
the Microsoft Windows Operating System as much as possible by installing only Microsoft Software and Security.

There are an few third party softwares, however, those third party softwares have proven to me over time, reviews,
personal testing, and third party testing results, to be worthy of being installed in the magical environment of the
Microsoft Windows Operating System, in defiance to the fact, that;

The Microsoft Windows Operating System is designed to be "open" to third party software configurations.

All software that is Digitally Signed insures that the code has not been tampered with and is compatable with the
Microsoft Windows Operating System the software is designed and advertised for.


HKEY1952

 

PrivateFirewall for one is a product of Privacyware and is located in NEW ALBANY, OH just outside Columbus, Ohio.
http://www.privacyware.com/news.shtml
They made themsleves known with a much touted security app named ThreatSentry.

All PC Security is a trial n error escapade. What makes your own PC security so unique and trustworthy is the valuable information that can be found here at Paul Wilder's thru discussion of comparisons as well as testing for yourself locally if it meets with your expectations or not.

As far as "tiny little companies" go, there have been single individuals aka: software developers, many starting out freelance who have contrived some very useful Windows protection apps in the past, some of which are still relied on even today.

 

This is a good can of worms to open.

For all practical purposes, the only difference between built in and 3rd party wares is whose name is on the files. Windows isn't a flat surface that everything else runs on top of. It's a collection of layers itself. All of the potential problems that are possible with 3rd party wares are also possible with Windows own components. No matter whose code it is, there's bugs. The more code there is, the more bugs there's liable to be, not a comforting thought when you consider that the amount of code in Windows has increased by more than a factor of 10, as has the attack surface.

This cuts many ways. A lot of us use 3rd party security apps because we don't trust Windows built in defenses. Some pri/sec applications exist for the purpose of countering certain undesired behaviors of Windows. An example would be Windows storing user activity recoreds and MRU blaster. With software and the companies behind it, trust is not a yes or no question. The fact that you're using a particular OS, security app, browser, etc says that you trust it to a point. As an example, look at the recent discussions here regarding powershell and applocker, or the "Circumventing SRP and AppLocker by design, with LoadLibraryEx" threads. Are these bugs? Are they deliberate backdoors? How do you know for certain either way? For a typical user, it probably doesn't matter. If you're a whistle blower, a dissident, a loud critic of a repressive government, etc, it could be another story. Factor in the buying and selling of exploits with governments being the biggest customers. How far will you trust a company, an OS, an application, a community, etc?

Trust is not a simple question or an easy one to answer. Lots of factors to consider, which means the answer is most likely a variable and a compromise.

 

Any programming code that is not embeded, fixed, or enveloped, (in programming speak 'compiled') into the Microsoft
Windows Operating System Code Base is permitted by the operating system to 'Patch' and/or 'Tap' the required 'Layer'
to properly function "on top of the operating system".

Example: If the application wants to check if an particular language support is available from the operating system,
the application can "Tap" the Application Programming Interface (API) of the operating system by calling:
'EnumLanguageGroupLocales' in the applications code base.

Source:
http://msdn.microsoft.com/en-us/goglobal/bb978453


EDIT: clarity/completeness


HKEY1952

 

I think most members here are either intermediate to advance pc users, or techs or developers, malware hunters etc. I think the sampling of knowledge here is pretty reliable. So they would not try or use inferior products.

 

Well, in terms of reliability it's simple enough to figure out. There are tons of videos on security products that give at least a small insight into their capabilities.

Of course, without understanding how the actual program works (for example, understanding how an AV detects) a user can never really understand whether or not it actually works well.

As for whether the program is programmed well or securely you can check to see if it supports basic security techniques such as DEP and ASLR. I wouldn't trust any security program that didn't support both of these, and if I were using Windows I wouldn't install a program that didn't.

 

edit: Acutally, that's a perfect example. I didn't know how they functioned and therefor could not make a proper assumption.

 

To elaborate on the Quote for clarity

Synopsis of Data Execution Prevention (DEP), Address Space Layout Randomization (ASLR), and
How and Why Independant Software Venders (ISV) Can Take Advantage of These Defenses to Protect End Users

Data Execution Prevention is an set of hardware and software technologies that perform additional checks on memory
to help prevent malicious code from running on an system. The primary benefit of Data Execution Prevention is to
help prevent code execution from data pages in memory, such as the default heap pages, various stack pages, and
memory pool pages. The exception-handling mechanisms in the Microsoft Windows Operating System raises an exception
when an execution occurs, when the exception is unhandled, the process will be stopped.

Hardware-enforced Data Execution Prevention:
Typically, code is not executed from the default heap and the stack. Hardware-enforced Data Execution Prevention
detects code that is running from these locations and raises an exception when executions occur. Hardware-enforced
Data Execution Prevention marks all memory locations in an process as non-executable unless the location explicitly
contains executable code. There exists an class of attacks that tries to insert and run code from non-executable
memory locations. Data Execution Prevention helps prevent these types of attacks by intercepting them and raising an
exception. Hardware-enforced Data Execution Prevention relies on processor hardware to mark memory with an attribute
that indicates that code should not be executed from that memory space. Data Execution Prevention functions on an
per-virtual memory page basis. Processor architecture determines how Data Execution Prevention is implemented in
hardware and how Data Execution Prevention marks the virtual memory page.

Software-enforced Data Execution Prevention:
Is an additional set of Data Execution Prevention security checks, these additional security checks, are designed to
block malicious code attempting to take advantage of the exception-handling mechanisms that are built into the
Microsoft Windows Operating System. Software-enforced Data Execution Prevention helps protect only limited system
binaries, regardless of the hardware-enforced Data Execution Prevention capabilities of the processor.

Source: http://support.microsoft.com/kb/875352


Address Space Layout Randomization
The effectiveness of Data Execution Prevention hinges on the exploit not being able to leverage code that is already
executable, or make the exploits data become executable, resulting in the exploits data to appear to be code.
Data Execution Prevention breaks exploitation techniques that have been traditionally relied upon, however, Data
Execution Prevention without Address Space Layout Randomization is not robust enough to prevent arbitrary code
execution in most cases. Data Execution Prevention and Address Space Layout Randomization used in combination are
very difficult to bypass. The effectiveness of Address Space Layout Randomization hinges on the entirety of the
address space layout remaining unknown by the exploit. This is accomplished by by making the address space layout of
an process unknown to the exploit that does not have local access to the machine. Thus preventing an exploit from
being able to directly and reliably leverage code in loaded modules. There are cases where memory may be mapped at
predictable addresses across personal computers despite Address Space Layout Randomization. This happens when
Dynamic-link library (DLL) files and Executable (EXE) files load at predictable addresses because they have not been
opted into Address Space Layout Randomization via the /DYNAMICBASE linker flag by the Independent Software Vendor.

Source: http://blogs.technet.com/b/srd/archive/2010/12/08/on-the-effectiveness-of-dep-and-aslr.aspx


Windows Independent Software Vendor Software Security Defenses
Independent Software Vendors should opt-in for both defenses (/DYNAMICBASE for Address Space Layout Randomization)
and (/NXCOMPAT for Data Execution Prevention) for all binaries. This document details the available defenses and
explains how Independant Software Vendors can and should take advantage of these defenses to protect End Users.

Source: http://msdn.microsoft.com/en-us/library/bb430720.aspx


EDIT: clarity/completeness


HKEY1952

 

Yes... I know what both DEP and ASLR do... thank you for the summaries?

To elaborate on my point if a security vendor is not making use of either of those technologies than
1) they're making my programs less secure
2) they're not fit to be making security decisions on my computer

 

There is clearly some kind of language barrier issue as you're not actually making sense and/ or completely misunderstanding what I've written.

That said, your opinion means less than most ( this is not the first time this has happened) so I'm not really interested in trying to decipher whatever your issue is.

 

I find these views interesting because they seem almost completely opposite to my own. Where you say "we trust until something proves otherwise", I would say "we don't trust until something proves trustworthy". Where you communicate "I trust that which I have not reviewed" I would communicate "I do not trust that which I have not reviewed".

Unfortunately, the various dictionary entries I have looked at seem to include both points of view:

1) That "trust" is belief where there is substantial justification for having that belief
2) That "trust" is belief where there is no substantial justification for having that belief

Where "substantial justification" is something objectively compelling and rational. This, I think, is a problem especially in any context where there can be significant consequences of a "wrong" belief. Perhaps this could be reconciled by interjecting "levels of trust", but I think that would still leave much room for subjective personal opinion. The later being important to the degree that it factors in the individual's context, but also being an impediment to discussing "trustworthiness" from a point of view that is useful to everyone.

 

And how do we get to that point?

 

I would suggest we each conduct and/or seek out quality, qualified reviews. Easier said than done of course, and arguably part of a perpetual process rather than destination.

 

I actually find software developed by little companies, specially one man developer to be more stable and effective. Example is Sandboxie . I don't know, but for some reason they seem to be more serious in developing their software.

 

As Rmus aptly noted, it all goes back to trust, but let's unpack that notion a bit...

You partially focus on proprietary software, but it's generally true for any software, open or proprietary. Actually, it's even true beyond software.

The only difference is the person or group of people you end up trusting. For the technically adept, perhaps you trust your own analytic capabilities. For the average user, you may trust a known individual whose prior guidance has proven worthy of trust, or perhaps it is availability from a trusted resource (specific hosting site/app store).

The fact of the matter is that occasionally our trust is misplaced and we may get burned in the process. Recognizing this, anyone should have a handle on the stakes involved to mitigate downside potential. With respect to software, essentially that comes down to having a plan to deal with the potential of complete and utter system failure. Of course, that plan needs to be in place for other more pragmatic reasons.

Invariably misplaced trust resolves itself in time and life moves on.

Blue

 

I test my programs. When I clean a system, after a malware scan, I usually use task manager (ProcessHacker) with a search engine for remaining crap in the computer. If I don't find any bad things it means the program did a good job.

 

Actually, Hungry Man is right in what he said. Windows comes with built-in security mitigation techniques, such as ASLR and DEP. Many software developers neglect them, and don't even support them. There was some research paper mentioning that many security software also neglects such mitigations.

What this means is, imagine that if you install say 7-zip, which does not support ASLR, it will add a shell extension (it will inject a *.DLL) to explorer.exe, which has no ASLR support.

Normally, explorer.exe wouldn't be as compromised as it can now be, and because it now contains a dll which has no ASLR support. This is enough to create a security hole in your system, through explorer.exe.

This is just an example. If you look this forum, you'll find the research I'm talking about, and in there there were mentions to security software injecting DLLs into web browsers, without supporting ASLR. This will create holes in the web browsers as well.

If you search for Didier Stevens (a security researcher) blog about such kind of thing, you'll also see the same concerns. He actually goes as far as saying that more isn't always better. He's 100% true. When this "more" creates holes, you'll actually have less security.

 

Source: http://blogs.technet.com/b/srd/archive/2010/12/08/on-the-effectiveness-of-dep-and-aslr.aspx


HKEY1952

 

What exactly are you trying to say? Because, what you have quoted from that Technet blog article, says the same I said. So... I'm lost here...

Or, are you just trying to confirm what I've said?

 

In an short trusted sentence, everytime an execution occurs in the Microsoft Windows Operating System an exeception
flag is raised, if the exception is unhandled the process will be stopped, if the exception is not unhandled the process
will execute, therefore, by making the attackers data appear as code the attackers data becomes executable while in the
non executable reagons of memory, the exception-handling mechanisms in the Microsoft Windows Operating System raises
an exception flag, executables are not permitted to execute in non executable regions of memory, so the attackers
process is unhandled and the process is stopped.


EDIT: clarity/completeness


Highlights in Quotes by HKEY1952


HKEY1952