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

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.

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...

[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.