Windows Vulnerable To 'Token Kidnapping' Attacks 126
cuppa+tea writes "More than a year after Microsoft issued a patch to cover privilege escalation issues that could lead to complete system takeover, a security researcher plans to use the Black Hat conference spotlight to expose new design mistakes and security issues that can be exploited to elevate privileges on all Windows versions, including the brand new Windows 2008 R2 and Windows 7."
Re:About Software (Score:5, Interesting)
#include <stdio.h>
int main()
{
printf("hello, world");
return 0;
}
Re:Yes (Score:2, Interesting)
This is completely correct. A bug isn't simply a coding error but a design error. Programming takes an abstract concept and makes it concrete in a formal language. This involves filling in all the details -- which is quite a lot more than non-programmers think. How should the program behave if it runs out of resources, user inputs incorrect information, external system provides incorrect information, operating system error, what should the performance characteristics be, details of statecharts and sequences, security and many more details that I have missed. All of these require trade offs that also require engineering time. Omitting important factors is just as bad, sometimes worse, and a lot more prevalent, than coding errors.
In general, users don't care if a feature doesn't work because of a programming mistake or because it isn't implemented. If a feature doesn't work, they are both the same.
Re:About Software (Score:5, Interesting)
Considering I once performed a security audit and found that the lead developer for the client had rewritten printf so it had damaging side effects...yes...
Re:Apple replies (Score:3, Interesting)
Re:About Software (Score:3, Interesting)
At a certain point of time it's a waste of time and resource to add extra checks.
In this case the target user would likely notice if printf fails to produce output and deal with it accordingly.
If printf produces output and still fails for some strange reason, the user is unlikely to care.
A professional way is to document it. "NOTE: in some cases printf may fail and the program not produce the desired output", buy the customer dinner and get them to sign off on everything.
Re:Apple replies (Score:2, Interesting)
Thank you for your, as usual, rational observation.
Unix-derived OS's are only recently gaining proper fine-grained security controls, and most are still hacks, IMHO. Newer Linux has "capabilities" that allows one to mark a binary as allowed to use certain privileges, such as CAP_NET_BIND_SERVICE, but this can't be used with *scripts* due to the fact that it is the *interpreter* that would need the privilege (*bad* idea to always give it to the interpreter). Solaris 10 has user privileges such as net_privaddr, which is closer to the VMS way, but in my experience it is easier to get a customer to install a script that starts the web server as root than it is to get them to create a user for that specific purpose and type 'usermod -K defaultpriv=basic,net_privaddr webservd'. Often the customer admin'ing the box is just the most-technically-competent user, with the job dumped into his lap, rather than a "real" admin who understands that job. He's OK with things he's been asked to do before, and suspicious of anything he's never seen or does not understand. It's even difficult to get other developers to understand half of this stuff (tried unsuccessfully with ACL's a while back, for example, and they interact poorly enough with "standard" Unix file security to frustrate people with 30+ years Unix experience).
The other issue is a complete lack of consistency between Unix variants on how any of this stuff is enabled, configured, managed, or audited. Unless you have a lot of programming and testing resources at your disposal, developers need to limit themselves to those things they can rely on having as "standard" across the platforms supported. The company I work for supports 3 Unix variants, and tests on more than that. Even something as simple as querying directory services is a cross-platform mess, and security-related issues are a whole new weed patch. Of course, VMS did not have this issue to deal with, but that OS is at least consistent from top to bottom. Anytime I have to do anything security-related on Unix I cringe and wish I was working with VMS again (when will Unix get installed images? http://hoffmanlabs.org/vmsfaq/vmsfaq_007.html [AIX almost has this -- equivalent to /SHAREABLE] ).
Even VMS is not invulnerable. The last exploit I know of was verified in 2008.