A blog about reverse engineering, mathematics, politricks and some more ...

Friday, April 27, 2007

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, whichis 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.

"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 morecommon that people do not understand thatthe last parameter to strncpy()is not the length of the source buffer :-)

About Me

I like simple things. And complex things. And drinking beer with people like Fyodor Yarochkin.
I like South America. And some parts of Asia, specifically Kuala Lumpur.
I like French. I like Spanish. I'd like to like more languages.