Microsoft seems to consider banning memcpy(). This is an excellent idea - and along with memcpy, malloc() should be banned. While we are at it, the addition and multiplication operators have caused so much grief over the last years, I think it would make total sense to ban them. Oh, and if we ban the memory dereference, I am quite sure we'd be safe.
Banning API calls is not the same as auditing code. Auditing is not supergrep. Sigh.
And "we fuzzed, but it was wrapped in an exception handler" is crazy talk. The debugger gets first notification of any exception, before the exception handler - if you are fuzzing without noting down all the exceptions that occur, you're living in ... uhm ... 2001 ?
But either way: The problem is that people think Vista will be "safe", in absolute terms, which
is false. Vista is "safer", e.g. a number of bugs won't be useful any more. Because of the false perception of Vista being "safe", some people are now disappointed (because of ANI).
Enough ranting. Everybody take a deep breath, relax, and watch the game as OS X gets owned badly for the next two years.
8 comments:
Are you serious or kidding? I'm not sure whether to be disturbed or scared....
Are you rejecting the whole idea of replacing easily-misused API calls with "safer" alternatives, or memcpy() in particular?
things like strcpy, memcpy, etc. are the straight-razors of the programming world. Yes, its perfectly possible to use them safely, but its also really easy to cut a gaping wound in yourself.
A couple of generations ago we came up with the safety razor and based on adoption rates I think most people agree that the slight reduction in quality and flexibility was worth the risk reduction.
I hope we'll be able to look back and say the same about efforts to make programming slightly/a lot safer.
Ban APIs?
Just ban C and C++, way more efficient :).
Laurent: and then you can ban operating system kernels and drivers, too!
retentive: what's the "safer alternative" to memcpy you're thinking of?
""Laurent: and then you can ban operating system kernels and drivers, too! ""
I'm glad somebody pointed this out -
"Banning" memcpy, in the sense that new code is required to use the proposed-standard memcpy_s interface, is a smart idea. Not sure how much it will do, but it's not a bad idea to put a (hopefully not arithmetically-calculated) upper bound on buffer copying.
You're correct that "auditing is not supergrep". However, you're missing the point. Microsoft is not replacing auditing with this "supergrep" approach. Rather, it is a complementary strategy -- vulnerability prevention rather than vulnerability discovery.
Microsoft doesn't have 15,000 Halvar Flakes to look over every line of Windows from top to bottom. Good thing, too, or I'd probably be looking for another job.
They have to make efficiency compromises, one of which is focusing a lot of effort on eliminating "easy" common vulnerabilities. Such tradeoffs offer the best return on a finite security dollar, by allowing the human engineers to assume a minimum standard of practice and look for "hard" vulnerabilities that automated code scanning would miss.
The problem with Microsoft's fuzzer(s) for the ANI vulnerability was that they produced files with a single anih record, where the exploit files used two. Thus, the fuzzer(s) missed it. There was no exception to be noted. Yes, Microsoft's fuzzers were lousy, but it's not due to Y2K-era design weaknesses.
Well there are functions which should be banned, just like gets() which can't just be used right. memcpy()
is not a real problem IMHO. Its much more
common that people do not understand that
the last parameter to strncpy()
is not the length of the source buffer :-)
Thomas: The 'Safer' alternatives Mr.Retentive is referring to are probably the likes of memcpy_s and co .
See http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1093.pdf
Only Microsoft have implemented any of this, AFAIK.
Post a Comment