64-bit systems and anti-malware software

[ssj100]

So what will you guys do when you eventually move to a 64-bit system? I personally don't anticipate a move to a 64-bit system for another 5-10 years.

I think 4Gb of RAM will be more than enough for my needs for at least the next 5 years. I am currently running on 2Gb of RAM, and I can do everything I need to with lightning speed. In fact, my computer/system is approaching 3 years old now, and it's still lightning fast and responsive with every program I personally use.

I don't anticipate to purchase a new system for at least another 2-3 years. When I do, I will most likely move to a 32-bit Windows 7 platform with 4Gb RAM and whatever new generation processor is available from Intel.

However, I can see that I will probably eventually move to a 64-bit system (unless I completely lose interest in computers, which might happen...10 years is a long time!). And so the question is what security software would I use then on Windows? It seems that my most favourite security application Sandboxie will never support 64-bit, period.

I know that a lot of you guys out there favour DefenseWall and Malware Defender greatly too, but neither will support 64-bit either. So what will you do?

I am aware that this is all quite hypothetical (especially from my view-point, since I don't intend to use a 64-bit system for at least another 5-10 years...I mean, the world might come to an end by then haha), but I am just interested to see some opinions here. Would any of you be willing to ditch DefenseWall in order to use a system that utilises more RAM? Would any of you be willing to ditch Malware Defender for the same reason?

Or are there any other perspectives out there? Will we perhaps see Windows 64-bit systems become more compatitble with security software like Sandboxie, DefenseWall and Malware Defender in the future?

[arjunned]

I had Vista x64. But i missed Sanboxie so much, that i evently changed back to x86. I will probably get W7 x64 when its out. I dont know why sandboxie wont support x64 since in the future (dont know how many years down the line), most systems, i'm guessing, would be x64. But that doesnt mean i'm gonna stop using sandboxie.

But then again, its good to know that app's like GeSWall will have a x64 version sometime later. Returnil has a x64 beta (v3).

For now i guess CIS would be the best bet.

[arjunned]

CIS x64 is IMO very stable and very secure.

I dont know if GeSWall x64 would as its x86. I'm guessing it might be a while untill they get it as secure.

[Dregg Heda]

Excellent thread ssj. Im intrigued to see peoples response since Im looking into moving into 64 bit computing when 7 comes out. Also I suspect 64 bit will become the standard within the next 2-3 years. I think you will end up switching sooner than you expect.

Personally Im probably going to end up using LUA + SRP as my primary protection. Ive heard that many 3rd party vendors are issuing weakened products for x64, as opposed to finding a way to provide the same quality of protection without having access to the kernel. As such I wont be trusting 3rd party apps, unless some workaround is found or MS does away with Kernel Patch Protection.

I expect that apps like DW and Sbie will make the transition to x64 once there is a sufficient number of users on those platforms, making it worthwhile for their developers to put in the necessary effort to make their apps 64bit compatible. Something which I think will happen in the next 2-3 years as I alluded to earlier.

The question off course is whether their developers will be able to provide the same level of protection with Kernel Patching in place. According to wiki some security providers dont patch the Kernel for example Eset and some other AV/AM providers. So we know it can be done, but the question is can it be done for sandboxing, policy management, etc software which may need that kind of access, unlike AV/AMs. I suspect that even if they find a way to make their products work and work well, the level of protection offered just wont be the same.

For those wondering what Kernel patch protection is check out wikipedia. It will give you an idea of why some products arent looking at x64 versions yet.

[Dregg Heda]

-{ Quote: "If CIS x64 doesn't lose any strength of security compared with x86, then shouldn't Malware Defender etc. be able to transition the same way? From what I hear from Ilya, Xiaolin and Tzuk, though, this isn't possible.

Also from what I've read in the past, I'm pretty sure CIS x64 fails a lot of POCs and tests compared with CIS x32." }-
Yup ive heard something similar along those lines too. The thing is once there are a sufficient number of x64 users, developers WILL find a way to use that extra available RAM, making the move to x64 even more inexorable.

Out of curiosity does x64 offer any other advantages other than being able to utilise more RAM?

[Dregg Heda]

-{ Quote: "The question is whether GeSWall's x64 version will be just as secure as its x86 version? We know that the reason why Malware Defender, DefenseWall and Sandboxie will never support x64 (period) is because they will be unable to protect the user properly.

I don't know much about CIS x64 version. Is it as secure as its x86 version?" }-

I think once there are enough x64 users they will back down. Even if that means producing a weaker product.

[Kees1958]

My son is now running Vista64 bits on his gaming rig, he will move to Windows 7 64 bits within a year or so.

Setup now looks
- UAC + Norton UAC tool
- Windows FW 2 way
- MSE
- Old PGS version of Sully to ensure Software Restriction Policy (SUL :thumb: when do you release the RC without month liimatation :D )

Setup will be
- UAC, neglecting user initaited elevations
- Windows FW 2-way
- MSE
- GesWall 64 bits

I know he visists the riskier area's of teh Internet, but 64 bits ops are just great (okay now there is lacking third party security, but market share of the OS is so low that it has MAC/Unix like risk exposure).

Regards Kees

[Osaban]

-{ Quote: "So what will you guys do when you eventually move to a 64-bit system? I personally don't anticipate a move to a 64-bit system for another 5-10 years.

I think 4Gb of RAM will be more than enough for my needs for at least the next 5 years. I am currently running on 2Gb of RAM, and I can do everything I need to with lightning speed. " }-

Out of curiosity, if you are thinking of going 64 in 5-10 years time (eons in computer technology) , why do you worry so much about Sandboxie?

I have an image with Vista 64, and when I use it I have DeepFreeze with Anti-executable V3, an amazingly light but robust combination. The reason I haven't yet decided whether to stay with 32 or 64 is some of the drivers which activate some keys on my laptop don't work with 64 (nothing important really, but why miss out on some nice options?).

Vista 64 is slightly faster than 32, and uses a little bit more memory. Opening up as many programs as possible it wouldn't use more than 1.6-7 GB of memory on my machine. Now if you are using 3-4 memory hungry programs simultaneously it will keep the same speed of operation as if you had only one program opened. This is definitely an advantage for designers and architects or scientists who use computers to produce models that can really push the machine specifications to its limits.

PatchGuard is a great feature of x64. A lot of malware is inactive for the same reasons many anti malware applications don't work with it.

[Dregg Heda]

-{ Quote: "My son is now running Vista64 bits on his gaming rig, he will move to Windows 7 64 bits within a year or so.

Setup now looks
- UAC + Norton UAC tool
- Windows FW 2 way
- MSE
- Old PGS version of Sully to ensure Software Restriction Policy (SUL :thumb: when do you release the RC without month liimatation :D )

Setup will be
- UAC, neglecting user initaited elevations
- Windows FW 2-way
- MSE
- GesWall 64 bits

I know he visists the riskier area's of teh Internet, but 64 bits ops are just great (okay now there is lacking third party security, but market share of the OS is so low that it has MAC/Unix like risk exposure).

Regards Kees" }-

Hi Kees,

The question is, will GesWall 64 offer the same level of protection as GesWall 32 if it cant patch the kernel? And if GesWall can do it, why cant DW or sbie?

[Dregg Heda]

-{ Quote: "

PatchGuard is a great feature of x64. A lot of malware is inactive for the same reasons many anti malware applications don't work with it." }-

But the problem is malware can still find a way around it while legitimate apps aren't allowed to do so, right?

[Rules]

I'm using vista x64 for couple of year with OFP, Avira an Prevx edge, imo it's run very fast for me.

So for the anti-malware software Prevx edge run fine and offer strong protection, MBAM too.


Actually They have lot lot lot:P Trojan variant on the web and pro-active protection is most Welcome:)


Sorry for bad english writing

Rules.

[Dregg Heda]

-{ Quote: "I personally wouldn't use Sandboxie if it was weaker and full of vulnerability." }-

Yup same here, which is why I have put my plans on hold and am considering other options which can work with x64.

Thanks for the article you posted. Gives me a better idea of what tzuk (and the others) is/are up against.

I doubt he would ever produce a sbie that was "full of vulnerability". But what happens as more and more people move over to x64. If MS produce a stable, competent OS with x64 ability as they seem to be doing with 7, I could easily see that happening within the next 2-3 years. I can easily see x64 becoming standard in 2-3 years time. Mac has already made the jump with Snow Leopard.

What happens to Ilya, Xiaolin and Tzuk then? Either they find a way to make their products work with x64, or they create new products that can work within the limitations of the system or they leave the malware business altogether, perhaps leaving around stable releases of their products for those few stragglers still living in a 32 bit world.

Assuming MS keeps patchguard, I think there is a chance they will find a way to make their products work with x64. Right now there is no real incentive for them to tear everything up and go looking for a way around this, as the market share isnt really there. But once its there, and it is financially viable to do so, I think they will start looking and if they look hard enough I think they might find a way around most problems with patchguard. I cant say that they will be able to produce something as strong as their 32 bit products, but I think they might be able to produce something close.

Another question is how well does patchguard help thwart malware, and how easily malware can help bypass it. If lots of x64 machines are getting hosed, because malware writers are able to easily bypass it, and 3rd party security vendors arent able to provide proper protection and MS itself is unable to provide any proper protection, then I can see public pressure being heaped on MS to get rid of it. And in that case all our favourite security apps will be ported to x64.

Im not a computer expert of any kind, so I could be totally wrong about all of this ;D , but these are just my musings on the subject and some possibilities.

[demonon]

From you post ,ssj100, it almost seems to me you care more about your security setup then you do for your PC productivity.
I personally have already switched to x64 on almost all my systems.
And I have not looked back, but then again I also do not really care about sandboxie or malware defender.
The only thing that I really need is an imaging software, and considering thatreturnil 2010 might support x64 I am totally happy.

[trjam]

-{ Quote: "From you post ,ssj100, it almost seems to me you care more about your security setup then you do for your PC productivity.
I personally have already switched to x64 on almost all my systems.
And I have not looked back, but then again I also do not really care about sandboxie or malware defender.
The only thing that I really need is an imaging software, and considering thatreturnil 2010 might support x64 I am totally happy." }-
:thumb:

[s23]

the new version of Prevx will have browser protection (through policies?)and some more things and will be compatible with x64 not is? someone from prevx can speak about?

[arjunned]

For me rite now, x64 isnt a necessity. I will shift to x64 once W7 is, by next year. Also becoz i find my Design applications (CAD, Max) are a bit more responsive in their x64 variables. (I'm an Architecture student and i'm going back to coll after a year). As for anti-malware, I'd stick with Outpost Pro and probable returnil when its outta beta.

[Kees1958]

-{ Quote: "Hi Kees,

The question is, will GesWall 64 offer the same level of protection as GesWall 32 if it cant patch the kernel? And if GesWall can do it, why cant DW or sbie?" }-

GW used windows internal mechanismes, that is why it so fast and does not have total untrusted file control like DefenseWall.

At a driver level you can intercept access to files an registry, also in x64 so that is no problem. Vista allows no access to critical resources of objects with a lower rights, inter process security is also quite good at x64. Possibly they also do something with ownership at file and registry level. Vista knows virtualisation allready now (will be there until Windows 9) of regsitry and files. Only poblem objects running virtualised get virtual admin rights. No idea on how they will be able to use existing (LUA) mechanismes while circumvencing the limitations of other options (like virtualisation).


I know Sully is progressing in making PGS a real power house with Software Restriction Policies, Using ownership of registry and file through a fake user (Surun acts in a simular way) and possibly x32 virtualisation in Vista/Win7. PGS will run on x64 also. In a way it is amazing what Sully might achieve with smart usage of Windows internals. When he can, why not the experts of GentleSecurity?


They (GW) used to know windows internal mechanismes real well so they must have found ways to do it. I suppose it will be a combo of soft sandboxing (like HauteSecure wanted to achieve) with smart usage of x64 internals.

Cheers

[jdd58]

-{ Quote: "Old PGS version of Sully to ensure Software Restriction Policy (SUL :thumb: when do you release the RC without month liimatation :D )
Regards Kees" }-

He already did.

-{ Quote: "As per requests, and since there have been no complaints of bugs, the time restraint has been removed and version 1 final is compiled and ready for download.

Follow the link in the first post.

Sul." }-

http://mrwoojoo.com/PGS/PGS_index.htm

[Kees1958]

Jdd58, thx

see post http://www.wilderssecurity.com/showpost.php?p=1519278&postcount=5296 Pretty Good Security is out, grab your copy :thumb: :thumb: :thumb:

PGS final up and running on Vista64, no extra overhead, just using the mechanismes of the OS to mitigate threats and appy a default deny execute

Yeaahhh SULLY :thumb: :thumb: :thumb:

[Dregg Heda]

Kees:

Thanks for the response. Do you think Ilya and Tzuk will be able to change the way DW and sbie work to utilise windows internal mechanisms and produce 64 bit versions of their products which are as powerful as 32bit?

[Kees1958]

-{ Quote: "Kees:

Thanks for the response. Do you think Ilya and Tzuk will be able to change the way DW and sbie work to utilise windows internal mechanisms and produce 64 bit versions of their products which are as powerful as 32bit?" }-

They will worry about (like Xioalin of MD), when 64 bits acquire a reasonable market share. Right now they have not developed Mac or Linux either, which have comparable share on the desk/lap-top market right now.

Easiest way of migration would be
a) a product with a different name to prevent their rock solid product brands, with limited features so they roam down to less PC savvy users.
b) develop a new product based with same strentgh, but different protection mechanisme, maybe they could join forces

[Boost]

-{ Quote: "From you post ,ssj100, it almost seems to me you care more about your security setup then you do for your PC productivity.
I personally have already switched to x64 on almost all my systems.
And I have not looked back, but then again I also do not really care about sandboxie or malware defender.
The only thing that I really need is an imaging software, and considering thatreturnil 2010 might support x64 I am totally happy." }-

:thumb:

[Ilya Rabinovich]

-{ Quote: "develop a new product based with same strentgh, but different protection mechanisme, maybe they could join forces" }-
Unfortunately, it's not that simple. At least, DefenseWal never relied on internal protection mechanisms of Windows because just one privilege escalation exploit can ruin both the defenses.

[trjam]

I feel that when Geswall is 64 bit ready, that it and something like Prevx will be a very secure setup.

[jmonge]

-{ Quote: "Ilya, care to comment on what you personally would end up doing when migrating to 64-bit? I know all you use for computer security is DefenseWall with 32-bit. Would you be willing to create and use a more vulnerable version of DefenseWall on a 64-bit system personally?" }-
dont forget to ask tzuk same question:argh: ;D :argh:
got it?

[jmonge]

-{ Quote: "Haha, I think Tzuk has been asked that question about 50 times in the last 50 minutes. His answer is no by the way." }-for me it doesnt matter at this moment i will remain using 32 bits for now:)

[Dregg Heda]

So what will he do? Create something else? Quit the malware business entirely?

[jmonge]

-{ Quote: "So what will he do? Create something else? Quit the malware business entirely?" }-this is something the developers has to decide;)as for me just stay with the 32 systems:thumb:

[Dregg Heda]

-{ Quote: "this is something the developers has to decide;)as for me just stay with the 32 systems:thumb:" }-

Indeed, but Id still be interested in his thought process, as to how he plans to deal with the situation, if hes willing to share it off course.:P

[jmonge]

-{ Quote: "Yes, as I said, 32-bit is working extremely well for me right now, and I predict for many more years to come.

In Tzuk's article, he actually implied that we shouldn't be supporting 64-bit Windows systems that has PatchGuard etc (that is, don't buy them) if we want to keep using programs like Sandboxie, (Malware Defender and DefenseWall).

A big question is why GeSWall is going to support 64-bit? For example, if GeSWall's protection is the equivalent in strength to DefenseWall, why can GeSWall freely support 64-bit and not Ilya? And then there is the question of whether GeSWall 64-bit will be much more vulnerable to security threats compared to its 32-bit version?" }-not sure how gentlesecurity is going to handle this patchguard situation but i am not supporting any 64 bit systems:thumbd:

[Dregg Heda]

Man if there was only some we could force MS to back down from this!

[jmonge]

-{ Quote: "I feel your pain brother haha. But seriously mate, unless you're finding huge gains from 64-bit, why not enjoy 32-bit for the next few years and let the future worry about itself?" }-wooo hahaha for the first time i agree with you in something;D

[jmonge]

-{ Quote: "Haha all good mate. Trust me, we have more in common than you think. For example I think that every single application that we've ever discussed via PM is excellent software. I'm sure you agree with that too." }-yes indeed:thumb: :argh:

[Ilya Rabinovich]

-{ Quote: "Would you be willing to create and use a more vulnerable version of DefenseWall on a 64-bit system personally?" }-
NEVER!!!!!

[Kees1958]

-{ Quote: "NEVER!!!!!" }-

And under a different product name, so the defensewall brand would not be affected?

[raven211]

-{ Quote: "And under a different product name, so the defensewall brand would not be affected?" }-

Hehe, Ilya won't be "Ilya" - he will go incognito on a secret mission. ;D

[Osaban]

-{ Quote: "But the problem is malware can still find a way around it while legitimate apps aren't allowed to do so, right?" }-
I can only refer to what I've been reading around, and it's not a matter of being allowed or not to do anything.

http://www.microsoft.com/whdc/driver/kernel/64bitpatch_FAQ.mspx

-{ Quote: "Q. Does patch protection prevent all viruses, rootkits, and other malware from attacking the system?
A.
No. Patch protection eliminates one way to attack the system, by patching kernel images to manipulate kernel functionality. Protecting the integrity of the kernel is one of the most fundamental steps in protecting the entire system from malicious attacks and from inadvertent reliability problems that result from patching. However, it is not a panacea." }-

[Dregg Heda]

-{ Quote: "I feel your pain brother haha. But seriously mate, unless you're finding huge gains from 64-bit, why not enjoy 32-bit for the next few years and let the future worry about itself?" }-
I hear what your're saying man. Its just annoying though. At some point we will all probably have to switch, and when it happens I might not have my favourite security apps or I might have them in a weakened form. If thats the case I may as well use apple imo. Atleast its beautiful!

Im seriously considering getting a mac with Snow Leopard when it comes out instead of win 7 x64.

[Dregg Heda]

-{ Quote: "I can only refer to what I've been reading around, and it's not a matter of being allowed or not to do anything.

http://www.microsoft.com/whdc/driver/kernel/64bitpatch_FAQ.mspx" }-

So basically Kernel Patch Protection will prevent legitimate security software from installing, but some malware can still find a way right?

[Dregg Heda]

-{ Quote: "NEVER!!!!!" }-
So what will you do once x64 becomes the industry standard?

[Dregg Heda]

Ive got a question for those who are more technically inclined than me? Why is M$ adding patchguard to only x64 systems? Why not do it for x32 as well?

Also what is the added advantage of 64bit computing other than access to more than 4 gigs of ram?

[Ilya Rabinovich]

-{ Quote: "And under a different product name, so the defensewall brand would not be affected?" }-
No way. If I know the defense is broken by design, I will never use it.

[Ilya Rabinovich]

-{ Quote: "So basically Kernel Patch Protection will prevent legitimate security software from installing, but some malware can still find a way right?" }-
Not from installing, but from properly doing its job as MS doesn't have all the features requires for proper sandboxing with their kernel-level filtering API.

[Ilya Rabinovich]

-{ Quote: "So what will you do once x64 becomes the industry standard?" }-
Will sue MS.

[MagisDing]

-{ Quote: "So basically Kernel Patch Protection will prevent legitimate security software from installing, but some malware can still find a way right?" }-
It depends on the behaviors of malware. Some malicious application don't install drive even replace the kerenl drive, they just modify files or registry keys to accomplish their nasty goals.

[Julian]

I don't buy it anymore when developers of smaller projects like Sandboxie or DefenseWall say it would be impossible to have good proactive protection on x64. KIS and Outpost HIPS' are very strong on Vista 64 and improved much over time. So give it time, I bet when 64 bit will be highly spread we won't have many disadvantages there.

Also KIS has a sandbox on x64. It is not as compatible as the 32 bit version but maybe it will improve with critical fix 2 (already announced) and later versions.

[OnSeeker]

I must say that my security solution BitDefender, has support both on 32 and 64 bits and the new one 2010 is even greater :P :) So happy to have it! (BETA testing)

[Ilya Rabinovich]

-{ Quote: "KIS and Outpost HIPS' are very strong on Vista 64 and improved much over time." }-
Oh yeah, really? From the Agnitum developers I know they are using user-mode hooks in security purposes and can't be considered any "strong". KIS's sandbox is officially limited and can't be considered as a strong security solution too. More examples?

[Julian]

At least Matousec SSTS doesn't unhook Outpost's user mode hooks so they must be secured in some way.
Of course you are the developer and not me so please tell me why secured ring 3 hooks are nonsense.
As long as malware doesn't slip through I don't see any problem. And the KIS sandbox isn't that bad, no problems with sandboxed Firefox on Vista 64 for me.

Btw: Are there any kernel mode driver rootkits for Vista and Seven x64?

[Ilya Rabinovich]

-{ Quote: "Btw: Are there any kernel mode driver rootkits for Vista and Seven x64?" }-
No, because of digital signatures, not because of the PatchGuard.

[Ilya Rabinovich]

-{ Quote: "At least Matousec SSTS doesn't unhook Outpost's user mode hooks" }-
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?

[Julian]

-{ Quote: "No, because of digital signatures, not because of the PatchGuard." }-
However.. at least one advantage for Windows x64. It's not only the bad devil as it's portrayed here.

-{ Quote: "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?" }-
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.

[Osaban]

-{ Quote: "Oh yeah, really? From the Agnitum developers I know they are using user-mode hooks in security purposes and can't be considered any "strong". KIS's sandbox is officially limited and can't be considered as a strong security solution too. More examples?" }-

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?

[tzuk]

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.

[PrevxHelp]

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 :-\ 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.

[Wildest]

-{ Quote: "Could you outline what you aren't able to do on x64? Microsoft provides functionality to monitor (and this list is incomplete):" }-
I am most interested to see one of the anti-64 bit developers respond to this post, as it has been very enlightening.

[PrevxHelp]

-{ Quote: "
Anyway, we're mainly talking about classical HIPS and sandboxing for 64-bit, as black-listing/behaviour-blocking technology like Prevx or Avira can still function the same as far as I am aware." }-

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.

[PrevxHelp]

-{ Quote: ""...just a different implementation".

Exactly, which is why they are different. Also, Classical HIPS rely much less on the roll of the dice than eg. Prevx/Avira when blocking unexpected malware. This becomes very apparent when you consider that Classical HIPS does not require regular updating of a (cloud) database." }-

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.

[Ilya Rabinovich]

-{ Quote: "
- 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" }-
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".

[firzen771]

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.

[PrevxHelp]

-{ Quote: "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." }-

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.

-{ Quote: "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"." }-

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 :)

-{ Quote: "Also why do I keep hearing that Defense+ gets bypassed with some tests in 64-bit, and not in 32-bit?" }-

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

[Wildest]

-{ Quote: "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." }-

-{ Quote: "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 :)" }-
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.

[Julian]

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.

-{ Quote: "
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!
" }-

[tzuk]

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?

[Ilya Rabinovich]

-{ Quote: "Driver installation requires a registry key change" }-
It's not per-process.

-{ Quote: "
section manipulation requires opening a section" }-
Opening thins section is legitimate. Manipulations are not :)

-{ Quote: "screen grabbing/input blocking can be covered without too much difficulty with more creative workarounds" }-
I see no legitimate ways to do this without relying on MS mechanisms.

-{ Quote: "I don't like when people say things are impossible, however" }-
You don't like physicists? :)

[PrevxHelp]

-{ Quote: "It's not per-process." }-

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 :)

-{ Quote: "Opening thins section is legitimate. Manipulations are not :)" }-

Manipulations can be prevented in other ways when first opened.

-{ Quote: "I see no legitimate ways to do this without relying on MS mechanisms." }-

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.

-{ Quote: "You don't like physicists? :)" }-
Indeed - I don't like natural physicists. Quantum mechanics/particle physicists, however, give me the room to work in ;)

[fax]

Aaah! What a refreshing discussion... :thumb:
Thank you all for the very interesting exchange, we should see more of this in here!

Cheers,
Fax

[wat0114]

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.

[Wildest]

-{ Quote: "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." }-
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?

[tzuk]

-{ Quote: "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." }-

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?

[PrevxHelp]

-{ Quote: "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?" }-

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.

[wat0114]

-{ Quote: "LOL, is the only interesting thing about a boxing match, the end result? :D
" }-

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?

[Wildest]

-{ Quote: "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?" }-
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.

[Wildest]

-{ Quote: "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." }-
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?

[Ilya Rabinovich]

-{ Quote: "
Manipulations can be prevented in other ways when first opened." }-
Wrong answer. The manipulation I mean can't be prevented this way.

-{ Quote: "
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)." }-
Bad idea.

-{ Quote: "
Indeed - I don't like natural physicists. Quantum mechanics/particle physicists, however, give me the room to work in ;)" }-
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.

[Ilya Rabinovich]

-{ Quote: "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." }-
User-mode hooks are not fine- they are weak. And if you are going to build PrevX x64 with it- poor users who will rely on such the "defense"...

[PrevxHelp]

-{ Quote: "User-mode hooks are not fine- they are weak. And if you are going to build PrevX x64 with it- poor users who will rely on such the "defense"..." }-

Prevx x64 has 0 usermode hooks - feel free to check for yourself. You and tzuk are misreading my post.

[PrevxHelp]

-{ Quote: "Wrong answer. The manipulation I mean can't be prevented this way." }-

If you would be so kind as to enlighten all of us and Microsoft on what flaw you've discovered in Windows' access management, that would be useful :)

-{ Quote: "Bad idea." }-

I disagree - a program is not malicious if it only reads screen contents. If it tried to then email them somewhere or other nefarious actions, then it would be malicious but you will be telling a lot of blind users that they can't use their PCs anymore.

This is the flaw in leaktests and why developers shouldn't spend time adding protection for leaktests - they don't represent real threats.

[PrevxHelp]

-{ Quote: "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?" }-

I need to stop being anecdotal :blink: I'm not suggesting that Sandboxie or any other software uses usermode hooks on 64bit. It is possible to block leaktest with usermode 64bit hooks but not real malware.

If Sandboxie only used usermode hooks, no one would ever use it because it would be flawed conceptually.

[Ilya Rabinovich]

-{ Quote: "If you would be so kind as to enlighten all of us and Microsoft on what flaw you've discovered in Windows' access management, that would be useful" }-
ZwMakeTemporaryObject.

[Ilya Rabinovich]

-{ Quote: "I disagree - a program is not malicious if it only reads screen contents." }-
You definitely do not understand the sandbox ideology. Sad.

[tzuk]

-{ Quote: "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." }-

Today it's a leaktest, tomorrow it's a trojan in the wild. Not good enough! Anti-viruses can afford to have this attitude because they're not primarily behavior blockers, and in any case, failing is built into the concept: Either they identify the virus or they don't. Front-line security software like Sandboxie doesn't have this luxury.

-{ Quote: "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?" }-

YES!

-{ Quote: "If Sandboxie only used usermode hooks, no one would ever use it because it would be flawed conceptually." }-

Thank you. That's exactly my point. I can't implement some things except as user-mode hooks, and I won't implement them as user-mode hooks because that would be a false sense of security.

You asked earlier about an example of missing functionality. There's a bunch of kernel services for connecting processes via LPC ports. Where are the kernel interfaces to supervise this?

[PrevxHelp]

-{ Quote: "Today it's a leaktest, tomorrow it's a trojan in the wild. Not good enough! Anti-viruses can afford to have this attitude because they're not primarily behavior blockers, and in any case, failing is built into the concept: Either they identify the virus or they don't. Front-line security software like Sandboxie doesn't have this luxury." }-

What is the threat of a program reading the screen if it can't do anything with it? In my opinion, a program that just reads screen contents and shows them back on screen to the user is not malicious - screen savers do this, screen readers, screen magnifiers, user-initiated screenshot programs, etc. etc.

-{ Quote: "Thank you. That's exactly my point. I can't implement some things except as user-mode hooks, and I won't implement them as user-mode hooks because that would be a false sense of security.

You asked earlier about an example of missing functionality. There's a bunch of kernel services for connecting processes via LPC ports. Where are the kernel interfaces to supervise this?" }-

Unfortunately I can't do your work for you. It is possible, that's all I can say.

[PrevxHelp]

-{ Quote: "You definitely do not understand the sandbox ideology. Sad." }-

Thank you for another personal attack akin to your previous one insulting my intelligence after swearing at me in another thread. I will continue to not use personal attacks.

My same comment applies here: "What is the threat of a program reading the screen if it can't do anything with it? In my opinion, a program that just reads screen contents and shows them back on screen to the user is not malicious - screen savers do this, screen readers, screen magnifiers, user-initiated screenshot programs, etc. etc."

I agree with sandboxing a program from the harddisk/internet/registry/OS/etc. but if you really want to have a secure sandbox and you consider echoing screen contents back on the screen to be malicious, wouldn't drawing on the screen be equally malicious?

What does your sandbox do if a program tries to draw all across the screen, potentially preventing the user from working? Is Photoshop malicious because it has an eye-dropper function which lets you get a pixel from the screen and then it draws on the screen as well?

[tzuk]

-{ Quote: "What is the threat of a program reading the screen if it can't do anything with it?" }-

I'll leave it to Ilya to debate the technical details with you, as I'm not familiar with clipboard protection.

But it seems to me that you're arguing that Ilya's approach of stopping a clipboard attack at the source (the moment when clipboard contents are copied) is the same as your approach of trying to guess, at the time of use, whether the pasted contents came from the clipboard.

Clearly, it's not the same.

-{ Quote: "Unfortunately I can't do your work for you. It is possible, that's all I can say." }-

Well, that's convenient. When I say there's missing functionality, you don't think twice before injecting doubt into the discussion by listing a long list of available kernel interfaces and asking (in so many words) what could I possibly be missing. Then I tell you what I'm missing, and you just blow it off. Nice.

[PrevxHelp]

-{ Quote: "I'll leave it to Ilya to debate the technical details with you, as I'm not familiar with clipboard protection.

But it seems to me that you're arguing that Ilya's approach of stopping a clipboard attack at the source (the moment when clipboard contents are copied) is the same as your approach of trying to guess, at the time of use, whether the pasted contents came from the clipboard.

Clearly, it's not the same." }-

We're primarily discussing the reading of screen contents (i.e. graphical screen contents from BitBlt/StretchBlt/etc.)

-{ Quote: "Well, that's convenient. When I say there's missing functionality, you don't think twice before injecting doubt into the discussion by listing a long list of available kernel interfaces and asking (in so many words) what could I possibly be missing. Then I tell you what I'm missing, and you just blow it off. Nice." }-

Not trying to blow it off, but don't think you HAVE to be in kernel mode for everything. While you can't prevent a program in the sandbox from following a usermode hook, a LPC calls a local function in another process. I'll leave you to fill in the blanks :)

[PrevxHelp]

-{ Quote: "What is your position on the function Ilya mentioned, this ZwMakeTemporaryObject?" }-

:-\ It's irrelevant - it can be easily blocked with a simply privilege check as I suggested (callers need at least the DELETE privilege on the handle AFAIK).

[Page42]

-{ Quote: "Some of us prefer to see not only the facts, but the process by which the facts were derived as well." }-
Absolutely. Other things besides facts are being revealed in the exchanges I have read on this thread...

[PrevxHelp]

-{ Quote: "That's an interesting point about a program/process that can't do anything except read the screen. I personally also think there isn't any threat here, although perhaps there is a privacy threat?

I know some people here on Wilders here are quite particular about their privacy, and at least one has asked Xiaolin about implementing a tool into MD to block everything from reading the system's registry, for privacy's sake. Is reading the screen a similar issue do you think?" }-

I agree with reading the screen primarily being a privacy issue (and reading the registry is probably even more of an issue - hadn't thought of that one :)) but the privacy implications occur only if the program was to try and save that data to the disk or email it out or transmit it elsewhere. If you have a program which merely shows you what is on your screen or in your registry and then does nothing with it, I don't see how that could possibly be seen as malicious.

[Einsturzende]

Mr. PrevxHelp instead "teaching" developers who are in business for years about concept of their protection, I suggest you to go to your marketing department and tell them that your prog. needs real trial mode and not rouge like false notification unlimited trial...
(http://www.wilderssecurity.com/member.php?u=87864)

[PrevxHelp]

-{ Quote: "Mr. PrevxHelp instead "teaching" developers who are in business for years about concept of their protection, I suggest you to go to your marketing department and tell them that your prog. needs real trial mode and not rouge like false notification unlimited trial...
(http://www.wilderssecurity.com/member.php?u=87864)" }-

This isn't relevant to this discussion but feel free to post in our forum: http://www.wilderssecurity.com/forumdisplay.php?f=104

[tzuk]

-{ Quote: "Not trying to blow it off, but don't think you HAVE to be in kernel mode for everything. While you can't prevent a program in the sandbox from following a usermode hook, a LPC calls a local function in another process. I'll leave you to fill in the blanks" }-

That's creative thinking indeed. :) I have to admit, it is a very amusing thought -- in a good way.

Alright, I take back what I said in my last post. I think this could work, but I'd be very uncomfortable with it. One of the things that is important to me with Sandboxie is to not interfere with programs running outside its supervision. Your idea requires injecting code into every un-sandboxed process in the system, including system processes, and that might trigger a barrage of warnings by other security software in the system, and who knows what other conflicts.

But I have to agree, you said that it should be possible, and your idea seems like it might be possible. And I guess I never said that you can't suggest crazy ideas. ;)

[Paul Wilders]

one post removed - please post specific Prevx questions over on the Prevx Support Forums

[PrevxHelp]

-{ Quote: "That's creative thinking indeed. :) I have to admit, it is a very amusing thought -- in a good way.

Alright, I take back what I said in my last post. I think this could work, but I'd be very uncomfortable with it. One of the things that is important to me with Sandboxie is to not interfere with programs running outside its supervision. Your idea requires injecting code into every un-sandboxed process in the system, including system processes, and that might trigger a barrage of warnings by other security software in the system, and who knows what other conflicts.

But I have to agree, you said that it should be possible, and your idea seems like it might be possible. And I guess I never said that you can't suggest crazy ideas. ;)" }-

:) It also may be worth mentioning that running from SSDT hooks or other means within the kernel that Sandboxie currently uses is still running yourself inside the context of each process across the system so there is technically little to no difference between the potential for conflicts (probably even less because it is hard[er] to bring down the entire system from usermode alone if there was a bug in the implementation).

[Wildest]

As there seems to be some resolution between the developers, I will now throw in my useless uninformed opinion with the others...

Microsoft has been hardening security since Windows 2003 and XP SP1.
I find it hard to believe that given Microsoft's steady increase in securing their OSes, and the hundreds of mathematicians and computer scientists at their disposal all over the world, that they would make x64 inherently less secure than x32.

Has any of these solo developers been involved in creating an OS, that they can be critical of OS design decisions? :-\

[Julian]

It's really interesting to see how developers of several programs discuss the potential of proactive anti-malware.

Well, I don't know how the Kaspersky x64 sandbox works in detail but it's using usermode hooks for sure. And if I didn't look over something here still my question if there is anything like safe user mode hooks is still not treated. Until I see a program that really jumps out of the sandbox what means that it writes to the real file system or the real registry I don't believe it that it's "totally insecure". The x64 HIPSes of Outpost and Kaspersky can also intercept window messages, dll injections, global hooks (KIS just partially) and several other process modifications.

So please answer if you know a possible method or if you have an idea: Is it possible to make non ring 0 hooks (almost) unhookable due to their protection?
Thank you, tzuk and PrevxHelp :)

[Wildest]

-{ Quote: "You definitely do not understand the sandbox ideology. Sad." }-
IMO a sandbox can be considered as essentially an "OS within an OS".
Microsoft doesn't want an OS environment created in their OS, for reasons I can only speculate.

Therefore sandboxing is a great idea, but ultimately destined for extinction.
Unfortunate, since the technology was just about ready for primetime.

[PrevxHelp]

-{ Quote: "
So please answer if you know a possible method or if you have an idea: Is it possible to make non ring 0 hooks (almost) unhookable due to their protection?
Thank you, tzuk and PrevxHelp :)" }-

I'm going to try and not get too technical while explaining something very technical :) The problem with ring 3 (usermode) hooks over the target process is that they only prevent access to system functions if the author of the hooked program is not intentionally avoiding the hooked functions.

For example, if you have a hook over the import of CreateFileA(), a process can dynamically import that function using a call like GetProcAddress(). If you then hook GetProcAddress() to re-hook any attempts to circumvent the import hook, they can get one layer lower and use LdrGetProcedureAddress(). If you try hooking that, they could write their own export parser and get the function on their own.

An alternate strategy to this would be to use a trampoline/detour method which actually overwrites the code of the function-to-be-hooked so that regardless of how the function itself is obtained, the hook code will be called. However, even if you apply a detour hook over CreateFileA(), a process could use CreateFileW() to write and it would circumvent the hook. To solve this, you can go a level lower and hook NtCreateFile(), but then a process can go one level lower and skip the NtCreateFile() all together and just directly call "function 0x3C" (the service number of NtCreateFile on Vista SP2) through the SYSENTER/INT 2Eh instruction (which is the barrier between usermode and kernelmode).

NtCreateFile exists in ntdll.dll and ntdll.dll is mostly just an ease-of-use wrapper around calls to ntoskrnl.exe which actually performs the specified function. Any sane software developer is going to use CreateFileA/W() or, for specific system-level developers, maybe they'll venture into NtCreateFile() but each level lower creates an added barrage of complexity.

Going down all the way to 0x3C thru SYSENTER produces massive headaches for any developer looking for cross-platform support (the "0x3C" changes between each OS version, service pack, and sometimes between hotfixes). However, malware authors generally don't care about mass-portability so they try and get as low as possible and using 0x3C/SYSENTER from usermode gets past any usermode hook.

Therefore, when working within the local process, it is not possible to prevent an application from circumventing your usermode hooks unless you're emulating the process' instructions and intercepting the execution of it (which dramatically impacts the performance).

However, by sitting in kernel mode, it is possible to still provide adequate protection because even though it is possible to call 0x3C directly to circumvent usermode protection, kernel mode hooks will still definitely be called (as the barrier prevents processes from directly calling kernel functions).

Ironically, malware authors cast even more suspicion on themselves when using a direct 0x3C call and this can be additionally used to heuristically identify threats or generically block specific operations so while it can be useful to bypass certain systems, it is a double-edged sword :)

Hope that helps! :)

[tzuk]

-{ Quote: ":) It also may be worth mentioning that running from SSDT hooks or other means within the kernel that Sandboxie currently uses is still running yourself inside the context of each process across the system so there is technically little to no difference between the potential for conflicts (probably even less because it is hard[er] to bring down the entire system from usermode alone if there was a bug in the implementation)." }-

I think there some small measure of difference between running a small piece of code in the context of each process, just small enough to ask "am I sandboxed" and bail if not;

And then your idea, which suggests actually modifying (the system DLL in) every process. So it's a different level of invasiveness into un-sandboxed processes. And if another HIPS in the system should choose to complain about this, could you really blame it?

I do think your idea is cool, as a solution to a puzzle, but I think as a real world solution, it is inappropriate. It's bending over backwards, don't you think?

I'm not prepared to put crazy hacks into Sandboxie just because Microsoft will not even consider additional kernel interfaces, unless one complains to leading tech web sites.

[PrevxHelp]

-{ Quote: "I think there some small measure of difference between running a small piece of code in the context of each process, just small enough to ask "am I sandboxed" and bail if not;" }-

There are a number of optimizations/cross checks which can be done to limit the scope of potential problems but I do agree it would be marginally more invasive. Personally, I would be willing to put up with some additional hooks to be able to use Sandboxie or another security product.

-{ Quote: "And then your idea, which suggests actually modifying (the system DLL in) every process. So it's a different level of invasiveness into un-sandboxed processes. And if another HIPS in the system should choose to complain about this, could you really blame it?" }-

I wouldn't blame them, but I doubt many HIPS are going to complain very loudly on usermode hooking like this, especially because Microsoft heavily uses shim libraries which hook using Detours to provide better compatibility for their software. And anyway, it is possible to hook in usermode without a HIPS product being aware of it if you do it from a driver :)

-{ Quote: "I do think your idea is cool, as a solution to a puzzle, but I think as a real world solution, it is inappropriate. It's bending over backwards, don't you think?" }-

It is bending over backwards a little, but developers already should be pretty flexible so a back-bend shouldn't be too difficult if we're already doing flip-flops to accomplish most of what we do :)

-{ Quote: "I'm not prepared to put crazy hacks into Sandboxie just because Microsoft will not even consider additional kernel interfaces, unless one complains to leading tech web sites." }-

All that Microsoft would have to do is extend some of their existing interfaces to make it easier to do some of these things. I suspect they will eventually make it easier to work with but right now it is probably a matter of getting obscure workarounds in place to get that critical last <1% of functionality supported.

[Wildest]

-{ Quote: "I think it's too early to call if sandboxing is destined for extinction. Why would Kaspersky implement sandboxing (for the first time ever) then? Why are Comodo planning to implement sandboxing? It seems sandboxing is getting more and more popular.

In my opinion, sandboxing is the best form of security, particularly Sandboxie with its combination of sandboxing AND start/run/internet/block/read-only restrictions etc." }-
I was about to respond, but apparently the match is not over, so I deleted it.

Personally, I would prefer to see the developers battle it out without the distraction of uninformed user opinions.

[Wildest]

-{ Quote: "By the way, PrevxHelp and Tzuk should join forces and develop a program that combines the technology of Prevx and Sandboxie haha." }-
As both approach the question of "what is secure?" from different angles, this can only be characterised as "wishful thinking".

Regards,
W.

[Wildest]

-{ Quote: "Again, more irony and dare I say it, hypocrisy haha. Relax relax, just making an observation mate.

To be honest, I created this thread in the hope that Ilya, Xiaolin and Tzuk would make comments and give useful insights. That is exactly what is happening, and I just want to thank Ilya, Tzuk and PrevxHelp for contributing in this thread." }-
If you created this thread in the hope that Ilya, Xiaolin and Tzuk would make comments, then maybe you should allow them to do so without helping to saturate this thread with uninformed opinions.

[Wildest]

-{ Quote: "Again, the hypocrisy is ringing out loud and clear. My "uninformed opinion" was in response to your "uninformed opinion". This is a public forum, and I created this thread mate. At the moment, you are doing more harm to this thread with these attacks directed at me. Let's please get back on topic and suppress our pride for once, for the sake of this thread." }-
Friend, no one cares about your opinion of my comments. ::)

Can't you give professionals some space to come to a resolution? ???

[Wildest]

-{ Quote: "I'm going to try and not get too technical while explaining something very technical :) The problem with ring 3 (usermode) hooks over the target process is that they only prevent access to system functions if the author of the hooked program is not intentionally avoiding the hooked functions.

For example, if you have a hook over the import of CreateFileA(), a process can dynamically import that function using a call like GetProcAddress(). If you then hook GetProcAddress() to re-hook any attempts to circumvent the import hook, they can get one layer lower and use LdrGetProcedureAddress(). If you try hooking that, they could write their own export parser and get the function on their own.

An alternate strategy to this would be to use a trampoline/detour method which actually overwrites the code of the function-to-be-hooked so that regardless of how the function itself is obtained, the hook code will be called. However, even if you apply a detour hook over CreateFileA(), a process could use CreateFileW() to write and it would circumvent the hook. To solve this, you can go a level lower and hook NtCreateFile(), but then a process can go one level lower and skip the NtCreateFile() all together and just directly call "function 0x3C" (the service number of NtCreateFile on Vista SP2) through the SYSENTER/INT 2Eh instruction (which is the barrier between usermode and kernelmode).

NtCreateFile exists in ntdll.dll and ntdll.dll is mostly just an ease-of-use wrapper around calls to ntoskrnl.exe which actually performs the specified function. Any sane software developer is going to use CreateFileA/W() or, for specific system-level developers, maybe they'll venture into NtCreateFile() but each level lower creates an added barrage of complexity.

Going down all the way to 0x3C thru SYSENTER produces massive headaches for any developer looking for cross-platform support (the "0x3C" changes between each OS version, service pack, and sometimes between hotfixes). However, malware authors generally don't care about mass-portability so they try and get as low as possible and using 0x3C/SYSENTER from usermode gets past any usermode hook.

Therefore, when working within the local process, it is not possible to prevent an application from circumventing your usermode hooks unless you're emulating the process' instructions and intercepting the execution of it (which dramatically impacts the performance).

However, by sitting in kernel mode, it is possible to still provide adequate protection because even though it is possible to call 0x3C directly to circumvent usermode protection, kernel mode hooks will still definitely be called (as the barrier prevents processes from directly calling kernel functions).

Ironically, malware authors cast even more suspicion on themselves when using a direct 0x3C call and this can be additionally used to heuristically identify threats or generically block specific operations so while it can be useful to bypass certain systems, it is a double-edged sword :)

Hope that helps! :)" }-
After over three years of reading comments on this forum, this is greatest post I have ever read.

It inspires confidence, and I will definitely add Prevx to my list of "must try" software.

Best regards,
W.

[Dregg Heda]

-{ Quote: "No, because of digital signatures, not because of the PatchGuard." }-

Can digital signatures provide all the protection provided by patchguard? If so then why stick with patchguard?

[Dregg Heda]

-{ Quote: "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." }-

I think you will find that they will be much better at thinking out of the box once it becomes financially viable to do so. Necessity being the mother of all invention!

[Dregg Heda]

-{ Quote: "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?" }-

Id like Ilya's response to this as well.

[Dregg Heda]

-{ Quote: "
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." }-

Ah thanks for that Tzuk!

[PrevxHelp]

-{ Quote: "Can digital signatures provide all the protection provided by patchguard? If so then why stick with patchguard?" }-

No, digital signatures allow a user/the OS to know what company a certain program or driver came from but outside of that they don't provide any additional protection. Granted, a vendor needs to go through hoops to get a digital signature for integrating with the kernel now but it is possible that the vetting process isn't perfect (or that "two" vendors will work together - one creating "legitimate" software which intentionally, but apparently unintentionally, exposes a flaw and the other exploiting that flaw).

The benefit of Patchguard is that it levels the playing field for most software developers, forcing them to use a standardized interface to do things that have been largely haphazardly done. It's still very possible to mess things up using the new framework but it is less likely.

Malware authors can, of course, still get around Patchguard (so can vendors but they will quickly have their kernel rights revoked) but this would require them to first have a digitally signed driver and then a massive amount of hackery - far more than in 32bit and it is orders of magnitude more difficult.

[Dregg Heda]

-{ Quote: "
1) To be honest, I created this thread in the hope that Ilya, Xiaolin and Tzuk would make comments and give useful insights. That is exactly what is happening, and I just want to thank Ilya, Tzuk and PrevxHelp for contributing in this thread.

2) I think Tzuk has got some ideas from PrevxHelp, so this thread has probably been very beneficial to all. It will be interesting to see how Sandboxie develops in the next few years, as more and more people start using 64-bit systems." }-

1) This is a fantastic thread ssj, and I would also like to thank Tzuk, prevxHelp and Ilya, especially the former two, for their participation. The exchanges between the developers gives one a better idea of the issues with patchguard and the possible workarounds.

2) Whats really interesting is that prevxhelp is a competitor so one would assume that whatever tips or hints he gives are merely the tip of the iceberg in terms of what is possible. It just makes one wonder what other tips and workarounds prevx have figured out, which could be utilised by guys like Ilya and Tzuk.

All of this just confirms my initial suspicions that the only real limiting factor was the popularity of 64bit, and once its market share was viable developers would find a way, atleast to deal with most problems.

[Dregg Heda]

-{ Quote: "No, digital signatures allow a user/the OS to know what company a certain program or driver came from but outside of that they don't provide any additional protection. Granted, a vendor needs to go through hoops to get a digital signature for integrating with the kernel now but it is possible that the vetting process isn't perfect (or that "two" vendors will work together - one creating "legitimate" software which intentionally, but apparently unintentionally, exposes a flaw and the other exploiting that flaw).

The benefit of Patchguard is that it levels the playing field for most software developers, forcing them to use a standardized interface to do things that have been largely haphazardly done. It's still very possible to mess things up using the new framework but it is less likely.

Malware authors can, of course, still get around Patchguard (so can vendors but they will quickly have their kernel rights revoked) but this would require them to first have a digitally signed driver and then a massive amount of hackery - far more than in 32bit and it is orders of magnitude more difficult." }-

I see. Thanks for your response. It seems to me that getting the drivers signed is the more difficult part of the equation than hacking patchguard.

Also if windows 64 is inherently more secure out of the box, then one wonders if using slightly weakened antimalware solutions, in comparison to 32bit, might not actually produce equivalent or perhaps even superior protection to that achieved by those same solutions on 32-bit.

For example if a vendor could get the 64bit version of their product to provide lets say 90% of the protection provided by the 32bit version, would this, together with the extra protection afforded by digitally signed drivers and patchguard make up for whatever protection was lost by trying to make the products comply with the limitations introduced by patchguard in the first place.

[Kees1958]

-{ Quote: "
For example if a vendor could get the 64bit version of their product to provide lets say 90% of the protection provided by the 32bit version, would this, together with the extra protection afforded by digitally signed drivers and patchguard make up for whatever protection was lost by trying to make the products comply with the limitations introduced by patchguard in the first place." }-

Let me try to resume what I understand of PrevXHelp/Tzuk/Ilya

1. A behavioral HIPS looks at the same intrusions as a classical HIPS, only difference is that Behavioral HIPS (or one combining several strategies such as PrevX), analyses the pattern of intrusions and only pops-up a warning when something is suspicious.

2. A virtualisation or policy management HIPS are also clasiscal HIPS, only they apply a strategy to don't ask the user every time an intrusion occurs:
- Sandboxie: don't make the changes in the real world, but in a (temporary) copy
- DefenseWall: prevent the contained application OR the file it has created in a stronger than limited user environment, so it can do not lasting damage. Everything within these bounderies is allowed, everything exeding, denied

==> Tsuk, Ilya and Xioalin need a secured and safe boundery which prevents the process or object from crossing the line. PrevX on the other hand also has a behavioral analysis component. When a developer digs three levels beneath the obvious and easy high level interface, this automatically makes it a very suspicious action. Because there is no reason for a normal developer to use these low level commands. This means that PrevX can send a programs showing this behavior for analysis to their servers (behavioral trigger) and mark it (blacklist) as malware when it indeed performs malicious actions.

==> This explains why PrevX can find ways to deal with the limitations and Tzuk, Ilya and Xioalin not.

==> Interesting claim of some of the one man bands is that some of the larger security companies, just keep the same basic architecture under x64, while missing the guarantee to fully protect, because 90% covered is no real security solution. When sandboxie would virtualise 99,99 % of the actions of a contained program, the 0,01% it did not virtualise would most likely screw the integrity of the system (same applies for DefenseWall in a different manner)


4. Signed drivers means that the producer of the software is "trustworthy". A signed driver is software which can have exploits (software bugs in untested situations which could be exploited by malware), or even worse as PrevX pointed out, two companies could work together (one offering an opening, the other exploiting it). So yes signed drivers would be a solution when no villians/cyber criminals lived in this world, signed drivers just raises the bar from script kiddies to professional malware writers and funds of criminals backing the developors to write malware. EDIT please understand that this is cinically intended: Signed drivers are no real soluton


Cheers Kees (please respond when this is not correct)

[Ilya Rabinovich]

-{ Quote: "My same comment applies here: "What is the threat of a program reading the screen if it can't do anything with it?"" }-
OK, I got it- you don't lock your flat because the the hall is secured. ;D

[Ilya Rabinovich]

-{ Quote: ":-\ It's irrelevant - it can be easily blocked with a simply privilege check as I suggested (callers need at least the DELETE privilege on the handle AFAIK)." }-
Yes, it is one of the possible solutions. Not ideal, but possible...

[Ilya Rabinovich]

-{ Quote: "Can digital signatures provide all the protection provided by patchguard?" }-
In fact, it's the solution protecting the platform against rootkits. It is possible to write a rootkit with official driver-level filtering API + DKOM.

-{ Quote: "
If so then why stick with patchguard?" }-
I don't know. I don't work for MS. :)

[Ilya Rabinovich]

-{ Quote: "If they "are identical under the hood at the kernel level", with the only difference being "the way they alert the user", then why are Xiaolin, (Tzuk and Ilya) struggling to find ways to migrate their products to 64-bit, and even claiming that it's "impossible"?" }-
You see, there is one more thing here- at x32, if we find a new way malware can penetrate, it is quite easy to bring a solution. With x64 restrictions, we don't have such the confidence. At least, as you can see, screen grabbing protection is the real problem. Same issue with the "virtual memory" subsystem and few other things must be covered.

[Ilya Rabinovich]

-{ Quote: "Id like Ilya's response to this as well." }-
I have no idea about third-party software. I can say only for my software and my work.

[Kees1958]

-{ Quote: "Thanks Kees for that post - seems like it's a very good summary of what's been discussed so far.

Which brings me back to this point that PrevxHelp made earlier in this thread:


If they "are identical under the hood at the kernel level", with the only difference being "the way they alert the user", then why are Xiaolin, (Tzuk and Ilya) struggling to find ways to migrate their products to 64-bit, and even claiming that it's "impossible"?" }-

PrevXHelp made an execellent post explaining it, I will try to explain in layman terms.

In an OS you have routines or modules which do a lot of task for you, comparable when you make a Macro or automate a sequence of actions with the task scheduler. So for intance when you would open a file, you could call a routine (easy accesible even for script languages) that would be called f.i. Open_File. This Open_File would prompt a standard dialog box with your defined skin (or the default user style default of XP, Vista or Windows 7).
And the user can enter the file to open, or navigate to the correct folder and select.

So instead of writing all this code yourself, you can call these routines with one simple 'call' to this routine.

This FIle_Open routine also consists of pieces of code and commands. So instead of using the File_Open, I could call to a "function", or even a high level statement (doing just one thing for all OS-ses complying to a certain standard e.g. NT or x32 or x64) or a low level statement (only guranteed on a specific OS and a specific patch, because displacements etc could be different in the next patch). What PrevX explains and Ilya and Tzul are arguing, you can not stop this in x64. Only difference when I use a low level statement this in itself is suspicious (all programmers are lazy and try create as many functionality with the minimum amount of code), so one of the PrevX defense mechanismes kicks in (send it for analysis to the central servers).

Because there is no way to stop it, Ilya and Tzuk can not make their software work.

For PrevX that single user might be infected, but they can create a blacklist fingerprint to protect all their other users and possibly provide a post-intrusion cure for the poor user who is hit by this malware.

It is the reasons why animals live in flocks/heards etc. Only now there is a nice park ranger (prevX) who runs in with a heart-reanimation (do not know the proper english word for it) device and try to kick some live in the attacked animal. It also provides a photo of the villian so the flock/heard will run when they see it.


Also from the answers of PrevXHelp (it is at least 25 years has been passed since I was involved in IT as system architect/designer), it seems that Ilya and Tzuk are making it more of a principal discussion. PrevX help tackles most of their complaints when you correlate intrussion risk and impact (nearly every car which is sold can drive harder than the maximum speed limit, still government allows sales of those cars)

[tzuk]

-{ Quote: "The benefit of Patchguard is that it levels the playing field for most software developers, forcing them to use a standardized interface to do things that have been largely haphazardly done. It's still very possible to mess things up using the new framework but it is less likely." }-

I don't get how you can say it has any benefits, other than to Microsoft, after all we've talked about here.

For those who didn't understand the technical stuff -- think about a bank robber driving down some main street. The police used to be able to put road blocks on the main street, but now there is a law that says they can't interfere with the main street anymore. So PrevxHelp has an idea: The police will put road blocks on every street that branches off from the main street.

The bank robber is the malicious code. The police is Sandboxie. The new law is PatchGuard.

PrevxHelp I suppose you're quite proud of your clever little idea, but seriously, if PatchGuard requires such crazy solutions to real problems, then does it really have a benefit?

And please don't tell me that this is only a temporary situation until Microsoft develop new official interfaces. Because this temporary situation is built into the design of PatchGuard. There will always be some missing mechanism that Microsoft still has to address but is dragging its feet.

If Microsoft wanted to make the kernel more stable, they could stop pretending that people don't do stuff like hook SSDT. Imagine that instead of PatchGuard, they would offer an official Hook-Kernel-Service function?

I'm just amazed that you want to support something like PatchGuard which is effectively converting an open market into a tyranny and a bureaucracy. In all of history, concentrating power in the hands of a few, has never been a good idea.

[Ilya Rabinovich]

-{ Quote: "so much so that he has (jokingly) said that he will "sue" Microsoft if 64-bit becomes the norm" }-
I was serious, it's not a joke.

[Windchild]

I've chosen to mostly stay out of threads like this, because they generally don't accomplish too much beyond just making people angry at each other - as we can see from the personal attacks and gibes in this thread. But I'll chime in with one comment. Get your flamethrowers ready. ::)

-{ Quote: "
The bank robber is the malicious code. The police is Sandboxie. The new law is PatchGuard.
" }-

And that is exactly the problem with the thinking of many people, and especially with third party security software vendors: they think security is the responsibility of some third party, instead of the user and the author(s) of the operating system and installed software. One might call that "practical" thinking, but if you only apply that kind of thinking, we end up in a huge mess.

Sandboxie is not "the police", as in the group of persons hired officially by the government that represents the people to offer protection to said people from criminal elements. Sandboxie is "some private security guard company" or "a group of kind-hearted mercenaries" hired by the bank. Windows is the police. How good it is at being the police is a different issue. If one understands that Windows is the police, then one also understands that Microsoft is the government (as far as their own OS is concerned), and the government will generally try to make laws that make things easier for the police to perform their tasks. The government isn't trying to make life easier for mercenaries or private security contractors. No, the mercs and the private security contractors will have to try and follow the laws, or move to a different jurisdiction. The government doesn't want the mercs and private security guards to be setting up roadblocks all over the place - that's the job of the police. If that makes things harder for mercs and private security companies, tough. People generally want the police to be effective, even if it makes some private security companies unhappy. Hey, no private security company is going to like it when the police are so good at preventing robbers from ransacking your house that you don't hire their guards and buy their security service to protect your house. This is exactly what's going on in the Unix world with AV products: the AV guys are trying to hype their products up and yell Unix is going to need them so badly, but users just don't care, because they feel that generally the police (the operating system) does a good enough job.

If Microsoft makes its systems even a bit more secure - or to use the police analogy, if the government gives more authority and manpower to the police so they're more effective at protecting people - third party security people may end up being unhappy about it. That's life. One main gains, another man loses. The users - "the people" - should understand what motivates private security companies to complain about something the government and the police do or don't do.

And no, this isn't intended to be an insult to anyone. If someone feels insulted, sorry, wasn't my intention. I'm just calling it like I see it - and everyone who thinks about these things should already know it anyway. Let us imagine a different world where we have a new operating system called "Doors" that is made by someone called "Microsift", and it is the most fantastically secure OS ever seen - no-one has ever even heard of a case of any user of "Doors" being infected with anything. Let's imagine that this OS steals number one market position from a OS called "Windows" made by "Microsoft." Now, what do you think all the third party security software vendors are going to think? Think real hard: are they just all happy-joy-joy about the appearance of the "Doors" OS, or are they going to hate the thing for making the stuff they're trying to sell useless to most people? Answer that question, and you'll know one of many reasons why a lot of folks are whining about any security change or added protection Microsoft might ever make to their OS.

And to answer the questions the original poster made:

-{ Quote: "So what will you guys do when you eventually move to a 64-bit system?

Would any of you be willing to ditch DefenseWall in order to use a system that utilises more RAM? Would any of you be willing to ditch Malware Defender for the same reason?" }-

I will do exactly the same thing I've been doing on 32-bit systems. I would ditch absolutely any single piece of software for an operating system that supports a lot more RAM. Some security software? I'd ditch it every day of the week and twice on Sundays! I don't run my systems for security software. I run my systems for me to do useful things with them. Am I going to install some anti-malware software on my 64-bit systems? No. Am I going to care if some anti-malware doesn't work on 64-bit? No, absolutely not. Am I going to get the most out of my 64-bit systems in productive use, and still go without being infected, while saving money? Yeah.

Sounds good to me. ;D

[pbw3]

-{ Quote: "Answer that question, and you'll know one of many reasons why a lot of folks are whining about any security change or added protection Microsoft might ever make to their OS.
" }-
Does a "security change" guarantee "added protection"..!? :)

Back to the police analogy - A government restricts private security firms from using any kind of force against potential criminals, because now only the police (with additional powers) are allowed to do that.. but if in fact the police are not a lot more competent than they were before....

btw, I am not making a judgement on the software issue, simply asking the layman's question.. ie it depends on whether suddenly the police really are bucket loads more competent, or whether the total net effect may be reduced security / less personal freedom of choice / depending on whatever your personal criteria are..

Peter

[BG]

"jump in"
Excellent post Windchild. I totally agree. After reading this very educational thread it was begging the question ...Which is more important the OS (productivity) or the Security software. Seems like security software was coming before the OS instead of the other way around.
"jump out"

[tzuk]

-{ Quote: "And that is exactly the problem with the thinking of many people, and especially with third party security software vendors: they think security is the responsibility of some third party, instead of the user and the author(s) of the operating system and installed software. One might call that "practical" thinking, but if you only apply that kind of thinking, we end up in a huge mess." }-

Obviously I take the opposite side and I think there is a problem with YOUR thinking. I take it from what you write that you don't appreciate free competition and you prefer that one entity (in this case Microsoft) is responsible for each subject (in this case operating system and security). As I said before, history shows this kind of thinking produces sub-optimal results.

None of us is against Microsoft tightening the security of its operating system. In fact if the operating system was insecure to the extent that the very foundation is merely a facade, then none of our security tools would be any good anyway.

But what we are against (Ilya and I, anyway), is for the largest entity to make it difficult for smaller entities to participate in free competition.

You may not care about this, in fact it is obvious that you don't care about this. This is not unexpected and certainly you're not the only one with this opinion. But please just say that: Say that you prefer having more RAM to the availablity of some obsure security tool. But don't try to justify anti-competition behavior as better security.

Mandatory driver-signing by itself achieves the goal of blocking bad guys from infiltrating the lower levels of the system. I don't object to that. Only to PatchGuard, which seems to have the goal of blocking the good guys.

[Windchild]

Then some replies...

-{ Quote: "Obviously I take the opposite side and I think there is a problem with YOUR thinking. I take it from what you write that you don't appreciate free competition and you prefer that one entity (in this case Microsoft) is responsible for each subject (in this case operating system and security). As I said before, history shows this kind of thinking produces sub-optimal results.

None of us is against Microsoft tightening the security of its operating system. In fact if the operating system was insecure to the extent that the very foundation is merely a facade, then none of our security tools would be any good anyway.

But what we are against (Ilya and I, anyway), is for the largest entity to make it difficult for smaller entities to participate in free competition.

You may not care about this, in fact it is obvious that you don't care about this. This is not unexpected and certainly you're not the only one with this opinion. But please just say that: Say that you prefer having more RAM to the availablity of some obsure security tool. But don't try to justify anti-competition behavior as better security.

Mandatory driver-signing by itself achieves the goal of blocking bad guys from infiltrating the lower levels of the system. I don't object to that. Only to PatchGuard, which seems to have the goal of blocking the good guys." }-

No, I do appreciate free competition. Free competition is great. Although "anticompetitive" seems to be the buzzword of the day, that argument is really not convincing here. Free competition isn't just free for "you", it's free for "everyone", including Microsoft. So, if Microsoft happens to want to do something with their OS that prevents, even only partially, certain types of actions on it - like modifying system service tables - then that is within their rights. Even if you don't like it, because it also prevents you from doing that. It also prevents others from doing that with the same methods, so there is no unfairness to it at all.

How about you? How is your "free competition"? I mean, would you like to allow other third party software to make whatever modifications they want to Sandboxie, changing its functions to do things other than what it was meant to do by default? Would you want to allow people to patch Sandboxie to do things it was not made to do? No? So how come it is okay when you do that, but wrong and anticompetitive when Microsoft does that? Because Sandboxie is security software, and should protect itself from tampering? Sure, that makes sense. And Windows is an operating system, and the operating system is the single most important technical aspect of ... well, operating system security. The OS is the single most important "security software" on any system. So, it should definitely be allowed for the maker of an OS to try to limit what changes can be made on its OS.

I don't prefer "one entity" to be responsible for everything. I have nothing against people making security software. They're free to make it. People are free to use security software. If people feel like they need it, they probably should use it. Third party security software is great, if you like it - just as long as it doesn't cause stability issues. What I am against is those security software makers coming in to tell Microsoft or any company what they can do with their own software, like, say, Windows.

You say: "But what we are against (Ilya and I, anyway), is for the largest entity to make it difficult for smaller entities to participate in free competition."

And what does this mean? It means: "I want to do X to Windows to make my security software more effective, but Microsoft won't let me patch their OS kernel!" Apply some logical thinking here, people. This is how it works:
If you, the "smaller entities" get what you want, then you get free reign to patch the kernel and do your thing. But then, Microsoft doesn't get what they want, which is to prevent certain kind of kernel patching that is known to have caused stability and security issues in the past. I've seen so many systems where security software causes bluescreens with their kernel patching that it's not funny. Either you get what you want, or Microsoft gets what they want. One is going to be disappointed. But which side should that be? Should Microsoft, the maker of Windows, have the right to decide what they do to their own OS? Or should "smaller entities" be able to tell Microsoft what they can do to their own OS, even if Microsoft is only trying to prevent stability and security issues? To me at least, it is obvious that Microsoft should have the right to apply protection against kernel patching, even if it's weak, and even if it causes trouble for some security software. It's their OS. Just like you can protect your security software from third party modifications, so can Microsoft. That is not anticompetitive. The point at which it would become anticompetitive is if Microsoft started telling you that "Defensewall can patch the kernel all they want, because we like them, but Sandboxie can't, because we're just mean and nasty that way" or in other words if they made arbitrary, unreasonable changes that can have no other useful purpose except blocking some competing software from working. Microsoft has given the same rules (patchguard) to everyone. They apply to you, me, and company X equally. Their OS, their rules. It's not anticompetitive just to make something hard or impossible in the OS. Windows 32-bit can't run 64-bit software, but that is not anticompetitive against makers of 64-bit software. It's just a limitation that the author of the OS decided to put in, and applies equally to everyone. Patchguard is for blocking - or at least making more difficult - kernel patching that can cause serious stability and security issues. Microsoft should have done that a long time ago.

You said: "Say that you prefer having more RAM to the availablity of some obsure security tool." Yes, I prefer more RAM to obscure security tools. It would be kind of unwise of me if I didn't, since RAM is really quite useful for the things I do.


-{ Quote: "Does a "security change" guarantee "added protection"..!? :)" }-

No, of course it does not. Which is why I used the word "or" in that sentence. :) There aren't that many 100 % guarantees in the world, anyway. That wasn't the point. The point was, third party security software vendors will complain about anything that: a) may decrease demand for their security software by making the operating system itself more secure and/or b) will make it more difficult to code security software that can then be sold to people. And they will do this, even if the changes they are complaining about will actually make (some) systems more secure than before. Or in other words, security software vendors aren't some fearless white knights out only to protect us poor users - their main interest is quite often making money, which is only reasonable when you operate a business. So, when security software vendors complain about something, they are not necessarily complaining about users becoming less secure in the future, as if they had a great selfless desire to protect the users - they're more likely complaining about having a harder time to make and sell their own products.

-{ Quote: "Back to the police analogy - A particularly useless government (!) restricts private security firms from using any kind of force against potential criminals, because now only the police (with additional powers) are allowed to do that.. but if in fact the police are not a lot more competent than they were before.... " }-

If the government sucks, overthrow it, or move somewhere that has a better government. Sure, you can stick around and try to protect yourself from the screwups of a bad or useless government by hiring mercs and private security. That might work. Or it might not. The government will still be one that you don't trust. And I don't see why you'd want to deal with that kind of government.

-{ Quote: "btw, I am not making a judgement on the software issue, simply asking the layman's question.. ie it depends on whether suddenly the police really are bucket loads more competent, or whether the total net effect may be reduced security / less personal freedom of choice / depending on whatever your personal criteria are.. " }-

I think the main issue is that the operating system does provide a lot of protection that could be used, but it isn't "on" by default and people don't use it. Or in other words: the house has strong doors with good locks and steel bars blocking Windows, but people just leave the doors and windows completely unlocked and open because they're uneducated, and then install a burglar alarm they bought from some door-to-door salesman. And after that, they register in some forum and complain that their burglar alarm couldn't stop criminals from taking everything they had. Marvelous. ;D

Anything that makes it more difficult, even a little bit more difficult, to screw around with the kernel makes the operating system more secure. That is good. Sure, it might give some third party security software a really hard time if they want to do stuff in the kernel, it might even make some fabulous program break completely. But it still did make the operating system more secure. If you make operating systems, that should be your concern - making your OS more secure out of the box.

[Johnny123]

-{ Quote: "

Mandatory driver-signing by itself achieves the goal of blocking bad guys from infiltrating the lower levels of the system. I don't object to that. Only to PatchGuard, which seems to have the goal of blocking the good guys." }-

Assuming this article from Wikipedia (http://en.wikipedia.org/wiki/Kernel_Patch_Protection) is accurate, there are other reasons besides ensuring the financial demise of security software developers.

-{ Quote: "

Advantages

Patching the kernel has never been supported by Microsoft because it can cause a number of negative effects.[3] Kernel Patch Protection protects against these negative effects, which include:

* The Blue Screen of Death, which results from serious errors in the kernel.[11]
* Reliability issues resulting from multiple programs attempting to patch the same parts of the kernel.[12]
* Compromised system security.[2]
* Rootkits can use kernel access to embed themselves in an operating system, becoming nearly impossible to remove.[11]
* Products that rely on kernel modifications are likely to break with newer versions of Windows or updates to Windows that change the way the kernel works.[3]

Microsoft's Kernel Patch Protection FAQ further explains:

Because patching replaces kernel code with unknown, untested code, there is no way to assess the quality or impact of the third-party code...An examination of Online Crash Analysis (OCA) data at Microsoft shows that system crashes commonly result from both malicious and non-malicious software that patches the kernel.

– "Kernel Patch Protection: Frequently Asked Questions". 22 January 2007. http://www.microsoft.com/whdc/driver/kernel/64bitpatch_FAQ.mspx. Retrieved on 22 February 2007. " }-

People have been beating up on Microsoft for years because of their poor security and when they attempt to do something about it, it's another conspiracy of the Evil Empire.

I admit that, like Windchild, I could care less if any of this security software works on 64 bit or not. I use the features of the OS to secure my system and this is nothing new. Just out of curiosity, are you also opposed to limited user accounts, software restriction policies and DEP because they make your application redundant?

[Ilya Rabinovich]

-{ Quote: "So, if Microsoft happens to want to do something with their OS that prevents, even only partially, certain types of actions on it - like modifying system service tables - then that is within their rights." }-
Not really. Three problems here:

1. MS is officially monopolist both in the USA and Europe.

2. MS is providing a platform, not just an OS. At least, they talking this way. But me, Ronen and other developers do not see x64 as a platform for us.

3. There are people who would like to switch the PatchGuard off and install third-party security solutions can't work under the PatchGuard restrictions. Why MS prevent this? It's your right as a consumer!

Yes, if you don't like security program you can download and install another one, but can you download and install another OS this way?

[Ilya Rabinovich]

-{ Quote: "I use the features of the OS to secure my system and this is nothing new. Just out of curiosity, are you also opposed to limited user accounts, software restriction policies and DEP because they make your application redundant?" }-
And it's OK, but why other people have no rights to switch this thing off? Who made a decision for us? You can switch LUA, SRP, DEP, built-in firewall off, but can't do the same with PatchGuard! Have you ever seen a security software do not allow to switch itself off "due to security reasons"? Hah?

[Osaban]

-{ Quote: "Oh yeah, really? From the Agnitum developers I know they are using user-mode hooks in security purposes and can't be considered any "strong". KIS's sandbox is officially limited and can't be considered as a strong security solution too. More examples?" }-

-{ Quote: " 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?" }-

-{ Quote: " I have no idea about third-party software. I can say only for my software and my work." }-

You asked for more examples, but obviously you retreat to your to your own software whenever you don't have the answers. As far as I'm concerned all of the technical talk sounds very impressive to people who are not programmers, but I for one I'm not impressed at all about the arrogance displayed by some people who call themselves developers towards a company (MS) who is trying to rectify some of the criticism that has been addressed to them for years.

I'd rather call it paranoia of minorities, and if you are serious about suing MS, I'd like to know on which grounds you are going to do it.

[tzuk]

-{ Quote: "How about you? How is your "free competition"? I mean, would you like to allow other third party software to make whatever modifications they want to Sandboxie, changing its functions to do things other than what it was meant to do by default? Would you want to allow people to patch Sandboxie to do things it was not made to do? No? So how come it is okay when you do that, but wrong and anticompetitive when Microsoft does that?" }-

You're completely wrong: I don't mind it at all. I absolutely recognize that Sandboxie is not the only component in the system. I accept that Sandboxie might be hooking functions that were already hooked by someone else. The other side of that coin is that I don't make it difficult to hook things that Sandboxie already hooked. I try to make my hooks as friendly an accomodating as possible and limit conflicts with other software.

PatchGuard is not the security barrier in 64-bit Windows. Driving-signing is the security barrier that prevents random bits from the Internet from going into kernel mode. PatchGuard merely takes away my freedom to create a solid product for 64-bit Windows, and your freedom of choice to run whatever security software you need. Yet here you are defending that.

There is already at least one publicly available hooking toolkits that circumvent PatchGuard. (And as a side note, it's ironic which site hosts it.) It's just that no security developer will risk using such a toolkit. But the future wave of 64-bit rootkits will have no such compunctions about that.

-{ Quote: "But then, Microsoft doesn't get what they want, which is to prevent certain kind of kernel patching that is known to have caused stability and security issues in the past. I've seen so many systems where security software causes bluescreens with their kernel patching that it's not funny." }-

As I said in an earlier post: There are friendlier ways to approach this problem. These crashes are usually caused by independent developers hooking things in ways that turn out to be incompatible. Microsoft could extend the kernel to provide full hooking and chaining services. But for ten years, they never did, they stuck their head in the sand and ignored it completely. And now they chose to block it off entirely. And you're here defending this anti-competitive behavior.

You're saying it is their right to do what they want with their operating system. I understand, and I agree, that you can't always force someone to be friendly and play nice. But these are underhanded tactics, and I am sorry to see so many people, like you, defending that.

-{ Quote: "You said: "Say that you prefer having more RAM to the availablity of some obsure security tool." Yes, I prefer more RAM to obscure security tools. It would be kind of unwise of me if I didn't, since RAM is really quite useful for the things I do." }-

That's not all I said. This is what I said: I am ok with you saying more RAM is more important. I'm not ok with you needing to justify to yourself that anti-competition is really security measures, just so you can feel you're not siding with the company that employs underhanded tactics. I'd rather see you say "Unfortunately, I have to side with the company employing underhanded tactics, because more RAM is more important to me than obscure security software."

[Johnny123]

-{ Quote: "
Have you ever seen a security software do not allow to switch itself off "due to security reasons"? Hah?" }-

You have a point, but it's part of the OS and not a add-on application. Microsoft introduced limited user accounts with the NT systems, but this has basically been undermined by third-party applications that don't work properly or at all with a LUA, thus practically forcing MS to make an admin account the default so that inexperienced users don't go crazy. As any sensible person knows, this has also resulted in a drastic decrease in the default level of security in Windows.

Maybe MS is tired of third-party developers dictating what level of security is the default in order that their applications will work. Who knows?

At any rate, according to the Wikipedia article I quoted, some AV developers don't seem to have a problem with it, e.g., ESET, TrendMicro, AVG and Sophos, who published this article (http://www.betanews.com/article/Sophos-Microsoft-Doesnt-Need-to-Open-Up-PatchGuard/1161379239) about PatchGuard back in 2006.

That said, I guess anyone who can't live without a particular security app should just stick to 32 bit.

[Dregg Heda]

Kees:

Two fantastic posts back to back!:thumb:

[Windchild]

More answers:

-{ Quote: "
1. MS is officially monopolist both in the USA and Europe.

2. MS is providing a platform, not just an OS. At least, they talking this way. But me, Ronen and other developers do not see x64 as a platform for us.

3. There are people who would like to switch the PatchGuard off and install third-party security solutions can't work under the PatchGuard restrictions. Why MS prevent this? It's your right as a consumer!

Yes, if you don't like security program you can download and install another one, but can you download and install another OS this way?" }-

1. It's a little more complicated than that. Even if Microsoft has been punished for one anticompetitive practice does not mean everything they do is automatically anticompetitive. So, whether Microsoft has a monopoly over the OS market or not is irrelevant in this discussion: either there is an acceptable reason for the limitations set by kernel patch protection in Windows 64-bit or there isn't, and Microsoft's market share has nothing to do with that. And yes, there is a reason: stability.

2. A platform? But what does that matter? They provide the kind of "platform" that they want. That's their right as a software company. You provide the kind of security product you want, Microsoft provides the kind of OS they want. It doesn't matter if someone doesn't see Windows 64-bit as a platform for their software. If you don't like the platform, find a different one. It's not Microsoft's legal duty to change their software to please everyone's needs.

3. Probably for the same reason Microsoft doesn't let you uninstall the Windows graphical user interface and use some different GUI and window manager. It's a design choice. Microsoft's design choice, not mine, or yours. It's within their right to make that choice. And while anyone can say that anything and everything is within my right as a consumer, that don't make it so. I haven't seen any law that gives me a legal right to do stuff like uninstall a GUI from an OS or disable a kernel protection feature even if the author of the software tries to prevent it. Or more accurately, there is no legal requirement that demands that Microsoft should make it easy and simple for people to change the GUI or disable kernel protection features.

-{ Quote: "
Yes, if you don't like security program you can download and install another one, but can you download and install another OS this way?" }-

Uhh... yes? In fact, I do that quite frequently - download and install operating systems, I mean. http://distrowatch.com/ Quite a lot of info and links there, and after a few clicks you can find places to download and install another OS. A free one. And you never have to use Windows again. So, I'm not entirely sure what you meant by your question. But I'm sure I'll find out soon. ;D


-{ Quote: "You're completely wrong: I don't mind it at all. I absolutely recognize that Sandboxie is not the only component in the system. I accept that Sandboxie might be hooking functions that were already hooked by someone else. The other side of that coin is that I don't make it difficult to hook things that Sandboxie already hooked. I try to make my hooks as friendly an accomodating as possible and limit conflicts with other software." }-

That sounds nice. But then, consider this: is your way the only right way to do things? Everyone else is wrong? If someone, like Microsoft, wants to take some measures to decrease stability issues by making it harder to modify critical parts of their software, is that wrong? Not if you ask me. Your mileage may of course vary, but it would be unwise for you to expect that most other people would agree with your position in this case.

-{ Quote: "PatchGuard is not the security barrier in 64-bit Windows. Driving-signing is the security barrier that prevents random bits from the Internet from going into kernel mode. PatchGuard merely takes away my freedom to create a solid product for 64-bit Windows, and your freedom of choice to run whatever security software you need. Yet here you are defending that." }-

Here I am, defending that. Because "that" is a little bit more complicated than what you just claimed. ::) Kernel Patch Protection is not the "security barrier" in 64-bit Windows, no. What it is, is an attempt by Microsoft to protect the kernel from patching that has caused stability and security issues in the past. Not to protect against random bits from the internet, but against modifcations that may cause stability issues, even if such modifications are made by legit software. Seems like a sensible thing for Microsoft to do.

-{ Quote: "There is already at least one publicly available hooking toolkits that circumvent PatchGuard. (And as a side note, it's ironic which site hosts it.) It's just that no security developer will risk using such a toolkit. But the future wave of 64-bit rootkits will have no such compunctions about that." }-

Yeah, and Microsoft admits that the system isn't perfect. Most systems are not. So? It's still an entirely valid attempt at protecting the system from stability issues. As for rootkits, well, it's not like you have to run everything as admin and give everything omnipotent control over the entire OS. There are a lot of people in the world who don't care about rootkits, because there's only an astronomically small chance their systems could ever become infected with one.

-{ Quote: "As I said in an earlier post: There are friendlier ways to approach this problem. These crashes are usually caused by independent developers hooking things in ways that turn out to be incompatible. Microsoft could extend the kernel to provide full hooking and chaining services. But for ten years, they never did, they stuck their head in the sand and ignored it completely. And now they chose to block it off entirely. And you're here defending this anti-competitive behavior.

You're saying it is their right to do what they want with their operating system. I understand, and I agree, that you can't always force someone to be friendly and play nice. But these are underhanded tactics, and I am sorry to see so many people, like you, defending that." }-

You can say anticompetitive over and over again as many times as you want. But words do not change reality. It's not anticompetitive unless you can prove that it is, with reasonable, convincing arguments. I haven't seen that so far. The legal side? I'm not a lawyer, and laws in different countries vary a great deal. Anticompetitive in country X may not be so in country Y.

Microsoft could extend the kernel to do a lot of things. And then, they could choose to not do it. It is their right. Just like it is your right to add some feature to Sandboxie, or choose to not add that feature. Even if it makes life difficult for other software. Friendly and nice doesn't always cut it. MS has tried for years to make people write software that works with LUA. It didn't work. It will not work until they stop being friendly and start being mean, forcing people to write software that works or write software for a platform other than Windows. Friendly is for an ideal world, where people are out to make perfect software instead of making money, and saving anywhere they can, like for example in choosing not to implement LUA compatibility.

You can be sorry if you want, but I don't think that's needed here. Your opinion is that kernel patch protection is underhanded. In my opinion, it's simply the wise thing to do. You know what they say about opinions...

-{ Quote: "That's not all I said. This is what I said: I am ok with you saying more RAM is more important. I'm not ok with you needing to justify to yourself that anti-competition is really security measures, just so you can feel you're not siding with the company that employs underhanded tactics. I'd rather see you say "Unfortunately, I have to side with the company employing underhanded tactics, because more RAM is more important to me than obscure security software."" }-

I don't really care what people would rather see me say. I'll say what I think, and if that doesn't work for everyone, well, that's the way it is.

You see, I don't think kernel patch protection is anticompetitive or underhanded. I've already explained why I think so. It's not a security measure, it's an attempt to increase system stability by preventing certain types of kernel patching. That is, in my opinion, a good goal. People must learn to distinguish their opinions from facts. In your opinion, PatchGuard is underhanded. But where are the facts? In your opinion, it's anticompetitive. But where are the facts? There's just opinion. And some people will disagree with your opinion. And you know what is not a good way to get people to agree with your opinion? To keep saying "underhanded" and "anticompetitive" and "out to block the good guys" without ever providing any convincing proof to support such outrageous statements. Indeed, why on earth would Microsoft want to block something like Sandboxie specifically? What's Sandboxie to them? Certainly not a threat or competition. So why go through all the trouble of making PatchGuard just to mess with obscure security software most Windows users know nothing about? There's no reason Microsoft would do that. They're doing what they're doing because they want to improve Windows' stability.

But since we started down the "I'm sorry to see" road, here's something I'm sorry to see. I'm sorry to see professional programmers say stuff like "PatchGuard merely takes away my freedom to create a solid product for 64-bit Windows" while completely ignoring the obvious fact that kernel patch protection was intended to decrease certain types of stability issues that result from kernel patching, and was not intended only to make life hard for small security software companies.

[Dregg Heda]

-{ Quote: "

1) Sandboxie is not "the police", as in the group of persons hired officially by the government that represents the people to offer protection to said people from criminal elements. Sandboxie is "some private security guard company" or "a group of kind-hearted mercenaries" hired by the bank. Windows is the police. How good it is at being the police is a different issue. If one understands that Windows is the police, then one also understands that Microsoft is the government (as far as their own OS is concerned), and the government will generally try to make laws that make things easier for the police to perform their tasks. The government isn't trying to make life easier for mercenaries or private security contractors. No, the mercs and the private security contractors will have to try and follow the laws, or move to a different jurisdiction. The government doesn't want the mercs and private security guards to be setting up roadblocks all over the place - that's the job of the police. If that makes things harder for mercs and private security companies, tough. People generally want the police to be effective, even if it makes some private security companies unhappy. Hey, no private security company is going to like it when the police are so good at preventing robbers from ransacking your house that you don't hire their guards and buy their security service to protect your house. This is exactly what's going on in the Unix world with AV products: the AV guys are trying to hype their products up and yell Unix is going to need them so badly, but users just don't care, because they feel that generally the police (the operating system) does a good enough job.

If Microsoft makes its systems even a bit more secure - or to use the police analogy, if the government gives more authority and manpower to the police so they're more effective at protecting people - third party security people may end up being unhappy about it. That's life. One main gains, another man loses. The users - "the people" - should understand what motivates private security companies to complain about something the government and the police do or don't do.

2) And no, this isn't intended to be an insult to anyone. If someone feels insulted, sorry, wasn't my intention. I'm just calling it like I see it - and everyone who thinks about these things should already know it anyway. Let us imagine a different world where we have a new operating system called "Doors" that is made by someone called "Microsift", and it is the most fantastically secure OS ever seen - no-one has ever even heard of a case of any user of "Doors" being infected with anything. Let's imagine that this OS steals number one market position from a OS called "Windows" made by "Microsoft." Now, what do you think all the third party security software vendors are going to think? Think real hard: are they just all happy-joy-joy about the appearance of the "Doors" OS, or are they going to hate the thing for making the stuff they're trying to sell useless to most people? Answer that question, and you'll know one of many reasons why a lot of folks are whining about any security change or added protection Microsoft might ever make to their OS." }-

1) The problem is what happens if the "mercs" as you call them provided better protection back when there were no laws inhibiting their performance than the police does now even with the extended powers provided. Why should the bank suffer? Why should its customers, the good people of the country suffer?

2) No one is denying that 3rd party vendors are businesses/businessmen who have their own interests at heart. However on this issue they do have a point. As a consumer I should have a choice in how I wish to secure my system. I dont know about 64 bit, but in 32 bit not every version of windows has SRP. I know that registry hacks are available, but id rather not have to hack my system just to ensure a decent level of security. LUA can be vulnerable to usermode keyloggers and privilege escalation exploits. I know the latter arent common since almost everyone runs admin anyway. But if weakening 3rd party vendors means more people running LUA then we will see them increase and become more common.

Also theres the loss of functionality of running in LUA. I know I know its all the fault of lazy ass developers who dont know how to code properly, but maybe if the lazy ass coders at M$ were only smart enough to implement solutions like sbie and DW out of the box on their OS, I would be able to use my pc in admin without any worries or loss of functionality, being able to do whatever I want. So thats a two way street right there.

[Windchild]

-{ Quote: "1) The problem is what happens if the "mercs" as you call them provided better protection back when there were no laws inhibiting their performance than the police does now even with the extended powers provided. Why should the bank suffer? Why should its customers, the good people of the country suffer?" }-

Easy answer. Because the bank chose to operate in a country where the government occasionally makes laws the bank and their mercs don't like. If the bank feels like it's suffering, it can always try to change the government and the laws, or move to a different country. If they can't do that, then I guess that's one of the many tragedies of life. Nothing is perfect, and sometimes there is no happy end. There isn't any ethical reason for why the bank should suffer, as in "what has the bank done to deserve this suffering."


-{ Quote: "2) No one is denying that 3rd party vendors are businesses/businessmen who have their own interests at heart. However on this issue they do have a point. As a consumer I should have a choice in how I wish to secure my system." }-

And you do have a choice. You have a lot of choices. But not all choices that could theoretically be possible, in a world where Microsoft chose not to implement kernel patch protection. That, again, is how the world works. There is no legal requirement for the makers of operating systems to provide endless different methods for security software vendors to do their thing. I'm amazed that people don't understand this stuff. Perhaps they really do, and are only trying to mess with my poor old head for their amusement. ;D

-{ Quote: "Also theres the loss of functionality of running in LUA. I know I know its all the fault of lazy ass developers who dont know how to code properly, but maybe if the lazy ass coders at M$ were only smart enough to implement solutions like sbie and DW out of the box on their OS, I would be able to use my pc in admin without any worries or loss of functionality, being able to do whatever I want. So thats a two way street right there." }-

Sure, there is a loss of functionality when running LUA. Like, "can't do admin stuff easily." As for MS implementing something like Sandboxie out of the box, there's a couple of reasons why that might not be too brilliant. 1) If they did that, there's a pretty good chance that the people who are now yelling "anticompetitive" would start yelling so loud everyone in the world would go deaf from all the noise. ;) 2) If they did, according to your theory that LUA would be targeted more as its use increases, wouldn't the bad guys just target those measures and find ways around them, just like they would work around LUA?

Me? I try to be a realist. I acknowledge that most everyone is out to make money, and not to make things easier for others. If MS implements kernel patch protection to decrease stability issues, that means MS marketing guys will be able to yell: "Look, guys, we really made Windows more stable, buy our new operating systems! Only $399, complete with annoying DRM that assumes you're a thief unless you prove yourself to us every week!" ;D But that's within their right. Rest assured, if the only reason for kernel patch protection was to mess with small security software companies, I would be against it so strongly that you'd all be telling me to shut up about it. ;D But, fact is, PatchGuard is not there to make life hard for nice guys from small security companies. It's there to make things a little easier for Microsoft. You know, those guys who make the Windows OS, and get to hear people complain how their Windows PC bluescreened after installing Norton.

[funkydude]

-{ Quote: "
I will do exactly the same thing I've been doing on 32-bit systems. I would ditch absolutely any single piece of software for an operating system that supports a lot more RAM. Some security software? I'd ditch it every day of the week and twice on Sundays! I don't run my systems for security software. I run my systems for me to do useful things with them. Am I going to install some anti-malware software on my 64-bit systems? No. Am I going to care if some anti-malware doesn't work on 64-bit? No, absolutely not. Am I going to get the most out of my 64-bit systems in productive use, and still go without being infected, while saving money? Yeah.
" }-

Such a brilliant post you touched my heart. *puppy*

[PrevxHelp]

-{ Quote: "I've got a direct question for PrevxHelp: do you think DefenseWall in particular (not policy HIPS in general...I'm talking about Ilya's DefenseWall in particular) can run with the same level of protection on 64-bit as with 32-bit? If not, then are you suggesting that you could create a policy HIPS (or sandbox) software program to be just as secure on a 64-bit compared with DefenseWall's protection on a 32-bit platform? If so, then maybe you should work with Ilya and help him out haha." }-

Honestly, across all of the posts so far, the only feature which wouldn't be supported fully on 64bit is small limitations for screengrabber protection and I think that is of little/no use

Regarding screengrabber protection: Ilya - your comment of "you don't lock your flat because the the hall is secured" avoids the question. What is the threat of a program reading the screen if it can't do anything with it? The analogy with my design of this would be that someone could LOOK at the door to my flat but would still prevent them from touching/opening the door. They can safely internally know exactly what my door looks like, but if they were to try and tell anyone else - then - I would step in and kill them (harsh, yes, but its the real world :P)

-{ Quote: "If Microsoft wanted to make the kernel more stable, they could stop pretending that people don't do stuff like hook SSDT. Imagine that instead of PatchGuard, they would offer an official Hook-Kernel-Service function?" }-

I disagree - if Microsoft wanted to make the kernel as stable as possible, they would prevent any third party developer from writing a driver that could intercept functionality :P Clearly most third party developers aren't careful enough to deserve the right to be in the kernel, as evidenced by the simple test done by Matousec: http://www.matousec.com/info/articles/plague-in-security-software-drivers.php

This test is a bit old, but if you scroll to the bottom, you'll see a list of basically every security product from a few years ago being vulnerable to argument validation attacks. To summarize what this means for the other readers: NIS 2008, for example, being vulnerable to a NtOpenSection attack means that in their implementation of the SSDT hook on NtOpenSection, they have a flaw which can be exploited from usermode to crash the system (BSOD) by just calling simply a function with invalid arguments. This can happen intentionally by malware looking to crash the system, or unintentionally from a simple bug in any program on the OS, and the crash may be unable to be attributed back to the security vendor so the user will blame Microsoft.

Most BSODs that occur on their system are not Microsoft's fault but in actuality, it is their AVs in most cases simply not taking the time to ensure that what they're looking at is really what they're looking at. No one is perfect (including software developers :P) so why run the risk of allowing vendors to mess up and crash the entire OS? I know I'm being altruistic here because Microsoft couldn't possibly prevent all vendors from intercepting any kernel functionality but they have at least taken strides forward in preventing vendors from having to deal with input validation by using callbacks.

-{ Quote: "Because there is no way to stop it, Ilya and Tzuk can not make their software work. .... Also from the answers of PrevXHelp (it is at least 25 years has been passed since I was involved in IT as system architect/designer), it seems that Ilya and Tzuk are making it more of a principal discussion. PrevX help tackles most of their complaints when you correlate intrussion risk and impact (nearly every car which is sold can drive harder than the maximum speed limit, still government allows sales of those cars)" }-

Kees1958 - you have made some fantastic analogies and posts :thumb: I have one minor comment to make but you are correct with the current design of Prevx in how we analyze the data/intercept it HOWEVER what I'm saying is that if we wanted to move to a sandbox approach like Sandboxie/DefenseWall where we block every piece of data from touching the OS.... we could. DeepFreeze and similar products can do it (within reason - there are still issues with the MBR rootkit of course because nothing is perfect) at the entire-OS level and it is significantly more difficult to do it on a program-by-program basis but it is possible.

However, as I've said - it is a lot of effort to add 64bit support in a product which is dependent on 32bit concepts, especially with DefenseWall/SSM/similar products which hook dozens/hundreds of SSDT entries. The hundreds of millions/(billions?) of 32bit computers aren't going to just disappear overnight, therefore, until the market is saturated enough (and it will be eventually), it is reasonable that smaller developers don't want to add this support. The same step change occurred with the old DOS TSR antivirus programs in the switch from a 16bit architecture to 32bit architecture.

[Windchild]

-{ Quote: "
I disagree - if Microsoft wanted to make the kernel as stable as possible, they would prevent any third party developer from writing a driver that could intercept functionality :P Clearly most third party developers aren't careful enough to deserve the right to be in the kernel, as evidenced by the simple test done by Matousec: http://www.matousec.com/info/articles/plague-in-security-software-drivers.php

This test is a bit old, but if you scroll to the bottom, you'll see a list of basically every security product from a few years ago being vulnerable to argument validation attacks. To summarize what this means for the other readers: NIS 2008, for example, being vulnerable to a NtOpenSection attack means that in their implementation of the SSDT hook on NtOpenSection, they have a flaw which can be exploited from usermode to crash the system (BSOD) by just calling simply a function with invalid arguments. This can happen intentionally by malware looking to crash the system, or unintentionally from a simple bug in any program on the OS, and the crash may be unable to be attributed back to the security vendor so the user will blame Microsoft.

Most BSODs that occur on their system are not Microsoft's fault but in actuality, it is their AVs in most cases simply not taking the time to ensure that what they're looking at is really what they're looking at. No one is perfect (including software developers :P) so why run the risk of allowing vendors to mess up and crash the entire OS? I know I'm being altruistic here because Microsoft couldn't possibly prevent all vendors from intercepting any kernel functionality but they have at least taken strides forward in preventing vendors from having to deal with input validation by using callbacks.
" }-


:thumb: :thumb: :thumb: Yes, the less you allow third parties to mess with the kernel, the better that is for stability. So, protecting the kernel from all kinds of hook, line and sinker isn't "anticompetitive", it's "common sense", if stability is a goal for you. :) Microsoft wants fewer people saying "Windows is unstable" so they'll take measures to make Windows more stable, like preventing some third party software from patching the kernel in a way that has previously caused all kinds of trouble.

My personal experience of BSODs on Windows? Out of all the BSODs that I've seen, perhaps roughly 45 % are caused by high-performance graphics card drivers, and about 50 % are caused by security software, most often AVs from big name companies - and the remaining 5 % is something else.

-{ Quote: "Such a brilliant post you touched my heart. *puppy*" }-

Well, I don't know what to say to that, LOL. It's so hard to tell when people are merely being sarcastic. ;D

[wat0114]

Personally, I feel badly for developers like tzuk and Ilya and others who have conceived brilliant security products for those looking for an alternative means to secure their computers. Sandboxie is a fantastic complement imo for running under lua and srp.The attitude being expressed by some in this thread of "too bad" or "think outside the box" towards these developers leaves a sour taste in my mouth, given their lack of compassion regarding their plight, but hopefully they will devise a means to somehow at least adequately work through the obstacles imposed by MS in 64 bit so that they can still carve out a decent living for themselves. That said, I also understand that MS is trying to achieve better security in their O/S with Patchguard. It's kind of a catch 22.

[Dregg Heda]

-{ Quote: "1) Easy answer. Because the bank chose to operate in a country where the government occasionally makes laws the bank and their mercs don't like. If the bank feels like it's suffering, it can always try to change the government and the laws, or move to a different country. If they can't do that, then I guess that's one of the many tragedies of life. Nothing is perfect, and sometimes there is no happy end. There isn't any ethical reason for why the bank should suffer, as in "what has the bank done to deserve this suffering."

And you do have a choice. You have a lot of choices. But not all choices that could theoretically be possible, in a world where Microsoft chose not to implement kernel patch protection. That, again, is how the world works. There is no legal requirement for the makers of operating systems to provide endless different methods for security software vendors to do their thing. I'm amazed that people don't understand this stuff. Perhaps they really do, and are only trying to mess with my poor old head for their amusement. ;D

2) Sure, there is a loss of functionality when running LUA. Like, "can't do admin stuff easily." As for MS implementing something like Sandboxie out of the box, there's a couple of reasons why that might not be too brilliant. a) If they did that, there's a pretty good chance that the people who are now yelling "anticompetitive" would start yelling so loud everyone in the world would go deaf from all the noise. ;) b) If they did, according to your theory that LUA would be targeted more as its use increases, wouldn't the bad guys just target those measures and find ways around them, just like they would work around LUA?

3) Me? I try to be a realist. I acknowledge that most everyone is out to make money, and not to make things easier for others. If MS implements kernel patch protection to decrease stability issues, that means MS marketing guys will be able to yell: "Look, guys, we really made Windows more stable, buy our new operating systems! Only $399, complete with annoying DRM that assumes you're a thief unless you prove yourself to us every week!" ;D But that's within their right. Rest assured, if the only reason for kernel patch protection was to mess with small security software companies, I would be against it so strongly that you'd all be telling me to shut up about it. ;D But, fact is, PatchGuard is not there to make life hard for nice guys from small security companies. It's there to make things a little easier for Microsoft. You know, those guys who make the Windows OS, and get to hear people complain how their Windows PC bluescreened after installing Norton." }-

1) Governments have a responsibility to their people, and so M$ has a responsibility to their loyal customers. Theres absolutely no reason why M$ cant build patchguard in such a way that it can be automatically disabled for those of us who wish to have it so anyway.

You're being very theatrical, but the reality is no ones asking M$ to provide "endless different methods for security software vendors to do their thing". All we security enthusiasts ask is this one little thing.

2) a) As long as there was nothing illegal in what M$ did in terms copyright violation, even if Tzuk did much shouting I doubt anyone would care, if M$ created a sandbox that could rival sbie and it was free out of the box, we would just use that instead. Although considering this is M$ I doubt they could do this.

b) DW and a well configured sbie offer stronger protection than LUA.

3) No one here thinks M$ made patchguard just to **** with Ilya and Tzuk. But I do have my suspicions that they did it to weaken 3rd party security apps and hence push their own crap. Whatever the case the reality is by doing so they have possibly prevented me, the consumer, from utilising some of the finest available defense mechanisms in protecting my computer and its contents. If M$ didnt have a monopoly and I could have just switched over to a different OS without any loss, then thats one thing. But the reality is they do have a monopoly and thanks to it are virtually forcing me to use their OS, then they should at the very least not prevent me from using the kind of apps which can provide me the security I need.

[PrevxHelp]

No one has brought this up yet so I thought I'd mention it. You can always use a virtual machine on x64 which hosts a 32bit OS.

Run your main programs outside of the VM and then either just run untrusted programs in the VM or install Sandboxie/similar apps within the VM also as an additional layer (although the VM is a full sandbox in itself).

[Windchild]

-{ Quote: "1) Governments have a responsibility to their people, and so M$ has a responsibility to their loyal customers. Theres absolutely no reason why M$ cant build patchguard in such a way that it can be automatically disabled for those of us who wish to have it so anyway.

You're being very theatrical, but the reality is no ones asking M$ to provide "endless different methods for security software vendors to do their thing". All we security enthusiasts ask is this one little thing. " }-

"Theatrical", says the man who types MS with a dollar sign. ::) Sure, MS has a responsibility to their customers. It seems a lot of customers have complained that Windows crashes. Looks like Microsoft is doing something about that, even though many of the crashes aren't Microsoft's fault. And this is bad? I guess when you're Microsoft, you can't do anything right - you're always in the wrong whatever you do. Sure, there are some "security enthusiasts" (more like "security software enthusiasts", in my humble opinion) complaining that Microsoft should do away with PatchGuard. I'm sure Microsoft will listen to these people when there are tens of millions of them, like there are people complaining about bluescreens and stability issues. :)

Sure, all you ask is "one little thing." Only, that "little thing" happens to be "I want to modify the most important part of your software - the kernel - even if you don't like it." And people are surprised Microsoft might not want to give you this? Oh dear...

And yes, there is a reason why Microsoft might not want to give you an option to disable PatchGuard. They make their OS for the large masses, not for a couple of thousand forumists or security software vendors. PatchGuard is intended to increase stability, as experienced by Joe Average and others. If they gave you an option to disable PatchGuard, guess what would happen - many "security software" would just disable PatchGuard during the installation, and many Joe Averages would again end up running without PatchGuard, and then sending crash reports caused by their poorly coded security software to Microsoft, complaining all over forums about how Windows is unstable and sucks, and finally praising the Lord for at least having all that great security software of theirs to save them from "M$" incompetence.


-{ Quote: "2) a) As long as there was nothing illegal in what M$ did in terms copyright violation, even if Tzuk did much shouting I doubt anyone would care, if M$ created a sandbox that could rival sbie and it was free out of the box, we would just use that instead. Although considering this is M$ I doubt they could do this." }-

Yeah, I doubt the people who code the entire operating system Sandboxie runs on could have the skills to make something as great Sandboxie. ::) This discussion is... well, I remember now why I didn't partake in it earlier.

Maybe Microsoft, having had people attack them for years for including a browser (!) in their OS with no option to uninstall it, doesn't want to start including sandboxes and HIPS products in their OS, just to see how many lawsuits they would get thrown at them for doing that.

-{ Quote: "
b) DW and a well configured sbie offer stronger protection than LUA. " }-

Perhaps. And they also offer better slowdown of the system, higher consumption of resources, and increased potential for stability issues. And they also offer you the option to pay for all the added protection. Life is all about choices and trade-offs. And please, don't bother to give me the "I see no performance loss on my system with security software X, Y and Z" speech. There is no way to run any software without using some of the available hardware power. Just because you can't see the performance hit doesn't mean no-one else can't, either - some people have higher demands on performance than others, or less patience.

-{ Quote: "3) No one here thinks M$ made patchguard just to **** with Ilya and Tzuk. But I do have my suspicions that they did it to weaken 3rd party security apps and hence push their own crap. Whatever the case the reality is by doing so they have possibly prevented me, the consumer, from utilising some of the finest available defense mechanisms in protecting my computer and its contents. If M$ didnt have a monopoly and I could have just switched over to a different OS without any loss, then thats one thing. But the reality is they do have a monopoly and thanks to it are virtually forcing me to use their OS, then they should at the very least not prevent me from using the kind of apps which can provide me the security I need." }-

Ah, so you foresee Microsoft trying to sell you sandboxes and HIPS in the future? Doesn't sound very realistic to me, quite frankly.

Their goal is increased stability of their OS. We could weave conspiracy theories all day if there was nothing more productive to be done. But since there is, I'll just point out that Microsoft, like any software company, makes their own design choices. Even if Microsoft has a monopoly position on the OS market, doesn't mean they're required to let other people patch their OS kernel freely.

And then there's that whole "responsibility to paying customers" issue. I mean, what if Windchild, a paying customer of Microsoft, says: "I want you to prevent software from patching the kernel all over the place, so I don't have to deal with people having stability issues caused by their security software." Microsoft has a responsibility to me, right? If you say you want an option to disable PatchGuard, and I say I want there to be no option to disable PatchGuard, what should Microsoft do? Do it your way, just because? Or should they perhaps consider things like: 1) How many people will benefit from PatchGuard, as compared to how many will benefit from removing it or providing an option to disable it? 2) What does Microsoft themselves think? Is it cool to let other software freely mess with our kernel? Or should we try to perhaps do something, even a little something, about that?

As a final note, if you really need stuff like Sandboxie or Defensewall to run a secure system - and when I say "need" I mean that you absolutely can't avoid infections and security breaches without them - then that's a problem-between-keyboard-and-chair, and really not something Microsoft is obliged to fix for you by making those programs possible on any and all future operating systems they might create.

Well, I think I've made my case here, and my flame-proof suit is wearing thin. This might be a good time to let all you gentlemen continue with the regularly scheduled programming.

[Kees1958]

Guys,

On an x32 machine (great OS=es of Microsoft by the way at least 15 years younger than any unix/linux variant) I prefer (Policy/Application) Sandboxes.

On an x64 machine, I only need UAC and SRP/PGS, and apply a default deny execye policy through Pretty Good Securitt of the user space plus Microsofts FireWall (two way_ and their AV (MSE)

thingies missing which I would like to have
a) an intelligent way of preventing side by side attacks of same authority processes and objects (with UAC a lower rights object/process can not touch a higher level process/object). for downloaded objects (Windows knows this allready) and objects running with the same rights as internet facing programs.
b) an intelligent virtualisation/rollback option of any registry changes made by my browser on a per session basis, think of it as a CCleaner like cleanup of cookies, Active, Add-ons, Plug-ins, Java related applets and the temporary internet/browser libraries would be welcome, with an option t save files (which would get 'protected mode' like minimal rights,

Can somebody convince Tzuk/Ilya to co-operate on such a program?

[Page42]

-{ Quote: "Well, I think I've made my case here, and my flame-proof suit is wearing thin. This might be a good time to let all you gentlemen continue with the regularly scheduled programming." }-
As an individual who can not personally converse in the same technical terms as many of you here on this thread, I must say that I AM capable of understanding the arguments, or positions, that you have so eloquently stated. I agree with your assessment that MS has every right to stabilize their own OS. It's hard to tell how this will all shake out, but I am glad that I have had the opportunity to read through this thread and weigh the various contributions. I think that PrevxHelp is one sharp dude, and that you, Windchild, really have a good grasp of the situation as it pertains to securing the Microsoft OS. Thanks for making your case here. :)

[tzuk]

-{ Quote: "Originally Posted by tzuk:
If Microsoft wanted to make the kernel more stable, they could stop pretending that people don't do stuff like hook SSDT. Imagine that instead of PatchGuard, they would offer an official Hook-Kernel-Service function?

PrevxHelp responded:
I disagree - if Microsoft wanted to make the kernel as stable as possible, they would prevent any third party developer from writing a driver that could intercept functionality Clearly most third party developers aren't careful enough to deserve the right to be in the kernel, as evidenced by the simple test done by Matousec" }-

I take it that you agree that kernel-level stability can never be guaranteed in the first place, and that PatchGuard does not really solve the root problem of third-party code introducing instabilities.

In other words, the possibility of conflict between two competing third-party filesystem filter drivers (as one example) to is still there, as is the possibility for a badly-written firewall filter driver to BSOD the system. Both kinds of drivers tie into the kernel using official interfaces.

Microsoft invites filesystem developers to "plugfests" where they can install everyone's software into the same computer and make sure it all works right. Why is there a need for such gatherings, when everyone uses official interfaces?

And finally: Where is the difference between a filesystem filter driver through an official API; and a hook on NtCreateFile, if the hook is done correctly? There is no difference except that PatchGuard now blocks the latter variations.

Punishing the entire developer community because some developers have acted badly and wrote bad hooks is a gross over-reaction. By that reasoning, if tomorrow Microsoft would cancel firewall filtering APIs, because a few firewall drivers are written badly, what would you say then?

I really wish all this propaganda about PatchGuard magically enhancing system stability would just stop. It seems to be taken straight from Microsoft press releases.

PatchGuard does only one thing extremely well, and that is to hinder innovation in kernel space. I don't presume to know the reasons for this policy, but I find it puzzling to see people make excuses and rationalizing it as somehow "good for the customer". Black is white now?

[Johnny123]

-{ Quote: "1) Governments have a responsibility to their people, and so M$ has a responsibility to their loyal customers. Theres absolutely no reason why M$ cant build patchguard in such a way that it can be automatically disabled for those of us who wish to have it so anyway." }-

That would be defeating the purpose.


-{ Quote: "2) a) As long as there was nothing illegal in what M$ did in terms copyright violation, even if Tzuk did much shouting I doubt anyone would care, if M$ created a sandbox that could rival sbie and it was free out of the box, we would just use that instead. Although considering this is M$ I doubt they could do this." }-

Of course "M$" can't do this, they can't afford to pay software developers in spite of the dollar sign. You do have a vivid imagination.

-{ Quote: "b) DW and a well configured sbie offer stronger protection than LUA." }-

Other trolls here have posted this as well. What evidence are you basing this on? Obviously on a 64 bit system this is not the case, since both of those apps don't even exist for 64 bit. FAIL.

-{ Quote: "If M$ didnt have a monopoly and I could have just switched over to a different OS without any loss, then thats one thing. But the reality is they do have a monopoly and thanks to it are virtually forcing me to use their OS, then they should at the very least not prevent me from using the kind of apps which can provide me the security I need." }-

How do you figure they are forcing you to use their OS? Buy a Macintosh or go to distrowatch.com and check out the ~300 Linux distros that can be downloaded for free.

[Wildest]

-{ Quote: "PrevxHelp seems to think that it is possible to create the same level of security on 64-bit as with 32-bit (with regards to the security provided by Sandboxie and DefenseWall etc)." }-
While I do understand your position, and that of Tzuk and Ilya, IMO it does not make sense that Microsoft should make their x64 software inherently less secure than their x32 software.
They are already finding it difficult to convince XP users to move to Vista and Windows 7; why add fuel to the fire?

The one thing that gets me riled up is software developers who state blithely that something is "impossible". I have heard this line over and over again from dozens of developers only to go over their code and find out that this is simply not true.
Both Tzuk and Ilya made statements here about things that couldn't be done.
PrevxHelp addressed these and both admitted that PrevxHelp's solutions could be effective.

With all due respect to the wonderful work that Tzuk and Ilya has done, if I have to choose between believing Microsoft and the hundreds of Phd mathematicians and computer scientists at their disposal and solo developers who need to defend their position to protect their livelihood, I will take the former every time.

In summary, I side with PrevxHelp.

My regards.

[funkydude]

Why do you doubt it? Prevx are already working on a 64bit sandboxing system for browsers. This is mentioned several times in Prevx threads.

[PrevxHelp]

-{ Quote: "Why do you doubt it? Prevx are already working on a 64bit sandboxing system for browsers. This is mentioned several times in Prevx threads." }-

We're currently developing something significantly different than what Sandboxie is focusing on (a complement to it but not a replacement).

[Wildest]

-{ Quote: "Sorry and thanks for that, but I was just doubting that they would make a product that is the equivalent of Sandboxie. We'll see though." }-
There will never be an equivalent to Sandboxie on x64.

[PrevxHelp]

-{ Quote: "And finally: Where is the difference between a filesystem filter driver through an official API; and a hook on NtCreateFile, if the hook is done correctly? There is no difference except that PatchGuard now blocks the latter variations." }-

The 'hook is done correctly' clause is the assumption that can't be made by Microsoft. SSDT hooking forces you to validate every parameter given to the function - IIRC there are 11 parameters for NtCreateFile alone. When many programs hook 100+ functions, that is a wide area to try and perfect.

However, a filesystem filter gets called after the OS initially interprets the data, preventing any possibility for invalid usermode data to be parsed by the unsuspecting filter.

A filesystem filter even provides more protection than hooking NtCreateFile directly because drivers will tend to ignore the hooked function itself anyway and just import the correct address - any SSDT hook would miss the call in that case. While it's possible to still call under a FSFD from kernel mode if you work at it, using a FSFD up's the bar another level.

Also, a FSFD allows the driver to be unloaded safely - many BSODs come from developers unloading their drivers while other processes are still calling their function. There is no practical way to reliably unload an SSDT hook without rebooting in a multi-core system. Using the supplied interfaces therefore reduces the need for unnecessary reboots and overall helps the reliability of the system. Sure, it's still possible to BSOD the system but Microsoft can't fix 3rd party flaws - all that they can do is steer 3rd party vendors in the right direction by removing support of hacks in the OS.

[PrevxHelp]

-{ Quote: "So you're saying that it's impossible? Tzuk has told me that in principle, Sandboxie can be created for 64-bit with the same level of protection. I don't know enough (or anything) about programming on 64-bit, and I most definitely don't understand the programming behind Sandboxie to technically support him on that though." }-

It isn't impossible. There might not be a function called SandboxProcess() built into Windows but with enough work equivalent protection can be achieved.

[Wildest]

-{ Quote: "It isn't impossible. There might not be a function called SandboxProcess() built into Windows but with enough work equivalent protection can be achieved." }-
Yes, what I meant was that there will never be a product like Sandboxie on x64 that can provide protection in the same manner possible on x32.

[PrevxHelp]

-{ Quote: "Yes, what I meant was that there will never be a product like Sandboxie on x64 that can provide protection in the same manner possible on x32." }-

Yes, true :) I doubt there will be a time when Sandboxie becomes irrelevant - as I've mentioned previously, if someone really needs to still use Sandboxie and has upgraded to 64bit hardware, you can easily just install it in a 32bit VM to use on the same system and run questionable software in there. On this 64bit system I'm using right now, I have a VM of Windows 98 and Windows NT4 for testing ;D (have to love < 2 second boot times on modern hardware even when virtualized).

[squid13]

I'm just a senior citizen and I've read this whole thread and most of it is over my head, but there is a saying when I was in the military. The impossible we do immediately, the practical may take awhile. So let it be written, so let it be done.

[Tarnak]

Any system(organization) that contrives to block/impede innovation cannot be good, therefore I have to side with the developers rather than Patchguard.

P.S. I have read through this thread from the beginning to end, and there have been good points made for the other side, too!

....but Innovation for me is key! ..."Innovate or die!"

[Windchild]

-{ Quote: "I take it that you agree that kernel-level stability can never be guaranteed in the first place, and that PatchGuard does not really solve the root problem of third-party code introducing instabilities." }-

PrevxHelp already addressed most of the points in your post, but I'll say this: Sandboxie can't prevent all malware attacks and infections theoretically possible - for example, successful social engineering attacks that can convince the user to execute code outside the sandboxed environment, which is a problem for all security measures - but that doesn't make Sandboxie worthless. Similarly, Kernel Patch Protection can't prevent all stability issues caused by third party code, but that doesn't make it worthless. It can prevent some issues, and that means it does cause an increase in stability. That's all the justification Kernel Patch Protection needs. People don't use things because they're perfect, since nothing is. People use things because they're useful, even if they're not perfect. You don't have to understand that, but one might expect that you would, being a developer and all. You can even think of it as a compromise. Microsoft might want to put a much bigger block on messing with the kernel, but that wouldn't be very practical and would make life really hard for a lot of developers big and small. So, maybe Microsoft takes some lighter measures, that give a small increase in stability in some cases and still leave developers a lot of room to play with the kernel, causing trouble only for a very small number of people developing a very special kind of software that few use.

-{ Quote: "In other words, the possibility of conflict between two competing third-party filesystem filter drivers (as one example) to is still there, as is the possibility for a badly-written firewall filter driver to BSOD the system. Both kinds of drivers tie into the kernel using official interfaces.

Microsoft invites filesystem developers to "plugfests" where they can install everyone's software into the same computer and make sure it all works right. Why is there a need for such gatherings, when everyone uses official interfaces?" }-

The need exists because people, being people, can mess up using official interfaces, just like they can mess up using unofficial, undocumented, and unsupported methods. But is there a difference between official methods and unofficial ones? Of course there is. It's a lot easier to mess up using the "unofficial" methods that Microsoft has long been trying to discourage people from using, since people very often use them wrong.

Where do we end up? If you leave the official methods in place, then they can cause stability issues. But it's still a better situation than before, where also all of the unofficial methods were completely free-for-all and anyone could mess up the kernel with them. Simple maths: you remove some methods to mess things up, and that leaves you with fewer methods to mess things up, and with fewer stability issues. Oh noes, this is horrible and underhanded! ::)

-{ Quote: "And finally: Where is the difference between a filesystem filter driver through an official API; and a hook on NtCreateFile, if the hook is done correctly? There is no difference except that PatchGuard now blocks the latter variations." }-

The difference is "if the hook is done correctly." If my aunt wore pants, she'd be my uncle. There's really no reason for Microsoft to expect that third party devs will always get the hooks done correctly, and when that's the case, there's a reason for them to try to prevent those hacks.

-{ Quote: "Punishing the entire developer community because some developers have acted badly and wrote bad hooks is a gross over-reaction. By that reasoning, if tomorrow Microsoft would cancel firewall filtering APIs, because a few firewall drivers are written badly, what would you say then?" }-

One man's gross over-reaction is another man's reasonable caution. Opinions, again. "Some developers have acted badly and wrote bad hooks"? LOL. How about "many developers have acted badly and wrote bad hooks, including almost all of the biggest name security companies and a whole lot of the smaller ones"? It's not a case of "few" apps being written badly with bad hooks. It's a case of loads of apps being written badly with bad hooks. If Microsoft wants to try to do something about that, good for them, I applaud that, because it doesn't harm me or most Windows users in any way but instead helps us by increasing stability. The few people that suffer from it - users of rather special software and developers of said software - will of course disagree with me, but that's how life is. You can't please everyone. MS is likely to first consider their own desires, and the demands of the majority of their customers, and then later they might, maybe, pay attention to a very small if vocal group of users.

-{ Quote: "I really wish all this propaganda about PatchGuard magically enhancing system stability would just stop. It seems to be taken straight from Microsoft press releases." }-

I really wish all this propaganda about PatchGuard magically "preventing innovation" and "blocking the good guys" instead of doing anything useful at all would just stop. It seems to be taken straight from the comments of a couple of developers of obscure security software the wide world knows nothing about - comments that offer no proof at all to support the ridiculous stance that PatchGuard has no useful purpose except messing around with small software companies.

But, years have taught me that we don't always get what we wish for. Microsoft press releases? Wow, that was funny. Perhaps it strikes some people as surprising that Microsoft might make press releases to explain some new feature or change in their new operating systems, and some other people might then refer to these press releases. But I get the feeling that you're implying that Microsoft's press releases are lying, and PatchGuard does nothing to increase stability - which it for a fact does, by preventing and discouraging certain types of kernel patching that has caused trouble in the past. Sure, we could play that game, and assume people are lying if they say something we don't like. If we go and assume Microsoft is lying, why would we not assume you are lying, as well? As for me, I don't assume such things. I look at what I see and make my conclusions. Microsoft has a legit reason for Kernel Patch Protection, and it is a measure which is within their rights to apply. If some people don't like that, that's their right. But that still doesn't change the facts of what PatchGuard does or does not do. You know, you could make your point of "I don't like PatchGuard because it makes my job harder or impossible" without resorting to claims of MS being anticompetitive or PatchGuard having no use in increasing stability. Those claims may raise applause among your present, faithful clientele, but a lot of other people remain fully unimpressed.

-{ Quote: "PatchGuard does only one thing extremely well, and that is to hinder innovation in kernel space. I don't presume to know the reasons for this policy, but I find it puzzling to see people make excuses and rationalizing it as somehow "good for the customer". Black is white now?" }-

I don't even remember how many times you've said the same thing in this thread without presenting any solid proof for it: PatchGuard does nothing well except "hinder innovation", "block the good guys", its only effective purpose is to block the good guys, and so on, ad nauseam. Never have you managed to prove that PatchGuard doesn't do exactly what MS says it does: offer an increase in stability. People aren't making excuses to support Microsoft. They're agreeing that it's a good idea to try to prevent some stability issues caused by kernel patching - stability issues that people have personally seen happen, frequently - even at the cost of blocking some security software most people don't use. I would even applaud PatchGuard as a show of force measure - a measure that was never intended to fully prevent any kernel patching, but instead only to show devs that MS doesn't want them messing with their kernel and causing BSODs left and right. Maybe Microsoft doesn't want other people's "innovation" in their kernel space, when in the past that "innovation" has caused stability issues that were blamed on Microsoft for no reason, and when the "innovative" software that PatchGuard now prevents has been used by only a pathetically small portion of Windows users. It's a design choice. An entirely valid design choice. You can hate it, I can like it, it doesn't really matter much.

My reason for posting in this thread was to present a different point of view from the one embraced by fans of security software.

[Kees1958]

Yep SSJ,

Windchild would have liked the nick name Pleonasme, only it was allready used on Wilders ;)

[Windchild]

-{ Quote: "Windchild makes comments that PatchGuard is actually very beneficial in increasing stability etc etc. Where have I heard this before? Does Microsoft saying that their systems will be more stable sound familiar to anyone? Tzuk's last post also reflects some doubt as to whether PatchGuard actually contributes a lot to increasing stability (and Tzuk seems to have some technical justification for this, unlike little old me).

So are Microsoft creating PatchGuard so that they can (also) screw over innovative software developers like Tzuk and Ilya? I have no idea really. What I do know is that Microsoft are a business, and in these fragile economical times, "no money, no talk" etc.
" }-

Hey, it's a free world - people have every right to have the kind of opinions they want. It would be sad indeed if everyone agreed with someone like me! ;D

Sure, Microsoft says their systems will be more stable. It would be odd if they didn't say it. Sure, it's marketing speak. That doesn't mean it's necessarily a lie, though. It works like this.
- Step 1: Microsoft gets complaints about Windows being unstable, and finds out that security software is causing BSODs left and right, thanks to poorly implemented kernel patching.
- Step 2: Microsoft gets annoyed, and implements Kernel Patch Protection to discourage such patching in order to increase stability.
- Step 3: Security software companies complain loudly.
- Step 4: Microsoft sends their marketing guys out to say: "Look, we increased the stability of our OS, just like you said you wanted, even though the stability issues weren't even our fault! Please buy our new OS, only $399, annoying DRM included!"
- Step 5: Profit for Microsoft, and profit for people who will now see less crashes caused by security software.

That doesn't mean Microsoft is lying about the stability increase. The "technical justification" Tzuk presented to support the position that PatchGuard really doesn't do anything useful for stability could be summed up as the following, and obviously unreasonable claim: "PatchGuard doesn't prevent all possible stability issues introduced by third party code in the kernel, but it does prevent me from making Sandboxie 64 like I want to, and therefore PatchGuard is useless, underhanded, anticompetitive, evil, (insert nasty word here)."

Microsoft is creating PatchGuard to do something that they've wanted to do a long time: discourage people from messing with their kernel. If that's not within their rights, I don't know what is.

I'm aware that it's fashionable for people to think of Microsoft as some sort of Evil Empire. Nothing wrong with that - people are free to have all sorts of beliefs. But that's no reason to fly in the face of logical thinking, though. ;D
- Let us pretend that someone believes in the following: "Microsoft made PatchGuard in 64-bit to prevent some security software I love. Microsoft is EVIL, and therefore I will not use 64-bit Microsoft operating systems." That kind of thinking is not logical. What would be more logical is the following:
- "Microsoft made PatchGuard in 64-bit to prevent some security software I love. Microsoft is EVIL, and therefore I will not use ANY Microsoft products."

The idea here is to say that anyone who doesn't trust MS, but still runs their OS, is acting irrationally. If you don't trust MS, why are you running their OS? Don't do that. If you don't trust someone, for heaven's sake don't run their OS! It's like giving your wallet to someone you don't trust. Would you give your wallet to someone you don't trust? I wouldn't. Would you put some GPS tracker in your wallet and then give it to someone you don't trust, with all the money still in it? I wouldn't. You can think of the GPS tracker as an analogy to security software...

-{ Quote: "I find it quite interesting how you're approaching this topic, although it is not unexpected, and I predicted someone would make comments like yours. Your take on this topic is quite similar to my take on recent sensitive Comodo topics (sorry if you think this comparison is unfair; feel free to give me a punch in the face later when we meet up at the pub haha)." }-

LOL, no face-punching will be required. Besides, there seems to be so many fans of security software here that it's more likely that I would be in the receiving end of the face-punching anyway! ;D

-{ Quote: "You are basically taking a step back and asking us all to look at the bigger picture. With this bigger picture in mind, you are giving very well rounded and justified reasons as to why we should just STFU and accept the way it is (excuse my language haha)." }-

Well, I really don't think you should all just SU - you should be free to voice your opinions, like anyone, like even me. My interest is in showing that Microsoft does have a valid reason for making Kernel Patch Protection, and the reason isn't to mess with small developers that you guys love. The reason, as has been said many times, is stability. And that remains a valid reason in spite of the fact that Kernel Patch Protection doesn't prevent all stability issues. It prevents some. That is better than nothing.

-{ Quote: "I think you're also suggesting/implying that we should just trust Microsoft on this 64-bit PatchGuard etc issue, and just work out whatever needs to be worked out once 64-bit becomes the norm." }-

I don't think people should trust anyone they don't feel like trusting. If you don't trust Microsoft, don't run their OS. I think people should put more trust in logical thinking, though. No-one has been able to give even one sensible reason for why Microsoft might possibly want to mess with small security software companies. Why not? Because that's not Microsoft's goal. PatchGuard, and that's a fact, does help with stability. No, it doesn't solve all issues - and Microsoft says this in those press releases that some people seem to have such disdain for. But solving some issues is better than solving none. Unless, of course, one believes that Microsoft should just throw up their hands and surrender their operating system to the control of third parties. Further, logical thinking also results in understanding that certain types of security software aren't a requisite of security. They may be useful tools, but not indispensable.

-{ Quote: "So it's all very well being cynical and opinionated, but I hope you can at least (try to) understand where we're coming from (us lowly consumers). Just how I see it though." }-

Oh, I can understand where you're coming from. I just live in hope that people could look past personal issues (like really loving software X, or disliking Microsoft) and observe the facts, and make rational conclusions based on facts.

[Windchild]

-{ Quote: "Windchild, you're basically saying the same thing over and over again too. Simplying in bullet points might make it easier haha. Anyway they are good points though." }-

Yeah, I am saying the same thing over and over again. The only difference is that the facts/proof are on my side, and against our friendly developers. ;) A rather big difference, in my humble opinion.

The facts being, that PatchGuard does help with stability. It doesn't prevent all issues, but it prevents some, and that makes it a valid measure. While it also prevents some things useful to security software devs, that doesn't make it invalid or underhanded, since it now has a reasonable justification in increasing stability - a good goal for any software developer.

The reason I don't do bullet points is they look kind of weird to my eye. You don't even want to know why. I have a boringly long-winded way of saying things, I'm fully aware of that. ;D

[Windchild]

-{ Quote: "There isn't any clear right or wrong here really. As you said, it's all about opinions. I don't think Tzuk said that PatchGuard does not help with stability at all, forever and ever and ever. He just said that it would be nice if there wasn't PatchGuard (or that Patchguard wasn't made like how it is) etc, for the sake of preventing one company to have all the power to control etc. It's just his opinion, and he's got every right to voice it.

Unfortunately for Tzuk, and as I've already stated, there probably isn't much he can do (or any of us here on Wilders) about what Microsoft does." }-

No, no clear right or wrong when it comes to opinions. But if Tzuk admits that PatchGuard does increase stability somewhat, then he's agreeing with me, and we don't have to debate that point. Then, we can debate opinions and rights. And as far as facts are concerned, Microsoft in fact has every moral right to implement PatchGuard to protect their own OS kernel. I have no trouble with Tzuk or anyone else stating as their opinion that they'd like PatchGuard removed or to have an option to disable it. I start having trouble at the point they imply or outright claim that PatchGuard does nothing except block the good guys - a claim that goes against the obvious facts of what PatchGuard does. Further, I'll reserve the right to try to explain why Microsoft could choose to not remove PatchGuard or not allow for an option to disable it.

But really, what I would most like to see is users understanding that security isn't a piece of software, it's a process.

[tzuk]

The folks here keep ignoring the most important points I make, and then accus me of not providing "solid proof". ssj100 suggested bullet points and I think that might be a good idea now.

* When I show real shortcomings of the effects of PatchGuard, I get a crazy ideas in response. Perhaps it was my mistake to take these ideas lightly and not say in bold letters that they are NOT GOOD ENOUGH. So let me state clearly, these are sub-par solutions: Injecting code into every system process is not better than kernel-level hooks. If you ever saw system processes lsass.exe or csrss.exe crashing, and Windows immediately saying it has to shutdown within a minute, you know what I'm talking about.

So a kernel hook has a lot of potential to cause system instability, but injecting code into csrss.exe (the main Windows user interface component) and de-stabilizing it, that is somehow better?

* At the same time, that the people suggesting (or backing) these instability-inducing workarounds, they are also touting the overall potential stability increases of PatchGuard. This is hypocritical.

* If you go back and read posts you will see even PrevxHelp, who suggested this idea, admits they are a workaround until Microsoft adds missing interfaces. To this I have to say, why so sure they will add missing interfaces? Why would they bother when people like PrevxHelp encourage non-technical people to think that crazy workarounds and sub-par security products (not referring to the Prevx product) are a viable solution? And how come this disclaimer (more or less) has been lost in later responses when people claim PrevxHelp has shown us the light?

* When the pro-PatchGuard people argued that PatchGuard is well worth the loss of developer freeedom because it completely stabilizies the kernel, I show the fallacy of this argument. It doesn't make any real difference, the kernel will still load and invoke third-party code that has the potential to be unstable. As much potential as any other piece of kernel code, including those from Microsoft. So now the argument has switched to: Ok, ok, it's not complete stabiliazation, but even it helps just a wee little bit, we think it's worth it, even if it means some security products have to lose their edge.

* At this point I want to remind everyone that it's not impossible to have Sandboxie 64-bit; only impossible to have as good Sandboxie as 32-bit Sandboxie. And it was also shown during the course of this topic that quite a few 64-bit versions of products are not as good as the 32-bit variants. But this information is ignored in the name of PatchGuard and the fallacy of improved system stability.

* When I suggest there could have been alternate approaches to solve this problem, like Microsoft backing a central hooking framework that all developers can use, it is completely ignored, because it doesn't jive with the mantra that PatchGuard is best. And then the arguments resume the course that PatchGuard is the only way to counter incompetent third-party hooks.

* Sandboxie deploys well-behaved hooks which even support the driver being unloading during upgrade/reinstallation. Without reboot. So it's not impossible and such a framework should have been made part of the kernel many years ago. Every security software could have hooked through this and many conflicts would be resolved. But nothing was done during all these years.

* The kernel interfaces at the time of initial launch of PatchGuard were grossly inadequate even for anti-virus products, which are not "cutting-edge" kernel mode software. I have shown this by refering you to the Vista SP1 "PatchGuard APIs" which are primarily intended for use by anti-viruses to block malicious code from terminating the anti-virus itself.

* Some of the people who argue for PatchGuard say it is a good idea to trust Microsoft with security, when the above bullet point shows Microsoft clearly has little experience at battling viruses. It has been common practice for viruses for years to try to terminate anti-virus software. Yet as far as Microsoft is concerned, it was an unnecessary interface, and was added only after security vendors went public and pressured Microsoft into it. But again, my point is completely discarded, people argue that if Microsoft put PatchGuard into effect "surely" they know what they're doing.

* To emphasize this last point: When Virtual Server 2005 (64-bit) had an update that caused PatchGuard to crash systems, the solution was a fix to PatchGuard, not Virtual Server 2005. So there is double-standard in the kernel, but you don't have to look father than a few of comments ago to see that this is just fine with some people, some of them freely admitting they do in fact favor free competition. Hypocrisy, again.

Now a summary of the summary:

* All in all, I believe most companies will offer a 64-bit version no matter what, because the CEO said he identified a new target market and products must be sold. It is not important how strong the product is, most companies are used to occasionally see their product lose tests. It's also quite possible (no argument there) to always devise a solution for a particular virus sample and look better on the re-test.

* And once the company releases a 64-bit product, it is no longer in their interest to claim that the 64-bit platform twists their arm to create a sub-par product. Why would they say that? Does the competition say the same thing? Probably not.

* But here we are, independent developers with no manager, exclaiming and explaining all the ills of PatchGuard, only to be countered by blind followers of Microsoft with unsubtantiated hype that comes straight from marketting material.

* As has been suggested, each side in this argument (except the bystanders) is representing a business, so let's rule out the business as any element here. (Again, I remind you, I too could release 64-bit Sandboxie that would be able to cover most of the areas that need protection.)

There is the side that argues PatchGuard increases system stability (to some small extent) while admitting (in so many words) that there is a negative impact (to some small extent) on security products.

There is the side that says the increases in system stability are negligent and the price to pay in terms of security is large.

The decision is ultimately left to the reader because it seems neither side is willing to budge. Good night, and good luck. :)

[Peter2150]

Couple of points.

First asking if I trust MS is a dual edged question. My answer is yes and no. But I run MS operating systems regardless, as the software I run only runs on their system.

So what side of this do I come down on

Do i trust Microsoft for my security no. I can take my fully up to date and patched system 32bit, and run malware against it and it goes down.

I run the same stuff against Sandboxie and the system is protected.

Based on this 32bit results who's word am I going to trust on the 64bit end.

should be obvious.

Pete

[Victek123]

-{ Quote: "The folks here keep ignoring the most important points I make, and then accus me of not providing "solid proof". ssj100 suggested bullet points and I think that might be a good idea now." }-
.
Thank you for laying this out in such detail and clarity. What I find interesting is while you are here explaining this issue from your POV there are no Microsoft (MS) representatives supporting Patchguard, etc. There are only other users saying that they prefer to trust MS, which I think is pretty naive. Patchguard may be a sincere attempt by MS to make x64 more secure, but sincerity is hardly a guarantee of effectiveness. MS has made a sufficient number of poor choices in the past to dispel any notion that they automatically know best IMHO. I'm actually quite surprised that more advanced users would take that position.

So, what is the bottom-line? Perhaps we will have to wait for the wide adoption of x64 and then look at the infection rates for there to be consensus about how secure it is. Since I have no compelling reason to switch to x64 I will watch and wait while this plays out.

[Windchild]

Looks like the bullet points caught on! Apparently this is getting more and more heated, but I'll play along a while longer. No offense intended, though. I like to think that issues are argued, but people don't develop grudges against each other. Warning, really long and boring post coming up! ;D

-{ Quote: "The folks here keep ignoring the most important points I make, and then accus me of not providing "solid proof". " }-

It's not that people (for example, me) keep ignoring your points. I just don't agree with them. Your premise seems to be that we really need innovative stuff like Sandboxie for security. My premise is that we don't. Shouldn't be a surprise if that leads to different conclusions.

-{ Quote: "* When I show real shortcomings of the effects of PatchGuard, I get a crazy ideas in response. Perhaps it was my mistake to take these ideas lightly and not say in bold letters that they are NOT GOOD ENOUGH. So let me state clearly, these are sub-par solutions: Injecting code into every system process is not better than kernel-level hooks. If you ever saw system processes lsass.exe or csrss.exe crashing, and Windows immediately saying it has to shutdown within a minute, you know what I'm talking about." }-

I cannot speak for anyone but myself. My solution? Don't do it. Don't inject code into every system process - obviously that could cause a diffent kind of stability issue, and is not too good. Use documented, supported methods to do what you want. If you can't do something with those methods - tough. You can take that up to Microsoft and hope they do as you tell them, or you can move to develop software for a different system that allows you to do your thing. What I wouldn't do if I were you is demand Microsoft to remove PatchGuard completely, or give an option to disable it. PatchGuard, in spite of your objections, has a useful purpose, and Microsoft and some of their customers may not want to let it go by making it possible to disable it, for reasons I previously stated: if you make it easy to disable, then security software will likely just disable it by default, and proceed with the crazy kernel patching MS wanted to stop.

-{ Quote: "* At the same time, that the people suggesting (or backing) these instability-inducing workarounds, they are also touting the overall potential stability increases of PatchGuard. This is hypocritical." }-

I'm not suggesting or backing any workarounds. I'm suggesting not doing it, if you can't do it in a way that's comfortable to you. Why? Because I don't think the world of security is going to end with some security software disappearing or becoming weaker. The world survived before Sandboxie. It's likely going to survive after Sandboxie, as well. Although, I have no desire for Sandboxie to disappear anywhere. People seem to like it, and that's fine by me.

-{ Quote: "* If you go back and read posts you will see even PrevxHelp, who suggested this idea, admits they are a workaround until Microsoft adds missing interfaces. To this I have to say, why so sure they will add missing interfaces? Why would they bother when people like PrevxHelp encourage non-technical people to think that crazy workarounds and sub-par security products (not referring to the Prevx product) are a viable solution? And how come this disclaimer (more or less) has been lost in later responses when people claim PrevxHelp has shown us the light?" }-

Yeah, it's a workaround. A bad workaround, that I wouldn't use. Not a good solution. But then, not my problem. I don't have to try to sell anything to anyone. I just want to run productive computer systems to do things with.

-{ Quote: "* When the pro-PatchGuard people argued that PatchGuard is well worth the loss of developer freeedom because it completely stabilizies the kernel, I show the fallacy of this argument. It doesn't make any real difference, the kernel will still load and invoke third-party code that has the potential to be unstable. As much potential as any other piece of kernel code, including those from Microsoft. So now the argument has switched to: Ok, ok, it's not complete stabiliazation, but even it helps just a wee little bit, we think it's worth it, even if it means some security products have to lose their edge." }-

Uhh... Show me where anyone said that PatchGuard "completely stabilizies" the kernel. I certainly haven't noticed anyone saying that, and if someone did say that, I guess they had a typing accident or really didn't know what they were talking about. PatchGuard doesn't completely stabilize things, obviously. It just prevents some stability issues, not all. It's an improvement, not a complete solution that prevents all issues. The argument hasn't switched. People have been saying all along that PatchGuard is not a panacea, a complete solution to all stability issues. Even Microsoft says that. It prevents some hacks, discourages others, but doesn't do anything to prevent, for example, nVidia from writing a poor driver and going BSOD-happy. Yes, I still think it's worth it. Improved stability is always worth it, even in small improvements, if it doesn't cause any serious damage or problems to the majority of users and to productive computing tasks. And in this case, it doesn't.

-{ Quote: "* At this point I want to remind everyone that it's not impossible to have Sandboxie 64-bit; only impossible to have as good Sandboxie as 32-bit Sandboxie. And it was also shown during the course of this topic that quite a few 64-bit versions of products are not as good as the 32-bit variants. But this information is ignored in the name of PatchGuard and the fallacy of improved system stability." }-

The information is not ignored - people do notice it, and understand what they read. Some people just don't care about it, like me, because it's not relevant information to them. "Some program I don't use and most other people don't use works badly in a new OS. Well... uhh... so what?" And there isn't any "fallacy of improved system stability." You can keep saying that, and hope that people believe you, but I can guarantee it won't work against everyone. If you believe there is a fallacy, prove it. Prove that PatchGuard doesn't increase stability at all. If it increases stability even one little bit, it's an improvement. PatchGuard leaves people with some methods of messing things up in the kernel, and removes some other methods. That means less methods to mess things up, less problems. It's a simple equation. If you had said "fallacy of total system stability", then I could have agreed with you. If someone thinks PatchGuard will solve all stability issues, they're obviously wrong. But that's not what people are saying in this thread. People are saying that PatchGuard is a small step forward: it prevents some issues (good) and makes things difficult for some security software used by only few people (either bad, or irrelevant, depending on whether you use that software or not). A small price to pay for a small improvement. Doesn't sound bad to me.

-{ Quote: "* When I suggest there could have been alternate approaches to solve this problem, like Microsoft backing a central hooking framework that all developers can use, it is completely ignored, because it doesn't jive with the mantra that PatchGuard is best. And then the arguments resume the course that PatchGuard is the only way to counter incompetent third-party hooks." }-

I wonder where you're dreaming up this idea of anyone repeating a mantra of PatchGuard being best. PatchGuard is a small improvement, but it's better than nothing, as I've said repeatedly. Better than nothing, of course, in the opinion of people who put stability over ability to run certain security software.

I fully agree with you that Microsoft could do all sorts of things to make it easier for developers to hook things and do their job. I also understand that Microsoft may not want to do that. Maybe they don't like doing still more extra coding work so that other people can do things in their kernel that they don't necessarily like very much.

-{ Quote: "* Sandboxie deploys well-behaved hooks which even support the driver being unloading during upgrade/reinstallation. Without reboot. So it's not impossible and such a framework should have been made part of the kernel many years ago. Every security software could have hooked through this and many conflicts would be resolved. But nothing was done during all these years." }-

Actually, something was done. Microsoft has been trying to discourage people from patching the kernel all over the place. That obviously hasn't worked, so now they bring in bigger guns, finally. It's really not Microsoft's fault that many third party developers apparently can't write code that doesn't crash things. It's not Microsoft's job to make life peachy for security software developers that want to patch the kernel. Of course, one might like it if MS did that, but one ought to understand why they might not want to do that.

-{ Quote: "* The kernel interfaces at the time of initial launch of PatchGuard were grossly inadequate even for anti-virus products, which are not "cutting-edge" kernel mode software. I have shown this by refering you to the Vista SP1 "PatchGuard APIs" which are primarily intended for use by anti-viruses to block malicious code from terminating the anti-virus itself." }-

That actually isn't surprising at all, considering the existence of the least privilege principle. Honestly, people. You don't have to run as admin and then use desperate kernel hooks to "prevent" malware running as admin from terminating your AV. The operating system includes a method of protecting processes from termination. Limited users can't terminate processes that run with superior privileges. Can't the AV guys make their scanner run as SYSTEM? They can. Can't people run as LUA? Yes, they can, but probably won't, unless forced or educated enough. One might want to consider that perhaps Microsoft is getting sick and tired of the security features of their operating system being systematically ignored.

AV company X: "Boo-hoo, my AV can be terminated by malware that runs with admin privileges, and your evil OS doesn't let me hook the kernel to protect my AV!"
Microsoft: "How about not running the malware as admin in the first place? And if you find a privilege escalation issue, how about letting us know?"

-{ Quote: "* Some of the people who argue for PatchGuard say it is a good idea to trust Microsoft with security, when the above bullet point shows Microsoft clearly has little experience at battling viruses. It has been common practice for viruses for years to try to terminate anti-virus software. Yet as far as Microsoft is concerned, it was an unnecessary interface, and was added only after security vendors went public and pressured Microsoft into it. " }-

See above. Maybe someone at Microsoft had enough brains to know about LUA, and maybe that someone thought: "Umm... limited users can't terminate processes running as SYSTEM. Why should I provide these guys with a method of protecting their processes from termination when it already exists?" On the other hand, that someone was probably a huge optimist, hence the later changes to the OS.

-{ Quote: "But again, my point is completely discarded, people argue that if Microsoft put PatchGuard into effect "surely" they know what they're doing.

* To emphasize this last point: When Virtual Server 2005 (64-bit) had an update that caused PatchGuard to crash systems, the solution was a fix to PatchGuard, not Virtual Server 2005. So there is double-standard in the kernel, but you don't have to look father than a few of comments ago to see that this is just fine with some people, some of them freely admitting they do in fact favor free competition. Hypocrisy, again." }-

I'll say this: Microsoft knows what they're doing a lot better than many other folks. I'm not sure where anyone has said that any "double-standards" in the kernel are fine. If Virtual Server has a problem, it should be fixed. If it's not fixed, that's one problem. But the existence of that problem doesn't magically make PatchGuard (PatchGuard is, interestingly enough, not Virtual Server) wrong and unholy, and anticompetitive, and whatever big buzzwords people care to dream up here.

-{ Quote: "* All in all, I believe most companies will offer a 64-bit version no matter what, because the CEO said he identified a new target market and products must be sold. It is not important how strong the product is, most companies are used to occasionally see their product lose tests. It's also quite possible (no argument there) to always devise a solution for a particular virus sample and look better on the re-test." }-

Sure, people will release products to make money with them, even if they aren't good products. Business as usual.

-{ Quote: "* And once the company releases a 64-bit product, it is no longer in their interest to claim that the 64-bit platform twists their arm to create a sub-par product. Why would they say that? Does the competition say the same thing? Probably not." }-

Sure, people will market their products as being great, even if they suck. Most people will not say their products are sub-par for any reason, even if the reason is "Microsoft is evil." Business as usual.

-{ Quote: "* But here we are, independent developers with no manager, exclaiming and explaining all the ills of PatchGuard, only to be countered by blind followers of Microsoft with unsubtantiated hype that comes straight from marketting material." }-

Ah, personal attacks - making people look smarter since 5400 BC. ;D "Blind followers of Microsoft with unsubtantiated hype that comes straight from marketting material. (sic)" I like that. I've never been a blind follower of anyone, although I was at one point literally blind. But that got better. As for hype, I find that it's not. PatchGuard does help with some issues. With some others, it doesn't help. Surprise, where?

-{ Quote: "* As has been suggested, each side in this argument (except the bystanders) is representing a business, so let's rule out the business as any element here. (Again, I remind you, I too could release 64-bit Sandboxie that would be able to cover most of the areas that need protection.)" }-

Actually, no. I'm neither a bystander in this argument or representing any business, even if some might be inclined to imply otherwise. I'm here representing me. One guy. One very annoying, boring and generally unpleasant guy, but not a business. And I say PatchGuard has advantages for me and most other people not using obscure security software, and no downsides, because we don't use obscure security software. It may have disadvantages for you, but that's not my problem. It's a dog-eat-dog world out there. The reason why I might state something that obvious is that sometimes some people forget that their problems aren't problems for everyone else as well. For example, some people here really hate not having admin/root privileges all the time, but for most Linux users that is not a problem.

-{ Quote: "There is the side that argues PatchGuard increases system stability (to some small extent) while admitting (in so many words) that there is a negative impact (to some small extent) on security products." }-

Yeah. That's the side I'm on, right there. ;D As said before, the negative impact on security products is irrelevant to me and I dare say most other humans, because we don't use computers so we could run security software.

-{ Quote: "There is the side that says the increases in system stability are negligent and the price to pay in terms of security is large." }-

And that's the side mostly filled with good guys trying to make their living by writing security software and people that are just really big fans of some security products. :) But, these people are few in number. And when you work on something as huge as Windows, you generally have to pay more attention to the majority. Most people aren't hurt by PatchGuard. Only very few people are. Many people will gain small benefits from PatchGuard through seeing less crashes.

-{ Quote: "The decision is ultimately left to the reader because it seems neither side is willing to budge. Good night, and good luck. :)" }-

Ain't that the truth. ;D Good luck to everyone.


As for my summary of the summary, so to speak:

1) PatchGuard is good, because small improvements in stability are better than no improvements in stability.
2) Security isn't the responsibility of third parties alone. They who make the OS have a huge responsibility over security, and the user has an almost equally huge responsibility. Only after that, can any third parties come in to the equation. Therefore, Sandboxie and AVs aren't "the police", Windows is. The third party guys are third party security guards many people cannot afford or don't know about. That's why it's good for the police to get even just a little bit better at keeping the streets open and the bad guys off the streets.
3) Security isn't a product. If your entire security policy is devastated by the loss of one product, or two, you're doing it wrong.
4) If you don't like PatchGuard preventing some software you develop or like, I don't think there's anything else to do except complain to Microsoft - you can even sue them if you like, but don't be too confident in victory - or move to a different OS that lets you do what you want.
5) Microsoft has every right to decide what to do with their own OS, unless it's something that happens to be illegal.

All in all, I've got nothing against no-one, even if I have a big mouth and a small head! :o

[pbw3]

-{ Quote: "My reason for posting in this thread was to present a different point of view from the one embraced by fans of security software." }-
and which both sides have put very eloquently..

Re some earlier issues, and as a layman bystander (!)..

As far as I am concerned, MS, for all practical intents and purposes (and ignoring legality), is a monopoly operating system - my clients use it, my clients' clients use it - we use common based files, software, software functionality, etc.. in essence, I have very little genuine choice practically if I wish to use a computer for the purpose it was purchased for.. ie, there is enough interdependency going on amongst users in the world for it to be "monopolistic" in nature..

With any monopoly should come responsibility, and the points made re the majority of users benefiting from change may well indeed be true..

However, and I do not have technical knowledge here, but from what follows, it appears that there may be genuine weaknesses (if running in admin mode?) whereby "honest" software may be at a potential disadvantage to malware as regards what it should be capable of accessing at low level on the OS (if I have read these posts correctly)..

-{ Quote: "

-{ Quote: "
There is already at least one publicly available hooking toolkits that circumvent PatchGuard. (And as a side note, it's ironic which site hosts it.) It's just that no security developer will risk using such a toolkit. But the future wave of 64-bit rootkits will have no such compunctions about that. " }-
Yeah, and Microsoft admits that the system isn't perfect. Most systems are not. So? It's still an entirely valid attempt at protecting the system from stability issues. As for rootkits, well, it's not like you have to run everything as admin and give everything omnipotent control over the entire OS." }-
If LUA is a solution to that particular problem, then great, and fine for those (including me) who use it.. But sometimes, trying to "force" a particular faith "for the greater good" (be it in software or politics - going back to the analogies) can be difficult / counter productive - and that ignores those who might need to operate outside of LUA..

My commercial gut tells me that MS's corporate bank account will lead them (as always!), and, as regards direction, from the least hassle / downside they get from whatever verbal conflict / adverse publicity they attract, whatever the ultimate balance of that is.. and lots of time to see where that route takes them....

Peter

[tzuk]

Of course I disagree with almost everything you write Windchild, but it's getting tedious. But I will counter in detail one of your points and I hope you will be able to draw general conclusions from that. First, I said:

-{ Quote: "* Some of the people who argue for PatchGuard say it is a good idea to trust Microsoft with security, when the above bullet point shows Microsoft clearly has little experience at battling viruses. It has been common practice for viruses for years to try to terminate anti-virus software. Yet as far as Microsoft is concerned, it was an unnecessary interface, and was added only after security vendors went public and pressured Microsoft into it." }-

Then you responded:

-{ Quote: "That actually isn't surprising at all, considering the existence of the least privilege principle. Honestly, people. You don't have to run as admin and then use desperate kernel hooks to "prevent" malware running as admin from terminating your AV. The operating system includes a method of protecting processes from termination. Limited users can't terminate processes that run with superior privileges. Can't the AV guys make their scanner run as SYSTEM? They can. Can't people run as LUA? Yes, they can, but probably won't, unless forced or educated enough. One might want to consider that perhaps Microsoft is getting sick and tired of the security features of their operating system being systematically ignored. " }-

This is only a part of the problem. The control panel of your anti-virus or HIPS has to run with your credentials because that visible part of the program is operating within your logon session. What faith would you have in a security solution that can't secure its own control panel?

Running the control panel as Administrator is not a suitable alternative. I'm sure that even you would complain if you had to respond to a UAC elevation prompt every time you started your computer, because your anti-virus control panel was trying to run as Administrator. And besides, not everyone might be careful as you, and they might respond to a UAC elevation request by a virus, without paying attention, and give free reign to a virus that stops the core processes of the anti-virus.

So yes, anti-virus software REALLY DOES HAVE TO be able to protect such activities from the kernel, anything else is just not foolproof, is a facade, a joke.

And repeating what I said earlier, Microsoft released PatchGuard at a time when the kernel had no official facilities to control such malicious behavior. And furthermore their policy at the time was "Tough!", just like you think is best. After the public pressure from anti-virus policies, they added a couple of new interfaces.

So I hope that you will agree, just throwing around empty words like LUA or "system stability" does not solve any real problems.

* * *

As for proof, you don't actually have any proof that PatchGuard will make any practical difference in the field. You can only speculate at this point that 64-bit kernel software will perform better, and that if it does, it will be largely thanks to PatchGuard. And because this speculation is based on press releases, I keep telling you it lacks critical thinking, or in other words, it's blind faith. I can ask you to examine this belief, but I'm sure you will just blow it off.

On the other hand, it is already a reality that PatchGuard limits the range of options available to some 64-bit security software.

Food for thought.

[wat0114]

-{ Quote: "

That actually isn't surprising at all, considering the existence of the least privilege principle. Honestly, people. You don't have to run as admin and then use desperate kernel hooks to "prevent" malware running as admin from terminating your AV. The operating system includes a method of protecting processes from termination. Limited users can't terminate processes that run with superior privileges. Can't the AV guys make their scanner run as SYSTEM? They can. Can't people run as LUA? Yes, they can, but probably won't, unless forced or educated enough. One might want to consider that perhaps Microsoft is getting sick and tired of the security features of their operating system being systematically ignored.

" }-

It's a little funny to read this because aren't MS Windows accounts created with administrative privileges by default during the installation process?

Anyways, I have a question for you Windchild or anyone else who can answer: Currently I have a couple pcs running Sandboxie as the only 3rd party security app under LUA and SRP, and another running Outpost Security Suite and Sandboxie also under LUA and SRP, all three machines 32 bit - two @ XP and one @Vista. To my knowledge, I can honestly say I have not experienced any stability issues on any of the three machines running this software that surely must be hooking the kernel.

So...


Is it not possible Agnitum and tzuk have done a pretty decent job designing their products, since I and countless others are running these products successfully with no freeze ups or BSODs? I've even got my Vista machine overclocked by 3% with no issues at all.
Could it be this setup offers better security than a 64 bit system running only LUA/SRP but no 3rd part software to complement?
is it fair that MS spearheads the Patchguard solution because there are a few (okay, many) developers who can't hook the kernel properly?
Why can't MS develop a merits program of sorts to allow developers who can meet a minimum technical standard to hook the kernel properly access to the kernel, and shut out those who can't? This way the truly talented and responsible developers are not punished en masse along with everyone else.


That's about it. Thanks!

[Windchild]

Sorry for being tedious! I've been called that before, and I know it is true. But an annoying man can't help but be his annoying self. ;D Your posts, like many other posts in this thread, have been interesting to read.

-{ Quote: "
This is only a part of the problem. The control panel of your anti-virus or HIPS has to run with your credentials because that visible part of the program is operating within your logon session. What faith would you have in a security solution that can't secure its own control panel?

Running the control panel as Administrator is not a suitable alternative. I'm sure that even you would complain if you had to respond to a UAC elevation prompt every time you started your computer, because your anti-virus control panel was trying to run as Administrator. And besides, not everyone might be careful as you, and they might respond to a UAC elevation request by a virus, without paying attention, and give free reign to a virus that stops the core processes of the anti-virus.

So yes, anti-virus software REALLY DOES HAVE TO be able to protect such activities from the kernel, anything else is just not foolproof, is a facade, a joke." }-

Well, quite a lot of security software seems unable to secure their own control panel even on 32-bit systems - at least when I last tested. But that doesn't really affect my faith in them (it's low in every case). As long as the important part - the scanner part - works and doesn't get terminated, it isn't a big deal, in my humble opinion. So there isn't a definite, absolute, unavoidable "need" to have termination protection for the control panel part. Instead of "this is needed, necessary, I absolutely can't do without it" I would say "this would be nice, even great, but my security won't be a disaster if it doesn't happen - but go ahead and make it possible." And I'm not sure that limited users, in all environments, should have a control panel to the AV - especially in corporate environments, and especially if that control panel lets them disable the AV... I could see some folks running an AV with no control panel, silently in the background, killing whatever needs killing and not asking the user.

But yes, I fully agree with you that it's good for AV software to have methods other than LUA to protect their processes from termination. Apparently, Microsoft now thinks so, as well. I can only guess, but perhaps their initial failure to offer that was a simple mistake or knee-jerk reaction of some sort. I really don't know. That they would later fix that suggests that they're capable of learning from mistakes and even correcting them occasionally. Me, I said that the initial failure of MS wasn't surprising at all, since LUA exists. I didn't say that it was a good thing, or that MS should not ever change it. How did I put it... ah yes, "that someone (people who made the decision not to offer methods for termination protection) was probably a huge optimist, hence the later changes to the OS". ;D To me, it's still easy to overlook the "need" for termination protection. LUA can protect the important parts, and as for the control panel, even if it dies it's not a disaster - just "not pretty." But yes, I agree that pretty is better than "not pretty."

-{ Quote: "And repeating what I said earlier, Microsoft released PatchGuard at a time when the kernel had no official facilities to control such malicious behavior. And furthermore their policy at the time was "Tough!", just like you think is best. After the public pressure from anti-virus policies, they added a couple of new interfaces." }-

"Tough" is a pretty harsh policy, but I can certainly agree with "tough". I'm just unpleasant like that. Then later, if one finds that it was a little "too tough", there's always the option of backing off a little. :) AVs need to protect their processes from termination? Well, let's give them that, if it doesn't bother us too much. Didn't seem to bother MS. I like to think that it's best, generally, to start with harder restrictions and then progress slowly towards less and less strict restrictions as serious problems are discovered. After all, we're not talking software that's widely used now. 64-bit Windows with PatchGuard isn't on the systems of the majority of Windows users. It's in a kind of testing phase if you think about it in that way - and we, the users, are test dummies. That's how the world works.

Actually, I believe, that with time, Microsoft may indeed open up their restrictions as developers give feedback, as you have done. As I said, I don't think there are other ways than to just complain to MS or change to another OS. If you complain enough, maybe they'll do what you want. It may not be good for everyone, but as long as it's good for you, then that's likely what you should do. For you guys who love Sandboxie and others, you can do things, too: you could contact Microsoft reps and politely but firmly explain your point of view to them - that Sandboxie needs to be able to do some things, and MS should make it possible in spite of PatchGuard. It won't necessarily help, but it's better than doing nothing. What really doesn't help is the whole "Evil Empire" and "anticompetition" talk. People don't necessarily respond well to being called names and antagonized.

As for me, I only opened my mouth to say that it's not like third party developers are the ones responsible for Windows security. And further, to say that PatchGuard does do something useful, even if it isn't as useful as, say, the ability to use a lot more RAM than before. And then finally, there was the idea of explaining the other point of view - you know, the point of view that is opposite to the "PatchGuard is evil, Microsoft is evil, I will not use 64-bit" one.

-{ Quote: "So I hope that you will agree, just throwing around empty words like LUA or "system stability" does not solve any real problems." }-

I agree that empty words don't solve problems. But I don't think LUA is an empty word. Or that system stability is an empty phrase. In my experience both are pretty important, even as compared to Sandboxie. There are, of course, issues they can't solve. But those issues may have other solutions. When it comes to AV software control panels, there are two "solutions" immediately obvious to me:
1) Microsoft could go ahead and give AV folks ways to protect their processes from termination. I guess that they have done that, so... that's that.
2) Do nothing. Even if you can terminate an AV control panel, so what? It doesn't terminate the protection - or shouldn't. And it's not like there's anything preventing the part of the AV that runs as SYSTEM from just creating the control panel process again if it disappears unexpectedly - with the usual lower privileges, of course. (That of course could then lead to the malware just terminating it again, over and over again... but at least that would be a very decent sign of infection!) Perhaps it's not as "pretty" a solution as the one you would prefer, and Microsoft later chose, but it's hardly a complete disaster, either. It's not a case of "if we can't do this, you will get owned, because we can't protect you."

-{ Quote: "As for proof, you don't actually have any proof that PatchGuard will make any practical difference in the field. You can only speculate at this point that 64-bit kernel software will perform better, and that if it does, it will be largely thanks to PatchGuard. And because this speculation is based on press releases, I keep telling you it lacks critical thinking, or in other words, it's blind faith. I can ask you to examine this belief, but I'm sure you will just blow it off.

On the other hand, it is already a reality that PatchGuard limits the range of options available to some 64-bit security software." }-

Ah, so now we're talking about "practical difference" in the field. It's a little different from the previous expressions "completely stabilize" or "improved system stability". The proof I was referring to was simply logic, and I never said it would prove "practical differences" on all systems for all users, depending on what one means by practical: remove some methods to mess things up, and the result is fewer methods to mess things up, which means improved stability. Whether the difference is huge or something that can be immediately observed in practice is another thing. Most improvements coders make to software aren't immediately noticeable in practice, to users. Very often, the improvements are almost invisible. It's not easy to tell whether something was caused by PatchGuard or not. But, one thing is sure: PatchGuard does decrease crashes caused by the kinds of kernel patching it prevents. That is not about blind faith. It's just logic. If you prevent a certain type of patching, then how can that patching - which you cannot do - cause crashes? It can't. So, that means fewer of those crashes. Other crashes may still occur, but they're a different case, then.

Sure, devs can start writing code badly in other ways. But really, what was stopping them from doing that before? Nothing. The positive part that can be justifiably attributed to PatchGuard is simply that PatchGuard does in fact limit the ways you can patch the kernel. Remove even one method that caused trouble before, and that is an improvement. It's an improvement that might not be called a practical difference in the field in situations where people then create different kinds of problems when PatchGuard prevents one type of problem - but any improvement is good to me. I like even "theoretical improvements", such as rewriting some piece of software to be smaller but do the same things just and only as well as before - or preventing some kernel patching methods but leaving others. That is not based on press releases. It's based on logic.

But yes, I readily admit that most people will never be able to tell whether their systems were saved from a crash by PatchGuard or not. But then again, they will never be able to tell many other things, either, like that memory management is now 1.2 % more effective than before or that AV X has made a 0.7 % improvement in scanning speed. Or that Sandboxie now uses 0.2 % less memory to do its thing than before. Unless, they really spend some time trying to find out. Improvements can be small, even near invisible, while still being improvements. And on the other hand, if we consider practical differences... What is the practical difference between systems with PatchGuard and systems with no PatchGuard, when they're used by someone who doesn't know anything about obscure security software? Nothing? Or that their "choice of security software" is limited? Well, if it's the latter, in that case it's not just PatchGuard that limits it. The lack of popularity of the 64-bit platform is the first limit that discourages people from developing software to it, and once it gets popular and that changes, it still leaves things like driver signing that prevent brilliant young students from writing all kinds of "anti-rootkits" and stuff that use unsigned drivers to do their thing - because they don't have the means to sign their drivers. My point here is that the limitations aren't exactly dreadful. In fact, to most people, they're completely acceptable.

Still, to all you guys concerned that 64-bit may not run your fave security software, there is something that you can do:
1) You can stick with 32-bit.
2) Or you can use virtualisation, like PrevxHelp suggested, to run your security software - and it might even increase security further. Maybe.
3) You can contact Microsoft and give constructive criticism! Don't call them a bunch of evil idiots of M$ who can't code. That likely won't work. Explain your point, and maybe they'll even listen. The hopes ain't high, but...

[majoMo]

-{ Quote: "Your premise seems to be that we really need innovative stuff like Sandboxie for security. My premise is that we don't." }-
So the crucial question isn't "64-bit systems and anti-malware software" topic about.

The purpose'core component is then how to dwindle "stuff like Sandboxie". If needed for that, is a fitness to keep ignoring the point even.

Humm.. I'm clarified now! It's good to leave alone to talk, talk and talk again. To understand the veiled thoughts.

[BG]

-{ Quote: "So the crucial question isn't "64-bit systems and anti-malware software" topic about.

The purpose'core component is then how to dwindle "stuff like Sandboxie". If needed for that, is a fitness to keep ignoring the point even.

Humm.. I'm clarified now! It's good to leave alone to talk, talk and talk again. To understand the veiled thoughts." }-

what?!:blink:

[Windchild]

-{ Quote: "It's a little funny to read this because aren't MS Windows accounts created with administrative privileges by default during the installation process? " }-

Yes, they are. And that is only one of many things I - a "blind follower of Microsoft" - have criticized Microsoft for over the years, just like many other people have done. That is Microsoft's fault, although I can understand why they're slow and reluctant to change that default, and I understand also why they made it originally. I understand it, but I don't agree with it. Fortunately, we don't all have to use the default config.

-{ Quote: "Anyways, I have a question for you Windchild or anyone else who can answer:


Is it not possible Agnitum and tzuk have done a pretty decent job designing their products, since I and countless others are running these products successfully with no freeze ups or BSODs? I've even got my Vista machine overclocked by 3% with no issues at all.
Could it be this setup offers better security than a 64 bit system running only LUA/SRP but no 3rd part software to complement?
is it fair that MS spearheads the Patchguard solution because there are a few (okay, many) developers who can't hook the kernel properly?
Why can't MS develop a merits program of sorts to allow developers who can meet a minimum technical standard to hook the kernel properly access to the kernel, and shut out those who can't? This way the truly talented and responsible developers are not punished en masse along with everyone else.

" }-

1. Yeah, it's definitely possible. From what I've heard from users of Sandboxie, Tzuk seems to have done a really good job. I don't use the product myself, and I haven't reverse-engineered it or anything, so I shouldn't comment further. It is possible to do things the right way. It's just a little difficult and takes a bit of effort, and many coders are lazy. Fortunately, some coders are not. :)

2. Yes, that could be the case. But finding out if it really is the case is a pretty complex task that requires you not only to evaluate what kind of user you're dealing with but also consider bugs in the various software involved. In this case, I would argue that a combo of Outpost Security Suite and Sandboxie should offer "good enough" protection for most any user (this is based on what I've heard from people who use those softwares, not on my personal experience, since I don't use the softwares in question). On the other hand, I would also argue that LUA and SRP would also be "good enough", and do it for free, while using less hardware power and not introducing, potentially, new vulnerabilities into the system. But whichever you choose, I won't say that your setup is poor. If one can't stay safe with a setup like that, then it's likely a case of the user just being incredibly careless.

3. Yes, I think it is fair. Harsh, and tough, but fair. And by "fair", I mean that it is treating all developers the same: no-one gets special permissions to patch something other developers have no permissions to patch. Further, it is "fair" in that it's Microsoft's OS, and it is morally within their rights to try to prevent hacks to their OS kernel.

4. They could! But I suspect they, like I, might consider that "too much work" to find out who they can trust to get it right, and then further the others might get really bitter, so it's also "too much risk". Imagine the flamewars and potential lawsuits that could happen if Microsoft gave AV company X free rights to patch the kernel but told AV company Y that their company can't do it, because their company isn't good enough!


Microsoft is far from perfect, like most everyone. And it's true that PatchGuard can cause trouble to people that are trying to do some types of kernel patching, even for legit security software. But, I try to tell users that this isn't such a huge problem. There aren't any particular security software products I know of that are indispensable to running a secure system. For one thing, most Windows users have never even heard of these security products we talk of in this thread. They don't use them, they can't lose them even if MS gets ugly with PatchGuard. The people that use stuff like Sandboxie are quite often, I suspect, people that frequent security forums like this one right here instead of being just Joe Average. These people could run a secure system without Sandboxie and others, or at least they have the capacity to very quickly learn how to do so. So, it's not a disaster for them, and it's not a disaster for the common user who doesn't run Sandboxie anyway, because he doesn't know it even exists. For those people who just want to use their computers to do useful things (like creating music or graphics), 64-bit Windows is no problem once it gets mainstream, and has many advantages. That was pretty much my point here. In my opinion, too much emphasis is given to the ability to run some specific security software that does very special things. Isn't running more productive software more important? They, of course, need not be mutually exclusive, but in a case like PatchGuard where MS really seems to want to do it on a platform that offers some nice advantages (like more RAM, yummy!), it would certainly be acceptable to a huge majority of users. And should be, I think. But that's just my point of view, and the world can disagree with me. But maybe not everyone does. :)


-{ Quote: "So the crucial question isn't "64-bit systems and anti-malware software" topic about.

The purpose'core component is then how to dwindle "stuff like Sandboxie". If needed for that, is a fitness to keep ignoring the point even.

Humm.. I'm clarified now! It's good to leave alone to talk, talk and talk again. To understand the veiled thoughts." }-

I'm not sure I understand that. But let me try.

I really have no agenda to "dwindle", that is to say destroy, software like Sandboxie. I don't want someone to come in and destroy them, or anything like that. But, if Microsoft makes some large change in their OS that makes Sandboxie impossible or weaker than before, and that change has a reasonable justification like PatchGuard does, I won't cry about that. It won't be a problem to me, or most Windows users. That's the way I see it.

I don't think there are any veiled thoughts in my posts here. There may be thoughts not expressed very clearly, but that's my failing.

What I mean when I say "My premise is that we don't (need software like Sandboxie for security)" is that I know you can be reasonably secure without running Sandboxie, and therefore Sandboxie is not needed (required) to run a reasonably secure system. That's as deep as it goes. There's no hidden agenda. In my experience, there is no one security software so indispensable that it is a requisite of security. That's the point. That's the reason why I'm not worried if PatchGuard breaks some security software. I would be very worried, on the other hand, if PatchGuard broke all graphics editing software, for example, since that is a type of software very much needed by me and a huge number of other users.

I don't think I can explain it any better than that.

[majoMo]

Like I said before I understood: "So the crucial question isn't "64-bit systems and anti-malware software" topic about."

It's very good to have things clarified. The issue isn't "64-bit systems and anti-malware software" anymore; it's "64-bit systems and their - MS - excellence". Anti-malware software is an hindrance, fetter - such "stuff like Sandboxie" at all here. A convenient way to change the point: there aren't issues because 64-bit is the excellent issue... (for now...). The axiom needs to be changed to change the point... Thus won't there be original point anymore...

[wat0114]

Thank you for your comments, Windchild! The thread has actually become more interesting for me of late because you and kees, for instance, have explained things in a way that I can understand a bit better, as opposed to the hieroglyphic-like technical language wielded about by the software developing gladiators ;D

I do understand to a point Microsoft's reluctance to allow only select members access to the kernel, but their decision to shut out everyone just to simplify things for themselves seems a little excessive, even knee-jerk, to me, given the abilities of developers like tzuk, Ilya and Prevx, to name a few, to hook the kernel in an efficient and responsible manner, although your point about potential lawsuits due to unfairness is valid to say the least. Oh well, it is, after all, their O/S and they'll certainly do as they please especially to suit their best interests.

[Wildest]

-{ Quote: "Thank you for your comments, Windchild! The thread has actually become more interesting for me of late because you and kees, for instance, have explained things in a way that I can understand a bit better, as opposed to the hieroglyphic-like technical jargon wielded about by the software developing gladiators ;D " }-
I am sorry but I must strongly disagree with this insinuation.

IMO Tzuk, Ilya and PrevxHelp have all gone to great lengths to make very complicated concepts accessible to the average user, and the comments by these talented individuals are the backbone of this thread.

Please let's give credit where credit is due.

My regards.

[wat0114]

-{ Quote: "I am sorry but I must strongly disagree with this insinuation.

IMO Tzuk, Ilya and PrevxHelp have all gone to great lengths to make very complicated concepts accessible to the average user, and the comments by these talented individuals are the backbone of this thread.

Please let's give credit where credit is due.

My regards." }-

Oh my goodness, am I the only one who doesn't understand the technical concepts put forth in this thread by the three gentlemen :o :D

[Wildest]

-{ Quote: "Oh my goodness, am I the only one who doesn't understand the technical concepts put forth in this thread by the three gentlemen :o :D" }-
jar⋅gon –noun
1. unintelligible or meaningless talk or writing; gibberish.
2. language that is characterized by uncommon or pretentious vocabulary and convoluted syntax and is often vague in meaning.

I apologise if I misinterpreted your position.

[trismegistos]

-{ Quote: "So the crucial question isn't "64-bit systems and anti-malware software" topic about.

The purpose'core component is then how to dwindle "stuff like Sandboxie". If needed for that, is a fitness to keep ignoring the point even.

Humm.. I'm clarified now! It's good to leave alone to talk, talk and talk again. To understand the veiled thoughts." }-
Nicely put.
The veil has been lifted.
Those with the darkside versus the Force. ha ha

[Peter2150]

-{ Quote: "I'd also just like to make a further point that there are many users out there that actually rely heavily on Sandboxie for everyday security (eg. Peter2150...sorry to single you out mate!). When I say they "rely heavily", I mean exactly that.

" }-

No problem. I do rely quite heavily on Sandboxie, simply because it works, and several people I do trust can use my machines, with anyone worrying.

I have no incentive to go x64, since a lot of my software doesn't yet run on it, at least an in an advantageous way.

[Wildest]

-{ Quote: "If I was entirely a Linux user (and could do everything I needed to with Linux), and swore I would never touch Microsoft again (I have a couple of friends in the computer business that have this type of mentality...perhaps not this extreme, but close haha), then I would perhaps have the mentality that Microsoft can do whatever they want, even if it broke all graphics editing software for everyone else. This is called being selfish. That's the problem with taking this type of debate in this direction - there isn't really a right answer ultimately. Greater good I hear you say? Lesser evil I hear you say? You can always justify anything. Tzuk and Ilya etc have every right to be unhappy about what Microsoft are doing, and have every right to try to legally prevent or discourage users from supporting Microsoft's PatchGuard etc on 64-bit. On the other hand, you have every right to be happy/content about what Microsoft are doing." }-
Ultimately this thread's purpose was to serve as an entertaining distraction.
Microsoft only listens to Corporate; even DirectX was a ploy to lock in Corporate.

When Corporate agrees with Tzuk's and Ilya's position, then Microsoft will effect some change, possibly in the form of a service pack with some new APIs, otherwise, this discussion is pretty much moot.

[Victek123]

-{ Quote: "Ultimately this thread's purpose was to serve as an entertaining distraction.
" }-
.
Well, it has also been educational. I've been considering switching to x64 for a while, and have been wanting to learn more about Patchguard, how security software is implemented, etc. Becoming more aware of the issues has made me more cautious and I feel that's a good thing.

[Kees1958]

-{ Quote: "Looks like the bullet points caught on! Apparently this is getting more and more heated, but I'll play along a while longer. No offense intended, though. I like to think that issues are argued, but people don't develop grudges against each other. Warning, really long and boring post coming up! ;D

-{ Quote: "
So a kernel hook has a lot of potential to cause system instability, but injecting code into csrss.exe (the main Windows user interface component) and de-stabilizing it, that is somehow better?
" }-

I cannot speak for anyone but myself. My solution? Don't do it. Don't inject code into every system process - obviously that could cause a diffent kind of stability issue, and is not too good. Use documented, supported methods to do what you want. If you can't do something with those methods - tough. " }-

@Windchild,

You are missing TZUK's point.

Microsoft history on streamlining progrom to program communication and limiting the points of entry for possible malware comes from undocumented 'features' in a final OS-releases. That is why we needed third party security software in the first place.

So now they are improving their opinion on this. An improveent is PatchGuard, but even within the UAC policy model objects and processes of the same rights category are allowed to perform dll injections.

See Mark's Russinovich presentation on http://eusecwest.com/esw07archive.html for an explanation.

Now it is to say at the least a bit hypocrite attitude, they could have streamlined other more urgent matters first ('official' openings in the OS security model which effect system reliability more)

for ease of understanding (a real world's example):

A museum director has to allow everybody in, due to its function in society. Because of the shelter the museum buildings provide they attract alcoholists and drug abusers who sleep in the interconnecting sheltered pathways. Making them smell awefull.

So now they Museum director hires a security agency and installs toilet ladies to clean the official toilets. Only the museum closes at 21.00 and the premises at 22.00 hours. At 21.15 the security guards leave the premises and the toilet ladies leave the buildings at 21.00 (after locking the toilets).

After a six month evaluation period, they report happily that the offical toilets are cleaner, but the interconnecting building pathaways smell worse (logically when you know that the alcoholists/drug abusers do not spend money on offical toilets, but ~Snip~ at the more quiet parts of the premises, and by nature have learned to evade security guards).

So now they are hiring an extra cleaning service which operates during the day

Consider patchguard the toilet ladies, the security service as being UAC, the ~Snip~ still roaming freely are the allowed side by side intrusions of objects with same rights (the point TZUK is making), the extra cleaning service is the free AV which Microsoft is releasing.

The point I am trying to make
When you keep stepping back, the discussion changes to a concrete very interesting experts opinion's thread, to a discussion on a philosophical level. When you take to much of a helicopter approach, what you say is true, but is not relevant anymore. For sake of clearity I do not argue your right to post, just trying to get you out of your helicopter, back on the ground.

I agree with you that PatchGuard is a step forward and I basically agree that restricting third party access to the kernel will improve OS stability.

But I also agree with Ilya and TZUK that the roll out scheme could have provided a clearer and more structured API to ensure system security OR have the guts to limit side by side intrusions also within UAC (but this would have a to big an impact on commercial software using formerly undocumented features of previous Windows OS-ses).

The guys from PrevX seem to have found a pragmatic approach, their security product uses diffferent (more) security mechanismes, so they can say (without weakening their security promise): we have ways to deal with it.

Emotions aspect in the discussion
Well considering the measures taken and the actions planned (to be released free AV), I do not believe that MicroSoft is only driven by ethical and more profound reasons to improve the security and quality of the digital world. After an unsuccesfull attack on the security industry some other arguments must play a role also in the release calendar.

Back to our real life example:
It turned out that the same city counselor was responsible for reducing drugs abuse (alcohol, any) and the museum. Keeping them (alcoholists, drug abusers) nicely centred at night in the museum, helped to the impression that his anti-drug policy was succesfull, therefore he willingly took a half witted approach to the museum's problem (which was frequented by tourist outside the city, with no right to vote for a city counselor :-)

-{ Quote: "
Microsoft only listens to Corporate; even DirectX was a ploy to lock in Corporate.

When Corporate agrees with Tzuk's and Ilya's position, then Microsoft will effect some change, possibly in the form of a service pack with some new APIs, otherwise, this discussion is pretty much moot." }-

Yep, agree with Wildest: third party security suppliers directed at the home market (the museum visitors from outside MicroSoft city) wil not be heared by this counselor (MicroSoft) until its (corporate) citizins start to complain about it.



Cheers

Kees

[Windchild]

Well now, another long and tedious post from me, coming up. We've been warned. But this is the last long one, I promise, before I leave you guys to discuss only expert opinions. ;)

-{ Quote: "@Windchild,

You are missing TZUK's point. " }-

Thanks for trying to explain it to me. :) However, I don't think I'm missing his point. We just appear to have a completely different point of view on the subject. Which is only normal in any discussion.

-{ Quote: "Microsoft history on streamlining progrom to program communication and limiting the points of entry for possible malware comes from undocumented 'features' in a final OS-releases. That is why we needed third party security software in the first place." }-

Microsoft history on limiting the points of entry for possible malware comes from undocumented 'features' in final OS-releases? Either I don't understand that statement, or I don't agree with it, but I'm not sure which it is. Perhaps a little bit of both.

Microsoft's history on limiting what malware can do traces back to about 1989 at the least, when they started planning Windows NT. The limits and the 'features' aren't all undocumented: on the contrary, the security model of NT is documented well, complete with the rights and privileges of limited users and the all-conquering power of admins. The idea being least privilege. To limit the damage malicious users or programs can do, run them in a limited user context - don't give them all-powerful admin privileges. MS made a mistake, from the security perspective, with the default configuration, trying to make things as easy to use as possible by making everyone admin. That probably helped buy them the market share, but at the cost of lots of deep malware infections. But understanding things like this is pretty useful if you're interested in knowing why MS does something - they're a business.

As for points of entry? What's undocumented about them, except the vulnerabilities, which are obviously undocumented in any software until they have been discovered?

Some people have been able to run Windows NT systems safely without AVs and anti-malwares etc for over 15 years, using just the very well documented features of the operating system. Are those features perfect? No, nothing is. But they're pretty good. They could still be better, of course. And as it happens, they are getting better with each release of Windows.

Is third party security software needed? Depends on what you mean by needed. If it means it's necessary, then no, it's not needed. If it means it's useful to many people, then yes, it's needed. But I'd rather say useful than needed, when useful is closer to the truth.

But to put it short, my point here is that security in Windows isn't achieved through some undocumented hacks here and there. The OS provides a simple, effective way to limit what software and users can do by providing accounts with different levels of access to the system - just like any reasonably modern OS. Can you then run some third party software on top of it to do even 'better'? Sure, you can. And I doubt MS is planning on breaking all security software in the future. With people making enough noise, it's quite possible they'll even reach a compromise with Tzuk and similar developers.

-{ Quote: "So now they are improving their opinion on this. An improveent is PatchGuard, but even within the UAC policy model objects and processes of the same rights category are allowed to perform dll injections. " }-

PatchGuard really isn't a security barrier, which is exactly what Tzuk said earlier. I see it being more about stability than anything else. Of course, stability also affects security (it can't be secure if it's not available to authorized parties, and it can't always be available if it is unstable).

Sure, you can do dll injections. Sure, Microsoft could do something about that. But if they don't feel like doing that, then I guess they don't, and I can't force them, even if I really wanted to. Maybe they don't want to break all the programs that do dll injection - maybe they've estimated that doing so would cause a bigger noise than breaking a few security software. MS is a business, they have to consider this kind of thing. On the other hand, if you run LUA, and don't happily execute untrusted code, I don't really see that it would be very likely for you to catch some dll-injecting malware. And then of course there's always stuff like SRP for helping prevent the untrusted code from running. Not a perfect solution, no, but life is all about less than perfect situations. In the end, I can safely say that dll injection isn't something that makes me lose my sleep. It doesn't prevent my systems from performing their productive tasks.

-{ Quote: "Now it is to say at the least a bit hypocrite attitude, they could have streamlined other more urgent matters first ('official' openings in the OS security model which effect system reliability more)" }-

Hypocrite? No, I don't think so. It's their OS. Their priorities. If they put discouraging kernel patching before preventing dll injection, that's their right, and I don't see any hypocrisy in it.

-{ Quote: "Consider patchguard the toilet ladies, the security service as being UAC, the ~Snip~ still roaming freely are the allowed side by side intrusions of objects with same rights (the point TZUK is making), the extra cleaning service is the free AV which Microsoft is releasing. " }-

Well, that was a nice example. But where does it leave us? If MS doesn't want to do anything about dll injection in fear of breaking legit software that does it or for other reasons, then they don't, and the problem remains. That in no way prevents them from doing something about kernel patching, or makes PatchGuard hypocritical. And as for the "alcoholists and drug abusers", it's not like you have to let them in, which may be one of Microsoft's reasons for not trying to make dll injection impossible. Your system isn't any public museum, unless you make it so. If untrusted code doesn't execute, then it doesn't inject dlls or fiddle with knobs, either. And there are ways to severely limit the chances of untrusted code executing, especially in a highly privileged context.

-{ Quote: "The point I am trying to make
When you keep stepping back, the discussion changes to a concrete very interesting experts opinion's thread, to a discussion on a philosophical level. When you take to much of a helicopter approach, what you say is true, but is not relevant anymore. For sake of clearity I do not argue your right to post, just trying to get you out of your helicopter, back on the ground. " }-

There isn't any helicopter here. ;D You want concrete? Concrete is that most people don't run obscure security software, and still most people survive. Concrete is that many people will get infected. Concrete is that some people will be very much safe without obscure security software. Concrete is that 64-bit Windows has benefits, like ability to use much more RAM. And finally, it's very much real that there will not be some great security disaster if MS fails to provide the interfaces some developers want in 64-bit Windows. Doesn't get much more concrete than that. Keep things in perspective, is what I like to think. Some people here are acting like the sky is falling if some security software goes down. Guess what. The sky isn't falling. Frankly, I think those people who think security is over without security product X and that it's better to be able to run some security software than to get more RAM are the ones in the helicopter - out of touch with the world and the majority of computer users.

We can argue about random features all day long, and point out how nice it would be to be able to do X and Y. But it never hurts if someone at least takes a look at the actual reality outside security forums most people don't know about. Out there is a reality where almost no-one knows about the programs that are so very loved here. Out there are hundreds of millions of people who will not, in reality, suffer if those programs get weaker or disappear, because they don't even know about those programs. That is very concrete. We can cry all day long about how awful it is that programs we like get weaker or extinct. But while we're doing that, we should remember also that most people just don't know or care. Most users are greatly affected by the default configuration of Windows as it comes out of the box - witness XP SP2 for example. Any improvement to that configuration - like better stability, even just theoretically, or better memory management, or LUA by default - is good. Even improvements to hinder dll-injection attacks you mentioned. This is why PatchGuard serves a useful purpose. There's a lot to be done. I, for example, would like to see admin-by-default finally die, and not by some workaround like UAC, but really just die: LUA by default. That's one step that should be taken. After that, many more.

That is not to say that Microsoft could not or should not give some security software companies ways of doing what they want. But it is to say that instead of that, it would be much more important to improve Windows security out of the box - and sure, of course, you could try to do both. And it is also to say that, ultimately, it is Microsoft's operating system. We can complain about what they do, try to steer them in the direction we want, or we can move to greener pastures if we feel like it. It's not "philosophical." It's very real. And it is real that in this world, me and many other users are not worried about one security software or two going under. Other people may be worried, and that's their right. But surely I am not doing wrong if I state why some people aren't worried, and why no-one actually needs to be (well, except for the guys making the security software)?

-{ Quote: "I agree with you that PatchGuard is a step forward and I basically agree that restricting third party access to the kernel will improve OS stability." }-

So, there we agree.

-{ Quote: "But I also agree with Ilya and TZUK that the roll out scheme could have provided a clearer and more structured API to ensure system security OR have the guts to limit side by side intrusions also within UAC (but this would have a to big an impact on commercial software using formerly undocumented features of previous Windows OS-ses). " }-

Yeah, I also agree with Tzuk that Microsoft could have done a lot of things differently: changed default setting Y, created methods to do X without resorting to complex workarounds, etc. But I also understand that if they don't, then there is not much we can do except to try to make them change their minds. Meanwhile, I find it important for users to keep things in perspective, to stay in concrete reality, to use your choice of word. In reality, whether or not Microsoft provides ways for Tzuk and guys to do their thing like they want to, doesn't break the security of the world, and doesn't make doing the tasks we bought computers for impossible. In forums like this, that seems to be sometimes forgotten. It is literally as if people used computers only so they could run security software and then post about that software in forums. ;D Hey, if someone does that, they can. But they shouldn't think that's how everyone else works as well. And most importantly they shouldn't expect that a huge software company like Microsoft would follow their whims rather than their own plans.

-{ Quote: "Emotions aspect in the discussion
Well considering the measures taken and the actions planned (to be released free AV), I do not believe that MicroSoft is only driven by ethical and more profound reasons to improve the security and quality of the digital world. After an unsuccesfull attack on the security industry some other arguments must play a role also in the release calendar." }-

A business driven by only ethical reasons? Obviously not. Microsoft is in it to make money, just like everyone else. That's why, when they make changes, they make them so that they first consider their own plans, then the majority of their customers, and after that some smaller groups like AV vendors or fans of security software. Only logical.

But I don't see Microsoft making any attacks on the security industry. That's quite ridiculous, really. If anything, the security industry should get gratefully on their knees and thank Microsoft for making it possible for them to earn a living by selling security software. Try doing that in Unixland if you want a challenging environment! ::) Microsoft has constantly recommended people use AVs, for example, and firewalls, and has never told people not to use security software. They even include features in their OS that warn people if they aren't running some AV! If they wanted to attack the security software industry, they could perform really crushing attacks even just by PR. But they don't, because they don't have any desire to attack the security industry. What PatchGuard is isn't an attack on the security industry - it's Microsoft trying to defend their kernel from stability issues caused by third party code, even from security software companies. What the free AV is isn't an attack - if they wanted to attack the industry, why would they jump into it? That's what the AV is - jumping into the AV industry, part of the security industry. Is it competition? Well, sure. But an attack? Nah. Not as I see it. But here I can smell that old paranoid MS is evil attitude coming through again. People can have that attitude if they want, I don't mind. But they should then understand that it would be wiser to not use stuff made by evil people.

And that, I think, is all I needed to say here, complete with my usual repetitive (lack of) style. Sorry to be a bore, but I've spoken my mind. Now, I shall leave you to continue the thread, and shall derail it no further. Sorry for the interruption. :)

[tzuk]

ssj100 I like your summary.

And Windchild, I'm sorry to see that you're blowing me off again, but I'm getting used to it. :) This is a security forum, here of all places I would expect people to take it seriously when an OS deprives security software of the foundation to do its job. When you suggested LUA is the answer to everything security related, I showed you this is naive thinking. But instead of accepting, your response is: so a virus can terminate security software, no big deal.

This "no big deal" school of thought has been running throughout your posts from the very beginning. Security products get bypassed, no big deal. Microsoft takes action that ultimately hinders free competition, no big deal. (Nevermind the reasons; as the saying goes: the road to hell is paved with good intentions; not that I think the intentions here are good, but you seem to). Developers are forced to produce lower-quality products, no big deal. The potential increases in stability are only minor, no big deal.

If it's no big deal, then why are you trying so hard to take the opposing view? That would be the view that -- for whatever irrelevant reasons -- encourages the biggest player in the field to abuse its strength in order to weaken everyone else. Today it's kernel security software, tomorrow it's graphics editing software. And I can understand you not caring until it gets to graphics editing, I really do. But at least have the decency to not JUSTIFY it, until it gets to graphics editing, when you too would be against such tactics.

-{ Quote: "And I doubt MS is planning on breaking all security software in the future. With people making enough noise, it's quite possible they'll even reach a compromise with Tzuk and similar developers." }-

That's what I'm trying to do here, raise awareness to the ills of PatchGuard issue. It is understandable that not all people research the subject and they might not understand what PatchGuard means to developers. But I think I was able to get this message across.

And then you stopped by, to argue that the ends in this case justifies the means -- no matter how small that end is, no matter how cruel those means are. I think this is what ssj100 means when he says that your argument is philosophical.

[ronjor]

-{ Quote: "An Introduction to Kernel Patch Protection

What is Kernel Patching?

"Kernel patching" or "kernel hooking" is the practice of using unsupported mechanisms to modify or replace kernel code. Patching fundamentally violates the integrity of the Windows kernel and is undocumented, unsupported and has always been discouraged by Microsoft. Kernel patching can result in unpredictable behavior, system instability and performance problems—like the Blue Screen of Death–which can lead to lost user productivity and data. More importantly, kernel patching has increasingly become a mechanism used by malware developers to attack Windows systems.

Motivations for patching the kernel vary widely. Anti-malware vendors, for example, may intercept system calls to prevent applications they have deemed malicious from creating processes on the system. The goals of these types of software are obviously laudable but these practices also may cause reliability and performance problems. The greatest risk from kernel patching comes from virus and spyware writers that use this technique with malicious intent and to hide their presence.

Malware authors are motivated to patch the kernel because it is a powerful mechanism for attacking the user's PC and data. Patching can be used to implement rootkits, which also hide the presence of other malware on the system. This form of malware can be extremely potent—for example, allowing the capture of banking passwords and monitoring of all user activities. " }-http://blogs.msdn.com/windowsvistasecurity/archive/2006/08/11/695993.aspx

[Windchild]

All right then, let's go over it once more... :)

-{ Quote: "That's what I'm trying to do here, raise awareness to the ills of PatchGuard issue. It is understandable that not all people research the subject and they might not understand what PatchGuard means to developers. But I think I was able to get this message across.

And then you stopped by, to argue that the ends in this case justifies the means -- no matter how small that end is, no matter how cruel those means are. I think this is what ssj100 means when he says that your argument is philosophical." }-

Yes, and I understand your point there. I think it's within your rights to try and get MS to make your job easier/possible. I think you, and the fans of your software, should try to affect that change. I think the best way to do that is not by calling MS anticompetitive or evil and such things, though. I'm sure your fans don't mind if you call MS anticompetitive. But it might not convince MS to agree with your position. I think a little bit more diplomacy might work better.

My point, on the other hand, was to say that there's no need to panic or fear disaster even if PatchGuard prevents stuff like Sandboxie from being as great as they used to be in 32-bit, and that PatchGuard actually has a justifiable good purpose even if the approach is harsh and ungentle, instead of being M$'s evil tool of destroying good guys. 64-bit with PatchGuard doesn't make you magically insecure, even if you can't run some security software. I tried to make these points, because some people seemed to me to be honestly worried about this, as if fearing for disaster for their security brought on by evil 64-bit Windows! I think these points of mine are much more a realistic argument than a philosophical one that is out of touch with reality, but hey, that's just my opinion.

-{ Quote: "
And Windchild, I'm sorry to see that you're blowing me off again, but I'm getting used to it. :) This is a security forum, here of all places I would expect people to take it seriously when an OS deprives security software of the foundation to do its job. When you suggested LUA is the answer to everything security related, I showed you this is naive thinking. But instead of accepting, your response is: so a virus can terminate security software, no big deal." }-

Actually, I've constantly said that LUA is a good thing, but isn't perfect, and isn't an answer to all issues. And I said there may be other answers to those issues. Such an answer might be third party security software. And MS seems to be allowing third party security software in the future, as well. And nothing is set in stone yet about what that software can do - changes can happen. You yourself have stated that they have happened. So, there is hope.

As for what I said about malware terminating security software, now you're just outright lying there. I never said it's "no big deal" if a virus can terminate security software. I said that it's not a disaster or big deal if a malware can terminate only the control panel part of some AV, for example, as long as malware can't terminate the part that offers the protection. Do you want me to quote myself to prove that, or can we leave it at that? Your choice. Actually, no, I'll quote myself anyway:

-{ Quote: "As long as the important part - the scanner part - works and doesn't get terminated, it isn't a big deal," }-

What I think: Malware can terminate the control panel process of some security software? Not pretty, but no big deal - still, would be better if it couldn't terminate it, and I fully support making termination protection possible. Malware can terminate those processes of some security software that offer the actual protection, like an AV's scanner? Huge deal. But that wasn't the case here. In plain English: if you can terminate the important part of a security software, that is a big deal; if you can only terminate some control panel part but not the actual protection, that is not a big deal.

-{ Quote: "This "no big deal" school of thought has been running throughout your posts from the very beginning. Security products get bypassed, no big deal. Microsoft takes action that ultimately hinders free competition, no big deal. (Nevermind the reasons; as the saying goes: the road to hell is paved with good intentions; not that I think the intentions here are good, but you seem to). Developers are forced to produce lower-quality products, no big deal. The potential increases in stability are only minor, no big deal." }-

Maybe the "no big deal" school of thought is there because it really is no big deal. Security products get bypassed today, in 32-bit. Maybe some Security Software X doesn't, but then, only few people are using it. Microsoft takes action that hinders free competition, I don't see that. They took action that is within their rights to do, and may prevent some types of software being made for their OS, but it prevents it equally for all developers of those types of software. Developers are forced to produce lower quality? Well, many developers have been producing pretty awful quality already, so it's not like the change will be shockingly large for most users.

You may call this cynical, or something like that. I call it realistic. Yes, there are real problems. But no, they aren't so huge that we'll see any great disasters - so, no big deal. The world will roll along pretty much as usual, without any huge changes in security issues. That's what I mean by "no big deal." There's no disaster waiting to happen. Things will not be very different from how they are now. They will be a little different, but not very different. Most people will never notice. Most people will never suffer. Ergo, no big deal.

-{ Quote: "If it's no big deal, then why are you trying so hard to take the opposing view? That would be the view that -- for whatever irrelevant reasons -- encourages the biggest player in the field to abuse its strength in order to weaken everyone else. Today it's kernel security software, tomorrow it's graphics editing software. And I can understand you not caring until it gets to graphics editing, I really do. But at least have the decency to not JUSTIFY it, until it gets to graphics editing, when you too would be against such tactics." }-

The above should already answer the question. I took the "opposing view", because it's realistic. Most people are not affected by the problems PatchGuard causes to some security software. Most people don't use that security software. Therefore, realistically, to those people, it is no big deal, and does not affect productivity. Further, Microsoft has the right to protect their kernel from third party code, even if they don't protect it very well or very nicely. And I stated that obvious thought out because it seemed to be less than obvious to some people. There is no matter of "decency". The justification follows automatically and logically from the fact that the changes from PatchGuard don't cause problems for the vast majority, while PatchGuard provides a (small) benefit that can be logically proved.

But wait, I'll make a promise. Once Microsoft starts trying to break all graphics editing software, I will buy Sandboxie just to support you (assuming of course that you'd even sell it to a doofus like me ;) ). But that might take a while. Because no matter what folks think, MS isn't doing all of this to mess with people.


-{ Quote: "Windchild's points essentially are (and my responses are in italics):
1. Microsoft are a business, and are trying to make money. Life isn't fair, get used to it. No one is denying this mate.
2. Nothing is perfect, and Microsoft is no exception. No one is denying this mate.
3. Windows is getting better with each new release. Perhaps and in many ways
4. Third party software is not a necessity. Who ever said it was anyway? Even water is not a necessity...everything is relative in this world.
5. Computer security is dynamic. Yes it is.
6. Tzuk and Ilya have good points, and perhaps if enough noise is made, there may be a compromise reached. I hope so.
7. PatchGuard is generally a good thing. Good to hear.
8. LUA and SRP are good. What's new?
9. Ultimately, productivity is more important than anything else. Perhaps.
10. Microsoft can do what they like with what they own. Of course, no one is denying this here.
11. The majority is what matters more ultimately. No.
12. Most people don't get infected anyway. I'm not sure about this one; please give me statistical evidence from a reliable research source.
13. Some people are over-reacting to these issues. I don't see anyone over-reacting to these issues in this thread.
14. Microsoft could do things better. Yes.
15. Some people seem to only use security and post about it on forums, and these people shouldn't expect everyone to be the same as them. I don't see anyone having this expectation here.
16. Some people are too paranoid. Guilty.
17. Linux beats all. Of course haha!
18. None of the above points are "philosophical" in nature. Please re-read above points." }-

1. Didn't say anyone was denying it, mate. But some people seem to be forgetting it. How? By a) acting like Microsoft needs to cater to the needs of a minority, instead of doing what Microsoft pleases and thinks is better for the majority of their customers, and by b) implying that Microsoft is "anticompetitive" and "underhanded" and "evil" for doing so. It's not "underhanded" or "evil". It's "business."

2. Didn't say anyone was denying that, either. In a perfect world, we'd have an endless library of perfect security software to choose from, without evil M$ limiting our freedom of choice. Except that we wouldn't. Because in a perfect world there would be no security software at all, because it wouldn't be needed or even useful.

3. I don't think there is any "perhaps" to that. Windows is getting better, at least in my experience, and that's really the only experience I can concentrate on when speaking about my own personal opinion.

4. People may not say third party software is a necessity, but then they act like it is. Well, actually, they do say stuff like "That is why we needed third party security software in the first place", for example, like in Kees' previous post. Sounds pretty much like saying it's a necessity to my ears. And then to even more obvious stuff: In spite of "everything is relative", water is needed for humans to survive. It is a necessity, unless you're not human. It's also quite easy to test what happens if you stop "using" water - any human can test this and always get the same result, death. On the other hand, random third party security software is not necessary for all humans to avoid getting their computer systems infected. That is also easy to test. I do that every day, and survive without getting infected without random security software. Some people may get different results from mine, which then proves that instead of being "necessary" the software is merely "useful for some folks." It may be obvious, but still some people act like it isn't, and that's reason enough to remind them about it.

6. I think what Tzuk and others want to do is an entirely valid thing to want to do. I think a compromise between MS and the desires of small security software companies is possible. And I think that compromise is more likely to happen if people take a more constructive approach, instead of tired old "M$ is evil and anticompetitive." Understanding why MS does something helps there. I know I said that friendly and nice doesn't always cut it in this world, but in some situations it's a good idea to be nice. For example, when you're trying to get something you want from someone who is a lot stronger than you. Like, say, a bunch of guys trying to get what they want from Microsoft. So, I really don't think the small developers are somehow bad guys here, if someone got that idea from my posts. But I don't think MS is either. I think both are just trying to do what they think is best for their own software, and may have different views on it.

8. I am constantly amazed by how many people find LUA and SRP to be, in their opinion, either "new, I didn't know this stuff existed!", "blah, I don't care, I just wanna be admin, yeaaah!" or "they suck because I don't really understand anything about security except running a lot of AVs". If you don't get amazed, count yourself lucky! ;D

9. Perhaps? If productivity isn't more important than anything else, then what is? You might say that one of the most obvious reasons security is important is because insecurity destroys productivity. For example, if malware is killing all your files all the time, you lose valuable work. If a keylogger is stealing your bank account passwords and your money is stolen, you can't use the money any more for productive, useful purposes like buying yourself some food. Most people really do use computers so that they can do things with them, using them as tools for useful, productive purposes. Most people don't use computers to do things to them, like play with security software. But, if someone can tell me what is more important than productivity, I'm all ears! If they can show that this thing is more important than productivity to most people, not just a small minority, I'll be quite impressed. And yes "having fun" is a productive purpose - it's useful for relaxation for example.

11. Well, the majority may not matter the most to you. But it matters the most to a lot of other people. Including me.

12. Never said that. In fact I said that many will get infected. I'll say that many would get infected even if they had all the security software in the world on their systems - some people just don't learn.

13. I do. When someone says stuff like "Down with 64-bit" or "I won't use 64-bit because some security software doesn't work on it" that is an overreaction, in my opinion.

15. I have seen a lot of people who seem to be like that out in the net.

16. But then again, just because I'm paranoid doesn't mean they're not out to get me. ;) But seriously, some people are too paranoid. Paranoid to the extent that I'm worried about their health. I guess we've all seen some of those threads in various forums. Conspiracies everywhere..

17. I don't think it beats all. But if you don't trust Microsoft, and if you think they're evil, then using Linux sure beats using the OS of someone you think is evil. ;) And Linux is good stuff. I, for one, like it. Actually, I have a recommendation. Next time, when the reader has too much time in their hands and thinks about playing with some new security software, why don't they try Linux. Might learn something.

18. Didn't say that. My point about the issue not being philosophical is that there's a real world out there where almost no-one cares about Security Software X (say, a thousand guys care, a million guys don't). A real world where people are mostly "protected" by the default config from Microsoft, and maybe some AV they got with the computer or downloaded because some geeky kid next door recommended it. Because of the way this real world works, it's much more important to concentrate on trying to make the default config better and to educate the users, than it is to concentrate on brilliant but mostly unknown security software. And because of the real world not using Security Software X for protection, the real world will not suffer if Security Software X doesn't work as great as it used to, or disappears.

But really, I think that's enough, before I get the banhammer thrown at me. ;D

[Kees1958]

-{ Quote: "
Thanks for trying to explain it to me. :) However, I don't think I'm missing his point. We just appear to have a completely different point of view on the subject. Which is only normal in any discussion.
" }-
Really you are missing the factual point

-{ Quote: "
Microsoft history on limiting the points of entry for possible malware comes from undocumented 'features' in final OS-releases? Either I don't understand that statement, or I don't agree with it, but I'm not sure which it is. Perhaps a little bit of both.
" }-
It is up to you, there is nothing to explain about it, o see http://en.wikipedia.org/wiki/Windows_API , read it at least until you come accros |"A large emphasis has been put by Microsoft on maintaining software backwards compatibility. To achieve this, Microsoft sometimes even went as far as supporting software that was using the API in an undocumented or even (programmatically) illegal way."

As a rule of thumb, I try to understand before disagreeing, but love and peace man when you are disagreeing without understanding where you are opposed to.

-{ Quote: "
But to put it short, my point here is that security in Windows isn't achieved through some undocumented hacks here and there.
" }-
I only mentioned undocumented use of API's is where MS came from, Now MS is actually working on conversion and structuring in stead of achieveing backward compatibility of wrong code, In this light UAC/Patchguard are improvements. Read Ronjor's quote please

-{ Quote: "
PatchGuard really isn't a security barrier, which is exactly what Tzuk said earlier. I see it being more about stability than anything else. Of course, stability also affects security (it can't be secure if it's not available to authorized parties, and it can't always be available if it is unstable).

Sure, you can do dll injections. Sure, Microsoft could do something about that.
" }-
That was something Tzuk was hinting. From a stability point of view an API is a standard (Application Programming Interface), when they are so rigid on that why not tackle a far more destabilizing technique of injection. or provide a compleet set of API's. But you did not catch what Tzuk said, neither my explanation.

-{ Quote: "
Your system isn't any public museum, unless you make it so.
" }-
You are right about this, example was on half witted priorities though, where MS has to allow bad coding (even in a perfectly configuread LIA/SRP environment) to do side by side injections.

-{ Quote: "
And that, I think, is all I needed to say here, complete with my usual repetitive (lack of) style. Sorry to be a bore, but I've spoken my mind. Now, I shall leave you to continue the thread, and shall derail it no further. Sorry for the interruption. :)" }-
Ahh come on, I said everyone is welcome, what I don't like is that you just managed to change the Thread Topic from x64 to Windchild. Even so, you could not resist posting again :-X see post nr 230

Cheers Kees

[Kees1958]

-{ Quote: "http://blogs.msdn.com/windowsvistasecurity/archive/2006/08/11/695993.aspx" }-

You are great :thumb: , had not though about that, define where we are talking about ;D

[Windchild]

-{ Quote: "Really you are really missing the point

It is up to you, there is nothing to explain about it, o see http://en.wikipedia.org/wiki/Windows_API , read it at least until you come accros |"A large emphasis has been put by Microsoft on maintaining software backwards compatibility. To achieve this, Microsoft sometimes even went as far as supporting software that was using the API in an undocumented or even (programmatically) illegal way."

As a rule of thumb, I try to understand before disagreeing, but love and peace man when you are disagreeing without understanding where you are opposed to." }-

Ah, so you're talking about backwards compatibility and APIs. If you had just said that, instead of saying cryptic stuff like "Microsoft history on streamlining progrom to program communication and limiting the points of entry for possible malware comes from undocumented 'features' in a final OS-releases" I would have understood it. Because really, I still don't understand how Microsoft's "history of limiting the points of entry for possible malware" somehow comes from undocumented 'features'. And I'm sure I'm not the only one who can't make heads or tails of that sentence. Sorry, but English isn't my native language.

Yes, I know Microsoft - understandably, since they're trying to please a lot of people - puts great emphasis on backwards compatibility, even at the cost of accepting stuff they probably shouldn't. Ironically, isn't this thread about exactly that: Microsoft trying to stop people from doing things they shouldn't, using PatchGuard to prevent certain kernel patching? In spite of backwards compatibility, however, NT has a solid security model, and that model is not based on "undocumented features" in any way that I can see. Limiting the points of entry for malware? I don't understand how that is based on some undocumented features. More like undocumented features have caused more points of entry for malware, instead of undocumented features being the tool used to limit entry points.

Yes, backwards compatibility does cause problems. But what can you do? If you remove it, you will face a storm of protest larger than anything that fans of Sandboxie could hope to create because of PatchGuard. Look at how people protest UAC, or PatchGuard! And even after you've removed it, you'll still have problems. Malware works perfectly well without the OS having backwards compatibility with ancient stuff. Backwards compatibility at the cost of security is one problem, but solving that wouldn't lead to people no longer finding third party security software useful. There would still be vulnerabilities elsewhere. But yes, I certainly agree that removing the vulnerability caused by backwards compatibility would be good!

-{ Quote: "Great, I agree, I only mentioned undocumented use of API's is where MS came from, Now MS is actually working on conversion and structuring in stead of achieveing backward compatibility of wrong code, In this light UAC/Patchguard are improvements. I was not clear (because you did not catch it in the right context)." }-

Yeah, sorry for not understanding. I've never claimed to be unusually smart, but have often admitted being somewhat dense. ;D

But yes, I think MS should just wipe off a lot of the backwards compatibility in order to increase security and clean up the OS code. That would be good for security. But a lot of people might be very unhappy, for some time. That then leads to MS taking only small steps, like UAC or PatchGuard. And even those small steps raise storms of protest.

-{ Quote: "That was something Tzuk was hinting. From a stability point of view an API is a standard (Application Programming Interface), when they are so rigid on that why not tackle a far more destabilizing technique of injection. or provide a compleet set of API's. But you did not catch what Tzuk said, neither my explanation. " }-

I think I did catch it. I just have a different point of view. I understand that Tzuk or you might consider it illogical to tackle kernel patching while doing nothing to dll injection. That's because you're looking at the technology, and not what the users will be doing and experiencing, I think. Why not tackle the very real problem of dll injection? Because that could hurt backwards compatibility, and that would raise a storm of protest, like has been demonstrated many times... and since there are some ways to mitigate the injection issue, it isn't as large a problem as it could be. MS is a business, and they will consider something like that when they make decisions. It's a lot easier for them to make a change that breaks some unknown security software than make a change that breaks loads of software used by millions of people everywhere. Developers like Tzuk, I think, should easily understand where MS is coming from in this case. They don't need to agree with MS, of course not. But I would think they could understand how MS makes such decisions, and how someone else, like me, might also understand it. Like I said, realism. Few will notice if PatchGuard breaks some obscure security software, and MS will get few complaints. Millions will notice if DoctorInjector breaks loads of legit software that does ugly dll injection, and MS will drown in complaints. And as to the issue of MS not providing the APIs certain developers want, again, they're a business. They probably don't feel like providing any APIs that they don't think they need to provide. It's all work. Sure, they'll make AVs work. Sure, firewalls. But some much more rare security software that does more unusual things? Well, maybe they won't spend as much effort on providing the kind of API developers of those programs would want. I'm not saying it's the way things should be. I'm saying that it's quite understandable. And that's where folks come in to say to MS that, no, we really do need you to give us more ways to do things so we can make good security software. If the criticism is wide enough and constructive enough, it has a good chance of going through and making MS give you what you want. :)

I understand that from the security perspective MS makes a suboptimal choice. But from a business perspective, it may not be so suboptimal. And they are a business. That's what this is about. That's why I keep saying they're a business. If you understand that, and really understand it, a lot of these questions answer themselves.

-{ Quote: "You are right about this, example was on half witted priorities though, where MS has to allow bad coding doing (even in a perfectly configuread LIA/SRP environment) to do side by side injections." }-

This is another case of the different points of view: I don't think the priorities are half-witted. MS fears users will complain if they kill some backwards compatibility, so they place keeping compatibility as a priority. Is it half-witted? Unlikely, they've probably more than aware of how users would react and have carefully considered their decisions. Do I like it? No, I don't. I wish for security to be given a higher priority than backwards compatibility. But I understand why MS works in that way. They gained large market share by being easy to use.

-{ Quote: "Ahh come on, I explicitely mentioned everyone is welcome.
" }-

Yes, but I'm even making myself tired with my ramblings, and even I can tell when others get tired, as well. ;D

[Kees1958]

OK, let's agree we disagree :)

[Windchild]

-{ Quote: "OK, let's agree we disagree :)" }-

But that's the fun part - I don't think we really profoundly disagree. :) I think we all mostly want better security in Windows. I certainly want it. You seem to want it. The disagreement only happens when we discuss how to get there. Really, just because I understand something about why a big business like Microsoft does something doesn't mean I have to like it, or do. I just understand it, and accept it as their right - businesses try to make money, and that isn't wrong. In the real world, we just have to live with that.

I think I shall end my ramblings by saying the following:

Tzuk, Ilya, other developers - I hope the best for you. Really, I do. I hope that you can convince MS to give you the interfaces you want - but I also hope PatchGuard isn't killed. I certainly think it's better if developers like you have access to well documented APIs instead of having to use complicated, unstable and unsupported hacks to do something useful that they want to do, like some sandboxing function. I think there are many "diplomatic tricks" that you might try, if you feel like it. Why not even have your users help you? You could start a petition and have all your users sign it, and give that to MS, asking them to give you better, wider APIs to do what you want to do so you can protect people running 64-bit Windows. I'd sign it. Maybe you've even done something like that. But I think that almost always more could be done - if one has time.

And to other users, like me, I would like to say that you don't really need to worry about 64-bit. You can still be safe in that environment, and if you're lucky, MS will make your fave security software possible in that environment, too. So, no disaster looming. And it will take a long while before you "have to" move to 64-bit, so there's lots and lots of time for things to happen. Enjoy computing. :)

[JRViejo]

-{ Quote: "http://blogs.msdn.com/windowsvistasecurity/archive/2006/08/11/695993.aspx" }-
Ron, thank you for that link and I have to say that this thread has been an amazing read.

I do have one question for the developers, based on this Kernel Patch Protection: Frequently Asked Questions (http://www.microsoft.com/whdc/driver/kernel/64bitpatch_FAQ.mspx) statement found there (I apologize if it has been covered already):
-{ Quote: "If your application or driver must perform a task that you believe cannot be accomplished without patching the kernel, then contact KPPinput@Microsoft.com for help in finding a documented and supported alternative. The white paper that explains the criteria we are using to help evaluate and prioritize the types of APIs that will be developed and when they will be delivered can be found here (Kernel Patch Protection Criteria Evaluation Document (http://www.microsoft.com/downloads/details.aspx?FamilyId=4C7561E6-6F9D-4125-8A8C-AEAF8E3342B9&displaylang=en))." }-
Question: Did you originally contact MS, using their criteria, and was what their reply?

Follow-up: If you read the criteria and decided not to contact MS, what prevented you from doing so?

[Ilya Rabinovich]

One developer from the kernel team told me the time to add interfaces is about 3-5 years if chief manager will make a decision to implement it. And it's very hard if you are not Adobe, Symantec,...

[firzen771]

-{ Quote: "One developer from the kernel team told me the time to add interfaces is about 3-5 years if chief manager will make a decision to implement it. And it's very hard if you are not Adobe, Symantec,..." }-

maybe it wuld be easier to get in contact with Adobe/Symantec etc. to do it then ;D :P

[JRViejo]

-{ Quote: "One developer from the kernel team told me the time to add interfaces is about 3-5 years if chief manager will make a decision to implement it. And it's very hard if you are not Adobe, Symantec,..." }-
Ilya, thank you for being the first to respond. So in your case, I assume that it was more of a time frame issue than anything else?

After reading the Kernel Security Criteria document, I can see how a developer would have a hard time getting MS to approve their API, especially when I read these statements:
-{ Quote: "A significant consideration for Microsoft involves the technical efficacy and viability of providing the requested APIs. This means helping ensure that any areas that are assessed can be implemented correctly from security, reliability and performance perspectives. In addition, any new API should not impede the ability to implement future planned enhancements to the operating system, such as virtualization and hardware-assisted security." }-
-{ Quote: "Any new API will be considered based on a complete understanding of the end-to-end issue that ISVs are attempting to address. A partial understanding is insufficient because this may lead to an incomplete design that could be flawed from a security, reliability or performance perspective. This is not to say that future requirements may not be introduced but rather that at a given point, the most complete possible understanding of the requirements must be communicated to Microsoft. In this context, the necessary requirements include a description of the problem being solved and the desired API behavior rather than intimate implementation details." }-
One stops a developer from creating something that MS is already working on and the other asks a developer to divulge intellectual information they might not be willing to share.

[Ilya Rabinovich]

-{ Quote: "maybe it wuld be easier to get in contact with Adobe/Symantec etc. to do it then" }-
Big corporation- big ~Snip~. Always.

[Ilya Rabinovich]

-{ Quote: "So in your case, I assume that it was more of a time frame issue than anything else?" }-
I have no idea. I even have no idea if MS guys will apply anything. I'm not a Symantec, remember? ;D

[JRViejo]

-{ Quote: "I have no idea. I even have no idea if MS guys will apply anything. I'm not a Symantec, remember? ;D" }-
Ilya, yes, I know you are not Symantec, but it sounds like you did submit your proposal and now must wait? Am I understanding you correctly?

[tzuk]

-{ Quote: "One developer from the kernel team told me the time to add interfaces is about 3-5 years if chief manager will make a decision to implement it. And it's very hard if you are not Adobe, Symantec,..." }-

Yeah, same here, more or less. I was asked to bring my issue up again for consideration in a few years.

-{ Quote: "As for what I said about malware terminating security software, now you're just outright lying there. I never said it's "no big deal" if a virus can terminate security software. I said that it's not a disaster or big deal if a malware can terminate only the control panel part of some AV, for example, as long as malware can't terminate the part that offers the protection" }-

Lying? I'm not lying. You said it's "no big deal" if a virus can terminate components of your anti-virus. You didn't care to consider that many people might actually find this very alarming behavior, and I didn't care to quote all your many qualifications about whether just control panel or the core component is stopped.

-{ Quote: "I took the "opposing view", because it's realistic. ... Further, Microsoft has the right to protect their kernel from third party code, even if they don't protect it very well or very nicely. And I stated that obvious thought out because it seemed to be less than obvious to some people. There is no matter of "decency". The justification follows automatically and logically from the fact that the changes from PatchGuard don't cause problems for the vast majority, while PatchGuard provides a (small) benefit that can be logically proved." }-

You can't logically prove a speculation, and it also won't cause problems for the vast majority if Microsoft blocked any non-Microsoft graphics editing software.

To put things in context, your response here is to my question, why do you feel so strongly about taking Microsoft's side if it's all "no big deal" to you. Feeling a need to protect justice? More like feeling a need to protect injustice, it seems to me, and that is why I said it is not decent.

You said earlier many of the BSODs you experienced were related to security software. Did you bother to research the cause of the conflict, before subscribing to the position that PatchGuard will cure this? Have you considered the possibility these security software might conflict in ways that do not involve undocumented interfaces at all? What if only half of those crashes were related to undocumented interfaces, does that still justify PatchGuard?

Bottom line: A powerful company with a history of strongarming its competition, and your whole reasoning to support their approach hinges on speculation that PatchGuard will make things better.

-{ Quote: "Malware authors are motivated to patch the kernel because it is a powerful mechanism for attacking the user's PC and data. Patching can be used to implement rootkits, which also hide the presence of other malware on the system. This form of malware can be extremely potent—for example, allowing the capture of banking passwords and monitoring of all user activities." }-

Read about DKOM rootkits to see that rootkits do not need to patch the kernel to hide their processes. PatchGuard does not protect system data areas and a rootkit can simply "delete" the information associated with its processes. It will still execute, just won't show up in Task Manager.

Read about file system filer drivers to see what rootkits do not need to patch the kernel to hide their files. They can ask to install a "fake" filesystem on top of an existing one, and return "not found" error codes for any attempts to access their files.

Besides, rootkits can afford to disable PatchGuard. It's naive to think they won't. Only good guys have to play by the rules, and that makes the part about "greatest risk" in the "Introduction to Kernel Patch Protection" fairly nonsensical.

[Wildest]

I have been trying to keep up with the flurry of responses in this thread, but I failed; information overload!

Pls forgive if the following question was answered:

1. Security software developers dislike PatchGuard because it doesn't allow them to jump into bed with the kernel.
2. By not being able to become intimate with the kernel, they cannot give you the "best of the best" protection to protect you from malware authors.
3. Here is where become confused: Malware authors are software developers!!

If the good guys can't in, how can the bad guys get in? :wacko:

[Peter2150]

-{ Quote: "

If the good guys can't in, how can the bad guys get in? :wacko:" }-

That should be obvious. They are willing to do things that reputable software authors won't do.

[Wildest]

-{ Quote: "That should be obvious. They are willing to do things that reputable software authors won't do." }-
Malware authors have the same access to MSDN that "good" software developers do.
Ironically, this the same rationale used to explain the reason why Wilders restricts discussions about how to create malware; the reasoning?
It will make it more difficult for the script kiddies.

I am still missing the point of why Microsoft should not have as much exclusivity as possible regarding the kernel.

[Kees1958]

What it all concludes to IMO:

1. PatchGuard is intended to increase stability, which is a good switch since MicroSoft used to provide backward compatibility of undocumented/illegal API usage in the past.

2. PatchGuard in itself is not a bad thing, WHEN microsoft would have given a 'complete' featured interface set, so security programs could do their work. Currently both Ilya and Tzuk have asked for additions, which are scheduled for Win9 problably (5 years from now).

3. The release calendar / priorities taken by Microsoft is questioned by Tzuk/Ilya since it focusses on API hooks, while it still leaves wide open the much more destabilizing technique of injecting code, which is under LUA allowed by objects of the same rights level (so called side by side intrusion), also issue mentioned at 2 adds up to to questionable release calendar of kernel protection improvements.

4. Multi security angle applications like PrevX (heuristics/behavior analysis, in the cloud blacklist and community warning/protection) have currently enough means to implement strong protection which would not harm thebrand value of their x32 peer.

5. One man band developers with a product focussing on implementing one HIPS approach in an excellent way (have a so called champion in its class ambition) refuse to release x64 products not having the same protection strength as their x32 peers.

6. Some of the complaints of larger security developers is that a third party is needed to rescue teh OS when it fails, I think it is a clear strategy of Microsoft to limit Kernel patching for any third party

7. Signed drivers are no real solution, because every software has exploits which could be used by malware writers, or even worse two companies could work together, one acquiring a signed driver and leaving an undicumented hole in it, the other exploiting it.

8. This was a great thread to read, thx PrevHelp, Tzuk and Ilya and SSJ for starting it.

[Windchild]

Now, about the issue of adding interfaces taking 3 to 5 years of time... Sounds like a long time - but, it will take a long time, I think, before 64-bit systems are more common than 32-bit systems. So, it's entirely possible for MS to make such changes before 64-bit takes over completely and most people practically stop running 32-bit. Getting such changes made is obviously hard for smaller developers who aren't some bigname, bigshot company like Adobe. Perhaps joining forces would somewhat help. Meaning, the smaller companies could work together on this, and also try to get their users to help convince MS about this. I'm certainly not saying it's guaranteed to work, but I would think the chances are much better than zero. I can understand that you guys are upset. If I was you, I would probably also be upset. But I'm not sure that starting the anticompetitive, evil and so on chants will help in this case. MS has heard that so many times before, I don't think they care anymore unless they get slapped with a really horrifyingly enormous legal sanction that will cost them so much money even they start caring. So, more diplomacy might help better. :)

-{ Quote: "Lying? I'm not lying. You said it's "no big deal" if a virus can terminate components of your anti-virus. You didn't care to consider that many people might actually find this very alarming behavior, and I didn't care to quote all your many qualifications about whether just control panel or the core component is stopped." }-

Well, I'll not argue that line further. But let me say this. I think those "many qualifications" you didn't care to quote are pretty important in such a discussion. I think there is a very real difference of meaning between "terminating security software", "terminating the core part of a security software that provides the protection, like an AV's scanner" and "terminating only a control panel part of a security software, while being unable to terminate the parts that offer the actual protection." If other people don't see a difference, then I guess I can't help it. But in many previous discussions, it has often been stated by various people, that just because a malware can terminate, say, a firewall's GUI, isn't that big a deal as long as the actual firewall service stays up and running and blocks the malware from connecting out. In this way, there is a real difference between these situations to real people. Other than just me, of course.

And naturally I did consider that many people would find their AV control panel dying alarming. I have seen people get all "alarmed" about such things. But just because I consider that doesn't mean I have to think it's a big deal. Yes, it's a problem. But not the kind I would call a big deal. A big deal would be the whole software going down, including the main scanner part, which would mean the entire AV dies and no longer does anything to protect the system. But then, as far as I know, MS has provided ways for security software devs to protect their products from termination. Sounds good to me!

-{ Quote: "You can't logically prove a speculation, and it also won't cause problems for the vast majority if Microsoft blocked any non-Microsoft graphics editing software." }-

But it will most certainly cause problems for an enormous number of users - and just a tiny little bit more enormous than just blocking a few very special security software products. Therefore, MS is pretty unlikely to do something like that.

-{ Quote: "To put things in context, your response here is to my question, why do you feel so strongly about taking Microsoft's side if it's all "no big deal" to you. Feeling a need to protect justice? More like feeling a need to protect injustice, it seems to me, and that is why I said it is not decent." }-

I feel the need to protect a realistic view of things. While "Security Software X not working" may be a "no big deal" to me, "realism" on the other hand is a very big deal to me. Some people are honestly concerned whether they can be secure in 64-bit, and whether they can even move to 64-bit because of some security software not working or not being as great as before - and they think like this in spite of the productivity advantages of 64-bit such as taking advantage of more RAM. In my opinion, it is realistic to say that there's no reason to get all worried about stuff like that. In my first post in this thread I said I, for one, have no reason to care or worry about that. Because, I know for a fact that in 64-bit Windows in the real world, you can still run a secure system, and you don't have to be afraid that you will get inevitably owned without some Security Software X that you had in 32-bit. In the real world, you can happily move to 64-bit, stay safe, and take advantage of new benefits like having a boatload more RAM. Further, I think it's realistic that Microsoft has a right to decide what they do with their own software, and I think it's realistic that they might want to take steps to discourage kernel patching. You don't have to agree. You can even say that thinking like I do is indecent. I can take that. :) But it's not going to change my mind.

-{ Quote: "You said earlier many of the BSODs you experienced were related to security software. Did you bother to research the cause of the conflict, before subscribing to the position that PatchGuard will cure this? Have you considered the possibility these security software might conflict in ways that do not involve undocumented interfaces at all? What if only half of those crashes were related to undocumented interfaces, does that still justify PatchGuard?" }-

Naturally I have not researched each and every BSOD, especially on systems that weren't in my control. But in almost all of those cases there was only one security software - the AV - installed on the system, and the reasons for the crashes were rather likely to be either bugs in the AV drivers or those issues related to using undocumented and unsupported hacks to patch the kernel. Even if only 0.1 % of all those hundreds of crashes were because of kernel patching hacks that PatchGuard now discourages, I feel that PatchGuard is very much justified. Even as merely an idea, PatchGuard is already justified: it has a reasonable, good goal, and causes no real harm to about 99,9 % of all computer users. In my opinion, of course. The reason why I mentioned the crashes caused by security software wasn't that I believe such crashes will all go away with PatchGuard. The reason was to show that in my experience, security software does have a lot of issues and does cause a lot of system stability issues in the real world. So, with PatchGuard, Microsoft isn't trying to solve imaginary issues or chasing wild geese. When Microsoft says "kernel patching causes stability issues", that's not a lie or an excuse so that they can justify PatchGuard which really has no intention beyond just being evil to small security software companies.

-{ Quote: "Bottom line: A powerful company with a history of strongarming its competition, and your whole reasoning to support their approach hinges on speculation that PatchGuard will make things better." }-

My reasoning to support them hinges on realism. PatchGuard has a decent goal, and harms few people. It's Microsoft's OS, and their design choice. I find it realistic to support that. Some might disagree. Life is like that. I don't think we've ever agree about this, so I figure it's agree to disagree on my part.

[Windchild]

-{ Quote: "Anyway, the main point of creating this thread (personally) was actually to find out if Windows 64-bit systems would be less secure than 32-bit systems, and not so much about discussing how Microsoft can do what they like with what they own.
" }-

Well, if that's the only question, the answer is very obvious:

- Windows 7 in 64-bit is more secure than Windows 7 in 32-bit. 64-bit has security enhancements, such as driver signing, that really do help. So, the OS is more secure in 64-bit. Assuming, of course, that MS didn't fantastically mess something up with the 64-bit that they didn't mess up in 32-bit, leading to a boatload of 64-bit only vulnerabilities. Unlikely.

- On the other hand: If you rely absolutely and only on the products that may get weakened or made impossible by PatchGuard for your security, then yes, you will be less secure in 64-bit Windows, if you stubbornly refuse to update your security policy. Note that the operating system itself is not any less secure than before - it's actually more secure than before. It's just that you no longer can run some third party security software on it, and if you rely on that, then obviously there's a security impact.

- If you don't rely on the products that may get weakened or made impossible by PatchGuard for your security, then no, you won't be any less secure in 64-bit than you were in 32-bit Windows. Actually, you'll be more secure, since the OS is safer (driver signing, and all, do help).

But really, this is only common sense and logic. :)

[Ilya Rabinovich]

-{ Quote: "Am I understanding you correctly?" }-
Yes, correctly.

[Kees1958]

-{ Quote: "

But really, this is only common sense and logic. :)" }-

To an enlightened Windchild it might be common, but for the majority of us mortals it is a great mystery.

[Windchild]

-{ Quote: "I see, so what you're saying is that by default, Windows 64-bit systems should be more secure than 32-bit in theory (as long as Microsoft don't mess something up).
" }-

Well, no. I'm saying quite plainly that they are more secure, in real life, in practice. In 64-bit Windows systems where driver signing and such work, this can be quite clearly experienced, as well.

But of course, there can be vulnerabilities we don't know about. Of course, there are bound to be some. But there can be even unusually serious vulnerabilities, too, in the very unlikely case that MS somehow royally messed up their 64-bit Windows 7. Most likely they didn't, but it's a world of uncertainty out there. ;D But then, there are unknown vulnerabilities in practically all software (except perhaps the Hello World! kind) and how bad they are we will not know before they get discovered. This goes not only for Microsoft's operating systems, but also for all other software. Like, say, security software from Symantec or some other company. This is one of those philosophical style arguments, I might say. ;)

In real life, 64-bit Windows is more secure than 32-bit Windows. It's only that some users of 64-bit might end up being less secure, if they fail to replace any security software of theirs that no longer works with some solution that does, or fail to find such a solution. But for the vast majority of users, 64-bit Windows will increase their security. The increase won't be gigantic, but it's there.


-{ Quote: "To an enlightened Windchild it might be common, but for the majority of us mortals it is a great mystery." }-

Oh come on. ;D I'm probably one of the least enlightened people on earth! ;D

But where's the mystery? If we're talking about the OS - and that means only the OS, not some security software that is not part of the OS - then it's obvious that 64-bit Windows has improved security over 32-bit Windows. This isn't that complicated. As long as we can understand that the security of an OS does not depend on third party products. That's how this whole argument started on my part. The police - Windows - is better in 64-bit than before. The security guards might get a little worse. The OS is more secure, some other stuff might not be.

[Windchild]

-{ Quote: "Cool, so Windows 64-bit systems are definitely more secure than 32-bit systems by default. It would only be less secure (in relative terms) if the user doesn't know what they are doing." }-

Yeah. Or to put it less harshly: if the user just really likes some security software that doesn't work as well in 64-bit, and can't find replacements for them, then their security may end up being lower than it was in 32-bit. But the operating system itself is definitely more secure than in 32-bit. I think that's a pretty good thing, since most users do not have sophisticated third party security software. :)

[tzuk]

Why do you argue in circles, Windchild? To me it looks like all your arguments in favor of PatchGuard fell apart (if perhaps only partially in your mind) so you revert back to talking generally about greater security of 64-bit Windows and the benefits of more RAM. That was square one and I thought we moved on from that.

* * *

To reiterate points that seem to get lost again and again:

64-bit Windows is more secure only thanks to mandatory driver signing, and I don't think anyone is contending this fact. Not me, at least. Mandatory driver signing does raise a barrier to rootkit malware, they now have to be stamped by an unbiased certificate authority (like VeriSign) as having come from a trusted source.

But rootkit malware might get to kernel mode somehow, perhaps by fooling the certificate authority, or by exploiting some vulnerability in other kernel mode software. Then PatchGuard is not an issue at all for the, as both rootkit and PatchGuard operate on the same level, which is kernel-level. PatchGuard is not magic, it's just a piece of kernel mode code that runs every 10 minutes or so and checks the rest of the kernel. It can be disabled and there are ready-made hooking toolkits that already do this.

However, good guys cannot afford disable PatchGuard in order to do the things we were used to do on 32-bit Windows. Because such an action risks the validity of the driver certificate, and might have other legal ramifications.

[Windchild]

Oh boy. I guess we're not finished yet.

-{ Quote: "Why do you argue in circles, Windchild? To me it looks like all your arguments in favor of PatchGuard fell apart (if perhaps only partially in your mind) so you revert back to talking generally about greater security of 64-bit Windows and the benefits of more RAM. That was square one and I thought we moved on from that." }-

I do not think I argue in circles or that my arguments fell in any way apart. I don't think that has been shown in any way, and we could sit here and argue about it all year. I "reverted" to talking about greater security and more RAM because You asked me:

-{ Quote: "why do you feel so strongly about taking Microsoft's side if it's all "no big deal" to you" }-

And here I thought it would be polite to answer why I feel so "strongly" about it, since a respectable man asked me politely. Perhaps I was wrong! I feel so strongly because it's not "all" a "no big deal" to me: the problems PatchGuard causes to a small number of people are a "no big deal" to me, but having a lot of more RAM is a "very big deal" to a large group of people including me and MS finally trying to do something about kernel hacks is a big deal to me. I feel so strongly because I think it's realistic that Joe User doesn't need to worry about migrating to 64-bit and fear that 64-bit will be destroying his security and getting him magically owned, and because I think 64-bit Windows is an improvement and to top all that off because I think PatchGuard has a good purpose that I support. That's why I feel strongly about it. And if you ask me to explain why I feel strongly, surprisingly enough, I will then explain why and describe the general benefits of 64-bit Windows and that PatchGuard doesn't hurt most users in any real way that they will ever notice but instead has a good purpose that I support. So then, why should I not support PatchGuard, even if a very small minority hate it? I think that is realistic, practical thinking - sure, selfish, but then what isn't. It's not like you, Tzuk, are thinking about what's best for Microsoft or Windchild when you tell us what MS should do to make your job easier and possible - you're thinking about yourself and your customers, as you should. If all this isn't alright with you, then I guess I'm just sorry my thinking doesn't please you.

This is how it's gone so far. I say that generally folks don't need to worry about 64-bit, you can still be secure on it, so enjoy computers. I say that PatchGuard has a good goal, and will really improve stability, even if you don't notice that on your systems and even if it is nowhere near perfect - it will really prevent legit devs from doing certain kernel patching hacks that they regularly messed up with and crashed systems before. I say that, and then you point out PatchGuard doesn't solve all issues and what about dll injection for example and what about the fact that devs will just use different ways to mess things up and cause crashes by accident and most evilly of all PatchGuard prevents obscure security software from working as well as they did before. I say that PatchGuard ain't perfect just as I said before, but I support its purpose. You ask me why I feel so strongly about this issue if some AV control panel dying or some Security Software X not working in 64-bit are all a no big deal to me. I explain why - because of the reasons I stated in my very first post: users don't have to worry about PatchGuard making their security on 64-bit a disaster, but still some users seem to be worrying, and I would like to bring some peace of mind to them and have them more worried about productivity than some obscure security software - have them take a realistic point of view on computing instead of getting trapped in the world where Security Software X is the most important thing in computing and things like having more RAM to do useful things with the system are not as important. And after that, you tell me I'm arguing in circles. Oh dear, oh dear.

I knew I shouldn't have said anything at all in this thread, having seen what discussions like this have previously caused. One dev insulting another, almost everyone ignoring the big picture and the only some hundreds of millions of users who won't care about losing some program they never heard of, people calling my arguments philosophical and then talking about "hindering innovation in kernel space", getting called a blind follower of Microsoft after I have flamed Microsoft for years for not making LUA the default and messing up ActiveX, and so on. This would be funny, if it wasn't so bloody sad. ;D Listen, I'm not a software developer. But you are. Maybe, instead of arguing with me, your time would be better spent trying to convince Microsoft to let you do what you want. Because, even if you pull some magic trick and make me completely agree with you about PatchGuard and religion and war and peace, it still won't make your problems with PatchGuard disappear, or convince the rest of the world they need to care about it. ;)

To summarize my argument about PatchGuard:
1. MS has the right to implement it. It's their OS. I accept this. I support that right.
2. PatchGuard has a good purpose. Its idea is to increase stability and security by preventing and discouraging kernel patching, which has caused problems in the past. It's not a complete panacea type solution, and not even MS has claimed that. It does have real effect, however: when it makes some type of patching impossible for legit developers, the software of those legit developers won't ever again cause stability issues by patching something PatchGuard prevents them from patching. There may be other stability issues, yes. Who knows, maybe developers will be angry and will start intentionally coding serious bugs in their software just to show that PatchGuard didn't make crash issues rarer but in fact more common! ;D But still giving developers less methods to mess the kernel up is an improvement. To me, at least. To you, it can be the worst thing in human history for all I care - it's not in my power. But since the purpose is good, I support it.
3. Most users - a vast number of people - will never suffer from not being able to run some security software because of PatchGuard, because they don't even know the security software exists, and if they did, wouldn't want to use it anyway, being too busy in Facebook. This means the real world impact of PatchGuard is not negative to a vast majority of users. Like me, and everyone I personally know face-to-face and almost the entire population of the continent I live on. Therefore, I have no problem with it.
4. The intended good effects of PatchGuard, no matter how small, affect everyone, and the effect is not negative. Even the very existence of PatchGuard discourages kernel patching by legit software, and that already reduces the use of certain hacks that can cause stability issues. It isn't bad, ergo I do not oppose it.
5. The security of the OS depends on the OS, not on other software. Where other software comes in is the security of a computer system, running some OS and some software on the OS, operated by some human. Most humans rely on the default configuration of the OS and maybe some AV for their security. So, an increase in the security and stability of the default config is a good thing to most users - you know, making the police everyone has around better, instead of making the third party security guards many people don't have better. I support that.
6. If devs want more documented interfaces from MS to do their thing, I'm fine with that, and support that. Why not? Using documented interfaces is surely better than having to resort to hacks.
7. Considering all this, I know that users of 32-bit can happily migrate to 64-bit and enjoy more RAM, without having to worry about "oh no, I can't secure my system without Security Software X and will surely get owned now!" Some users may indeed worry, and can. But I'm saying they don't need to. Calm down, enjoy computing, the sky isn't falling, and PatchGuard doesn't make us all insecure all of a sudden, even if some people would like to think so. I feel strongly about being a realist!

I don't really see that many circles, or fallings-apart. But others are free to see things differently. The great thing about life: diversity of opinions and points of view.

-{ Quote: "64-bit Windows is more secure only thanks to mandatory driver signing, and I don't think anyone is contending this fact. Not me, at least. " }-

Yes, I think driver signing is a good thing and does improve security. Sounds good to me. :)

-{ Quote: "But rootkit malware might get to kernel mode somehow, perhaps by fooling the certificate authority, or by exploiting some vulnerability in other kernel mode software. Then PatchGuard is not an issue at all for the, as both rootkit and PatchGuard operate on the same level, which is kernel-level. PatchGuard is not magic, it's just a piece of kernel mode code that runs every 10 minutes or so and checks the rest of the kernel. It can be disabled and there are ready-made hooking toolkits that already do this." }-

I'm sure no-one here thinks PatchGuard is magic. Even if rootkit malware "might" get to kernel mode "somehow", which I'm sure is somehow possible since nothing is perfect, that is still a real improvement over the current 32-bit situation where the malware can just freely walk right in there completely unchecked easy as pie, instead of having to "might" and "somehow" get to kernel mode. ;) As for PatchGuard? It's not a security barrier, like you said. It just discourages kernel patching hacks that have caused stability issues and security issues in the past. It doesn't make rootkits impossible or anything like that, and I for one never claimed it does. Even if malware gets to kernel mode, and then blows up PatchGuard or changes its name to PantsGuard for all I care, the existence of PatchGuard in Windows makes legit developers avoid the types of kernel patching that PatchGuard prevents, and at least devs won't make mistakes in how they implement that kernel patching, since they won't be implementing that kind of kernel patching at all. Hence, improvements in one place. In some other place, yes, devs can make more mistakes than before if they feel like it. But then, they could do that already right now. PatchGuard is not needed for them to be able to mess up things in other ways.

-{ Quote: "However, good guys cannot afford disable PatchGuard in order to do the things we were used to do on 32-bit Windows. Because such an action risks the validity of the driver certificate, and might have other legal ramifications." }-

Yes, I know, and understand. But I don't really think that means anything at all to my arguments about PatchGuard.

-{ Quote: "But surely there are replacements to give the same level of security right? Because if there isn't, then 64-bit is in theory less secure than 32-bit (at the "higher end" of securty). And if there are replacements that give the same level of security, then the only way it can end up being less secure is if the user doesn't know what they're doing." }-

Of the replacements, I wouldn't know - it doesn't really concern me, as I don't use that kind of software these days. But unfortunately, now we are inevitably getting in the philosophical argument that you folks implied you wanted to avoid. ;)

In theory and in practice, 64-bit Windows is more secure than 32-bit Windows. That is clear. To come true, the "less secure in 64-bit" scenario requires a case where a user has been running some rather special security software in 32-bit Windows, then migrates to 64-bit Windows, and can't find any ways to achieve similarly effective protection in 64-bit Windows. In such a case, the security of the systems admin'd by that user, may really be lower than it was in 32-bit Windows. But even that does not mean that the 64-bit OS itself is less secure than a 32-bit OS - it's important to understand that. We must understand the operating system and the actions of some user are different things. This simply means that with 32-bit Windows the user was able to use some security software for their security that they no longer can in 64-bit, and if they can't find any replacements to achieve same level of security, then their security may indeed suffer. It's clearly not a problem in the security level of the OS - that is higher than before. The problem exists in the user's security policy and what software they use to enforce it. For example, if one really wants to run the a browser in a limited environment where it can't do anything much to the real system, there is always VMware for example. Not what I would do, though.

[Windchild]

-{ Quote: "So are you implying that the security that can be achieved on 32-bit is stronger than what can be achieved on 64-bit?

If not, then why say this: "and if they can't find replacements to achieve same level of securty, then their security may indeed suffer."

Because if there are no replacements to achieve this "same level of security (or better)" on 64-bit, then 64-bit must be less secure than 32-bit at that level. Right?" }-

No and no. I'm saying that in 32-bit, there may be some software that does things in a way that you really like, but that software may not work in 64-bit, and if you can't accept other options that may be different or more expensive or more resource-hungry, then there may be trouble for your security setup. And, I'm saying that it's possible and even easy to stay clean in 64-bit Windows. :) Let's take a user who bases his security on Sandboxie alone. There is no 64-bit Sandboxie, so the user can't use it in 64-bit Windows. Now there's a problem. If the user will not accept any other option, varying from going just cheap LUA+SRP to prevent most malware attacks from being successful to going expensive and running VMware or some other virtual machine to do untrusted browsing "outside" the real system, then their security does suffer. But that's not a problem in the operating system, it's a problem with the user's security policy. That's how it is.

As for the last question, lack of some security software does not mean the 64-bit OS is less secure. The OS itself is not. The OS does not include third party security software, and lack of third party software for an OS does not affect the security of the OS. This is, as said, a question of "semantics" or philosophy - or if you prefer, just understanding the terminology. The security of the OS is determined by the code of the OS. Features and mistakes in the OS code determine how good the security is: driver signing is good and an advantage, some accidental remote code execution vulnerability is bad and a disadvantage, and the sum of all this stuff is how secure the OS is compared to earlier versions. The security of some systems - complete with hardware, OS, third party software and users - may be lower in 64-bit than in 32-bit if the admin doesn't find any acceptable replacement for their security software. That's a downside, surely, but still the OS itself remains more secure. Or to quote Tzuk, 64-bit is more secure (than 32-bit) due to driver signing, for example.

[Windchild]

-{ Quote: "This all makes 64-bit sound rather negative. Again, I am not talking about the default level of protection the OS gives. I am talking about higher levels of security, like LUA/SRP (which might not work well for some people who want more freedom/convenience/usability?)

So you do admit that the Windows 64-bit platform is limiting security options, and that other options may be more expensive or more resource-hungry? Doesn't sound too good to me from that aspect.

Also just to clarify, so you do think there is a "replacement" for Sandboxie that provides the "equivalent" level of protection (or greater) for 64-bit?" }-

Instead of "higher levels of security", I think "compatibility with third party security software" would be the better term in this case. LUA/SRP don't count there, but then, LUA and SRP do work in 64-bit like in 32-bit. Of course, they aren't enough for everyone. And that is where the third party stuff come in, and the very real problems start, as others have said.

With 64-bit Windows, yes, I certainly admit that some security software just doesn't work as before - like Sandboxie - and may not have similar alternatives. So, yes, surely, 64-bit Windows puts some new limits to what security software can do and how and those make some security software less powerful than before. That is the way it is, unless MS makes changes in the future. This is of course what Tzuk and others have been saying, and I haven't missed that. Even I am not that dense yet. ;D Yes, this is a downside. My point from the start was that for most people this is a non-issue, since they don't use such software anyway, and for those who use such software, they typically have more than enough knowledge to find alternative solutions that still offer a very high level of security. So that point was in essence "some large benefits to all, some disadvantages to very few, so it sounds good to me."

And yes, I also think that this would logically make 64-bit sound negative to someone who puts a great value on certain security software that no longer work in 64-bit. That's why I recommended finding those alternative solutions, or just sticking with 32-bit as long as practical. Or if you're like me or most users, just jumping to 64-bit and not worrying very much. One can be insecure or secure in 64-bit, and that really depends mostly on the users themselves. :) The OS itself is more secure than 32-bit versions, but some security software doesn't work. We just have to deal with that, or try to coerce MS to making the security software work again.

But really, if we want to show what 64-bit could do in terms of security and want something as powerful as the Sandboxie we've been using so far, how about the following:
- run 64-bit Windows
- run VMware on top of it
- run a 32-bit Win 7 in VMware, and run Sandboxie inside the Win 7 32-bit to do your browsing.
- profit... I mean, security, that is pretty likely to be actually higher even than in just running a real Windows 7 system 32-bit with Sandboxie. :) With much higher cost and resource impact, though, so it's not all bunnies and roses...

[tzuk]

Once again, a long and tedious essay by Windchild. Since I believe I've been able to deconstruct most of your arguments regarding the benefits of PatchGuard, it looks like you'd rather try to wear me down by being tedious and circular, than admit that I may have a point.

De-constructing your stability argument: Your percentage for BSODs that PatchGuard will avoid was initially 50%. Getting this number down to 0.1% is what I call largely de-constructing the argument. Same with security, initially you said PatchGuard is good because Microsoft is trying to make systems more secure, more recently you began to accept that it won't hinder malicious rootkits.

But in your mind:

-{ Quote: "I do not think I argue in circles or that my arguments fell in any way apart. I don't think that has been shown in any way, and we could sit here and argue about it all year." }-

Feels like we've been doing it already. In any case what we're talking about is PatchGuard. Are you mentally unable to separate the issue of the driver signing issue and the benefits of the additional RAM -- both good points -- from the problems PatchGuard creates or the way it is promoted? To me it seems that you want to keep bringing up the other issues to in order cloud the core argument and take the discussion to irrelevant points.

And your response to everything so far has consistently been a very long and tedious variation on "So what I don't care, it's their kernel they can do what they want, besides I like having more RAM, so there!" Pardon my paraphrasing. But obviously we can't have a sensible discussion when this is your core argument.

I get it that you think those of us who complain about PatchGuard are cry-babies that's your opinion. But for you to go to such lengths to justify everything that is wrong with PatchGuard, when you don't even have a stake in it, that's just wrong.

* * *

Final word abou security. Again: Windows 64-bit is more secure thanks to mandatory driver signing. There is also mandatory driver signing on 32-bit Windows by enabling a policy setting. If you complement this with some HIPS that will guard this policy setting against modifications, then you have virtually the same net result.

[tzuk]

-{ Quote: "EDIT: Yes Tzuk, Windchild appears to be going to great lengths to justify (and unfortunately, indirectly and probably unintentionally stab Tzuk/Ilya etc in the back haha) his points about PatchGuard, Microsoft and the greater good of all haha. Perhaps it's all in good spirit though mate." }-

Perhaps in good spirit, and with no bad intentions, but certainly not very kind. Which is to say: Here I am in the middle, on one side I have the alternative of disappointing fans of Sandboxie by not releasing a 64-bit product. On the other side the alternative of releasing a 64-bit product that I am not happy with. And there is Windchild telling me to take it and shut up, and when I try to explain the injustice I feel, he ultimately falls back to - you know what, I don't really care, I'm happy with my extra RAM. So it feels like he's trying to antagonize me but I will give the benefit of the doubt that it is in good spirit.

[Kees1958]

-{ Quote: "Perhaps in good spirit, and with no bad intentions, but certainly not very kind. Which is to say: Here I am in the middle, on one side I have the alternative of disappointing fans of Sandboxie by not releasing a 64-bit product. On the other side the alternative of releasing a 64-bit product that I am not happy with. And there is Windchild telling me to take it and shut up, and when I try to explain the injustice I feel, he ultimately falls back to - you know what, I don't really care, I'm happy with my extra RAM. So it feels like he's trying to antagonize me but I will give the benefit of the doubt that it is in good spirit." }-

Well,

I can only speak for myself, but the effort you put into his circle reasoning (direct translation from Dutch) is noticed and the points you made mattered to me. :thumb:

Regards Kees

[thathagat]

well how much of the said security::) of 64-bit systems to do with the unpopularity/low % usage of that architecture ? for i rembember prevx help commenting this...
-{ Quote: "Because of the low market share of 64bit operating systems, the malware authors aren't focusing much on them and definitely not focusing on them for the in-the-wild MBR rootkits.

So, the 64bit OS didn't directly prevent it, per-se, but the unpopularity of that architecture prevented that variant from operating properly." }-

[tzuk]

Thanks Kees, I appreciate that.

[Victek123]

-{ Quote: "well how much of the said security::) of 64-bit systems to do with the unpopularity/low % usage of that architecture ? for i rembember prevx help commenting this..." }-
.
Yes, at this point it's very premature to conclude that 64 bit Windows is more secure based on infection rates. Like the MAC it may only be the result of malware writers not making the effort to target the 64 bit OS since relatively few people are using it. This is beginning to change though because more and more desktop and laptop PCs are being sold with x64 Windows pre-installed. At some point they will be targeted.

[Windchild]

-{ Quote: "
De-constructing your stability argument: Your percentage for BSODs that PatchGuard will avoid was initially 50%. Getting this number down to 0.1% is what I call largely de-constructing the argument. " }-

Tzuk, I certainly never intended to say that PatchGuard is certain to avoid or fix 50 % of all BSODs. That would be crazy, there's no data to support that! If I have said that, please show us where. And if I really said that, and just don't remember doing so, then I owe you all an apology - sorry, I messed up big time, it is not true, PatchGuard does not prevent 50 % of BSODs.

But... if you're referring to my statement about how roughly 50 % of BSODs that I have personally seen were caused by some security software, mostly AVs, then I would like to point out that I did not say that PatchGuard would "avoid" all those BSODs caused by security software. This "50 % of BSODs Windchild has seen were caused by security software" statement was made only to show that in my real world experience, security software certainly is not flawless and really does cause crashes, which means there's a valid reason for MS to wonder about whether they should be letting anyone and everyone to freely patch their kernel. I will now quote that statement in its entirety, and show that it doesn't make any mention of PatchGuard fixing those BSODs.

-{ Quote: "Yes, the less you allow third parties to mess with the kernel, the better that is for stability. So, protecting the kernel from all kinds of hook, line and sinker isn't "anticompetitive", it's "common sense", if stability is a goal for you. Microsoft wants fewer people saying "Windows is unstable" so they'll take measures to make Windows more stable, like preventing some third party software from patching the kernel in a way that has previously caused all kinds of trouble.

My personal experience of BSODs on Windows? Out of all the BSODs that I've seen, perhaps roughly 45 % are caused by high-performance graphics card drivers, and about 50 % are caused by security software, most often AVs from big name companies - and the remaining 5 % is something else." }-

So, I think we have a misunderstanding here. Maybe that's due to my boring style of writing, or something like that. Perhaps the first paragraph that talked about MS doing something to stability issues made you think that I was claiming PatchGuard can fix all the BSODs caused by security software that I have seen. I should learn to write shorter texts, but I was never good at that. Honestly, way back when I was in school, I always went over the word limits when writing some paper, and had to work hard to avoid that.

-{ Quote: "Same with security, initially you said PatchGuard is good because Microsoft is trying to make systems more secure, more recently you began to accept that it won't hinder malicious rootkits." }-

More recently began to accept? No, that's not really what I thought. As far as I can recall, I never said that PatchGuard can do anything to prevent rootkits. (Again, if I did say that, I must have been drunk, and apologize.) All this time, I was saying that PatchGuard is MS's imperfect attempt at doing something to stability and security issues caused by kernel patching, even by legit software. But really, I don't think it's any anti-rootkit solution.

"Initially", in my first post, I argued against your example where Sandboxie is the police of the Windows world, and said that the police is actually Windows and Sandboxie is a third party hired security guard or kind-hearted merc or something. I criticized the line of thinking that on some OS security is a matter of what third party security software can do. I said that whenever Microsoft does "anything" to make an OS more secure some people have reason to complain. Only after that I made statements about PatchGuard, and claimed it is good because it's within Microsoft's rights to implement and because it's doing something to the stability and security issues caused by kernel patching, even something far less than perfect but still better than nothing. And yes, security and stability are related. PatchGuard isn't blocking rootkits, but it does address some stability issues, and better stability translates to better availability, which translates to better security (CIA triad, and all). So really, I don't see where I've said that PatchGuard will do something about rootkits and then have backed down from that statement.

-{ Quote: "Feels like we've been doing it already. In any case what we're talking about is PatchGuard. Are you mentally unable to separate the issue of the driver signing issue and the benefits of the additional RAM -- both good points -- from the problems PatchGuard creates or the way it is promoted? To me it seems that you want to keep bringing up the other issues to in order cloud the core argument and take the discussion to irrelevant points." }-

Yes, we're talking about PatchGuard. But the topic of the thread is 64-bit systems and anti-malware, and in this thread people have wondered whether to go 64-bit anytime soon at all, due to some issues with security software. It is all related: the effects of PatchGuard, third party security software, the good sides of 64-bit. Obviously, I can separate driver signing and additional RAM being good from what PatchGuard does. And have. But those things still relate to one subject: 64-bit systems and anti-malware software, which oddly enough is the subject of the thread. And to me, there's nothing irrelevant about this. 64-bit Windows gives you more RAM, and that is good. It gives you PatchGuard, and that is either bad or good depending on whether you are Tzuk or Windchild or someone else. When you know the good sides and the bad, you do some counting and see what the big picture is. For me and most users, more RAM is good, PatchGuard's effect on stability is either good or at worst neutral, and PatchGuard preventing some obscure security software is really not a big deal when we don't use it anyway. When you sum that up, looks like it's a good idea for most to at some point jump to 64-bit without worrying about getting owned without Security Software X. So, the benefits of 64-bit are not irrelevant to a discussion where people wonder whether they should go 64-bit or not! Obviously in such a discussion the benefits and negatives are both important to consider! As for the benefits or negatives caused by PatchGuard, I think PatchGuard is good, and you apparently think it's bad. Well, that's where we have to disagree. I support what PatchGuard is intended to do. I know that it solves some issues, and leaves others. I know that it also causes problems for some, but I don't mind that, since those affect only a minority. And further, I hope that you devs and Microsoft can ultimately reach an understanding where MS gives you the interfaces that you really need to make your software as good as you want it. But if MS doesn't do that, I can live with that, too, and if someone else can't, then it's really just "tough" - there's always Linux or OS X. But I hope it doesn't come down to that.

-{ Quote: "And your response to everything so far has consistently been a very long and tedious variation on "So what I don't care, it's their kernel they can do what they want, besides I like having more RAM, so there!" Pardon my paraphrasing. But obviously we can't have a sensible discussion when this is your core argument." }-

My core argument is: "Even if you can't run some security software X in Windows 64-bit, that is not a disaster, and you can still easily be safe in 64-bit Windows. So, don't worry. Jump to 64-bit when you feel like it, and don't fear that it will make you all insecure. 64-bit has some nice benefits that should boost your productivity, enjoy them. As for PatchGuard, it has a good purpose, and doesn't harm most users in any way they'll ever notice, so I support it. You can disagree with me, and I don't mind. Just don't hate me too much even if I don't agree with you." And look, I managed to explain it in a single paragraph now, without being too tedious, I hope. :)

-{ Quote: "I get it that you think those of us who complain about PatchGuard are cry-babies that's your opinion. But for you to go to such lengths to justify everything that is wrong with PatchGuard, when you don't even have a stake in it, that's just wrong." }-

No-no, I don't think you're cry-babies. That would be very foolish of me to say. But I think some of you do worry too much, because 64-bit isn't any security disaster even if your fave security software doesn't work on it. And I think some of you spend too much of their time being generally angry at MS when they could spend that time thinking up ways to make MS give you what you want even if that is a difficult task. Like I said, if you end up starting a petition to appeal to MS to give you the interfaces you need to do your thing as well as before, I will sign it, as long as you don't demand doing away with PatchGuard entirely or giving a simple option to disable it. And further, I think some of you place far too little value on productivity and far too much on obscure security software, no matter how good.

-{ Quote: "Final word abou security. Again: Windows 64-bit is more secure thanks to mandatory driver signing. There is also mandatory driver signing on 32-bit Windows by enabling a policy setting. If you complement this with some HIPS that will guard this policy setting against modifications, then you have virtually the same net result." }-

As said, most users rely on the default configuration. Which is why admin by default was such a bad thing. In 64-bit driver signing is the default, in 32-bit it is not the default. Big difference there.


All in all, I really do NOT have anything against any of you. Honestly. I'm not trying to antagonize Tzuk here. I know I'm not the kindest guy you'll find anywhere, and I've been called worse things before for good reason! I'm just trying to show a different, but still realistic point of view: "Sure, devs and fans of security software don't like PatchGuard, but most people really don't know about it, and will not care. And 64-bit does have benefits that make it worth small costs here and there..." It's not a "nice" point of view, no. But it is realistic, and rather common. For example, the people I know on a face-to-face basis practically all consider it completely irrelevant if PatchGuard prevents even all HIPS products and such - they're happy people as long as they can run the system and do their productive tasks without getting owned all the time, and double-happy if they can get more RAM, and still more happy if PatchGuard may improve stability.

But, I have understood for some time that there is a permanent disagreement here that can't be done away with. I can understand and accept your point of view. I just don't fully share it. But I'm not sure if you can accept that my point of view might be more than me just being unkind and inconsiderate, and that my point of view is actually based on reality, where most really don't suffer if some programs go away, but will still gain benefits from more RAM and maybe they'll even get less crashes due to PatchGuard. It's not all bad and there are benefits even to PatchGuard, is what I'm trying to say.

Perhaps I would have caused less offense if I had chosen my words more carefully earlier, but at that time, I of course didn't have the brains to consider that. But, if it makes anyone feel better, they can read here that they're right and I'm wrong, and feel better. ;D But now, we still haven't gotten MS to give you the interfaces certain software need. That's the real task.

[Franklin]

Way above me all this Patchguard jargon but I'll throw in another aspect:

"Trust and Confidence"

I have way more trust and confidence in Tzuk and Sandboxie than anything MS security related.

[jmonge]

-{ Quote: "Way above me all this Patchguard jargon but I'll throw in another aspect:

"Trust and Confidence"

I have way more trust and confidence in Tzuk and Sandboxie than anything MS security related." }-agree with you 100% look at my signiture:) do you think i will trust microsoft?no way "jose":argh:

[wat0114]

-{ Quote: "Well,

I can only speak for myself, but the effort you put into his circle reasoning (direct translation from Dutch) is noticed and the points you made mattered to me. :thumb:

Regards Kees" }-

Count me in on Kees' opinion, too.

Windchild, I have tremendous respect for your technical understanding and will admit you presented a very compelling argument (you are well spoken) for your support of Patchguard, but I don't like your "corporate-like" attitude where you agree to a sweeping change that affects everyone, including highly skilled and, maybe more important, highly responsible developers like tzuk and Ilya. When I say corporate I mean it is so typical in the corporate world to make an all-encompassing policy change that affects absolutely everyone, because it is simply "easier" this way, rather than address those few employees who have one way or another violated the current policy. I have worked in the corporate environment for many years and this is a disturbing (to me anyways) attitude I have seen many times over. Microsoft could show some backbone and pioneer a merits type program to allow responsible developers the necessary access to the kernel if they wanted, but they can't be bothered and are likely even afraid to address the inevitable repercussions that would accompany such a policy. They are more interested in looking after their own concerns rather than do the "right thing".

Anyways, this did turn out to be a great thread; very contentious at times but good points presented from all main participants, particularly, ssj100 (aka haha ;D ) , Kees, Windchild, and of course tzuk, Ilya and Prevxhelp :)

[Windchild]

-{ Quote: "Windchild, I have tremendous respect for your technical understanding and will admit you presented a very compelling argument (you are well spoken) for your support of Patchguard, but I don't like your "corporate-like" attitude where you agree to a sweeping change that affects everyone, including highly skilled and, maybe more important, highly responsible developers like tzuk and Ilya. " }-

Well, like I said, I don't mind if people disagree with me. It would be strange indeed if no-one did. :) Instead of getting everyone to agree with me, my goal is rather that people at least see that there is another viewpoint besides their own, and that this different viewpoint may be logically valid and not evil, even if it is disagreeable to you and based on moral values that you don't share. And further, my goal is that no-one is "scared off" from 64-bit because of being afraid for their security in the new environment. It's entirely ok, of course, to avoid 64-bit simply because it does not run certain software that one really likes. But that's that, really.

I don't think I deserve much respect for technical understanding - there are devs around with far greater understanding than mine in this thread. :) As for being well-spoken, if I was, I wouldn't get caught up in debates like these! ;D

[majoMo]

-{ Quote: "Why do you argue in circles, Windchild?" }-
Good to see that someone has a very solid aristotelian logic here.

It's the better way to avoid be confused with the common sophistics'tactic: confusing or illogical argument used for deceiving the evidence; evidence isn't their core motivation - instead they like rethoric and words and more words, that allows to encircle logics arguments using circumstantial evidence to dissemble the real and direct evidence.

Appearing and seeming but not really being.

Like isn't common to see such insight in this forum: my congratulations!

[BG]

-{ Quote: "Good to see that someone has a very solid aristotelian logic here.

It's the better way to avoid be confused with the common sophistics'tactic: confusing or illogical argument used for deceiving the evidence; evidence isn't their core motivation - instead they like rethoric and words and more words, that allows to encircle logics arguments using circumstantial evidence to dissemble the real and direct evidence.

Appearing and seeming but not really being.

Like isn't common to see such insight in this forum: my congratulations!" }-

Ain't that just what you got through doing? :gack:

[funkydude]

-{ Quote: "Ain't that just what you got through doing? :gack:" }-

That's what I was thinking...

[majoMo]

-{ Quote: "Ain't that just what you got through doing? :gack:" }-
Typical ad hominem argument and logical fallacy. Ad hominem arguments are always invalid in syllogistic logic.

Once you like it you can resumes the circles alone.

[Peter2150]

-{ Quote: "Way above me all this Patchguard jargon but I'll throw in another aspect:

"Trust and Confidence"

I have way more trust and confidence in Tzuk and Sandboxie than anything MS security related." }-

I couldn't agree with this more. Windchild, candidly you may have good arguments, but your posts are way to long for me to go thru.

I think what right now might make 64bit more secure is it's still not mainstream. Once it gets there, I bet we discover MS releasing patches and fixes as vulnerabilities are found.

[Windchild]

-{ Quote: "I couldn't agree with this more. Windchild, candidly you may have good arguments, but your posts are way to long for me to go thru.

I think what right now might make 64bit more secure is it's still not mainstream. Once it gets there, I bet we discover MS releasing patches and fixes as vulnerabilities are found." }-

Yeah, they're long. I'm rather quiet now, though. ;D

And yes, certainly there will be patches to 64-bit Windows vulnerabilities. There already are many. All software that does anything much, practically, has vulnerabilities and fixes to them. Mostly impossible to avoid.

[Victek123]

-{ Quote: "And further, my goal is that no-one is "scared off" from 64-bit because of being afraid for their security in the new environment. It's entirely ok, of course, to avoid 64-bit simply because it does not run certain software that one really likes. But that's that, really.

I don't think I deserve much respect for technical understanding - there are devs around with far greater understanding than mine in this thread. :) As for being well-spoken, if I was, I wouldn't get caught up in debates like these! ;D" }-
.
I find your POV inconsistent. If, as you say, you don't deserve much respect for technical understanding then why are you engaging in a complex debate about core programming issues of the Windows OS as if you do understand? If your personal opinions are not based on technical understanding, then how can you make valid generalizations? What then is your basis for re-assuring people that they shouldn't be scared-off of x64 because of security concerns? Are you saying "Don't worry, be happy"?

[Wrongusername]

-{ Quote: "Originally Posted by PrevxHelp
I'm going to try and not get too technical while explaining something very technical The problem with ring 3 (usermode) hooks over the target process is that they only prevent access to system functions if the author of the hooked program is not intentionally avoiding the hooked functions.
...
Therefore, when working within the local process, it is not possible to prevent an application from circumventing your usermode hooks unless you're emulating the process' instructions and intercepting the execution of it (which dramatically impacts the performance)." }-

Even full machine-level virtualization doesn't introduce "dramatic" impact on performance, specifically cpu performance. Sure there're still enormous limitations and overheads : ram,space, GPU. All combined makes it too cumbersome for everyday casual or scenarios like when testing some new applications and garbage being left in system is undesired.
Booting the virtual machine, having it eat away a gig of ram, still have to take additional measures to keep virtual OS clean(snapshots, sandboxie etc).

Moreover i don't consider things like Deepfreeze, Shadowuser, Returnil feasable solutions for home PC - usability comfort overhead incurred would on par or greater compared to booting full VM, security provided - less. Still possible to defeat their hooks etc.

Device-level access-filter approach as in 3 abovementioned products doesn't just cut it(naturally it has it's uses in corporate/public access pc etc. areas). It's a big plus to know what files application installs/changes, sometimes registry keys. System-wide vs individual process-specific access control, latter wins.
Constant need for restarts to do actual changes to system IS a big deal.

So apparently there's a specific area of taks where Sandboxie really shines. Ofcourse even with kernel hooks/no patchguard protection is not 100%(historically there've been exploits that allowed even virtual machine containment to be escaped and code executed on host OS), but something close to that can be achieved if application being sandboxed runs with normal user rights.

Now back to virtualization.
If what Vmware Thinapp(former Thinstall) developers claim is true it provides sandboxing via usermode virtualization. That should provide level of security equal or greater to kernel-mode hooks. Found some article with specific figures on overhead http://www.xpnet.com/appvirt2008.pdf Claims to be 20-40% if i read it correctly.
That seems strange as from articles i've read before on native vs full virtual machine cpu peformance overhead is much smaller. Article with comparison of usermode virtualization vs full machine-level virtualization would be interesting to read.
Too bad they don't offer security-oriented product based on this sandboxing. Though one could package cmd.exe only and get somewhat of sandbox i guess.

There's a mantra proponents of Patchguard keep on chanting "It's MS OS, they do whatever they want. MS knows what's better for users". Why doesn't MS implement Patchguard in 32-bits? Answer is simple, they wouldn't be able to handle public backlash. So much for their rights to do whatever they want with their OS. Would they not listen maintaining Patchguard'd simply become a liability. There're examples of most draconian drm and copy protections falling because of widespread negative opinion of them. Now maybe MS would still stubbornly not provide users with option to disable Patchguard on x64. That's where liability part comes in, they can only keep releasing updates against bypass techniques for so long and complicate it's protection only so much.

-{ Quote: "Originally Posted by Windchild
Windows 7 in 64-bit is more secure than Windows 7 in 32-bit. 64-bit has security enhancements, such as driver signing, that really do help." }-
Oh really? Is 32-bit any different about drivers signature than 64-bit?
There's another mantra "allowing users to optionally disable Patchguard defeats the whole purpose".
Wait, but MS opted to "compromise" another big security feature of theirs, that exact driver signature enforcement. Doesn't it look like a greater security tradeoff for sake of common sense than allowing to disable Patchguard? Kernel-level unsigned code yes, patching kernel - NOO way. I'm talking about testsigning mode allowing to load self-signed drivers, even on x64 OS, even on Win 7.

This concerns third-party security vendors too. The claim "we can't play it rough with MS and disable Patchguard, MS is going to revoke/blacklist our signing certificate/ban us from kernel-land" - not truely valid. x64 drivers can be provided self-signed requiring users to run in testsigning mode - a small inconvenience imo and not really that big of security compromise since if provided with administrative privilegies needed for driver installation malware intent on installing drivers could easily make use of signature bypass methods too.

Would be interesting to see Patchguard coexistance solution based on hypervisor using VT-x, Amd-V as a very generalized approach. Sure not all CPUs support that, but that' not an issue in this case. A PC with 6-8gb of ram and x64 cpu is unlikely to be equipped with some "value" version of that CPU without this technologies.
They promise to patch all bypass techniques, but IMO MS would likely just let it slide if you hide from Patchguard using a hypervisor. There're legal hypervisors out there so they can't just deny them all and not too likely they'd go to such extents as detecting specifically if hypervisor is concealing kernel hooks from Patchguard.
Eventually they'll have their own hypervisor in mainstream OS, perhaps invalidating this possibility, but not sooner than 3-5 years from now.

More rocks need to be thrown into 3rd-party ISVs garden. In the beginning, like 2006, there used to be a lot of discontent and noise, complaining about Patchguard. But then everything went silent. Have they found a miraculous way to provide equal or at least close to former level of security? Not really. But they invested into inferiour ways to provide at least some level. And most prefer users to stay unaware about shortcoming of 64-bit versions of their products. Instead of pointing that shortcoming out in bold right letters and naming the party responsible. This is definitely very wrong approach that deserves criticism.

It's all worked good so far because of very small x64 market share and little interest from malware authors, but that's going to change soon, especially with Win 7 release many may opt for x64 to make full use of their RAM... And lets hope it won't be malware authors who realize first what a fine gift MS brought them here by driving out security vendors from kernel.

[halcyon]

-{ Quote: "So what will you guys do when you eventually move to a 64-bit system? I personally don't anticipate a move to a 64-bit system for another 5-10 years." }-

Moving this week. I have Win7 on pre-order and legal access to select volume licensing through my work.

My new build will have 12GB memory, so 64bits it'll be (memory due to massive data set analysis).

I still haven't figured out what the complete setup will be, but my reasoning currently is roughly this:

If I can do away with as many a 3rd party security app as possible then I'll be a happy camper. All that, without comparatively losing a lot of security compared to my current 32bit XP build.

The more streamlined my setup, the less headaches I have from it. To me security is a combination of behaviour/awareness, security rules/tools and usability. My current setup takes too much time to build / add exceptions and deal with issues coming from the security software. I don't like that, so I'll try to prune the setup down in my next build.

Also, finally I hope that many people will not upgrade to 64bits for a long time. Comparatively it'll then remain a less interesting attack platform and that may affect the amount of ITW exploits for it. I have all the device drivers I need already, so my support is good enough.

So, just don't upgrade to 64-bits, pleeeeease :D

[Windchild]

-{ Quote: ".
If, as you say, you don't deserve much respect for technical understanding then why are you engaging in a complex debate about core programming issues of the Windows OS as if you do understand? What then is your basis for re-assuring people that they shouldn't be scared-off of x64 because of security concerns? Are you saying "Don't worry, be happy"?" }-

Please note how I didn't say that I "don't understand." I said some people have a greater understanding. Those statements are quite different, really, at least in the kind of English that I have learned. One person can know enough about firearms, for example, to be quite effective with them in practice, but then someone else may have much higher understanding in building them - and yet they can still discuss and the person with less understanding can still have valuable views and input. And this debate is of course about much more than just core programming issues. It's also about the user perspective. But I think I won't go through all of that stuff again, when people found it tedious to begin with!

As for the basis for re-assuring people that they shouldn't be scared-off of x64? The basis is personal experience, and a much higher level of understanding of the technology involved than most people have, even most people posting in security software forums - obviously that doesn't include professional developers and such, who obviously have a still higher technical understanding than little old me. Note, though, that developers often have different desires than even rather knowledgeable users, since developers often aim to sell things, and users aim to use things. Windows in 64-bit has the same good old NT security model as 32-bit, and some enhancements like driver signing being required by default. You can run Windows 64-bit more than reasonably secure without some of the highly loved and recommended programs often mentioned in this forum. That's why I say there's no reason to worry. But no-one has to believe me - it's a free world. You can worry, if you want. Or you can try for yourself and see whether you can run 64-bit safely and whether there is a reason to worry. I can run safe in Windows 64-bit. A lot of other people can, and many much better than me. And to tell you the truth, those people who really honestly can't, probably couldn't do it even if they were running all the security software in the world that ever worked on any OS.

-{ Quote: "
Oh really? Is 32-bit any different about drivers signature than 64-bit?" }-

Yeah, really. The driver signing requirement in 64-bit is a security improvement that really does help. No-one in this thread said that it's perfect, or impossible to bypass in any way. As for 32-bit being any different about drivers signature, you've lost me there. Fact is, in 32-bit Windows, driver signing requirements are not enabled by default. Sure, the technology may be the same, but the defaults really do matter.

-{ Quote: "There's another mantra "allowing users to optionally disable Patchguard defeats the whole purpose".
Wait, but MS opted to "compromise" another big security feature of theirs, that exact driver signature enforcement. Doesn't it look like a greater security tradeoff for sake of common sense than allowing to disable Patchguard? " }-

Well, sure, that would be a greater security tradeoff than allowing to disable PatchGuard, since PatchGuard really isn't a security feature any more than UAC is. It may have security impact, sure. But to me it seems that PatchGuard is mainly about stability, just like UAC is mainly about kicking devs up the rear-end so they'd start remembering that not everyone is an admin all of the time and not all software should be allowed to do absolutely anything without confirmation from the user. So, allowing to disable PatchGuard would be more of a stability than security tradeoff, and maybe everyone doesn't want that. A novel thought.

As for the issue of MS not enabling PatchGuard in 32-bit, well duh. Microsoft themselves openly state why they don't: it's always easier to make changes that break stuff in situations where a lot of stuff inevitably breaks anyway. That really has nothing to do with what MS has the right to do with their own software. Because, you know, when you have the right to decide what you do with your software, you can also use that right to decide that you won't make great changes to your 32-bit OS if it would annoy your customers, but that you'll make the changes in 64-bit versions where other big changes happen anyway. Obvious stuff.

Finally, I'd say one thing about security in 64-bit. If you're running happily along as admin, and you're the kind of user who knows little of security issues, it's not exactly a slam dunk that security software would save you from ever getting serious infections. Many people really have neither desire nor skill to run complex security software. Many people have trouble with a simple AV. We've seen how "effective", or if you prefer "ineffective", the most popular anti-malware software are in keeping a system forever clean - in 32-bit. That in mind, there's no reason to think things will enormously change in 64-bit. There will still be a whole lot of people getting infected, just like in 32-bit, and often in spite of security software. Realistically, that's how it is. 64-bit may be an improvement in some ways when it comes to security, but there's no way to make such a great improvement that it would prevent certain people from getting infected. Dancing pigs, and all. Will 64-bit somehow leads us to even much worse infections, much more numerous than before, that couldn't have happened in 32-bit? I really don't think so. But we'll see soon enough, won't we.

As was said before: there's a big task ahead for people who want Microsoft to give them documented, legit ways to do what they want with their security software to offer strong protection. Lobby, lobby, lobby, I guess.

[noone_particular]

-{ Quote: ""Trust and Confidence"

I have way more trust and confidence in Tzuk and Sandboxie than anything MS security related." }-
Definitely agreed, and I'll apply that to all of the vendors in this discussion and those who develop(ed) the other software I use. It's not just a question of trusting MS to properly secure a system. Some of Microsofts own activities are questionable. On an older 32bit system, a classic HIPS enabled the user to have at least partial control over that, a balance of power. I don't claim to understand everything in this thread, but it looks like that balance is gone on 64bit, and MS has total control over those systems.

Before anyone says "If you don't trust MS use something else", all of the options have their own problems and/or limitations. Windows has been the option best matched to my needs, until recently.

[trismegistos]

-{ Quote: "It's not just a question of trusting MS to properly secure a system. Some of Microsofts own activities are questionable. On an older 32bit system, a classic HIPS enabled the user to have at least partial control over that, a balance of power. I don't claim to understand everything in this thread, but it looks like that balance is gone on 64bit, and MS has total control over those systems.
" }-
If that is true, then, it looks like a fascist move. Curent financial system of Globalization, trade liberalization and focus on Virtual economies seems to breed Monopolistic tendencies of the Immortal and Immoral Corporations and in some way, people tend to be treated as livestock. Sorry, been reading too much conspiracy theories though those undeniably carry some pearls or kernels of truths amongst the bunch of crappy stuff like UFO stuff, outright lies and deceptions, pseudoscience and hidden agenda(Read the Bilderberger, Council of Foreign Relations, etc.)

Hello, folks. Welcome to the Matrix.
We are now living in Userland. ha ha

[Kees1958]

-{ Quote: "
Moving this week. I have Win7 on pre-order and legal access to select volume licensing through my work.

If I can do away with as many a 3rd party security app as possible then I'll be a happy camper. All that, without comparatively losing a lot of security compared to my current 32bit XP build.
" }-

Depends on your XP setup now but, WIn7 UAC, PGS , MSE and Windows7 Firewall control (see http://www.wilderssecurity.com/showpost.php?p=1523049&postcount=1) is an easy and pretty strong setup. I always use Windows FireWall control to get the correct progams who want go outbound, then I use Stems's post to make the FW quiet (see http://www.wilderssecurity.com/showthread.php?t=239750&highlight=Vista+FireWall+Stem) and de-install Win7FWC


-{ Quote: "
Also, finally I hope that many people will not upgrade to 64bits for a long time. Comparatively it'll then remain a less interesting attack platform and that may affect the amount of ITW exploits for it. I have all the device drivers I need already, so my support is good enough.

So, just don't upgrade to 64-bits, pleeeeease :D" }-

:thumb: Great idea, lets keep x64 an un interesting OS like Mac and Unix, so malware writers keep on focussing on the large x32 market :thumb:

[Kees1958]

-{ Quote: "Yes, please don't move to 64-bit yet, otherwise things will get boring if all the malware writers target them and forget about 32-bit haha!" }-

Well the gamer does not want anything else. He handled the RAM usage of x64 by putting in 8GB RAM, runs only x64 or Vista's own security aps.

[raven211]

-{ Quote: "Well the gamer does not want anything else. He handled the RAM usage of x64 by putting in 8GB RAM, runs only x64 or Vista's own security aps." }-

I'm a gamer - but a knowledgeable gamer. ;D If he was too, he would at least not buy 8 Gigs of RAM now, unless he wants to waste money cause he thinks it's fun or something. :P

[Kees1958]

-{ Quote: "I'm a gamer - but a knowledgeable gamer. ;D If he was too, he would at least not buy 8 Gigs of RAM now, unless he wants to waste money cause he thinks it's fun or something. :P" }-

He was a fanatic, until he found out that being a Dutch top gamer did not help wth his school grades. Possibly his increasing level of testeron also helped him to switch from web contact to phisical contact (meeting real girls that is).

All the gamers I know waste money, buying new video cards while half a year later they are half the price. So all your remarks apply I think (he started Vista x64 with 2GB, doubled to 4GB which was a great improvement, so he problably could not resist doubling that to 8GB)

[3TAMMUZ]

It's the matter of the credit and debt system over the monetary policy for computerization and you'd better get used to the Windows x64 platform soon.

With the help of the internet of the MS, the world banking system is getting better off.

[Lebowsky]

-{ Quote: "It's the matter of the credit and debt system over the monetary policy for computerization and you'd better get used to the Windows x64 platform soon.

With the help of the internet of the MS, the world banking system is getting better off." }-
What? :blink:

[Johnny123]

-{ Quote: "What? :blink:" }-

LOL, that's exactly what I thought too. We'll have to wait for the next cornflakes box that has a decoder ring in it.