Slashdot Mirror
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 ...'"
Microsoft and Secure? I'm I missing something here.
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.
Yeah, this is kind of like the church releasing its guidelines for picking up hookers under Creative Commons.
which is totally what she said
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
Just another "Cubible(sic) Joe" 2 17 3061
Shouldn't this be tagged as "humor"?
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...
This is not the Special Olympics.
Help stamp out iliturcy.
Proud member of the Ferengi Socialist Party.
That the world needed a free lesson in how not to develop secure software?
Unless someone converts it to PDF I'm not downloading that....
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...".
Or "they're not done re-inventing UNIX yet."
Now, now, they've been reinventing VMS, not Unix, as anyone should know.
Socialism: a lie told by totalitarians and believed by fools.
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.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
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.
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.
"What do you despise? By this are you truly known." --Princess Irulan, Manual of Muad'Dib
/)
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.
"What do you despise? By this are you truly known." --Princess Irulan, Manual of Muad'Dib
/)
For anyone not willing to follow the progress of this thread, here's the summary: .NET escalation exploits. .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.>
--
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).