Where Microsoft is now becoming even more monopolistic

[Arariel]

Shall we compare the numbers?

http://www.kb.cert.org/vuls/bymetric?se ... &count=100
http://www.kb.cert.org/vuls/bymetric?se ... &count=100
http://www.kb.cert.org/vuls/bymetric?se ... &count=100
http://www.kb.cert.org/vuls/bymetric?se ... &count=100

The security risks for Microsoft and Windows are mostly much higher and more recent than the ones for "Red Hat" and "Linux" (except for a a 100+ security risk for Red Hat from 1999). These were security risks, mind you, which exist regardless of whether or not people actually exploit them, so low market adoption can't be an argument here. Furthermore, if high market adoption leads to more security vulnerabilities, how come GNU/Linux web servers haven't been cracked to oblivion?

[Ghostbear]

Shall we compare the numbers?

http://www.kb.cert.org/vuls/bymetric?se ... &count=100
http://www.kb.cert.org/vuls/bymetric?se ... &count=100
http://www.kb.cert.org/vuls/bymetric?se ... &count=100
http://www.kb.cert.org/vuls/bymetric?se ... &count=100

The majority of all of those listed are, again, from the pre-security overhaul era. Still not relevant.

Furthermore, if high market adoption leads to more security vulnerabilities, how come GNU/Linux web servers haven't been cracked to oblivion?

You insist on ignoring the specifics of what is said. Higher market share leads to more people looking for your security vulnerabilities. That means more people will find the security holes that already exist, not that more security holes pop into existence from out of nowhere. For web servers, again, you're missing the difference between a market where the dominant player is 12 times larger than the next biggest member (and that other member is "other", aka made up of multiple other groups; the largest concentrated target is ~1/17 the market share of Windows), and a market where it's 65/35 -- the larger target is slightly less than twice as large as the next one. There are huge differences between those markets. Malware tends to be OS specific, and it tends to use the infected machine to spread to other computers. When there is such a large disparity in market share, then you'll want to target the bigger one.

Beyond that, I don't believe the code bases between for Windows:Windows Server or Linux(server versions):Linux(desktop versions) is all that significant. They're already familiar with Windows' flaws from the desktop side.

[Arariel]

54.62 VU#899748 2010-11-03 Microsoft Internet Explorer invalid flag reference vulnerability
47.04 VU#309739 2008-08-12 Microsoft Color Management System (MSCMS) module remote code execu...
44.04VU #545228 2009-07-13 Microsoft Office Web Components Spreadsheet ActiveX control vulnerabilit...
41.04VU#492515 2010-01-14 Microsoft Internet Explorer HTML object memory corruption vulnerability

And so on.

You insist on ignoring the specifics of what is said. Higher market share leads to more people looking for your security vulnerabilities. That means more people will find the security holes that already exist, not that more security holes pop into existence from out of nowhere. For web servers, again, you're missing the difference between a market where the dominant player is 12 times larger than the next biggest member (and that other member is "other", aka made up of multiple other groups; the largest concentrated target is ~1/17 the market share of Windows), and a market where it's 65/35 -- the larger target is slightly less than twice as large as the next one. There are huge differences between those markets. Malware tends to be OS specific, and it tends to use the infected machine to spread to other computers. When there is such a large disparity in market share, then you'll want to target the bigger one.

You would still expect more cracks for the dominant GNU/Linux in web servers than Windows. Yet doesn't Windows on web servers suffer from more cracks? The minority is suffering from a majority of the security vulnerabilities.

[Ghostbear]

54.62 VU#899748 2010-11-03 Microsoft Internet Explorer invalid flag reference vulnerability
47.04 VU#309739 2008-08-12 Microsoft Color Management System (MSCMS) module remote code execu...
44.04VU #545228 2009-07-13 Microsoft Office Web Components Spreadsheet ActiveX control vulnerabilit...
41.04VU#492515 2010-01-14 Microsoft Internet Explorer HTML object memory corruption vulnerability

And so on.

Yes, some of them are from the proper era. Most are from an irrelevant era. You're comparing the size of one list with a bunch of data that isn't relevant to other lists.

You would still expect more cracks for the dominant GNU/Linux in web servers than Windows. Yet doesn't Windows on web servers suffer from more cracks? The minority is suffering from a majority of the security vulnerabilities.

You're trying to twist my argument into something it isn't. Just because you're ignoring the nuances of what is said for the third time doesn't make you any less wrong. The first three sentences of my quote that you used covered this:

You insist on ignoring the specifics of what is said. Higher market share leads to more people looking for your security vulnerabilities. That means more people will find the security holes that already exist, not that more security holes pop into existence from out of nowhere.

[somebody already took it]

I would accept any of the following types of reasoning:
A review of the potential security solutions, and explanations of why they would all fail.

Other security solutions:
Virus scanners, monthly malware remover, sandboxing.
All useless once the boot sector has been compromised, because now you can identify whatever you can modify things so that it isn't detected as impermissible activity. They'll have a higher access level than the security measures, meaning that those security measures can't remove the infection anyway, even if you somehow do detect it. Which I've tried to explain to you twice already, but you keep ignoring it.

I do not mean to ignore you. I acknowledge that if a virus compromises the boot sector it is a very bad thing indeed, but it shouldn't be happening at all. If a virus is capable of compromising the boot sector, it has already compromised another part of the system, from which there are likely other avenues for attack.
You mention sandboxing which seems to me like a sure fire way to prevent viruses from gaining access to the boot process. So what if its useless one the boot sector has been compromised if it's impossible for the boot sector to be compromised.

[Ghostbear]

I do not mean to ignore you. I acknowledge that if a virus compromises the boot sector it is a very bad thing indeed, but it shouldn't be happening at all. If a virus is capable of compromising the boot sector, it has already compromised another part of the system, from which there are likely other avenues for attack.
You mention sandboxing which seems to me like a sure fire way to prevent viruses from gaining access to the boot process. So what if its useless one the boot sector has been compromised if it's impossible for the boot sector to be compromised.

