64-bit systems and anti-malware software

Then some replies...

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.

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.

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.

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.

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.

 

Assuming this article from Wikipedia is accurate, there are other reasons besides ensuring the financial demise of security software developers.

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?

 

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?

 

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?

 

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.

 

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.

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.

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

 

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

 

Kees:

Two fantastic posts back to back!

 

More answers:

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.

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.

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.

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.

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.

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

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.

 

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.

 

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.

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

 

Such a brilliant post you touched my heart.

 

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 )

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

Kees1958 - you have made some fantastic analogies and posts 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.

 

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.

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

 

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.

 

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.

 

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

 

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

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.

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.

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.

 

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?

 

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.

 

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?

 

That would be defeating the purpose.

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.

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.

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.

 

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.

 

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