Microsoft's Security Development Process Under CC License

An anonymous reader writes "The H Online writes: 'Microsoft has placed its process for secure software development under a Creative Commons License. The company hopes that this will lead to more developers utilising its process for programming software more securely across the entire product lifecycle ...'"

Comments

Oh boy...

[Anonymous Coward]

Cue a multitude of Slashbot posts pointing out that Microsoft could never do "secure software development".

Re:Oh boy...

[somersault]

Yeah, this is kind of like the church releasing its guidelines for picking up hookers under Creative Commons.

Re:Oh boy...

[DJRumpy]

Yes and no. The MS OS is actually written with a lot of safeguards in place to make the OS more secure. Years of being attacked tends to make one a bit defensive and certainly more technically adept.

I think their problems are on multiple fronts:

Overly complex code
Lax permission requirements,
Too many admins (still default on workstation installs)
Poorly written apps that in turn requires them to bend the rules or to provide workarounds.

MS could take a hard line, and force apps to comply with OS guidelines, but they'd be shooting their compatibility in the foot. although I see them nudging folks in that direction, with more functions locked out by default, they have a long way to go. Instead, they bend over backwards to try to work around compatibility issues and legacy support, and as a result, leave tons of loopholes. I had great hopes for their VirtualPC bit and was hoping they would take a more Apple-centric approach, allowing them to just start with a fresh slate while virtualizing old OS compatibility. It appears that was a wasted hope however...

Re:Oh boy...

[jimicus]

I think it's simpler than that.

Windows can be very heavily locked down so end-users can literally do nothing more than that which is explicitly made available to them. Heck, with something like SteadyState, it can even roll back any changes with a simple reboot.

But far too many third party developers seem to actively go out of their way to break any security - they seem to have some sort of mental block understanding that the assumptions you make when you're designing an application which will run on a system which you can more or less guarantee will only ever have one person using it (and that person has no realistic hope of screwing it up badly simply because there's so little to screw up) simply do not work on a modern multi-user, multi-tasking networked operating system.

I've lost count of the number of applications - and these aren't crappy things you find on download.com, they're expensive commercial products that are intended to have multiple users - that explicitly expect the end-user to have local admin rights and their first support response is "Does the user have admin rights? No? Go away and come back when they do. I don't care if you can explicitly prove that this isn't the issue here...".

Re:Oh boy...

[lgw]

Or "they're not done re-inventing UNIX yet."

Now, now, they've been reinventing VMS, not Unix, as anyone should know.

Re:Oh boy...

[bill_mcgonigle]

UNIX doesn't have ACL security.i

Take your pick: SELinux, GRSecurity, classic or new Solaris ACL's. Use a supporting filesystem with NFSv4.

You can even go MAC with SELinux if you're at a TLA or similar.

Re:Oh boy...

[Anonymous Coward]

Pretty sure you have no idea about Unix internals vs NT internals. UNIX doesn't have ACL security.

So, the "Unix internals vs NT internals" is resumed as UNIX not having ACL security?

Pfffff.. Yeah, looks like you know a lot more on the subject.

WRONG. Unlike windows, which only supports ONE ACL scheme which is builtin, the most variety of UNIXes out there supports complex ACL mechanisms through a modular design or patches. Windows ACLs are also very basic compared to the full access control provided by SELinux.

Keywords: SELinux, GRSecurity, FS extended attributes, PAM, ...

Now go back under the rock you came from.

Re:Oh boy...

[RobertM1968]

...I think their problems are on multiple fronts:

Overly complex code
Lax permission requirements,
Too many admins (still default on workstation installs)
Poorly written apps that in turn requires them to bend the rules or to provide workarounds.

You forgot a few very very important ones:

- Way too much legacy code that was not written with network security in mind

- Way too many technologies, that by their design and the functions they provide, can never be made secure (ActiveX, .NET Click Once and more)

