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 ...'"
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.
I am TheRaven on Soylent News
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)
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!
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).