Right, but those security breaches are going to happen no matter what. The overall system is just too complex and too high value of a target while dealing with too many idiot users*, for any overall security system to be flawless. Protecting the boot sector in this way is a method to mitigate those inevitable breaches: one of the worst methods of infection available to them is now made significantly more difficult, perhaps about as secure as it can be made secure. It's like putting your absolute most valuable things in a safe bolted to the floor. There's tons of options to make your house secure, but if someone really wants to break in, eventually they will. Now, unless they brought something with them to take out part of your floor, they'll have to steal your TV or laptop, instead of the jewelry collection passed down your family for five generations.

* A lot of hacks these days rely in part on human engineering -- get the user to install this, or put a certain flash drive in their system, or disable this, or...

[somebody already took it]

The overall system is just too complex and too high value of a target while dealing with too many idiot users*, for any overall security system to be flawless.
* A lot of hacks these days rely in part on human engineering -- get the user to install this, or put a certain flash drive in their system, or disable this, or...

The process for users to escape from a sandbox could be made just as laborious as the process for them to disable secure boot.

Also, I don't think having a computer's boot sector compromised is that much worse for the average user than other types of attack. If I were to just have my browser compromised, pretty much all the information I care about protecting would be revealed. The attacker might not be able to add my computer to their botnet, but to me that's not nearly as big of concern as having my credit card information stolen. And I should reiterate, if a virus is capable of compromising my boot sector, it has already compromised another part of the system. At that point there are likely other avenues for attack that Microsoft's technology will do nothing to stop (this is especially true for those who don't pay the extra 50$ for antivirus software). Thus, I doubt there will be any reduction in the number of compromised systems as a result of UEFI boot restrictions. There may even be more compromised systems since fewer people will go over the additional hurdles to use GNU/linux.

[Ghostbear]

Also, I don't think having a computer's boot sector compromised is that much worse for the average user than other types of attack. If I were to just have my browser compromised, pretty much all the information I care about protecting would be revealed.

If just your browser is compromised, the problem goes away when you restart it, switch to a new browser, reinstall it, or perform a virus scan (depending on how it was compromised). If your boot sector is compromised, the problem goes away when you reformat the disk, completely. Maybe. If you're lucky; if you aren't, you'll have to toss aside all of your data as well. That's a huge difference.

And I should reiterate, if a virus is capable of compromising my boot sector, it has already compromised another part of the system.

I think you're failing to understand what I'm explaining. Those base-system security holes are going to exist no matter what. Microsoft could spend the next 10 years working with the same codebase trying to secure it, and there would still be holes after they finished.

Secure boot means that when people start to compromise Windows 8 systems (not if, when), that the result of that breach is less catastrophic. Microsoft will have a far greater chance of detecting and removing that infection with the monthly malware removal tool. If that doesn't work, then users will have a far better chance of getting rid of it with anti-virus software. If it can't get rid of it, the software is far more likely to be able to detect it for users to do manual removals. If it can't be removed even after all of that, it will be able to be removed with a system wipe. Secure boot is like locking doors inside a locked building. If the primary building will get broken into no matter what, there are now less rooms to access afterwards.

This won't reduce infections (directly anyway -- making infections easier to remove could mitigate their propagation, indirectly reducing the infection rates): it will make the infections that happen far less severe of a problem.

(this is especially true for those who don't pay the extra 50$ for antivirus software)

MSE is $0 and a pretty good anti-virus.

[somebody already took it]

Also, I don't think having a computer's boot sector compromised is that much worse for the average user than other types of attack. If I were to just have my browser compromised, pretty much all the information I care about protecting would be revealed.

If just your browser is compromised, the problem goes away when you restart it, switch to a new browser, reinstall it, or perform a virus scan (depending on how it was compromised). If your boot sector is compromised, the problem goes away when you reformat the disk, completely. Maybe. If you're lucky; if you aren't, you'll have to toss aside all of your data as well. That's a huge difference.

When it comes to cloud computing I think your premises are wrong. For example, it is conceivable that a browser's data/app syncing features could transmit a virus to a freshly installed version. And reformatting a disk isn't a big problem when my data is backed up in the cloud. However, that means my virus could also be in the cloud.

Those base-system security holes are going to exist no matter what. Microsoft could spend the next 10 years working with the same codebase trying to secure it, and there would still be holes after they finished.

Well what about running in a sandbox? Where are the holes there that secure boot would do anything about?

Secure boot means that when people start to compromise Windows 8 systems (not if, when), that the result of that breach is less catastrophic. Microsoft will have a far greater chance of detecting and removing that infection with the monthly malware removal tool.

If Windows couldn't catch the virus when it was installing a rootkit, why would it be any more likely to catch it afterwards?

[Ghostbear]

When it comes to cloud computing I think your premises are wrong. For example, it is conceivable that a browser's data/app syncing features could transmit a virus to a freshly installed version. And reformatting a disk isn't a big problem when my data is backed up in the cloud. However, that means my virus could also be in the cloud.

You aren't going to transfer an actual infection to the cloud. All that is, is a giant storage space for you -- it's not going to run any of your code on their machines, and if it does, you can bet your ass they're going to have better security setups than are used for home users. You definitely aren't going to get system access as a customer. All you will be transferring, at worst, is an infected file. There's a decent chance that the server on the other end will detect that, and if it doesn't, it still gives you a chance to detect it upon re-downloading it.

Reformatting your system isn't a trivial task to most people: the actual process itself is quite simple, but needing to backup all of their data, re-install everything, get their user settings back to where they were.. That's going to take a while. If you need to download all of your files all over again, that might take hours, days, or even weeks depending on how much data you have. Telling a user "here, run this scanning routine, follow the instructions" is a lot more reliable and causes less productivity loss than saying "Reformat the whole system. Backup your shit first." Especially since, as already mentioned, most users are morons: a lot of them won't back up their stuff first, and they're going to blame the OS vendor for that (because their security lead to the problem happening at all).

EDIT:
I'm not even sure how a compromised browser is going to be causing this problem. You won't be having a Cloud sync service running in a browser -- it'll be its own standalone task. You might be able to use a browser to upload to the cloud, but even then, that's not really a prime target with a compromise browser.

Well what about running in a sandbox? Where are the holes there that secure boot would do anything about?

The sandbox won't be perfect. That's the point. No matter how hard they try, unless it's dealing with an absurdly simple system (i.e. not an operating system) it's always going to have a flaw. Beyond that, you're acting as if sandboxing is some universal cure-all to protect against infections. It isn't.

If Windows couldn't catch the virus when it was installing a rootkit, why would it be any more likely to catch it afterwards?

Updated definitions, active scans (instead of passive scanning), tools written specifically for that infection that know how to find it, new patches (either to the system or to the malware scanner), and so on. It happens all the time.

You are both over-trivializing a lot of factors, while overblowing many others here, throughout this whole conversation.

[somebody already took it]

Well what about running in a sandbox? Where are the holes there that secure boot would do anything about?

The sandbox won't be perfect. That's the point. No matter how hard they try, unless it's dealing with an absurdly simple system (i.e. not an operating system) it's always going to have a flaw. Beyond that, you're acting as if sandboxing is some universal cure-all to protect against infections. It isn't.

Say I have a electronic design automation tool which I use to simulate a computer's circuitry. Do you think it is possible to make the simulated computer to infect the simulating OS with a virus?

[Ghostbear]

Say I have a electronic design automation tool which I use to simulate a computer's circuitry. Do you think it is possible to make the simulated computer to infect the simulating OS with a virus?

None of the simulated data on it is going to be outputted in a form that, in memory, would be usable for an infection. I certainly can't think of any I've encountered yet that would even output that kind of data at all, regardless of the format it's in for the actual computer. Also, a simple* simulation program is a trivial system to sandbox. I don't think you're getting the complexity difference between "individual program" and "modern operating system".

* Simple here is defining the actual run process of the program. The code itself is, undoubtedly, going to be rather complex.

[KnightExemplar]

I'm not an expert on PC bootup routines, so I am somewhat talking out of my ass here. But lets say a bootsector virus writer write a small (say less than 20MB) Fedora distribution with NTFS support. To make modifications on the kernel, they can simply write a kernel module that is loaded after boot time in an init script. (or do kernel modules also have to be signed during secure boot? That in of itself may pose a problem...)

The kernel modules must be signed. And pretty much any method of loading unsigned code is disabled if you're using secure boot.

Essentially, if you want to run unsigned modules or load unsigned code from those modules, you must disable secure boot, as otherwise the entire point of secure boot is defeated.

EDIT: Even better, in the "Wait signed what" heading on the artcile, they specifically address these concerns, that if you could load unsigned code, then it could be used to compromise other OSs.

Indeed, sounds like they really thought this out then. Thanks for the information.

----------------

As for Gnu/Linux vs Windows, its a bit of a apples / bananas thing. Writing a virus for Linux is not necessarily an easy thing to do, because deploying a virus across Fedora and Android are completely different. Yes, both are Linux, but Linux distributions are so different from implementation to implementation that we really don't have a fair basis of comparison.

I mean, Android has more viruses for it than Windows Phones. Not that they all work on the latest version of Android, but due to fragmentation... a ton of Androids are still using Eclair and Froyo. We've got a perfect storm: Open Source but very very slow patches because handset makers don't necessarily push updates fast enough to the end devices. So everyone knows about the bugs (due to many eyes), but end users are powerless to apply the updates.

So what now? Do we blame Linux because they have more viruses than Windows Phones? That is downright nonsensical. Its an issue of Market Share when we compare Android vs Windows Phone.

Similarly, its an issue of Market Share when we compare Desktop Windows vs Desktop Linux. Woops, sorry, each linux is too different. Its really Desktop Windows vs Fedora vs CentOS vs Debian vs Ubuntu. (Ex: Debian and Ubuntu were open to a very bad ssh bug a few years ago, but not Fedora or CentOS).

[somebody already took it]

Similarly, its an issue of Market Share when we compare Desktop Windows vs Desktop Linux. Woops, sorry, each linux is too different. Its really Desktop Windows vs Fedora vs CentOS vs Debian vs Ubuntu. (Ex: Debian and Ubuntu were open to a very bad ssh bug a few years ago, but not Fedora or CentOS).

Well, Windows XP is quite a bit different from Windows 7 and Windows 7 has a larger market share but fewer vulnerabilities (I think):

[Arariel]

Yes, some of them are from the proper era. Most are from an irrelevant era. You're comparing the size of one list with a bunch of data that isn't relevant to other lists.

But the major risks found under Microsoft and Windows are much more recent the ones found for GNU/Linux systems.

You're trying to twist my argument into something it isn't. Just because you're ignoring the nuances of what is said for the third time doesn't make you any less wrong. The first three sentences of my quote that you used covered this:

You insist on ignoring the specifics of what is said. Higher market share leads to more people looking for your security vulnerabilities. That means more people will find the security holes that already exist, not that more security holes pop into existence from out of nowhere.

If higher market share leads to more security holes found and exploited or if more people look for and exploit those vulnerabilities, again, why the disparity on web servers? The only explanation is that GNU/Linux + Apache servers are genuinely more secure than Windows web servers.

As for Gnu/Linux vs Windows, its a bit of a apples / bananas thing. Writing a virus for Linux is not necessarily an easy thing to do, because deploying a virus across Fedora and Android are completely different. Yes, both are Linux, but Linux distributions are so different from implementation to implementation that we really don't have a fair basis of comparison.

I mean, Android has more viruses for it than Windows Phones. Not that they all work on the latest version of Android, but due to fragmentation... a ton of Androids are still using Eclair and Froyo. We've got a perfect storm: Open Source but very very slow patches because handset makers don't necessarily push updates fast enough to the end devices. So everyone knows about the bugs (due to many eyes), but end users are powerless to apply the updates.

So what now? Do we blame Linux because they have more viruses than Windows Phones? That is downright nonsensical. Its an issue of Market Share when we compare Android vs Windows Phone.

Similarly, its an issue of Market Share when we compare Desktop Windows vs Desktop Linux. Woops, sorry, each linux is too different. Its really Desktop Windows vs Fedora vs CentOS vs Debian vs Ubuntu. (Ex: Debian and Ubuntu were open to a very bad ssh bug a few years ago, but not Fedora or CentOS).

The thing is Android isn't GNU/Linux. It contains the Linux kernel, but no GNU components, AFAIK. Google substituted their own code for the GNU software. The modern, mainstream, desktop GNU/Linux distros are more similar, although you're right in that one vulnerability can't necessarily be exploited in another distro. And of course, spread of malware will be hindered by the fact that Fedora can't use debs and Ubuntu can't use rpms, so that always helps.


End users aren't necessarily powerless to apply updates; I run an older Android version, but I'm planning on compiling ICS for my phone sometime this summer. Now, if you mean non-technical end-users, that's another story. Of course, the handset makers are really at fault for not pushing out the updates.

[Ghostbear]

But the major risks found under Microsoft and Windows are much more recent the ones found for GNU/Linux systems.

Sigh. Fine, I'll just go through all of them that came out after Vista, one by one. Spoilered for length.

Spoiler:

2007-07-10: Microsoft Windows Active Directory fails to properly validate LDAP requests: Doesn't affect Windows versions with overhauled security.
2007-07-10: Microsoft Windows Vista Teredo IPv6 interface firewall bypass vulnerability: Did affect a Windows version with overhauled security (Vista only). Threat not present if using a different firewall.
2007-07-27: Microsoft Windows URI protocol handling vulnerability: Doesn't affect Windows versions with overhauled security.
2007-08-14: Microsoft GDI Windows Metafile AttemptWrite integer overflow: Doesn't affect Windows versions with overhauled security.
2007-08-28: MSN Messenger and Windows Live Messenger webcam stream heap overflow: Did affect a Windows version with overhauled security (Vista only). Threat mitigated if security features used. Threat only present if user hadn't updated Windows Live Messenger for two years.
2007-09-12: Microsoft Windows Services for UNIX privilege escalation vulnerability: Did affect a Windows version with overhauled security (Vista only).
2007-10-30: Microsoft Kodak Image Viewer code execution vulnerability: Doesn't affect Windows versions with overhauled security.
2007-11-13: Microsoft Windows DNS Server vulnerable to cache poisoning: Doesn't affect Windows versions with overhauled security.
2007-12-12: Microsoft Windows Media Format Runtime ASF handling buffer overflow: Did affect a Windows version with overhauled security (Vista only).
2008-01-09: Microsoft Windows IGMPv3 and MLDv2 processing vulnerability: Did affect a Windows version with overhauled security (Vista only).
2008-03-20: Microsoft Windows fails to properly handle the NoDriveTypeAutoRun registry value: Did affect a Windows version with overhauled security (Vista only). Threat mitigated if security features used.
2008-09-09: Windows Media Encoder WMEX.DLL ActiveX Control buffer overflow: Did affect Vista, but only if users disabled new security features.
2008-12-11: Microsoft WordPad Text Converter vulnerable to remote code execution: Doesn't affect Windows versions with overhauled security.
2009-12-14: Microsoft Indeo video codecs contain multiple vulnerabilities: Doesn't affect Windows versions with overhauled security.
2010-06-10: Microsoft Windows Help and Support Center URI processing vulnerability: Doesn't affect Windows versions with overhauled security.
2011-10-11: Windows font library file buffer overflow: Did affect a Windows version with overhauled security (Vista and Win7).
2011-11-08: Microsoft Windows TrueType font array indexing vulnerability: Did affect a Windows version with overhauled security (Win7 only).

So there you go, a handful of those that affect Vista but not Win7, about half of those that did were removed or mitigated if you didn't disable UAC, and a whopping two that affected Win7. There are more listed vulnerabilities under the Linux section after the same cut-off date. So by your metric, Windows is safer than Linux now, right?

If higher market share leads to more security holes found and exploited or if more people look for and exploit those vulnerabilities, again, why the disparity on web servers? The only explanation is that GNU/Linux + Apache servers are genuinely more secure than Windows web servers.

What, exactly, does "That means more people will find the security holes that already exist, not that more security holes pop into existence from out of nowhere." mean to you? Does it mean anything to you at all? I'm serious, you appear to be having a complete reading comprehension fail with that sentence.

It's clear from your posts in other threads and this one that you don't like Microsoft, or at least Microsoft's products. That's fine, I have no strong love for them myself, but don't let your dislike of them make you blind to reality.

[Arariel]

But the major risks found under Microsoft and Windows are much more recent the ones found for GNU/Linux systems.

Sigh. Fine, I'll just go through all of them that came out after Vista, one by one. Spoilered for length.

Spoiler:

2007-07-10: Microsoft Windows Active Directory fails to properly validate LDAP requests: Doesn't affect Windows versions with overhauled security.
2007-07-10: Microsoft Windows Vista Teredo IPv6 interface firewall bypass vulnerability: Did affect a Windows version with overhauled security (Vista only). Threat not present if using a different firewall.
2007-07-27: Microsoft Windows URI protocol handling vulnerability: Doesn't affect Windows versions with overhauled security.
2007-08-14: Microsoft GDI Windows Metafile AttemptWrite integer overflow: Doesn't affect Windows versions with overhauled security.
2007-08-28: MSN Messenger and Windows Live Messenger webcam stream heap overflow: Did affect a Windows version with overhauled security (Vista only). Threat mitigated if security features used. Threat only present if user hadn't updated Windows Live Messenger for two years.
2007-09-12: Microsoft Windows Services for UNIX privilege escalation vulnerability: Did affect a Windows version with overhauled security (Vista only).
2007-10-30: Microsoft Kodak Image Viewer code execution vulnerability: Doesn't affect Windows versions with overhauled security.
2007-11-13: Microsoft Windows DNS Server vulnerable to cache poisoning: Doesn't affect Windows versions with overhauled security.
2007-12-12: Microsoft Windows Media Format Runtime ASF handling buffer overflow: Did affect a Windows version with overhauled security (Vista only).
2008-01-09: Microsoft Windows IGMPv3 and MLDv2 processing vulnerability: Did affect a Windows version with overhauled security (Vista only).
2008-03-20: Microsoft Windows fails to properly handle the NoDriveTypeAutoRun registry value: Did affect a Windows version with overhauled security (Vista only). Threat mitigated if security features used.
2008-09-09: Windows Media Encoder WMEX.DLL ActiveX Control buffer overflow: Did affect Vista, but only if users disabled new security features.
2008-12-11: Microsoft WordPad Text Converter vulnerable to remote code execution: Doesn't affect Windows versions with overhauled security.
2009-12-14: Microsoft Indeo video codecs contain multiple vulnerabilities: Doesn't affect Windows versions with overhauled security.
2010-06-10: Microsoft Windows Help and Support Center URI processing vulnerability: Doesn't affect Windows versions with overhauled security.
2011-10-11: Windows font library file buffer overflow: Did affect a Windows version with overhauled security (Vista and Win7).
2011-11-08: Microsoft Windows TrueType font array indexing vulnerability: Did affect a Windows version with overhauled security (Win7 only).

So there you go, a handful of those that affect Vista but not Win7, about half of those that did were removed or mitigated if you didn't disable UAC, and a whopping two that affected Win7. There are more listed vulnerabilities under the Linux section after the same cut-off date. So by your metric, Windows is safer than Linux now, right?

Considering how only about half of all Windows systems use Windows 7, I think unresolved issues with older versions of Windows are still an issue.

What, exactly, does "That means more people will find the security holes that already exist, not that more security holes pop into existence from out of nowhere." mean to you? Does it mean anything to you at all? I'm serious, you appear to be having a complete reading comprehension fail with that sentence.

It's clear from your posts in other threads and this one that you don't like Microsoft, or at least Microsoft's products. That's fine, I have no strong love for them myself, but don't let your dislike of them make you blind to reality.

That's not what you said earlier.

Everything has security flaws. I don't think any OS with as large a market share, with so many people that are functionally morons when it comes to security using it, as Windows could be made practically secure against these kinds of attacks. Such security methods are just an acknowledgement of such.

Where you seem to imply that Windows cannot be practically made secure because of market share.

I'm only saying market share is not the only reason why Windows is less secure. If more people trying to crack web servers are trying to crack GNU/Linux + Apache servers than people trying to crack Windows web servers, yet more damage is done to Windows web servers, it must mean GNU/Linux + Apache is more secure, right?

Anyway, despite the earlier article's age, http://www.theregister.co.uk/2004/10/22 ... monolithic still applies to Windows AFAIK.

[Goplat]

And I should reiterate, if a virus is capable of compromising my boot sector, it has already compromised another part of the system.

I think you're failing to understand what I'm explaining. Those base-system security holes are going to exist no matter what. Microsoft could spend the next 10 years working with the same codebase trying to secure it, and there would still be holes after they finished.

And yet somehow secure boot is a magic bullet against the virus making itself persistent? No way any of the hundreds of drivers and services that run on startup will ever be exploitable? We've already seen iOS jailbreaks that are persistent across reboots and that's on the platform with the most fanatical devotion to trusted computing there is. No reason a virus can't do the same.

[Ghostbear]

Considering how only about half of all Windows systems use Windows 7, I think unresolved issues with older versions of Windows are still an issue.

Which still isn't relevant for discussing modern versions of Windows. XP isn't secure. I haven't claimed otherwise. Yet, how secure XP is has no bearing on how secure Windows 7 [and by extension, Windows 8] is.

That's not what you said earlier.

Other than the three times I said it before.

Where you seem to imply that Windows cannot be practically made secure because of market share.

No system with that large of a market can be made perfectly secure in practice. Those statements are not in disagreement with each other.

I'm only saying market share is not the only reason why Windows is less secure.

And I'm saying that market share is going to exacerbate any vulnerabilities in systems. The greater the market share disparity (65:35 vs 84:fuckall is a huge disparity in disparities), the greater this effect. How different are the code bases for the server and desktop versions? I'd expect there's quite a bit of shared code. In which case, you can't compare the server market shares to prove your point: you'd have to compare desktop+server vs. desktop+server for each. Which is one where Windows would, again, be in a crushingly huge market size advantage.

Anyway, despite the earlier article's age, http://www.theregister.co.uk/2004/10/22 ... monolithic still applies to Windows AFAIK.

Not really. Essentially all of the examples of stuff being too integrated into windows (IE, Outlook, video drivers) no longer suffer from such. I'd say Linux is built more secure, but the difference is Windows is constantly being told where it is insecure. They have a good routine now for how to handle new vulnerabilities, and they've gotten quite good at plugging them up and testing for new ones. Linux also some has nice advantages for certain groups, in that they can roll out their own security updates if the OS vendor fails to roll out their own. Constantly having your defenses tested is still a great way to get them improved though. OSX is built on something else that was Unix-based, yet many security experts will say it has far, far worse security than Windows 7.

And yet somehow secure boot is a magic bullet against the virus making itself persistent? No way any of the hundreds of drivers and services that run on startup will ever be exploitable? We've already seen iOS jailbreaks that are persistent across reboots and that's on the platform with the most fanatical devotion to trusted computing there is. No reason a virus can't do the same.

I would invite you to read the multiple times I have explained what secure boot would be accomplishing. They're all in this thread. Secure boot is not meant to be a silver bullet. It's supposed to make it so that targeting the boot sector is now a significantly more difficult task -- accomplishing it will take far more work than it does now. Considering that that's one of the worst places for an infection to hit, that sounds quite useful. I don't think it's worth the external damage (making it difficult to install Linux and such), but it's not some imaginary security improvement either.

[somebody already took it]

Say I have a electronic design automation tool which I use to simulate a computer's circuitry. Do you think it is possible to make the simulated computer to infect the simulating OS with a virus?

None of the simulated data on it is going to be outputted in a form that, in memory, would be usable for an infection. I certainly can't think of any I've encountered yet that would even output that kind of data at all, regardless of the format it's in for the actual computer. Also, a simple* simulation program is a trivial system to sandbox. I don't think you're getting the complexity difference between "individual program" and "modern operating system".

* Simple here is defining the actual run process of the program. The code itself is, undoubtedly, going to be rather complex.

What if the simulation program is simulating a computer running the OS?
Do you still believe:

The sandbox won't be perfect. That's the point. No matter how hard they try, unless it's dealing with an absurdly simple system (i.e. not an operating system) it's always going to have a flaw. Beyond that, you're acting as if sandboxing is some universal cure-all to protect against infections. It isn't.

[Ghostbear]

Say I have a electronic design automation tool which I use to simulate a computer's circuitry. Do you think it is possible to make the simulated computer to infect the simulating OS with a virus?

None of the simulated data on it is going to be outputted in a form that, in memory, would be usable for an infection. I certainly can't think of any I've encountered yet that would even output that kind of data at all, regardless of the format it's in for the actual computer. Also, a simple* simulation program is a trivial system to sandbox. I don't think you're getting the complexity difference between "individual program" and "modern operating system".

* Simple here is defining the actual run process of the program. The code itself is, undoubtedly, going to be rather complex.

What if the simulation program is simulating a computer running the OS?
Do you still believe:

The sandbox won't be perfect. That's the point. No matter how hard they try, unless it's dealing with an absurdly simple system (i.e. not an operating system) it's always going to have a flaw. Beyond that, you're acting as if sandboxing is some universal cure-all to protect against infections. It isn't.

I went ahead and bolded and underlined the relevant parts of my quotes that you are ignoring. Making the program's internals more complex doesn't make it harder to cordon off that individual program from the rest of the OS. The differences between that an OS sandboxing everything are enormous. There is no need for that program to send out data other that display information: it doesn't need to interact with anything besides the simplest I/O systems, and for most of those it only needs to take data IN, but not OUT.

With an OS, there are, first of all, a huge number of different things that would need to be isolated. Right now, there are 79 processes and 935 threads running on my computer. Do you sandbox every process, every thread? What happens when components need to interact with each other? What about higher system processes that have the sole purpose of interacting with other things? Do you give up on any thought of memory sharing and not let two tasks both interact with the same dll, but instead need it to be loaded into RAM twice? There are a huge number of interactions that you need to concern yourself with when dealing with this on an OS scale, while an individual program does not need to worry about that on anywhere near that scale. When you make a system more complex, when you give it more interactions, more fail points, you'll eventually reach a point where it is too complicated to make it perfect. And to top it all off, you're still treating sandboxes as some magical "no malware ever again! HOORAY!" solution. It really isn't. Why do you keep pretending it is?

The data will still not be formatted properly either.

[somebody already took it]

Right now, there are 79 processes and 935 threads running on my computer. Do you sandbox every process, every thread? What happens when components need to interact with each other?

Ah, I think this is where we're miscommunicating. I'm talking about running the OS in a virtual machine, not sandboxing individual processes.

Edit:
Also, let me state the argument this fits into because it is getting a bit tangential:
It shouldn't be necessary to restrict access to the boot process because it is possible to run the Windows in a virtual machine which would make it impossible for any security flaw in the Windows guest OS to compromise the boot process of the physical machine.

[Ghostbear]

It shouldn't be necessary to restrict access to the boot process because it is possible to run the Windows in a virtual machine which would make it impossible for any security flaw in the Windows guest OS to compromise the boot process of the physical machine.

There's still quite a few problems with that:
(1) Virtual machines run slower than native machine. To get that slowdown minimized, you're going to need an enterprise class VM. Those are not cheap; paying to include one for every licence of Windows would be absurdly expensive. It would also be absurdly expensive for Microsoft to build one from the ground up.
(2) From my understanding of VMs, getting them to interact with the hardware is still fairly complicated, and I could see that being prone to having potential vulnerabilities.
(3) The actual VM itself is still going to need to be booted to, it's still going to need updates, and it's still going to need drivers et. all for interacting with the hardware itself. Whatever method you give it to do such (internet, allowing the VM'd OS to apply those updates somehow, USB drives, etc.) is going to introduce a vulnerability where that VM can be attacked. Some of them would remove the principal security advantage in this context (no ability to interface with anything that can change the boot sector), most of the others would just be a ginormous headache for users, and last one (internet) would pose its own potential security issues.
(4) It would still likely be vulnerable to USB based infections as well.

I expect the future is going to entail a switch to VMs, and in a big way. We aren't there yet though, and it's still not a perfect security cure-all. At the end of the day something needs access to the boot loader, and that thing is going to be complicated enough for it to have its own weaknesses.

[Arariel]

Other than the three times I said it before.

Let me be more clear: It's not what you said at first.

No system with that large of a market can be made perfectly secure in practice. Those statements are not in disagreement with each other.

Perhaps not, but some systems are more secure and can be made more secure than others.

And I'm saying that market share is going to exacerbate any vulnerabilities in systems. The greater the market share disparity (65:35 vs 84:fuckall is a huge disparity in disparities), the greater this effect. How different are the code bases for the server and desktop versions? I'd expect there's quite a bit of shared code. In which case, you can't compare the server market shares to prove your point: you'd have to compare desktop+server vs. desktop+server for each. Which is one where Windows would, again, be in a crushingly huge market size advantage.

Then what about just the server software itself, Microsoft IIS, I believe? Apache has a larger market share than IIS by some margin, yet more IIS exploits are found and exploited more often. Furthermore, that's only relevant if we're discussing intrusion by malware. What about targeted attacks by crackers? Would you say a cracker would have a tougher time getting into a Windows + IIS server or a GNU/Linux + Apache server?

Not really. Essentially all of the examples of stuff being too integrated into windows (IE, Outlook, video drivers) no longer suffer from such. I'd say Linux is built more secure, but the difference is Windows is constantly being told where it is insecure. They have a good routine now for how to handle new vulnerabilities, and they've gotten quite good at plugging them up and testing for new ones. Linux also some has nice advantages for certain groups, in that they can roll out their own security updates if the OS vendor fails to roll out their own. Constantly having your defenses tested is still a great way to get them improved though. OSX is built on something else that was Unix-based, yet many security experts will say it has far, far worse security than Windows 7.

Windows still integrates its components pretty heavily. That's one of their strategies for ensuring IE never dies, after all, which is definitely something that can potentially cause exploitable bits in Windows.
And again, GNU/Linux systems have been fairly popular among servers. I don't believe OSX has been used much for any actual serious computing (by the way, OSX is actually built on a Unix system and is a Unix system itself). So GNU/Linux systems should have had their security tested for quite a while by now.

[Ghostbear]

Let me be more clear: It's not what you said at first.

The two statements you are highlighting do not conflict with each other.

Perhaps not, but some systems are more secure and can be made more secure than others.

I have never denied this. I am not sure what relevance it has at all to your insistence that nearly all of Windows' found vulnerabilities can not be explained in large part by marketshare disparities.

Then what about just the server software itself, Microsoft IIS, I believe? Apache has a larger market share than IIS by some margin, yet more IIS exploits are found and exploited more often. Furthermore, that's only relevant if we're discussing intrusion by malware. What about targeted attacks by crackers? Would you say a cracker would have a tougher time getting into a Windows + IIS server or a GNU/Linux + Apache server?

You appear to have intentionally ignored the entire beginning of the quoted text of mine: "The greater the market share disparity (65:35 vs 84:fuckall is a huge disparity in disparities), the greater this effect [exacerbation of vulnerabilities]." The differences in those margins between those two markets is enormous. I don't see how you can't understand the differences between "the leader in this market is about twice as big as the next up" and "the leader in this market is about 17 times bigger than the next up". In one of those situations, the market sizes aren't far enough apart that people will predominantly attack one platform no matter what. In the other situation, the market sizes are far enough apart that they will do exactly that.

Windows could be the single most secure OS (and worth using on a massive scale, I should hasten to add) ever developed in the history of ever, and it would still have the most vulnerabilities found for it, solely because of how big its market share is compared to the competition. There is just too huge an incentive in attacking Windows compared to the alternatives with the current market balance.

And again, GNU/Linux systems have been fairly popular among servers. So GNU/Linux systems should have had their security tested for quite a while by now.

They have not been tested on anywhere near the same scale. The underlying architecture is almost certainly more secure, as it was built from the ground up in ways that favor being more secure. Due to the extent to which Windows NT has had its vulnerabilities constantly prodded and poked and exploited for over a decade, and in no small fashion, is goes a huge way to bridging that gap. Linux could still be more secure overall, but the differences are going to be small enough that you can't attribute much to that. Marketshare is king in this comparison; it drowns out all other factors.

[KnightExemplar]

Actually... based on what I've been reading on some vulnerabilities, Windows seems to also get a larger share of hate.

IE: the title of this article reads Safari opens up Vulnerability in Windows.

But Linux users tend to be more specific when vulnerabilities are discovered. IE: SQL Injection discovered in PhpMyAdmin (a far far more serious threat than the previous one, especially in a server environment).

Is the latter a "Gnu/Linux" problem? Or is it isolated to PhpMyAdmin? What about all of the absolutely critical PHP Bugs that have been discovered over the years? Are these Gnu/Linux or isolated to PHP?

Part of the apples and oranges comparison here is how unified a Window stack is compared to Linux. And indeed, an application built on ASP.NET / C# / SQL Server / Windows Stack is invulnerable to SQL Injection due to LINQ... and also invulnerable to PHP Include attacks because C# isn't PHP (duh).

Both Linux and Windows have their vulnerabilities, and both have more than enough security measures to lock themselves down. Its the job of the security analyst to actually lock down your network... and any security analyst worth their salt ain't gonna care about Linux vs Windows. Both are damn insecure in their default form, and anyone who thinks otherwise is going to get a rude awakening. Hell, the last major attack was on what? Sony Playstation 3 hack that stole some millions of Credit Cards?

What were they running? Apache on Linux.

[Ghostbear]

Going with KnightExemplar's line of thought: it's interesting to note that almost 30% of the logged crashes for Vista in its first year after release were caused by a single company.

NVIDIA, and their inability to make drivers that operated properly in the new driver model, were a greater source of Vista crashes than Microsoft was. If you add in Intel and ATI, you get nearly half of the crashes to Vista being caused by poorly written drivers. Yet Microsoft got all of the blame for that. Security vulnerabilities isn't too different; how many threats are created by Adobe in Flash/Acrobat, or Java, or your web browser? Those seem to be the most common ones I read about, and are almost certainly issues that would have cropped up on another OS if it were the dominant one instead.

[Dark567]

Hell, the last major attack was on what? Sony Playstation 3 hack that stole some millions of Credit Cards?

What were they running? Apache on Linux.

Off-topic:

Spoiler:

Dr. Spafford told congress that Sony were not using a Firewall, which heightened the security risk

Da Fuq? Seriously that's like the most basic line of security.

Although I would like to get more details.... How does hacking a web server get you PCI data? Any connections should terminate there and not propagate without more auth.

[Arariel]

The two statements you are highlighting do not conflict with each other.

Very well, then.

I have never denied this. I am not sure what relevance it has at all to your insistence that nearly all of Windows' found vulnerabilities can not be explained in large part by marketshare disparities.

Of course some of Windows's found vulnerabilities are caused by market share. But not all, and maybe not even most; who know? But I have commonly heard people say if X operating system were as popular with Windows, it would be just as insecure, which is certainly not guaranteed to be true, which is what I thought you were saying.

You appear to have intentionally ignored the entire beginning of the quoted text of mine: "The greater the market share disparity (65:35 vs 84:fuckall is a huge disparity in disparities), the greater this effect [exacerbation of vulnerabilities]." The differences in those margins between those two markets is enormous. I don't see how you can't understand the differences between "the leader in this market is about twice as big as the next up" and "the leader in this market is about 17 times bigger than the next up". In one of those situations, the market sizes aren't far enough apart that people will predominantly attack one platform no matter what. In the other situation, the market sizes are far enough apart that they will do exactly that.

Windows could be the single most secure OS (and worth using on a massive scale, I should hasten to add) ever developed in the history of ever, and it would still have the most vulnerabilities found for it, solely because of how big its market share is compared to the competition. There is just too huge an incentive in attacking Windows compared to the alternatives with the current market balance.

Of course, but there should be more people searching for Apache vulnerabilities than IIS vulnerabilities regardless, even if Apache only has twice as many users as IIS. If more people than 35% or so are targeting IIS, it must be because it's easier to crack, which means it's less secure. But I only brought that up as an example of a case where less popular software suffers more vulnerabilities.

They have not been tested on anywhere near the same scale. The underlying architecture is almost certainly more secure, as it was built from the ground up in ways that favor being more secure. Due to the extent to which Windows NT has had its vulnerabilities constantly prodded and poked and exploited for over a decade, and in no small fashion, is goes a huge way to bridging that gap. Linux could still be more secure overall, but the differences are going to be small enough that you can't attribute much to that. Marketshare is king in this comparison; it drowns out all other factors.

I see. I misinterpreted what you were saying. But I would disagree with the differences being small. The inherent security differences may be small compared to market share factors at current state, but at a higher usage rate, they would probably have a significant effect.

Actually... based on what I've been reading on some vulnerabilities, Windows seems to also get a larger share of hate.

IE: the title of this article reads Safari opens up Vulnerability in Windows.

But Linux users tend to be more specific when vulnerabilities are discovered. IE: SQL Injection discovered in PhpMyAdmin (a far far more serious threat than the previous one, especially in a server environment).

Is the latter a "Gnu/Linux" problem? Or is it isolated to PhpMyAdmin? What about all of the absolutely critical PHP Bugs that have been discovered over the years? Are these Gnu/Linux or isolated to PHP?

Well, there seems to be several differences here:
1. The Windows vulnerability is a consumer vulnerability, while the phpMyAdmin one only directly affects people with SQL databases.
2. phpMyAdmin is cross-platform, so this isn't strictly a GNU/Linux vulnerability. Evidently the Safari vulnerability doesn't affect Mac OS X, otherwise they would have said.
3. The blog post was from 2011, and the latest version affected by that vulnerability was in 3.0.1.1. phpMyAdmin 3.1 was released on 28 November 2008. In contrast, the affected Safari version was the current running version.

I've also noticed many GNU/Linux vulnerabilities are only noticed for earlier versions. Most GNU/Linux desktop/consumer users keep all software up to date, which is really easy. This would probably explain why found vulnerabilities aren't exploited much. I think the only time I've heard of a GNU/Linux vulnerability for a running version was a Debian vulnerability mentioned earlier, but that was big news.

Both Linux and Windows have their vulnerabilities, and both have more than enough security measures to lock themselves down. Its the job of the security analyst to actually lock down your network... and any security analyst worth their salt ain't gonna care about Linux vs Windows. Both are damn insecure in their default form, and anyone who thinks otherwise is going to get a rude awakening. Hell, the last major attack was on what? Sony Playstation 3 hack that stole some millions of Credit Cards?

What were they running? Apache on Linux.

Of course, if you have a bad sysadmin, it really doesn't matter what system you're running, you're screwed either way. Which is what Sony had. They didn't patch their servers, and apparently they didn't even have a firewall? Anyone could see that was a recipe for disaster.

However, that doesn't mean a sysadmin shouldn't care whether it's GNU/Linux or Windows or that a sysadmin should be equally competent with either. Just because a bad sysadmin can screw up equally badly on either system doesn't mean a good sysadmin can work equally well with either. And when you have a vulnerable system, it's probably not a good idea to not fix it when everyone knows about it...

Dr. Spafford said that Sony had not only known about these vulnerabilities on their systems but had also known that this information was in the public domain, as security experts monitoring internet forums said it had been reported in an open forum, which was apparently monitored by Sony employees, 2 – 3 months ago.

[Ghostbear]

Of course some of Windows's found vulnerabilities are caused by market share. But not all, and maybe not even most; who know? But I have commonly heard people say if X operating system were as popular with Windows, it would be just as insecure, which is certainly not guaranteed to be true, which is what I thought you were saying.

I had to hunt for it to get a link, but my original post was that any OS with as large a marketshare as Windows is just not going to be able to be made perfectly secure.

Of course, but there should be more people searching for Apache vulnerabilities than IIS vulnerabilities regardless, even if Apache only has twice as many users as IIS. If more people than 35% or so are targeting IIS, it must be because it's easier to crack, which means it's less secure. But I only brought that up as an example of a case where less popular software suffers more vulnerabilities.

Right, but my point was that that's a poor counter-example with Windows' OS marketshare. Hitting "just" 35% of a market isn't bad at all for security breaches; with the difference in size between the Apache and MS, that size difference isn't going to be the sole concern, because the smaller party is "big enough". In operating systems, this isn't really true: if you target the next largest market after Windows, you get a positively puny market, and since you rely on infected computers to spread the infections, you'll want a minimum marketshare before seriously considering going after one.

This is why Apple has been able to get away with their rather terrible security; despite being a far better target in all other aspects than Windows -- Apple's users don't consider the chances for infection, Apple's users tend to be less tech savvy, Apple's users tend to be wealthier, the underlying software is less secure, and Apple themselves have no proper readiness for infection issues cropping up -- despite that, MS still gets the brunt of all of the attacks, because it's just so insanely more worthwhile for the attackers to go after it. If OSX jumped to 20-30% marketshare without those above problems being fixed, you could bet a silver cookie that they'd be under a huge barrage of infections in short order.

I see. I misinterpreted what you were saying. But I would disagree with the differences being small. The inherent security differences may be small compared to market share factors at current state, but at a higher usage rate, they would probably have a significant effect.

At higher marketshare that's entirely possible, and I'd lean towards agreeing. I'm talking about as things stand now though.

I've also noticed many GNU/Linux vulnerabilities are only noticed for earlier versions. Most GNU/Linux desktop/consumer users keep all software up to date, which is really easy. This would probably explain why found vulnerabilities aren't exploited much. I think the only time I've heard of a GNU/Linux vulnerability for a running version was a Debian vulnerability mentioned earlier, but that was big news.

This is actually a great example of where marketshare has a big impact. Since Linux isn't a valuable target, vulnerabilities get ignored and are left undiscovered for years -- by the time the hole is found, no one is using that version anymore. That wouldn't stay true with a dominant market position though.

[Arariel]

I had to hunt for it to get a link, but my original post was that any OS with as large a marketshare as Windows is just not going to be able to be made perfectly secure.

I see now, I just misinterpreted it slightly, since the more common argument I've heard is that the market share was the only reason why Windows is insecure.

This is actually a great example of where marketshare has a big impact. Since Linux isn't a valuable target, vulnerabilities get ignored and are left undiscovered for years -- by the time the hole is found, no one is using that version anymore. That wouldn't stay true with a dominant market position though.

I would actually say this is the difference in analogising the security of Mac OS X and GNU/Linux systems. GNU/Linux systems are probably actually more important than Mac OS X systems since they tend to be deployed in enterprise situations more frequently. In contrast, Mac OS X is a primarily consumer operating system (I've honestly never heard of a Mac OS X system being used in an enterprise environment or other serious computing work). A cracker making targeted attacks would probably find more valuable GNU/Linux systems than Mac OS X systems. But the example KnightExemplar brought up was a phpMyAdmin vulnerability, something used with MySQL, which is fairly popular (even more popular than Microsoft's SQL software, IIRC), and the Sony cracks were on an unpatched Apache server, which are dominant. These are popular pieces of software, yet the majority of vulnerabilities are only discovered after they have already been patched and the vulnerability removed. Given that, if GNU/Linux became more popular on the desktop, I doubt much would change.