64-bit systems and anti-malware software

There will never be an equivalent to Sandboxie on x64.

 

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.

 

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.

 

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 (have to love < 2 second boot times on modern hardware even when virtualized).

 

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.

 

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!"

 

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.

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!

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.

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.

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.

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.

 

Yep SSJ,

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

 

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!

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

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!

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.

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.

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.

 

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.

 

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.

 

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.

 

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

 

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!

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.

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.

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.

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.

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.

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.

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.

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.

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?"

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.

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.

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

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.

Ah, personal attacks - making people look smarter since 5400 BC. "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?

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.

Yeah. That's the side I'm on, right there. 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.

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.

Ain't that the truth. 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!

 

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

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

 

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:

Then you responded:

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.

 

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

1. 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.
2. Could it be this setup offers better security than a 64 bit system running only LUA/SRP but no 3rd part software to complement?
3. is it fair that MS spearheads the Patchguard solution because there are a few (okay, many) developers who can't hook the kernel properly?
4. 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!

 

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. Your posts, like many other posts in this thread, have been interesting to read.

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". 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."

"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.

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."

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

 

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?!

 

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.

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.

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.

 

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

 

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

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.