- NO interest in removing "core components" that compromise the security of Windows systems (.NET and ActiveX) as (1) too many of their clients use it and (2) (the really important one) those technologies are Microsoft's bread and butter in the server marketplace and the only thing that differentiates them from other implementations. With the ease of use of .NET and ActiveX, it allows a larger IT entry point and provides a support model that xAMP does not have (and while that does not make the choice better, we all know there are numerous "admins" and "developers" who do not deserve their titles - but the Microsoft products and "technologies" give them an entry point into those fields that other technologies (PHP for instance) do not - all with Microsoft's support behind them.

I had great hopes for their VirtualPC bit and was hoping they would take a more Apple-centric approach, allowing them to just start with a fresh slate while virtualizing old OS compatibility. It appears that was a wasted hope however...

C'mon, you really didnt, did you? I dont know anyone in the IT or support industry who thought that or even had any real hopes for that to happen. The day they bought Connectix, we in the OS/2 world knew that the OS/2 version would be killed, followed by the MacOSX version (I even made such posts on the OS/2 World Forum when the announcement of the acquisition was made public), followed by any version Microsoft deemed as detrimental to their server and high end client OS sales. Of course, their promises of the exact opposite behavior notwithstanding, that is exactly what happened. Maybe because we're part of the OS/2 Community and have seen it happen to a far greater extent, it made it easier to see the writing on the wall. So, I cant blame anyone for that. I suspect that MacOSX users may have seen that writing as well, especially after the broken promises on fully feature compatible versions of Office, updated versions of IE and so on.

Fact is, as some of us speculated, due to issues they've had and never fully resolved with backwards compatibility, we were quite sure that Microsoft's biggest intent was to grab the Connectix stuff to use it as a compatibility layer, while at the same time, preventing people from using other operating systems as the host OS. And thus, the current (Vista onwards) WoW implementation was born. This too was finally admitted to by Microsoft when they touted the better backwards compatibility Vista would provide due to their acquisition.

I'm not saying that's a bad thing... I'm saying I dont know any IT Professional who thought of any of those situations differently or didnt understand the reasoning behind it, or what the outcome would be. I suspect that you too saw where things would go. I guess the only difference is you decided to hope, while my colleagues and I knew it wasnt worth hoping.

Re:Oh boy...

[nmb3000]

...unless a serious rootkit gets installed with whatever piece of malware infected your machine while you were using it

A user without administrative access cannot install a rootkit.

Sadly, .NET is still broken. The exploits still affect all versions of the OS. The exploits still dont need the user to have admin rights. The exploits still bypass security measures on a locked down machine.

It sounds like you're talking about a local privilege escalation exploit, and those are usually patched pretty quickly. Do you have any examples or sources to back up that claim?

Re:Oh boy...

[LordLimecat]

A user without administrative access cannot install a rootkit.

Thats inaccurate. A non-admin can very easily get infected with a userland rootkit with no exploits necessary. Google "n00bkit".

Re:Oh boy...

[nmb3000]

Yeah, as I indicated, it's called "Windows Updates" - check it out sometime!

Perhaps now you see what I am talking about... if not, check your hotfixes/ Windows updates, read what they supposedly fix, then look at the similarities between the multiple attempts to fix the same damn issue over and over again.

So the answer is... No, you don't have any real sources. The generic description that comes with a Windows Update is just that -- generic. They all sound pretty much the same. Even the MS security bulletins like you linked to are usually pretty scant on details because they're designed to give an overview, not the nitty-gritty exploit information found elsewhere. I did look around Google for references to privilege escalation issues with .NET and didn't find anything.

If multiple updates which all say "This security update resolves two privately reported vulnerabilities in Microsoft .NET Framework and Microsoft Silverlight." has you convinced they've been trying to patch the same vulnerability for 10 years, then you have other issues.

As it stands, the specific vulnerability you point out doesn't even mention privilege escalation! It's also blazingly obvious what "Users whose accounts are configured to have fewer user rights on the system could be less impacted" means. If you don't have admin rights the worst thing the malware can do is put some entries in your startup folder/registry. If you're a full-on admin then we're talking kernel-mode drivers, raw disk access, machine-wide registry changes, the whole shebang. Big difference between the two.

