Submitted by “A core tenet of the SDL is to take and incorporate lessons learned when we issue a security update, and there is a great deal to learn from the recent animated cursor bug, MS07-017, so I want to spend a few minutes to go over some of the things we have learned from this bug.”
But I think they need to be more agressive when persuing the security issues; things such as the above should not be ‘left to a later date’ but instead, the focus should be fixing up the compiler then and there, and start force fixing things straight away.
This might have been a *very* minor update, but it is a signal to possibly bigger problems somewhere else in the system; rather than it being just an animated cursor, it could be something more serious.
reading the comments on that blog, i find it funny how there is no response to asotirov.
Easy, because unlike Sun, Microsoft heavily sanatises their channels of communication – only those who coo around like girls at a Justin Timberlake concert get their so-called ‘questions answered’.
Its like watching parliament when MP’s from the governments own party gets up and asks obvious question as to allow the government of the day to toot their own trumpet.
or sit at the back and mumble “here here”
That’s not really true. I read a good number of MS blogs and the authors do not seem to delete posts that aren’t spam (or just senseless trolling… which they used to leave around, but finally started eliminating).
Why did he not answer the question? Well, because he had no good answer. Clearly, the testers and developers assigned to fix the bug got it wrong. Michael Howard is probably furious at them. He’s probably exercising the maxim: “If you can’t say anything good, don’t say anything at all.”
Remember, you can’t take most Microsofties at face value (or people from any other organization, for that matter) when there’s a marketing impact to what they’re saying. This vulnerability demonstrates a pretty serious failure of the SDL patch process somewhere, and hopefully whoever was responsible has either reformed or moved on.
Lessons learned: Do not use MS software and Linux is superior.
Edited 2007-04-29 15:54
i keep having to remind myself that they are not talking about Simple Directmedia Layer…
“””
i keep having to remind myself that they are not talking about Simple Directmedia Layer…
“””
Sure they are. Holes like the “Animated Cursor” one give attackers a simple direct layer that they can use to format disk media or access ethernet media to run their servers. 😉
“Holes like the “Animated Cursor” one give attackers a simple direct layer that they can use to format disk media or access ethernet media to run their servers. ;-)”
That’s why we’re not using modern stuff like strcat() and strcpy() in UNIX world, we find ourselves bound in limits using ancient stuff like strlcat() and strlcpy(). 🙂
#include (string.h)
size_t strlcpy(char *dst, const char *src, size_t size);
size_t strlcat(char *dst, const char *src, size_t size);
From the article:
In the Windows Vista process, we banned certain APIs, like strcpy and strncpy, and changed well over 140,000 calls to use safer calls.
If you read from “man strcpy”, you’ll find the following SECURITY CONSIDERATIONS: The strcpy() function is easily misused in a manner which enables malicious users to arbitrarily change a running program’s functionality through a buffer overflow attack. (See the FSA and EXAMPLES.)
Maybe “Vista’s” API problem here is because of compatibility reasons…
And from Xepol’s comment (beneath the article):
“Dropping functions like strcpy and memcpy make it easier to avoid bad patterns, but the problem starts even earlier – you MUST check the data you accepting to see if it is valid. Does it fit into a buffer? Does the size value provided match the size of the data provided? What is the extra bit of data hanging off the end? Is a 200K URL reasonable? How many headers does an HTTP request really need?
He’s right. Because strlcat() and strlcpy() are not portable (as far as I know they’re BSD only: “Note that because strlcpy(3) is not defined in any standards, it should only be used when portability is not a concern.”), data entering a function should always be checked before doing anything else. C++ and Java provide good means with TRY and CATCH, but even ye olde plain C offers assert() via assert.h, along with the usual tests like != NULL etc.
“Dropping functions like strcpy and memcpy make it easier to avoid bad patterns, but the problem starts even earlier – you MUST check the data you accepting to see if it is valid. Does it fit into a buffer? Does the size value provided match the size of the data provided? What is the extra bit of data hanging off the end? Is a 200K URL reasonable? How many headers does an HTTP request really need?
I agree with his comments but i disagree with the ASSERTION that this is only way or replacing unsafe API is not useful.
When you are developing software, mistakes can happen. You may miss some places where the input is not fully validated or you miss some edge cases. Using safe API ensures that a malformed input will not cause security problems.
Using RtlStringCchCopy ensures that you never right past the destination buffer size. This is much safer than relying upon the source buffer being NULL terminated like what strcpy does.
I think memcpy should surely be replaced with memcpy_s as it will prevent accidental errors.
“I agree with his comments but i disagree with the ASSERTION that this is only way or replacing unsafe API is not useful.”
I’d say a clean-up of the API is one step, but not the complete way.
“When you are developing software, mistakes can happen.”
The usual “off by 1” mistake. 🙂
“Using safe API ensures that a malformed input will not cause security problems.”
The API should restrict errors to the application itself, so, if we assume the worst case, the application coredumps, but the system itself is not affected. Of course, this is very complicated for system related software, such as drivers.
“I think memcpy should surely be replaced with memcpy_s as it will prevent accidental errors.”
There should be abstraction layers that could be used, maybe they’re based upon memcpy(), but do neccessary checking and helping the programmer with this means.
Using unsafe languages for anything exposed to untrusted data is a bad idea. It’s 2007 for god’s sake, shouldn’t we be beyond this? All those contortions they’re suggesting (the boatload of acronyms) would be entirely unnecessary if they weren’t writing in C/C++ to begin with. In a safe language, you can’t have buffer overflows, period. That is not to say that programs written in secure languages cannot have security exploits, but rather that any attack vectors that rely on breaking memory safety are blocked. That’s a huge class of blocked errors (conventional wisdom says that about 50% of security bugs are memory-error related).
There is a lot of good research into this field, and its about time somebody applied it. For example, the Coyotos secure operating system is being written in a safe language called BitC: http://www.bitc-lang.org/docs/bitc/spec.html.
Just unplug the mouse… Windows doesn’t use a GUI, right?
“Windows doesn’t use a GUI, right?”
I always thought “Windows” is a GUI… 🙂
I know.. excuse the sarcasm.
The only lesson I learn from these types of bugs is not to use C any more: the chances of introducing a nasty problem like this are much higher than for other languages.
Sure except for all the people who allowed the action because they have been conditioned to just allow everything or because the exploit cleverly hid itself in with other actions the user did want to allow.
Microsoft can conveniently wash their hands of this of course and blame the user since Vista’s idea of security is to just make everything the users problem.