64-bit systems and anti-malware software

Discussion in 'other anti-malware software' started by ssj100, Aug 6, 2009.

Thread Status:
Not open for further replies.
  1. Ilya Rabinovich

    Ilya Rabinovich Developer

    Joined:
    Sep 13, 2005
    Posts:
    1,543
    Matousec tests are for WinXP 32 bit, but we are talking about 64 one. Why do you think x32 and x64 versions are the same?
     
  2. Julian

    Julian Registered Member

    Joined:
    Sep 14, 2008
    Posts:
    103
    However.. at least one advantage for Windows x64. It's not only the bad devil as it's portrayed here.

    Why do you think it would be relevant if SSTS was not 64 bit? It makes Comodo fail tests where it has only (unsafed) non ring 0 hooks. Outpost passes them (and Kaspersky passes the keylogger tests too).

    And please answer my question: Can non ring 0 hooks be properly safed? Look at Outpost, at least it can get along with the SSTS unhooker which seems to work on x64 Windows. It's not an argumentative question, I just want to know it for my knowledge :)
    Thank you.

    Btw: Windows 7 x64 runs much faster than the 32 bit version. Just my subjective impression.

    Edit: Btw2: Kaspersky first said that they couldn't add many proactive features because of patchguard and then it improved nevertheless. Don't take it too personally when I said that I won't buy such bad excuses (from my current point of view they are still bad excues) anymore.
     
  3. Osaban

    Osaban Registered Member

    Joined:
    Apr 11, 2005
    Posts:
    5,614
    Location:
    Milan and Seoul
    Could you tell us about DeepFreeze and Anti-Executable from Faronics? They've had x64 versions for a while, are they also affected in terms of the security they provide compared to the x32 versions?
     
  4. tzuk

    tzuk Developer

    Joined:
    Jul 4, 2004
    Posts:
    34
    I wanted to drop by and support Ilya. I completely agree with everything you said so far. The arbitrary limitations in Windows 64-bit are really getting in the way here.

    There are official kernel interfaces but they don't cover everything. It's the difference between being able to do everything you can think of (32-bit) and being able to do only the stuff Microsoft thought you should be doing (64-bit). Now, Microsoft did think about a lot of stuff and their official interfaces cover a lot of ground. Probably enough for most anti-virus software. But those interfaces can't possibly cover EVERYTHING, and more importantly, they don't cover enough at this time.

    Ilya, if you are sure that some 64-bit products get their way (perhaps partially) using user mode hooks then it confirms what I suspected and suggested in my forum some time ago, that many 64-bit versions of 32-bit security products are actually weaker by design.

    How ironic it is that some people then take those weakened 64-bit software as proof that it is possible to create robust 64-bit security software!

    * * *

    Final note Dregg Heda: PatchGuard would break A LOT of driver software so Microsoft did not want to go there. But 64-bit Windows requires recompiling drivers anyway, in other words it already breaks ALL existing driver software, so Microsoft felt this is a good opportunity to introduce PatchGuard. Of course I'm not a spokesperson for Microsoft, but as far as I recall, this rationale is explained in their official FAQ about PatchGuard.
     
  5. PrevxHelp

    PrevxHelp Former Prevx Moderator

    Joined:
    Sep 14, 2008
    Posts:
    8,242
    Location:
    USA/UK
    Could you outline what you aren't able to do on x64? Microsoft provides functionality to monitor (and this list is incomplete):

    - File reads/writes/deletion/renames/etc.
    - Network/Internet data inbound and outbound
    - Keyboard data access
    - Mouse data access
    - Cross process access/cross thread access (which can be additionally used for self protection)
    - Registry reads/writes/deletion/etc.
    - Process creation (incl. 16bit execution if you're creative)
    - DLL loading
    - Driver loading
    - Thread creation (incl. remote thread creation identification)
    - Section mapping
    - Named pipe/mapped file/mailslot access
    - Window hook creation
    - Raw disk reads/writes
    - Window message handling

    Granted, some of this functionality was first implemented in Vista SP1 so XP x64 users may be out of luck (however there are other techniques which still do work on XP x64 because the PatchGuard then wasn't as strong). I know it isn't as cut-and-dry as working from SSDT hooks but it is not impossible.

    Honestly, there are a couple areas which I wish had better support from Microsoft in x64, like the ability to protect clipboard contents easier, but we're working on different techniques for this and other areas which are definitely viable (and don't involve PatchGuard modifications). It is understandable that Microsoft can't provide every piece of requested functionality but I think they've done well so far.

    As I've said in a previous thread, I believe the changes for 64bit are for the better. Will they require software authors to make some major changes to their products? Yes. Will they improve stability for the end user? Yes Yes Yes.

    I understand that it is not commercially viable at the moment for many vendors to focus on x64 but I don't think it is necessary to go on an all-out crusade against Microsoft, threatening to sue them for integrating this "evil" technology called PatchGuard :doubt: It would be like malware authors suing AV companies for adding self protection because the malware wouldn't be able to terminate the AVs.

    If Microsoft would have had PatchGuard in since the start of 32bit Windows, would many security companies simply cease to exist? Personally, if it was viable (which it obviously isn't because of the need for software updates) I wish the kernel could be run from ROM at the hardware level to prevent any possibility of modification from any software not using defined interfaces with the proper signing/accreditation in place.
     
  6. Wildest

    Wildest Registered Member

    Joined:
    Apr 28, 2009
    Posts:
    304
    I am most interested to see one of the anti-64 bit developers respond to this post, as it has been very enlightening.
     
  7. PrevxHelp

    PrevxHelp Former Prevx Moderator

    Joined:
    Sep 14, 2008
    Posts:
    8,242
    Location:
    USA/UK
    Behavior blocking/classical HIPS are just a different implementation - Prevx/Avira just automate the decisions rather than warn the user on each action but the same low-level functionality is still in place.
     
  8. PrevxHelp

    PrevxHelp Former Prevx Moderator

    Joined:
    Sep 14, 2008
    Posts:
    8,242
    Location:
    USA/UK
    Yes, but this is outside of the scope of 32/64bit platform relevance :) A classical HIPS and a behavior monitoring product are identical under the hood at the kernel level - the only difference is the way that they alert the user. Products like Prevx/Avira use intelligence gathered from the engineers/researchers at the respective companies while classical HIPS/behavior blockers depend on intelligence from the user.
     
  9. Ilya Rabinovich

    Ilya Rabinovich Developer

    Joined:
    Sep 13, 2005
    Posts:
    1,543
    The list is too short to implement anything reasonable with it. A good sandbox must control: per-process driver installation (not loading, but installation!), sections manipulations (but not creation!), file system and registry ACL's manipulations, screen grabbing, input blocking, memory allocation/deallocation and a lot of other staff MS do not have filters for.

    I believe, single developers are more concerned about honesty with the software we produce that even small companies because we just can't fire ourself and say "yes, our product is just one big security hole, it's our developer's/manager's fault, he/she is fired. The case is closed, everybody shut up".
     
  10. firzen771

    firzen771 Registered Member

    Joined:
    Oct 29, 2007
    Posts:
    4,815
    Location:
    Canada
    i think the reason its the single person developers that are speaking out about this is one, because as ilya said, its about marketing and they dont want people to think its weaker, and second, single developer projects have MUCH less resources available for developement of the product to overcome obstacles like this which makes a big problem for their business.
     
  11. PrevxHelp

    PrevxHelp Former Prevx Moderator

    Joined:
    Sep 14, 2008
    Posts:
    8,242
    Location:
    USA/UK
    Driver installation requires a registry key change, section manipulation requires opening a section, registry/file ACLs are covered inherently with minifilters (on Vista and later), screen grabbing/input blocking can be covered without too much difficulty with more creative workarounds, memory allocation/deallocation can be securely analyzed in usermode alone.

    You should look into Microsoft's new filtering platform for Windows 2008/Vista SP1 - I suspect they've added new technology since you've last researched it.

    I'm sure that all software developers are concerned about honesty because protection is entirely transparent. Anyone anywhere can run any test they want - there isn't anything to be dishonest about: if it doesn't work, it's obvious.

    Supporting x64 is time consuming, and its understandable that single developers aren't going to move to it easily (we're even holding off support for some of our new features for x64 for a little while until we've completed everything in 32bit). I don't like when people say things are impossible, however :)

    It's probably a question of time: 32bit is by far the priority still. Do you know exactly what tests get past it?
     
  12. Wildest

    Wildest Registered Member

    Joined:
    Apr 28, 2009
    Posts:
    304
    O ho!

    From these statements I am concluding that some developers have a problem thinking outside of their box (pun unintended), of thinking of new ways to accomplish the same old things, and are stymied by insufficient resources in comparison to larger companies.

    It is unfortunate that there is less developer vs developer dialog here.
     
  13. Julian

    Julian Registered Member

    Joined:
    Sep 14, 2008
    Posts:
    103
    Neither Tzuk nor Ilya have picked on my questions / arguments, just destructive attacking.
    Sad, but ok. Now I know that I will never buy their software. Thanks, I'm out if no further good answers will appear.

     
  14. tzuk

    tzuk Developer

    Joined:
    Jul 4, 2004
    Posts:
    34
    It seems to me that some people here have an assumption that it must be possible to do anything using official kernel interfaces. And that it's only a question of us single-person-developers spending enough time to figure out the new ways of doing stuff.

    If this was the case then big name anti-virus vendors would not have had to bring public pressure to bear on Microsoft to get just 2 (!) new interfaces, which were needed in order to prevent trojans from terminating the processes of the anti-virus. Take note: There was no official way to supervise something as basic as one program terminating another.

    Just two more simple interfaces is the culmination of the work put into the new Windows Vista SP 1 "PatchGuard APIs", but this is enough to convince some people that everything should be possible in 64-bit Windows as much as in 32-bit Windows. (You can search for "Kernel Data and Filtering Support For Vista SP1" to read more about the new APIs.)

    There are also many forum and blog posts detailing many ways that PatchGuard is limiting developers altogether, or "merely" forcing them to find inferior ways to approach the problem.

    Given all this, which I invite you to research and corroborate, I think it's unfair to assume that us single-person-developers don't care or don't try hard enough. If at some point in time the official APIs were not good enough, and needed enhancements, why are you so sure that at this point in time they are good enough for everything? Is there no room for doubt in your minds that maybe we know what we're talking about?
     
  15. Ilya Rabinovich

    Ilya Rabinovich Developer

    Joined:
    Sep 13, 2005
    Posts:
    1,543
    It's not per-process.

    Opening thins section is legitimate. Manipulations are not :)

    I see no legitimate ways to do this without relying on MS mechanisms.

    You don't like physicists? :)
     
  16. PrevxHelp

    PrevxHelp Former Prevx Moderator

    Joined:
    Sep 14, 2008
    Posts:
    8,242
    Location:
    USA/UK
    There are probably a dozen different ways to go about doing this. You may want to trying cracking open IDA and taking a look at what occurs when a service/driver is registered - it is definitely possible to track it back to the originating process (It gets a bit more obfuscated on Windows 7 but on pre-Windows 7 it isn't difficult). And then also consider that interrogating the process registering the driver isn't anywhere near as important as interrogating the driver itself. Additionally, the driver will have to be written to disk, which can be captured by any number of means :)

    Manipulations can be prevented in other ways when first opened.

    I have to be vague for proprietary reasons, but rather than trying to block screen scraping leaktests, consider the differences between them and actual screen scraping attacks (i.e. the usage of the data rather than its origin).

    And if you really want to explicitly block the leaktests, you can resort to usermode hooks which work fine - I haven't seen any leaktest going directly to SYSCALL/INT 2Eh.

    Indeed - I don't like natural physicists. Quantum mechanics/particle physicists, however, give me the room to work in ;)
     
    Last edited: Aug 8, 2009
  17. fax

    fax Registered Member

    Joined:
    May 30, 2005
    Posts:
    3,899
    Location:
    localhost
    Aaah! What a refreshing discussion... :thumb:
    Thank you all for the very interesting exchange, we should see more of this in here!

    Cheers,
    Fax
     
  18. wat0114

    wat0114 Guest

    I see nothing interesting in the exchange because there is a dispute between the developers. Unless they all agree, we have uncertainty about the viability of properly protecting 64 bit systems.
     
  19. Wildest

    Wildest Registered Member

    Joined:
    Apr 28, 2009
    Posts:
    304
    LOL, is the only interesting thing about a boxing match, the end result? :D

    I am exercising some self-restraint relative to the knee-jerk reaction of making a comment, so as to allow this enlightening developer dialog to go uninterrupted.

    I would think it would be more inviting for a developer to go into a thread if he/she sees the last post was from another developer, no?
     
  20. tzuk

    tzuk Developer

    Joined:
    Jul 4, 2004
    Posts:
    34
    You don't seem to understand, that's the very point that I am (and as far as I can see, Ilya as well) protesting about. This arbitrarily-imposed requirement to substitute strong, untouchable kernel-level supervisory mechanisms with weak, malleable user-mode hooks.

    Malicious code that is aware of 32-bit Sandboxie today can, at most, choose to end itself with some obfuscated message, to tempt you to run it outside the sandbox. It cannot "overpower" the kernel-level hooks because it is inferior to them.

    What is there to stop malicious code that is aware of a 64-bit Sandboxie from stomping all over the user-mode hooks and getting away with it?
     
  21. PrevxHelp

    PrevxHelp Former Prevx Moderator

    Joined:
    Sep 14, 2008
    Posts:
    8,242
    Location:
    USA/UK
    I'm well aware of that - if you read the context of my post, I was referring to blocking specific leaktests if you absolutely have to which can be accomplished with usermode hooks but I agree that usermode hook-based protection is irrelevant and merely a speed bump for malware authors not wanting to decode the correct syscall indexes and actual protection cannot rely on usermode hooks.

    My point is that screen scraper protection can be developed differently and still be equally effective in x64 against real threats and everything else I've referred to can be accomplished on x64 without resorting to hooking the suspicious process.
     
  22. wat0114

    wat0114 Guest

    I'm not interested in a boxing match nor do I take glee in watching one. I want the facts on this subject, thats all. As long as there is disagreement between these developers who do know what they're talking about, then we don't really know the facts, do we?
     
  23. Wildest

    Wildest Registered Member

    Joined:
    Apr 28, 2009
    Posts:
    304
    I assume you would prefer that the developers hammer it out via PM, and then make public the "facts"?

    Some of us prefer to see not only the facts, but the process by which the facts were derived as well.
     
  24. Wildest

    Wildest Registered Member

    Joined:
    Apr 28, 2009
    Posts:
    304
    I am assuming that this response means that the answer to tzuk question,
    "What is there to stop malicious code that is aware of a 64-bit Sandboxie from stomping all over the user-mode hooks and getting away with it?"
    is "nothing", correct?
     
  25. Ilya Rabinovich

    Ilya Rabinovich Developer

    Joined:
    Sep 13, 2005
    Posts:
    1,543
    Wrong answer. The manipulation I mean can't be prevented this way.

    Bad idea.

    Then you have to know that there are some things that are impossible, for example, two electrons with the same spin at one energy level.
     
Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.