Re:Oh boy...

[nmb3000]

Wow, okay, let's take this slowly, piece by piece.

Wow, not just did you ignore most of the text in the advisory, but you dont know anything about how malware works either, do you?

I did read it, and I do understand.

Gee, adding things to the startup folder/registry means it might take what... two boots?

A standard user can only write to HKEY_CURRENT_USER. This key controls only their profile. So yes, malware run as a standard user can be set to run when that specific user logs in. Not upon machine startup.

to fully infect a machine with a piece of malware that has then gained full privileges?

Only if that user has administrative rights. If it was a standard user, then no, the malware did not magically gain more rights than the installing user had. That's why I asked about privilege escalation -- an exploit like that makes the situation much, much worse.

I've watched (on both Windows 7 and Vista) malware initiate itself using svchost and smss to, with admin privileges, install themselves with the same privileges.

Yes, it's common for malware to use existing system services to run. There are several methods from DLL injection, App_Init DLLs, remote thread creation, etc. However, ALL of these require administrative access. A process cannot play with system services unless it has rights to. A standard user cannot inject DLLs, write to shared memory, or do anything else to processes running with SYSTEM access unless the user itself has admin rights.

All it took, on a locked down machine, was a couple reboots.

There's nothing magic about rebooting Windows. Some registry keys aren't processed except at boot-time, but there are MANY ways to infect a machine with malware without rebooting the computer. Of course, these ALL require administrative rights.

So yeah, kernel mode drivers and full access may be worse, but in the end, it doesnt matter. The end results are the same.

No, they aren't. The results for malware infection via standard user and that via an administrator are drastically different, with the latter being terribly worse. A standard user's infection can be cleaned up in 5-10 minutes with ease. Simply deleting their user profile and creating a new one is the easiest method. Anyone can do it.

A machine that's been infected by somebody with administrative rights may as well be infinitely worse. Without taking the system offline and analyzing the hard drive in a separate computer (or maybe by booting to a different OS), you will never, ever know if the system is clean. Even offline analyzing isn't guaranteed to work unless you know of and can check every single infection vector, a very challenging task. You're almost always better off reinstalling the machine.

Hopefully that helps clear things up.

Re:Oh boy...

[Anonymous Coward]

For anyone not willing to follow the progress of this thread, here's the summary:
--
RobertM: Malware is taking advantage of .NET escalation exploits.
nmb: Which escalation exploits?
RobertM: The .NET escalation exploits that haven't been fixed in 10 years. <Offers patch details for a fixed .NET vulnerability that allowed code execution on the compromised user account.>
nmb: That wasn't an escalation exploit.
RobertM: You don't need an escalation exploit. The Windows operating system allows any process to automatically elevate itself through the registry and startup folders.
nmb: Wrong.
RobertM: OK I was wrong. You do need an escalation exploit. <Adds reference to a long-since fixed escalation vulnerability.>

---
Escalations affect all operating systems rather equally, are the absolute worst kind of vulnerabilities, are very uncommon compared to other holes, and have the shortest time-to-fix delay. It's really fucking big news whenever one is announced because they tend to be extremely valuable. Historically very few viruses have successfully taken advantage of one. If your customers are affected by system level malware, they (A) clicked yes on something they shouldn't have, (B) disabled UAC, (C) disabled updates, or (D) did all of the above (most likely it was D).

Re:Oh boy...

[nmb3000]

This will be my last post in the thread because you clearly don't know what you're talking about and refuse to realize that.

Point is, they just fixed one that they think may bypass privileges.

Citation please.

Explain why .NET ClickOnce and other .NET exploits still infect machines that are locked down (up until Aug 10th supposedly).

Citation please.

Or perhaps, the malware authors will simply choose one of the other numerous attack vectors created by .NET's security holes. As has happened for almost the last 10 years with .NET and ActiveX.

