Microsoft's Security Development Process Under CC License 164
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 ...'"
Re:Seriously? (Score:5, Informative)
Re:Oh boy... (Score:5, Informative)
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:Secure from *what*? (Score:3, Informative)
The antitrust suit against Microsoft was not dropped and did not ever involve any criminal charges.
Re:Oh boy... (Score:3, Informative)
...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.
Is this guide helpful or not? (Score:2, Informative)
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?
Re:Oh boy... (Score:3, Informative)
...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:secure? (Score:4, Informative)
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? (Score:3, Informative)
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.
Re:Oh boy... (Score:1, Informative)
...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.
Incorrect (at least as I was discussing). The *user* doesnt have to install it, the escalated malware (via .NET or other methods) does. There are a bunch of escalation exploits available via .NET and especially it's ClickOnce crapnology. But they've been fixed!!! For almost TEN years, that promise has been made repeatedly. The June announcement went way too far in claiming that all such issues were permanently and properly fixed - as opposed to the more truthful statement that the should have used indicating that a patch for the specific exploit was released (and leaving it at that).
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.
No... those are sometimes patched quickly, sometimes not (like the .NET exploit noted in June that took months to improperly patch.
If you are referring to the hotfixes they release that hope to mitigate the circumstance until a real (though usually not fully fixed - at least in the case of .NET) patch is released, well, I dont count those, since, as I noted, they generally dont really fix the hole.
Do you have any examples or sources to back up that claim?
Yeah, as I indicated, it's called "Windows Updates" - check it out sometime! You can go right into your (XP) "Add/Remove Programs" or (Vista upwards) "Programs and Features" and enable viewing of all updates, and check the last few weeks - then check the associated Microsoft pages which will tell you exactly what I posted in Microsoft's own words.
Use Google if you really want to learn more. In the meantime, with your lack of knowledge, and lack of interest/willingness to do the very simple check on a Windows machine that's up to date to verify my claims, don't assume/claim they are wrong.
But to give you a head start, here's ONE of the various CRITICAL updates (this one from this month): .NET issue [microsoft.com]
We Never Really Fixed the
This security update resolves two privately reported vulnerabilities in Microsoft .NET Framework and Microsoft Silverlight. The vulnerabilities could allow remote code execution on a client system if a user views a specially crafted Web page using a Web browser that can run XAML Browser Applications (XBAPs) or Silverlight applications, or if an attacker succeeds in convincing a user to run a specially crafted Microsoft .NET application. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights. The vulnerabilities could also allow remote code execution on a server system running IIS, if that server allows processing ASP.NET pages and an attacker succeeds in uploading a specially crafted ASP.NET page to that server and executing the page, as could be the case in a Web hosting scenario.
This security update is rated Critical for all affected releases of Microsoft .NET Framework for Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2; Microsoft Silverlight 2; and Microsoft Silverlight 3. For more information, see the subsection, Affected and Non-Affected Software, in this section.
Even users with "fe
Re:Oh boy... (Score:3, Informative)
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... (Score:5, Informative)
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... (Score:3, Informative)
--
RobertM: Malware is taking advantage of
nmb: Which escalation exploits?
RobertM: The
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... (Score:3, Informative)
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.