Microsoft, Once Infested with Security Flaws, Does an About-Face
nytimes.com
nytimes.com
Windows wasn't originally designed to be secure. Even NT, which is a serious multi-user kernel, was a product of 1990s C programming style. And while that's true of the Unices of the time as well, none of them had Microsoft's absurd user base, and so none of them had the same terrible malware incentives.
This all came to a head around 2001-2003, when the Internet worm phenomenon got so bad that Microsoft was routinely on the front page of CNN, and serious talk of congressional action began.
From what I understand, there was a dramatic top-down response, led by Gates and Ballmer, requiring software security training for developers, giving product managers the power to slip release dates to ensure bugs were caught, and funding what I believe is probably the largest 3rd-party software pentesting program in the industry. Several well-known software security firms (my old firm, Matasano, not really among them) were basically bootstrapped out of Microsoft contracts.
Today, Google probably does a better job on software security than Microsoft does, but it's hard to come up with another rival. Tellingly, Google's security efforts were also a top-down reaction to a major security incident.
That being said: A lot of Android's security issues are not always Google's fault. Some of them are in generic Linux libraries, some of them are in OEM added components (Samsung), and some of them are security issues unique to an app ecosystem (i.e. on Windows Win32 user applications normally have full permissions as that user, on Android an APK running as a user has a limited set of permissions, if it exceeds those permissions this is now an "exploit" which is now an additional set of security issues), and many are simply malware being placed on an app store.
Android's biggest issue isn't really that it is poorly designed (in particular with SELinux as standard). Android's biggest issue is how horribly the OS update mechanism works, so relatively minor security issues may not be fixed for years.
I think these mostly are Google's fault. They chose those Linux libraries and implemented them; they certainly have the resources to modify them, to otherwise secure them, or to develop their own. They are producing an OS not for a laboratory but for the real world where there are OEM components, app ecosystems, and malware. Dealing with those issues is an essential part of what an OS does. If you build a ship that works fine in calm weather but sinks when a storm hits, the problem is not the weather.
But is the cutting edge comparison really that much more skewed in Apple's favor?
I'd say that prior to the improvement on patch cycles as of recent in Android - iOS had an edge, but - outside of the walled garden I'm still very curious on the quality between the two with specific regard to the SDLC and resulting output.
I think it's more to do with the development culture inside Apple. The features in Swift designed to improve secure coding shows you they're actively thinking about secuirty and how to achieve it, and have been for a while.
The only regular security headlines you see about the Mac is in the Pwn2Own contest and their like, where researchers trot out vicious exploits that are then dutifully squashed by Apple in the next update, never to be seen in the wild. (And there's a reason Apple makes it a PITA to install Flash and Java these days, and includes their own very nice .pdf reader.)
Second, retail-level malware is a numbers game. Malware isn't cross-platform. A malware author chooses their target based on how remunerative the target is. Windows remains more remunerative than OS X.
There is no fundamental difference between the security models of modern Windows and OS X that accounts for the disparity in malware infections.
(I'm a Mac user, and have been since ~2001.)
Umm no - the update situation is better on iOS but fundamentally iOS has bigger problems - https://twit.tv/shows/security-now/episodes/532?autostart=fa... . That problem is unfixable easily due to the way ObjC works. Android gets code access control for free with Java. There have always been Jailbreaks for most iOS versions and it's not like they haven't had other security issues. The ability to fix them quickly is certainly an advantage but there is nothing in iOS that is fundamentally more secure than anything else on the market.
Frankly I think Apple's security is a combination of happenstance and restrictive policies - I don't think they care (yet) about the processes, infrastructure and people required to do what Google and Microsoft do. (No offense to the good security people at Apple - this isn't about them, this is about having organization wide security focus like MS needed to turn around Windows.)
>"There was significant growth in Android malware, which currently consists of 97 percent of all mobile malware developed. In 2014 alone, there were 1,268 known families of Android malware, which is an increase of 464 from 2013 and 1,030 from 2012", it said.
Apple’s iOS, on the other hand, went through last year basically unscratched. The report said that there were just four iOS targeted attacks in 2014, and the majority of those were designed to infiltrate jailbroken devices.
If you want to talk impacts - both iOS and Android have been similarly impacted - big name apps getting into App Store that were compiled by hacked XCode, Ad SDKs using forbidden APIs etc. Likewise most Android malware is due to rooting and side loading apps from questionable sources.
Remember that Android is a lot of things - there are Nexus phones, there are OHA OEM phones (majority of them), there are Chinese no name phones that use open source Android etc. So if most Chinese people use AOSP build provided by their phone maker and they all sideload apps and get infected - that's different. Even considering all this nobody is making the above statement.
Just having malware written for an OS means nothing. It only suggest that it is targeted more due to market share. If people jailbreak their iPhones and install random apps from untrusted sources there is hardly anything Apple's security can do to prevent it. Same goes for Android. Nothing in that reflects the security of the underlying platform.
Can you explain that?
Some apps were exploiting this to get a list of running apps and things like that.
I would have thought you will research it a bit before asserting silliness - but oh well.
The "receivers that they don't want you to" on iOS is not about security, but correctness, binary compatibility, and app store guidelines. iOS's security model is not defeated by bypassing the ObjC runtime.
On both platforms, these security policies are enforced at the process boundary, not by the runtime.
See https://www.usenix.org/system/files/conference/usenixsecurit... for details of how to write an app that bypasses App Store review but will have security holes that allow your app to access APIs at runtime with no notification that it was not supposed to have access to.
I certainly don't understand characterizing iOS's security model as "ordinary." For example, it encrypts using a separate coprocessor running an entirely separate OS, that is protected against even an iOS kernel exploit. That's definitely not an ordinary design!
Retrieving the application list is a particularly poor example as there used to be a public API that did exactly that: CFPreferencesCopyApplicationList
You should read Apple's iOS Security Whitepaper: http://www.apple.com/business/docs/iOS_Security_Guide.pdf See for example the data protection classes: a very thoughtful design, with no analog in Android, and that certainly could not have come about by "happenstance."
Heck, Android doesn't even encrypt your data by default! That alone makes iOS "fundamentally more secure."
You keep repeating that but I am certain you don't understand what you are talking about. Go download the Android SDK, emulator and write an app that does that and post it on Github We will talk about it then.
Also - I'll leave this here - http://www.macrumors.com/2015/10/19/apple-to-remove-hundreds...
Here's a sample of how to invoke `Activity.savedDialogKeyFor`, which is private:
Method privateMethod =
Activity.class.getDeclaredMethod("savedDialogKeyFor", int.class);
privateMethod.setAccessible(true);
String result = (String)privateMethod.invoke(this, 42);
System.out.println("Got result: " + result);
> Also - I'll leave this here
What's your point? There was no security exploit here, and no security policy can realistically prevent networked apps from sharing data like your email address. That falls to the review process.
What's remarkable here is how little data this malware was actually able to capture. Certainly less than on Android, where users routinely grant excessive permissions, like giving Netflix access to your phone.
Edit: Also my larger point was the iOS security is not fundamentally better than anything else. The closed nature, restrictive policies etc. help but fundamentally it's nothing outstanding. It was a response to tptacek claiming opposite.
You asserted that iOS is "unfixable" because the ObjC runtime cannot prevent apps from using "private/internal calls that your app is not supposed to use," whereas "Android gets code access control for free with Java."
But as I showed, Java access controls are easily bypassed, so they do not provide any security. This is by design: security is enforced at the process boundary, not by the runtime.
My hope is that you now appreciate that neither the ObjC nor Android Java runtimes are a security risk, because they are not responsible for enforcing any security policy.
> Also my larger point was the iOS security is not fundamentally better than anything else
iOS security is fundamentally better. You can read the whitepaper to understand the ways: data protection classes, the Secure Enclave, and lots more.
But here's a damning fact: iOS encrypts your data by default, Android does not. That by itself makes iOS fundamentally more secure.
What you are not understanding or ignoring is that iOS apps (over 250) that were App Store approved were able to retrieve personal user data including email addresses by reverse engineering the names of the private APIs and using message passing. Android sure has private APIs and you can access those but you're still restricted to the permissions you asked for. For example you need to declare android.permission.GET_ACCOUNTS permission to get the user's primary email. Not on iOS apparently where they rely on manual review to ensure you are not calling the Private API - which fails as can be seen in the Chinese AD SDK fiasco I posted.
So no Android runtime isn't a security risk as much as iOS private APIs are - your app gets a broad set of permissions on iOS by default and you can do clever trickery to call private APIs to collect personal info and who knows what else without the user knowing. Android needs your app to ask for that permission first (and at runtime on M)- you aren't calling a private method on Android without declaring the necessary permission to get what you want without user interaction.
I have read it. It describes an attack on the app review process, i.e. a trojan. Their apps require the user to grant privileges. For example, their GreetingCard app requests access to the user's address book, and the user has to grant it.
> iOS apps (over 250) that were App Store approved were able to retrieve personal user data including email addresses
This is not true. Here's the blog: https://sourcedna.com/blog/20151018/ios-apps-using-private-a...
The data they collected was list of installed apps, serial numbers, and some sort of AppleID numeric identifier. In particular, they did not (could not) collect email addresses.
It's bad that the SDK was collecting this stuff, but this data is fairly innocuous. Last I checked, Android provides information like the list of installed apps and various serial numbers without requiring elevated permission.
If you think it's possible to get the user's email address through an iOS private API, I challenge you to tell me what that private API is.
> For example you need to declare android.permission.GET_ACCOUNTS permission to get the user's primary email. Not on iOS apparently
This is wrong. On iOS, the only way to access the user's email is through the Address Book framework, which prompts the user at the time of access.
> your app gets a broad set of permissions on iOS by default
This is completely false. iOS has a comprehensive on-demand permissions model, which is widely recognized as better than the install-time permission model on Android. This is why Android is switching to iOS style on-demand permissions in Marshmallow.
> you aren't calling a private method on Android without declaring the necessary permission
Please stop confusing private methods with elevated permissions. You CAN call private methods without elevated permissions, as my code above demonstrates.
[Edited for unnecessary stuff]
Oh the article you linked has Apple response that is quoted verbatim below - it references user email addresses. Specifically.
“We’ve identified a group of apps that are using a third-party advertising SDK, developed by Youmi, a mobile advertising provider, that uses private APIs to gather private information, such as user email addresses.."
> Please stop confusing private methods with elevated permissions. You CAN call private methods without elevated permissions, as my code above demonstrates.
What I wrote was you are not going to be able to call an Android API via private invocation and succeed if the API requires a specific permission and your app hasn't declared it.
All of this only goes to prove that Apple's security in iOS is not extraordinary as you claim - it is fallible like every other platform except with the exception of fingerprints which are currently believed to be secure - but that's now the case with Android as well - in M they are using ARM Trust Zone with no app access.
> What I wrote was you are not going to be able to call an Android API via private invocation and succeed if the API requires a specific permission and your app hasn't declared it
Just like on iOS, with the difference that it happens at call time and not installation time.
> All of this only goes to prove that Apple's security in iOS is not extraordinary as you claim
It shows the exact opposite! Notice how ridiculously weak these results are. On one of the most high-profile targets today, an app may (unconfirmed) be able to determine the user's email address and send it to a server. On a trojan app that the user deliberately installed, and then deliberately granted access to Twitter, it can post a tweet without the user's confirmation, if the user has not updated the OS. Fetch the smelling salts!
Meanwhile, millions of Android phones are part of botnets, like NotCompatible.C, at one point reaching 1.5% of mobile devices in the USA. A Chrome 0-day came out last week, allowing full control remotely of fully-patched Android phones. These aren't research papers showing theoretical attacks, this is real life.
Yes, iOS has extraordinary security, and its competition only makes it look better.
/jeez why do I bother with Apple fanboys?
What was that? All I can think of is when the chinese stole their source code but the response to that would presumably be more about managing who has access to what internally than improving the security of their user facing products.
edit: to be clear I'm thinking of the time they had code stolen by a chinese employee in their china office, presumably on request of the govt.
https://www.usenix.org/conference/lisa13/enterprise-architec...
Unfortunately, other than the default full disk encryption it's pushing on Android 6+ devices, I'm not really seeing Google push client-side encryption anymore. I wonder if it even wants the E2E email extension to be fully developed anymore. And even though it should be quite trivial for Google to adopt Signal's text and voice encryption in Hangouts, I doubt it has any intention of ever doing that.
[1] http://apps.washingtonpost.com/g/page/world/what-yahoo-and-g...
[0] http://arstechnica.com/tech-policy/2013/10/new-docs-show-nsa...
> The US National Security Agency and Federal Bureau of Investigation have been harvesting data such as audio, video, photographs, emails, and documents from the internal servers of nine major technology companies, according to a leaked 41-slide security presentation obtained by The Washington Post and The Guardian.
Google is in that list. Granted, this did not demonstrate full access to all of Google's internal communications, but the category of "audio, video, photographs, emails, and documents" is broad and damaging enough that it doesn't really matter if NSA had full access or not.
And yes, I know that Google and all the other major companies vigorously denied any back doors, but as people were saying at the time on this very forum they didn't have any other realistic or legal choices. The President of the United States himself was saying things like: "You can't have 100% security, and also then have 100% privacy and zero inconvenience", which, if you were a smart enough CEO, was a very good hint about what to do and say in the heat of the moment.
Did they really turn it around that fast, in one iteration of Windows (XP was released 2001, Vista in 2007)? I would think that fixing bugs would be necessary but not nearly sufficient, and they would have had to re-architect and re-develop major parts of the system. And Microsoft needed to do that while maintaing the backward compatibility that is a major selling point and pushing products out the door quickly enough to generate revenue.
It sounds like a nightmare, and not acheivable in 4 years. My impression was that many bugs were fixed but there wasn't a major redesign, which always made me doubt how secure Windows could be.
f = open('C:/windows/test.txt')
try:
f.write('test')
print ex
In my particular legacy-apps' field, I believe most problems are due to interactions with the DCOM subsystem though.
I assumed it was just an interface stapled onto the old system, and something underneath that allowed changing permissions without logging off.
It might have had a big effect, but it doesn't sound like a significant change in the system. But maybe my assumptions are wrong ...
So you could run as a non privileged users, and you'd only need to log in as Administrator for some very specific tasks.
However, there were many applications that didn't play nice with that model and required you to run as Administrator. By changing the default, MS had to do a big push to make software makers abide by the rules (which had been in place since XP (edit: in the mainstream branch) but were often ignored)
Vista introduced a model that was almost as good, but made it more user-friendly and the default.
Windows 7 has the same permissions model as Vista, but has a much better reputation, because by the time 7 was released, applications had been updated to not require as much in the way of permissions. From the users perspective, this meant that 7 "worked properly", even though little had changed in terms of the security model between Vista and 7.
I'm conflating processor date with date-you-could-buy-a-computer-with-that-chip, but still: Pentium 4 is a world away from Core. Windows Vista does a lot more than XP.
The complaints went away because people gradually bought computers with Core architectures.
Microsoft has a program where they certify that hardware will work acceptably with their operating systems. This is important in the run-up to a new version of Windows, because during the period when everyone knows that Windows X+1 is coming soon but all you can buy off the shelf are machines with Windows X, people want to be confident that they'll be able to upgrade to Windows X+1 when it's available.
For Vista, if your machine passed this certification, you got the right to ship it with a shiny sticker that said "Vista Ready." Seeing the "Vista Ready" sticker on that XP laptop on the shelf at Best Buy told customers that they could buy it without fear. It was certified future-proof.
However, Vista required more resources than XP did to run with acceptable performance. That meant that OEMs had a ton of ultra-cheap XP machines in the pipeline that could not with a straight face be called "Vista Ready." And this was a problem, because they didn't want to get stuck with warehouses full of machines nobody would buy because they couldn't run Vista.
So what they pushed for, and what MS eventually gave them, was a new certification: "Vista Capable." Unlike "Vista Ready," "Vista Capable" didn't mean Vista would run well on the hardware in question. It just meant you could install Vista on it, with no guarantees as to how it would actually run. And the shiny "Vista Capable" sticker looked pretty much exactly like the shiny "Vista Ready" sticker, so if you weren't looking carefully, it was easy to confuse the two.
The OEMs loved this solution, because they could now slap "Vista Capable" stickers on all those crappy XP machines and unload them on people. But, entirely predictably, then Vista came out and suddenly tons of people were installing it on hardware that was nowhere near beefy enough for it. So for umpty-ump millions of people who bought that crappy hardware, the experience of using Vista was painful and awkward and slooooow. Eventually even the cheapest machines were powerful enough to meet Vista's requirements -- but by that point Vista's reputation had been sealed. As the saying goes, you never get a second chance to make a first impression.
But the OEMs did get all that inventory out of their warehouses. So, you know, mission accomplished.
Vista is now my go-to example for when people managing platforms say "just break badly written applications, their incompetence is their problem, not ours." Microsoft took a staggering PR hit when all sorts of crappy, poorly-written applications broke under Vista, because their users all blamed Microsoft for it. People don't know their applications are crappy under the hood; all they know is that they used to work, and now they don't.
Each token has different privileges on what it allows/ doesn't allow. One notable change in Vista was the introduction of SetTimeZonePrivilege, since in XP, you had to be an adminstrator in order to change the time.
Vista had A LOT of security improvements overall, but UAC shouldn't be considered as one of them (similar to PatchGuard for x64 Windows - it's cited as sometimes a security feature, but it's not).
Today, 8 years later, my Mom and Dad think Windows is a "secure" system as they haven't had any issues for long enough that their opinion of it has changed.
The final leg of this journey will be when Windows + Windows Defender is all you need to keep your system secure. Basically once there isn't a market for add-on security products because the base product is "good enough."
I'm curious why you mention Google though, their security record on Android is a lot worse than either Windows phone or IOS. In many ways I feel like they are exactly Windows in 2003 with regard to "its secure if you use our APIs" kind of security. Would love to hear your thoughts on that.
Chrome (OS)'s security model is a lot better, and compared to Android it was designed more in-house. Android was an acquisition and has more legacy design baggage (though of course the vast majority of the code has been written by Google at this point).
The latest junk even made it into Android 4.1 devices for security updates. But that is neither here nor there, the fact that we have 4.1 devices is a problem.
But, iOS's superiority (a) derives in significant part from Apple's total control over the hardware platform†, and (b) comes at the cost of a lot of user control tradeoffs that nerds like us tend to hate.
Really, to suggest that Android's security is at parity with Apple's, you'd have to be arguing that Apple does a terrible job at exploiting their inherent advantages of control over hardware and control over what's allowed to run on the platform. Apple does not do a terrible job at those things.
† Yes, Google controls some of their hardware, but they have an ongoing support requirement for a lot of hardware they have no control over at all, and will have that requirement forever, which limits their options.
Android development feels a lot like current web development plans, where things are released, and not a lot of thought is given to backward compatibility and backporting security. Google needs to tighten those reins a bit, either by pushing handset developers forward faster and/or giving reasonable support for older devices themselves.
Any system that allows free reign to OEMs will be ridlled with crapware.
The other technology was a classifier for panic dumps. When Windows crashes and reports data to Microsoft, that data goes into a classifier system which tries to cluster similar crashes together. So, when there's a crash bug, the reports of similar crashes are all looked at by the same person at the same time, which tends to get it fixed.
Linux lacks either technology, which is a problem.
[1] https://msdn.microsoft.com/en-us/library/windows/hardware/ff...
So somewhere in Sony and Target's organisations there are one or more Windows computers?
This is just lazy reporting NYT. Do better.
That nearly got me fired. You read that right: when I point out that a sloppily written application that someone wanted the entire developer division to run was insecure, my manager basically told me to run it or else. If the dev can't even be bothered to not write to PROGRAM_FILES (which is the only reason it needed admin privileges), what other holes does it have? Well, I'm not about to find out on my dev box that's hooked to the corpnet. Running on an internal-only alpha version of the early .NET runtime to boot; what could possibly go wrong? (And as it turned out, nothing went wrong, but still...)
And this was after Valentine's mail was sent. SQL Slammer had already happened. What, you thought the whole company just jumped on the security bandwagon? Yeah, I thought a new day had dawned, too. You can make 'em quit blindly using strcpy, but you won't change their minds with an email even after Valentine asks the whole company to come in and take Slammer support calls.
Certainly they have improved over the last decade, but who hasn't? Not to mention they have boatloads of cash to throw at the problem.
But the fact^W opinion remains Windows is still the easiest target of any OS. A user can configure any OS to be less secure, and other OS can become as popular a target as Windows but there's something about Windows that makes it a far greater liability than all the rest.
It's closed source.
How are you ever going to assess the quality of this software in terms of security? By reading the New York Times?
Boatloads of cash also buys PR.
How is that a fact?
My feeling would be that Microsoft have done a lot in the security line and have also given a lot back to the security community (their SDL documentation which is freely avaiable for example) and that they are one of the better examples of security in the software industry these days
It also has to do with design goals and priorities. Layer upon layer of cruft, with an OS weighing in at multiple GB, is not a confidence builder in the "security line". It also includes default configurations.
There are reasons that so many Windows instances have been and are now part of botnets. There are reasons why the security updates have increased in quantity and frequency over the years and appear to be neverending.
Some of those reasons have to do with design and priorities. Others with default configurations that Redmond assumes no user will ever change.
No amount of PR can change reality (e.g., massive botnets of Windows users), although it might change people's perception of reality.
Also, I never said "major competitors". I said "other OS". For example, the OS I use is probably not a "major competitor". It is much smaller and open source. That is what is important to me.
For example take SQL server as a good example, compare the number of RCE issues that it's had with say.... Oracle's Database server, another well funded company with loads of "PR" money. You'll find the SQL server has many fewer security issues than the competition, and I would suggest this is evidence of Microsofts improved attention to security...
MS default configuration are really very good. I'd compare to your OS of choice, but you don't choose to disclose it :)
So on the server-side I'd say that when I test modern default installs of windows based products they tend to have a good security posture out of the box.
Security Updates, well everyone has a load of those, are you suggesting the MS is worse than their competition? Counting OS vulnerabilities is notoriously difficult to it's hard to get an Apples to Apples comparison here.
Botnets, well there are botnets on linux for sure, and OSX has had it's share of malware to as has Android.
If you like a small open source OS then that's fine, but it doesn't necessarily make another entirely different OS have bad security.
now I know there's a reasonable chance you're thinking I'm an MS "fanboy" or similar at this point, but I'm not. I use OSX/Linux and Windows (as well as some iOS and Android) where they work best for me.
The neverending security updates is part of the difficult balance MS has to take between compatibility and security. Fixing a security problem that breaks a buggy program written 20 years ago by a company that no longer exists suddenly becomes a support issue, because there are a lot of people who don't want to hear that they have to upgrade their copy of PrintShop.
MS releases security updates in part because they audit their code, and are making strides to get rid of a lot of the cruft. Windows 10 pulled a lot more services out of kernel space and into user space, for example. They're doing so while being conscientious of user needs, instead of telling the user to just code the fix for older programs themselves.
In your small OS, who do you go to for support if something breaks? Who will you go to for support when a program from today breaks ten years from now? These are responsibilities many open source programmers will slough onto the end user, while they're working on the Latest and Greatest PulseConsoleSystemAudioKitD.
From my perspective, Windows doesn't seem to be less secure but it has a greater share of users who do stupid things.
I have seen popular Linux distributions where interfaces are enabled and have programs listening by default.
I, the user, never asked for that.
This is one reason I do not use Linux distributions.
Too many assumptions about what the user wants.
Exploiting common faults in Linux system software was pretty easy back then too.
I am not aware of a single third party that has reviewed all of the code that goes into a Linux distribution. Do you know of one?
Are you assuming I use a Linux "distribution"?
Sometimes I have done so, but only occasionally when I need to check something on Linux.
Anyway, I am missing your point.
My comment was about closed source versus open.
Popularity is only relevant to the extent someone would argue Windows is not the easiest target but rather the most frequent one, due to its popularity, i.e., userbase size.
There's more to open source than just Linux.
You made a point about Windows being impossible to audit, but in practice you're in pretty much the same boat when it comes to Linux.
And then there's this mythical "average user". But what does that have to do with me and my own solutions?
I know only one user: myself. I know what works for me. I live in a tty. Do I need a Windows GUI? No.
Finally, I also know that what one can do, another can do. But that is their decision and I am not trying to convince anyone to do what I do.
Windows is a massive, complex truckload of legacy source code that keeps growing with every edition; it has a lot of flaws and the number grows every year; it is not "open source" in the sense of public source code respositories and enabling users to compile from source. This is not opinion. It's fact. These facts do contribute to the state of Windows "security". Bravo for fixing flaws in recent years. But no points for having them to begin with: poor quality control.
Um, because you compare like to like. If you are comparing millions of lines of code to 10,000 lines of code, then obviously its easier to audit. Your point about auditing code makes no sense unless you compare the task of auditing equal amounts of source code.
>Windows is a massive, complex truckload of legacy source code that keeps growing with every edition
Please enlighten us how you got access to the source code, which parts you evaluated, what methods you used to evaluate it, and why you think those methods are accurate and scientifically valid.
Unless you do those things, you cannot claim to be fact based. Its fine to have an opinion. Many non technical users who don't understand the NT OS design, confuse the implementation flaws of user mode code, kernel code, third party code, and are unable to differentiate it from NT design flaws. Sure, from a responsibility standpoint, I'm right there with them - If you ship it - you should own up to the flaws regardless of where they come from. I think that MS in the past made some super bone headed decisions (possibly driven by commercial reasons) that screwed them security wise because the 'default install' of Windows was insecure out of the box.
> But no points for having them to begin with: poor quality control.
How do you know this?
As an aside, I find it ironic for you to lament about "complex truckload of legacy source code" while using a TTY which itself is the exact same thing. Ah ! C'est la vie
As a user, I don't. It's closed source. That's the point. What users have is only circumstantial evidence. And then there is the marketing and PR, such as the NYT article.
One of original two comments was "What would we find?" There is nothing to suggest I have read the source code.
Unless and until Windows becomes an open source project, such as the ones that are routinely discussed in this forum, where users can remove code they do not want, then no amount of "updates" or PR by Redmond is going "fix" Windows to my satisfaction. As I said, I am not expecting that to happen, ever.
There is a comment in these threads from a former Microsoft employee that confirms my suspicions about poor quality control. Are you still in disbelief?
As for your aside, I agree. There's legacy code in both. But I suspect it is far less code overall. And, in my opinion, it's in some cases higher quality than what I am getting with Windows (there are certainly exceptions: Dave Cutter's work on the NT kernel being one). Of course, I do not have the Windows source code so I can only speculate what is in there.
More importantly, the size of the software is much smaller and I can modify and recompile it.
I can see to some extent what has been added and changed over the years. I can continue to learn from the source and the people who wrote it, instead of from a marketing department.
Living in a tty is "the exact same thing" as using Windows?
Is that an example of "comparing like to like"?
I am in VGA textmode. I am not using a graphic layer.
The amount of code to implement the tty, which is available to me to read, edit, compile and redistribute, is, I speculate, much smaller and less complex than the amount of code and complexity used to implement the Windows GUI.
Pure speculation of course.
Windows isn't the easiest to target; but it is the most profitable, simply because it has the highest proportion of users.
Keep in mind what I said about configuration. Distinguish configuration from source code. Proper configuration s within the user's control and can be anticipatory and preventative.
Whereas poor quality code in a closed source program is outside the control of the user to fix and usually requires knowledge of someone exploiting it before it will be fixed. This is, unfortunately, after the fact.
Proactive versus reactive.
If it's very important to you, you can obtain a license that includes source code:
One where I can edit and compile the source, run it and redistribute it, too. All for free. But I guess all that is also possible under this shared source program you mention?
If Microsoft ever released the Windows source code, what would we find? Simplicity?
How easy would it be to audit?
Bias disclosure: I like small software. Windows and most all other software released by Microsoft is large, or packaged in such a way as to necessitate a large download/install.
Windows source code has been available for a long time under the Shared Source initiative. Some governments (including Russia), large companies, universities, partners and maybe even MVPs have had access to some versions. Email source@microsoft.com
Depends on where you look. Much of the NT kernel is "simple", but it's not easy stuff to get right. There's a bunch of legacy code in the Win32 layers, especially dealing with user input, that is just frightening (comments like "This stupid hack makes the utterly broken Compaq XYZ-3000 keyboard not crash the system"). The COM stuff is just complex and arcane and top-heavy with architecture astronautics. The build system is, or was, a soul-destroying, radioactive and rotting cesspool of Perl; doing Windows builds sucked real hard.
So it's a mix of really quite good code, and really quite awful code (that they're dealing with, I think), and code that makes you want to quit, every day.
(Soapbox: You should never have code in your project that you are scared of touching. Never. If you do, get rid of it and replace it. Don't layer over it, don't give it to some intern to maintain, just face the problem and deal with it, or it will be the most costly code in your product).
Given that MS is a very successful company that got to where it is today based on closed source and copyright, I am not expecting that to happen, ever.
I appreciate your candor.
The kernel I start with is indeed derived from the same one that project started with.
Though I'm sure you are not the only Microsoft employee who has used OpenBSD.
At one point, after the Danger acquisition, Microsoft HR was advertising a position for a NetBSD developer.
Are there any rules about using a non-Windows OS in the office? Even if it increases your capabilities and productivity?
For instance, Macbooks are really common on some apps teams. In contrast, I work on the OS itself, so tools such as WinDBG and Hyper-V are essential to getting work done.
SLAM, Z3, DART were all tools that came out of MSR and have been incredibly influential on the whole field of software verification.
Source?
I don't have Microsoft source though.
Source: me, who worked there (in VS, not Windows) at the time.
EDIT: oh, yeah, forgot about the Gates mail. References are buried in this link: http://www.microsoft.com/security/sdl/story/#chapter-1
I stand by the B. Valentine version, just can't find a link.
This is just like reporting on government where they report an idea a President mentions as "President dramatically reverses his entire 20 year belief system"
Cynically (and probably accurately), it’s a clever way to disguise a user feature (security) as a way to gather data so as to "protect" them. Sound familar?
Is that more secure in practice?
http://hackaday.com/2015/11/10/your-unhashable-fingerprints-...
I always pictured a really talented dev team somewhere in Redmond plugging away thanklessly on things that the powers that be thought no-one cared about (like security and usability) until one day someone decreed from on high that the whole frontend would need to "beat the iPad", and it all turned to poop.
This is speculation of course, but drawn on multiple similar experiences.
This whole debate has gone overboard through an inability to recognize the difference between telemtry and "spying". For example, between counting cars (important for city planning) and numberplate recognition.
FALSE.
But this statement does not surprise me. It is this distorted view of programs that is a large part of the "security" problem, in my opinion.
You think that false statement is a respectable "response" to a comment on the benefits of small software?
Small software exists both in the past (when memory and storage were more limited) and in the present. The very idea of small programs is a foundational one in the field of computing.
"All software is large" is not a "view" that is in agreement with reality. As such, it is distorted.
I am using small software every day. In fact I am writing this comment with a small program. When I write software, it is small, at least relative to anything from Microsoft.
I am too dumb to write large software.
Which small program is that?
If all you are aware of is large software, then your statement that "All software is large" makes more sense.
"All software is not as large as Microsoft's software."
Would you agree with that?
You do not believe such a program exists?
Or maybe you want to critique the program? That would be typical commenter behavior, but it is totally irrelevant to the discussion.
The topic is Microsoft software and the relationship between code size and probability of security flaws.
You brought it up and now you don't want to say, I find that odd. It's hard to have a conversation if you're going to be so.. cryptic.
> Or maybe you want to critique the program?
Maybe I want a significant example of a "small program". At this point, neither terms have been well defined. You called the program used to make your comment "small" so tell me what it is.
> The topic is Microsoft software and the relationship between code size and probability of security flaws.
The greater the code size the greater the probability of bugs. And security flaws can be exploited utilizing the combined flaws across different independent programs or included libraries.
My point is the only programs so small that security issues are a non-issue are either not interesting or combined with other programs to do something useful.
Right. I think we are done here.
Microsoft Windows is larger than any OS I know of, and only keeps growing.
To answer your question, I am using a text only browser that's based on the links project, with my own minor modifications.
I still have no idea why you and the other commenter are asking. It seems quite clear neither of you have any legitimate interest in such programs. Otherwise you would not be challenging my statement of such a simple fact as the quoted sentence above, as it applies to Microsoft.
I strongly disagree that "small" programs are not useful. As I have previously stated, I use them every day. I use programs such as sed and netcat to interact with the www even more than I use a browser.
Small programs that don't do anything are secure but nobody cares.
And you've probably written software larger than Notepad; a very popular small Microsoft program.
The only points I would contest are 1. that "a bunch" is effectively the "same thing" as large software. A "bunch" can vary in number and quality. My userland is a single "multi-call" binary and quite small. The sum total of source code is not so large that I cannot manage it. It's keeping tabs on the kernel code that presents the challenge; and 2. that "nobody cares".
If "nobody" cared, then you would not be seeing a comment such as mine because there would be nobody to author it.
Moreover there would be no reasonably small kernel source that users like me could use. Some people care enough to maintain that kernel and to keep it relatively small.
Maybe that group of people is like the software: small. Suits me just fine.