They might. And maybe you could give a citation of a currently unpatched privilege escalation attack vector.

So, if a rootkit drops a piece of malware (hmmm, maybe named svchost or smss?) into a "secure" folder

If a standard user has write access to a "secure folder" it isn't very secure, is it? Oh, and the name of the file doesn't really matter.

maybe in the System Volume Information folder?

Administrator and/or SYSTEM rights are required to even read from that folder, let alone write to it.

does it matter that the account of the next person who logs in is a limited user account? Somehow I dont think so.

A user must have administrative rights to compromise a "secure folder". Administrators can (obviously) impact all users on the machine.

BTW, without going into technical details

Oh, please do. I'd love to see a single technical detail.

For instance, killing the fake svchost or smss services will cause Windows to reboot because it thinks they are vital system services

Just plain wrong. You can even kill legitimate svchost processes (they just host services) without rebooting. There are only a few processes which cause a reboot. You can't kill these without admin rights.

You seem set on the idea that multiple security patches for ".NET" means they're fixing the same thing over and over. Here's a tip: .NET is a big product. Multiple patches just might mean multiple security issues.

Take some classes or read some books or something. You really need to either educate yourself about Windows security or stop posting such incorrect FUD.

Re:Oh boy...

[man_of_mr_e]

WTF are you prattling on about? .NET insecure? Seriously? Do you even know what you're talking about? You are making vague claims that make little sense. Like calling the Firefox plug-in a security flaw.. It's using the mechanism that Firefox provided for machine wide-plugins. Firefox has since improved on that, but it wasn't MS's fault nor was it a security flaw.

Please, point me to some evidence of any severe unpatched .net flaws or exploits. I don't know of any. I think you are confused and simply applying catchphrases you've heard and pretending you know what you're talking about.

secure?

[Murdoch5]

Microsoft and Secure? I'm I missing something here.

Re:secure?

[GarryFre]

if the thieves are getting past the guards, I would not want to emulate them. Something is wrong and needs to change, and till its changed I would not want to copy a security model that isn't secure. The question is, is it insecure because of a failure in the model or is it because so many resourceful thieves are finding ways around the so called safeguards. Who can know?

Re:secure?

[KarmaMB84]

Most of their problems have been in old code they're undoubtedly afraid to change until it's proven there's actually a vulnerability there. I haven't hard anything to indicate their fresh code produced since adopting their current security process is any more insecure than the stuff produced by the open source world.

Re:secure?

[PhrostyMcByte]

Talk I've heard from friends in Microsoft indicate that they're quite paranoid about security, putting strict checks on all levels of development. To mention one small portion of it, C and C++ contain some functions that, if misused, can be easy attack vectors. VC++ has a number of non-standard replacement functions for these that they use that include runtime safety checks. They're warned off the "insecure" functions, and anyone that uses them needs a full rationale written up on why. Needless to say, most coders will have an adjustment!

Re:secure?

[symbolset]

Actually, even dead-simple basic security like closing ports by default, reducing default services, not including the current working directory in the executable or library search paths, not auto-running anything, reducing app attack surface by turning off embedded format decode by default and a vast many other things are completely off the table at Microsoft. Doing security breaks backward compatibility. It removes popular features, and the fact that the features are in and of themselves the security vulnerability makes it a no go.

They see these essential vulnerabilities a large part of their value-add. It's not that they're afraid - it's that basic security primitives we've known about for decades are antithetical to their culture. As long as they hold that strategic position, discussing minor tactical matters like how they compose applications for security is simply a waste of time.

That Microsoft Icon On Slashdot

[Anonymous Coward]

Isn't it long past time it be updated and possibly the correct one be used?

Bill Gates hasn't worked at Microsoft in years, and really has almost no involvement with the company any longer.

It would be like used the Edsel to represent Ford, or still using the New Coke logo.

It no longer serves its purpose, and says more about slashdot than Microsoft these days.

Re:That Microsoft Icon On Slashdot

[hairyfeet]

