Slashdot Mirror
Windows Vulnerable To 'Token Kidnapping' Attacks
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."
Fixed the title for you.
Just don't connect to a Token Ring LAN! =V
There's a spot in User Info for World of Warcraft account names? Really?
Really? Can you find a bug in this...
#include <stdio.h>
int main()
{
printf("hello, world");
return 0;
}
It doesn't do anything useful.
So don't use Microsoft products and you're safer!!! To be fair to Microsoft their products have been steadily improved over the years. There products are now acceptable in regards to competitors.
Yep. It buggers up the prompt.
printf("hello, world\n"); /*is better*/
*This message was compiled with -pedantic.
After hearing about this exploit, an Apple VP referred to this as "Microsoft's Iphone 4".
#include <stdio.h>
int main()
{
printf("hello, world");
return 0;
}
RIP America
July 4, 1776 - September 11, 2001
You forgot the exclamation mark.
I don't know the last time I looked at everything in stdio.h for problems so it's tough to say...
That should be the first thing anyone familiar with Windows architecture notices. It means that it's an escalation from an account that's already running at elevated privilege (at least, it is on Vista and beyond).
So, it's definitely a security bug. But it seems like a disproportionate amount of noise for a local privilege escalation requiring higher than normal privilege to start with.
Really? Can you find a bug in this...
#include <stdio.h>
int main()
{
printf("hello, world");
return 0;
}
But Microsoft did not write that routine, had they done it, it would read something like:
#include <stdio.h>
int main()
{
printf("hello, world");
get_administrative_privileges();
collapse_system();
return 0;
}
You aren't checking the the return status of printf.
puts("Hello, world!"); /*is best*/
You, sir, deserve my respect. People sometimes forget that the bug can be outside the source they're writing, but on the code they're calling.
Buanzo Consulting - 15 Years of GNU/Linux experience, for you.
It does not checks to make sure it has access to enough memory to load the string "hello world" into standard output. It also do no checks to see that the stack size allows it to return 0.
This is why the majority of the public supports the Arizona legislation.
Oh, wait, this is a Windows story. Why'd you post that?
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...
but, he didn't want to disturb everybody, just the world.
It lacks i18n.
you're including an external file ('stdio.h'), which could be replaced by anything. A malicious person with access to that file could change the declaration for the printf statement to call an external function (or just add code into the header file), and then you're screwed.
Thinking about this makes me wonder if that's not a standard thing to do. No one checks stdio.h, right?
Ask me about repetitive DNA
Yes. You left out goatse.cx
Lately the security bugs I've seen are making me feel good.
Sounds weird I know, but it just seems like they are getting more and more bizarre.
Even the flash and PDF stuff makes me feel that we are starting to go into left field for vectors. The security industry is putting itself out of work...
Where will be in 5 years...probably in a relatively safe world.
I mean heck this things says "If you can upload an ASPX file you can take over the system". That means we are worrying about how to protect against inside jobs not general problems.
When was the last major worm anyways?
If you are being paid to run a SELinux box, you pry know more than 10 windows admins put together or 4-5 Linux Admins even.
An Education is the Font of All Liberty
This is way too incomplete. For one thing, you forgot NT and 2000.
Yes, "hello, world" should start with a capital letter and end with a punctuation mark. The comma is also unnecessary.
I suppose the article does say "more than a year..." but this is really old news. http://www.argeniss.com/research/TokenKidnapping.pdf was published in the summer of 08.
The comma is also unnecessary.
It is proper when addressing someone/something.
which is totally what she said
The file inclusion is done at compile time. Presumably, whoever is compiling the code has a good system (otherwise, the possibilities much worse that what you describe: the compiler might be hacked, for example).
Moreover, in this particular instance, the file is included with '#include <stdio.h>' (as opposed to '#include "stdio.h"'), which means the compiler will look for it first in the system include directories (e.g, /usr/include). This means that, if whoever compiles the code is being attacked this way, their system is already compromised.
Ironic how bugs are so well suited to infestation through windows. A RAID array might help....
It does not check the return value of printf.
Under windows it does only run in console mode.
Documentation is lacking.
The start of the source code is not marked. Since has a stop of line with a single "." there are 2 dots in start of the program that give a compile error.
There's an important distinction to be made, between bugs (eg a buffer overflow etc) which can be corrected with a relatively simple patch, and design flaws which may require serious changes breaking compatibility...
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
You aren't accepting incoming arguments, if you were running on bare metal I'd accept that there are no incoming arguments, but you're returning 0, so you're obviously not running on bare metal or there would be nothing to return to. One of those things is a bug, take your pick.
You also forgot to terminate the printf statement with a newline\carriage return or whatever fits the OS its for, which on some OSes will result in the line not appearing even though it does get printed.
It may not crash, but yes, its broken and buggy by my standards. You should probably not act like such a cocky fuck if you plan on doing any job interviews.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
On my desktop, no I don't check stdio.h
On our company buildfarm, yes, stdio.h is checked by the IDS before production builds run and after to confirm they are the originals.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
Dude, nobody wants a racist lunatic in the white-house
Wow, you're seriously out of touch with a large fraction of the American electorate...
I am TheRaven on Soylent News
So they know there is an issue with this but yet there is not another patch being released to fix this?
http://www.thetechnologygeek.org
Seriously though, what are you going to do if printf fails? Log to a file? What if that fails? Log an error message to syslog? Then what if that fails too?
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.
Really all versions? Going all the way back to 1.0, and also including the CE versions? I strongly doubt that! Perhaps it dates all the way back to NT4, but that is still very, very different than affecting all Windows versions.
Stylish sheet to fix many problems in Slashdot's D3: https://gist.github.com/801524
Really? Can you find a bug in this... #include <stdio.h> int main() { printf("hello, world"); return 0; }
A bit cryptic, your question is.
Are you saying that including stuff at compilation is safer than relying on DLLs that (by definition) get linked in at runtime? Just a guess of course. Why don't you just say what's on your mind? —or is C the only language you know?
Great men are almost always bad men--Lord Acton's Corollary
You aren't accepting incoming arguments, if you were running on bare metal I'd accept that there are no incoming arguments, but you're returning 0, so you're obviously not running on bare metal or there would be nothing to return to. One of those things is a bug, take your pick.
There is no requirement in Standard C to accept arguments - int main() is a perfectly valid conformant signature for the entry point. On the other hand, main is required to return an int (though, unlike any other C function, you can skip return, and the compiler should treat it as if 0 was returned).
So, no, neither of those is a bug. It could be a bug in a sense of not conforming to the specification, but in order to determine that, you have to see that spec first.
You do not need to use "int main()", and you can instead substite a slightly more efficient void return type (none in other words) and no need to return 0 either.
void main()
The above is not valid, and will not compile on a decent implementation. Go ahead, try it with gcc or any other standard-conforming compiler.
As a side note, omitting the return type - i.e. main() { ... } - is not the same as void return type. It's actually implied int. That one is valid, yes. And you can omit the return whether you omit int or not, because ISO C allows you to do so only and specifically for main, in which case it is equivalent to ending it with return 0; - this does not affect efficiency, though.
Really? Can you find a bug in this... #include <stdio.h> int main() {
int main(int argc, void **argv) {
Rampant carbon sequestration destroyed the Dinosaurs' tropical paradise. I'm here to help repair the damage.
I ran the Windows 7 RC on my home computer and Windows Vista Professional on my work computer for around 9 months. Both machines were roughly the same spec and purchased at the same time. Vista was an absolute hog, while Windows 7 felt fairly snappy and responsive. The free RC trial wasn't enough to convince me to pay $130 for an OEM license, but it was enough to convince me that Windows 7 is at least as good as Ubuntu for a general home computing / gaming platform.
Rampant carbon sequestration destroyed the Dinosaurs' tropical paradise. I'm here to help repair the damage.
Moreover, in this particular instance, the file is included with '#include <stdio.h>' (as opposed to '#include "stdio.h"'), which means the compiler will look for it first in the system include directories (e.g, /usr/include).
The include search path can be overridden on the compiler command-line (-I) or via environment variables (C_INCLUDE_PATH), both of which take precedence over the standard ("system") search path, so there is no guarantee that the file will not be unexpectedly located in some compromised directory under the nominal control of the current user.
"The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
Well, if someone can inject source code during compilation, they can obviously add malicious code to the final executable.
But in this particular instance, there would be no added include directories to the compilation process, since the source code is just one file. So, to do anything bad, the attacker would have to be able to screw the compilation (by changing the command line, environment or whatever other means he has to trick or change the compiler). If they can do that, they can also do any number of things that go way beyond simply overriding the search path of include files.
And which standard would you like to use as a official C reference point? I can think of four that are considered 'official' right now.
But, either way, reading comprehension is hard:
So ...being that I just told you the standard to use (mine) and that it was wrong ... well, not sure what my point was, but go read my previous post and try again.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
And which standard would you like to use as a official C reference point? I can think of four that are considered 'official' right now.
I'm only aware of 3 over the course of language evolution - K&R C, ANSI C89 (aka ISO C90), and ISO C99. My points apply regardless of which of those you pick, except that in C99 there is no "implicit int".
If you're talking about your subjective standard only, then it is entirely unclear to me why you feel that "accepting incoming arguments" is a requirement for main() in a "Hello, world" app. It's not going to do anything useful to them, so why should it do so?
Also, why would running on "bare metal" or not make any difference? Or, for that matter, why returning 0 means that he's "obviously not running on bare metal"?
So it sounded to me more like a factually incorrect argument over the requirements of free-standing vs full implementations of the Standard. If it's not that, then it sounds even more strange.