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

Discussion in 'other security issues & news' started by Gullible Jones, Apr 14, 2012.

Thread Status:
Not open for further replies.
  1. 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.]
     
  2. Rmus

    Rmus Exploit Analyst

    Joined:
    Mar 16, 2005
    Posts:
    3,943
    Location:
    California
    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
     
  3. twl845

    twl845 Registered Member

    Joined:
    Apr 12, 2005
    Posts:
    4,186
    Location:
    USA
    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.
     
  4. xxJackxx

    xxJackxx Registered Member

    Joined:
    Oct 23, 2008
    Posts:
    4,049
    Location:
    USA
    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.
     
  5. Dark Shadow

    Dark Shadow Registered Member

    Joined:
    Oct 11, 2007
    Posts:
    4,553
    Location:
    USA
    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.
     
  6. HKEY1952

    HKEY1952 Registered Member

    Joined:
    Jul 22, 2009
    Posts:
    648
    Location:
    HKEY/SECURITY/ (value not set)
    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
     
  7. EASTER

    EASTER Registered Member

    Joined:
    Jul 28, 2007
    Posts:
    5,633
    Location:
    U.S.A. (South)
    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.
     
  8. noone_particular

    noone_particular Registered Member

    Joined:
    Aug 8, 2008
    Posts:
    3,798
    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.
     
  9. HKEY1952

    HKEY1952 Registered Member

    Joined:
    Jul 22, 2009
    Posts:
    648
    Location:
    HKEY/SECURITY/ (value not set)
    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
     
    Last edited: Apr 14, 2012
  10. 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.
     
  11. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,148
    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.
     
  12. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,148
    edit: Acutally, that's a perfect example. I didn't know how they functioned and therefor could not make a proper assumption.
     
    Last edited: Apr 14, 2012
  13. HKEY1952

    HKEY1952 Registered Member

    Joined:
    Jul 22, 2009
    Posts:
    648
    Location:
    HKEY/SECURITY/ (value not set)
    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
     
    Last edited: Apr 15, 2012
  14. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,148
    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
     
  15. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,148
    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.
     
  16. TheWindBringeth

    TheWindBringeth Registered Member

    Joined:
    Feb 29, 2012
    Posts:
    2,086
    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.
     
  17. vasa1

    vasa1 Registered Member

    Joined:
    May 1, 2010
    Posts:
    4,152
    And how do we get to that point?
     
  18. TheWindBringeth

    TheWindBringeth Registered Member

    Joined:
    Feb 29, 2012
    Posts:
    2,086
    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.
     
  19. kupo

    kupo Registered Member

    Joined:
    Jan 25, 2011
    Posts:
    1,122
    I actually find software developed by little companies, specially one man developer to be more stable and effective. Example is Sandboxie :D. I don't know, but for some reason they seem to be more serious in developing their software.
     
  20. BlueZannetti

    BlueZannetti Administrator

    Joined:
    Oct 19, 2003
    Posts:
    6,590
    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
     
  21. Wroll

    Wroll Registered Member

    Joined:
    Nov 29, 2011
    Posts:
    549
    Location:
    Italy
    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.
     
  22. m00nbl00d

    m00nbl00d Registered Member

    Joined:
    Jan 4, 2009
    Posts:
    6,623
    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.
     
  23. HKEY1952

    HKEY1952 Registered Member

    Joined:
    Jul 22, 2009
    Posts:
    648
    Location:
    HKEY/SECURITY/ (value not set)
    Source: http://blogs.technet.com/b/srd/archive/2010/12/08/on-the-effectiveness-of-dep-and-aslr.aspx


    HKEY1952
     
  24. m00nbl00d

    m00nbl00d Registered Member

    Joined:
    Jan 4, 2009
    Posts:
    6,623
  25. HKEY1952

    HKEY1952 Registered Member

    Joined:
    Jul 22, 2009
    Posts:
    648
    Location:
    HKEY/SECURITY/ (value not set)


    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
     
    Last edited: Apr 15, 2012
Loading...
Thread Status:
Not open for further replies.