Oh please! At least Darth Gates was scary, and could do that whole "we'll crush you like a bug" thing real well. Ballmer is like putting the court jester in charge of the kingdom. What you have with Ballmer is "Hey, we can be like Apple and make cool stuff! Yes we can! We really can! STOP LAUGHING AT ME!!!!"

The whole EEE thing was Gates, Gates may have been a bastard but he, like Jobs and Ellison, was a tough bastard that played to win. The Ballmer monkey just flops from one idea to another and doesn't deserve the Borg Icon. It would be like pretending that IBM is the ruler of all things computing still and just ignoring the past 20 years. Gates is gone, and while Ballmer might try to do evil, he is a quasi-evil, he is the diet Coke of evil, he is the light beer of evil-half the taste and the buzz is a killer. In short he is lame and isn't worthy of being a pimple on Darth Gates's ass.

A MUCH more appropriate icon would be Ballmer in a jester hat with a I heart Apple!" T-Shirt, since he seems bound and determined to try to be Steve Jobs. And THAT would fit with the current situation at MSFT much more than the old Gates Borg, since without Gates it is like the Borg being led by Reno 911.

As for TFA MSFT's biggest weakness it hasn't ever been their own code as much as everyone else's. After SP2 MSFT code seemed to get better and better on security, whereas even with Windows 7 I have seen waaaaay too many apps that frankly shouldn't need admin for anything demanding admin rights. Sadly I doubt this will accomplish jack shit because too many lazy developers at too many lazy companies would rather just pretend everyone has admin and be done with it.

Seriously?

[ratboy666]

The PROCESS is Creative Commons licensed. Not the tools. Ok, but you know what? I would never have taken Microsoft as an example of a company whose secure coding practice I would want to follow.

Just sayin'

And why bother with a CC license for this? Just publish the practice, and don't take out "business process" patents. Microsoft did that with "Code Complete".

Anyway, I now have to read the frakkin stuff, just to stay on top of it. Maybe I'll be pleasantly surprised...

I hope

Re:Seriously?

[TheRaven64]

CERT publishes a good set. I've worked with some of the people behind them on some proposals for the C1X standard and they're very bright people. I'd trust their recommendations long before I'd trust ones from Microsoft.

mistagged?

[Anonymous Coward]

Shouldn't this be tagged as "humor"?

Re:At least they're trying.

[symbolset]

This is not the Special Olympics.

Re:Trying what?

[Anonymous Coward]

M$

good job ruining any credibility your post might have had and classifying yourself as a troll.

MS Security...

[leromarinvit]

Ahh yes, I can see it now:

• Never check your input, no matter where it comes from
• Make sure to make your algorithms as complex as possible so you don't run out race conditions and other non-trivial bugs, preferably in security critical areas
• Embed your security flaws in specifications you'll have to honor forever to maintain backwards compatibility
• Most importantly: When (not if) somebody finds a bug and reports it to you, don't fix it at once. Only when an exploit is out in the wild you can even start thinking about how to fix the bug.

So someone in Redmond decided...

[Dracos]

That the world needed a free lesson in how not to develop secure software?

Ugh, doc

[diegocg]

Unless someone converts it to PDF I'm not downloading that....

Re:At least they're trying.

[davester666]

It is for Microsoft.

Re:Secure from *what*?

[John Hasler]

The antitrust suit against Microsoft was not dropped and did not ever involve any criminal charges.

Re:Trying what?

[Anonymous Coward]

It doesn't matter how shoddy I think Microsoft products are. The moment I resort to name-calling like Republitard, Democunt, or M$, I take on the mental image of a 5 year old. Everything I said should be dismissed. If I can't stay serious for the 30 seconds it takes to write a post on the Internet, I don't have anything of value to say.

What are they trying? Not engineering. Not PR.

[SgtChaireBourne]

Why waste time publishing that crap? It's not even good for PR because it only serves to highlight the failure. It's only worth is documenting years of fail and we have Mitre and CERT for that. Every generation of Windows has been the model of bad design and insecurity, including Vista and Vista7. Before M$ reps revised it, /. even had a vista failure tag, for the version to come along after tagging was implemented. Otherwise there would have been a special tag for the XP SP2 disaster.

The SDL is what has contributed to very shitty quality. Of course the raw material, the managers and the engineers have to be mentioned as being incapable.

Important point: it's a CCSA license

[FoolishOwl]

Can we please get past the cheap shots about Microsoft's security, and pay attention to the trend wherein Microsoft, practically founded on opposition to sharing code, has been experimenting with open source licenses and making overtures to the FLOSS community?

Is this guide helpful or not?

[echnaton192]

So could someone with some knowledge please actually READ the darned document and say something relevant about it?

To me it looks like common sense practices:

- Make the software so it could work without administration priviledges except for certain actions. It should work under UAC with a non administrative account. To me this makes sense. 90 % of all security problems in Windows > XP are gone once you don't work with administrative priviledges, IIRC.

- Software is not allowed to make the system more insecure without the users consent. No Firewallchanges, no new ports or services, no enabling of services without the users consent

- don't use code which is already proven to be insecure

- etc.

About the rants securitywise: It is not like everything M$ made in the last decade was a step in the wrong direction.

- starting with XP, the whole enduser system was 32 bit and used a real security model with different types of priviledges. It was a real hell to work as a user without administrative rights, but it was possible.

- starting with XP SP2, they implemented a tool to watch if the system has some basic secure settings, the firewall was activated by default and M$ nagged every user to use an AV-product, which makes sense (as a last line of defense).

- starting with Vista, the user still has administrative rights by default, but UAC tries to minimize the threat. The side effect: In order to work under UAC, the software must ask nicely for adminnistrative rights for certain tasks. Thus software generally is more fit to work without administrative rights.

- M$ made MSE available, which *is* a good free AV-product according to different tests. Avira might be as good, but its Nagscreen every day is really annoying...

- With Win 7, UAC works better and new users are non-admin by default

I completely see your point about the insecure bullshit they did before XP SP2 to all end users or the ways in how they tried to maintain their monopoly. But to me a Windows system is not per se insecure provided someone uses some basic precautions:

- Keep software and OS up to date (PSI?)

OKOK, it is far more easy to keep a standard Linux up to date than the standard Windows because every company uses it's own update mechanism. But it is possible...

- Don't work with administrative rights

No Linux user would work with administrative rights permanently, so...

- Use strong passwords in all sensitive areas

NAT, Adminpasswort, Serverpasswords,...

- Use your brain before installing software or typing in your administrator's user credentials

Helps...

- Use your brain on links

Helps..

- As a last line of defense (not he only one) use an AV-product

And yes, I know that linux is more secure for a lot of reasons. But ignoring free guidelines like the one from M$ to develop more secure code for Windows sounds strange to me. It might be that there are better recommendations, but isn't it worth a read until someone comes up with arguments why this document is stupid and not worth reading?

That's a fallacy.

[melted]

Software that accepts external inputs is secure if it rejects invalid or malicious input. That's all there is to it. And it's perfectly possible to write a program that does just that. It doesn't even have to be 100% bug-free.

Re:That's a fallacy.

[Urkki]

Software that accepts external inputs is secure if it rejects invalid or malicious input. That's all there is to it. And it's perfectly possible to write a program that does just that. It doesn't even have to be 100% bug-free.

That doesn't cover valid input which triggers a bug.

Even defining "invalid or malicious input" to include "otherwise valid input that just happens to expose a bug in the code" doesn't help, because you don't know what you'd need to filter out (or if you did, better fix the bug).

Also, security is not just input, it's also output. All kinds of output. For example, there's a class of security exploits which depend on timing (mostly cryptography and authentication related). It's not enough that input is validated and code is 100% bug free, it also has to be coded so that processing time (and even power consumption) doesn't depend on validity or content of input.

There *may* be 100% secure complex programs, but there is no way to know which they are, or if there really are any.