tag:blogger.com,1999:blog-14114712.post7989128370120282796..comments2024-03-03T02:04:07.138-08:00Comments on ADD / XOR / ROL: halvar.flakehttp://www.blogger.com/profile/12486016980670992738noreply@blogger.comBlogger8125tag:blogger.com,1999:blog-14114712.post-12687917930015540732007-06-20T02:03:00.000-07:002007-06-20T02:03:00.000-07:00Thomas: The 'Safer' alternatives Mr.Retentive is r...Thomas: The 'Safer' alternatives Mr.Retentive is referring to are probably the likes of memcpy_s and co . <BR/><BR/>See http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1093.pdf<BR/><BR/>Only Microsoft have implemented any of this, AFAIK.chhttps://www.blogger.com/profile/16816295953605176082noreply@blogger.comtag:blogger.com,1999:blog-14114712.post-7269146563367419992007-05-29T23:43:00.000-07:002007-05-29T23:43:00.000-07:00Well there are functions which should be banned, j...Well there are functions which should be banned, just like <I>gets()</I> which can't just be used right. <I>memcpy()</I><BR/>is not a real problem IMHO. Its much more<BR/>common that people do not understand that<BR/>the last parameter to <I>strncpy()</I><BR/>is not the length of the source buffer :-)Sebastianhttps://www.blogger.com/profile/11886596387140041622noreply@blogger.comtag:blogger.com,1999:blog-14114712.post-35235073552548014272007-05-10T10:20:00.000-07:002007-05-10T10:20:00.000-07:00"Banning" memcpy, in the sense that new code is re..."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.<BR/><BR/>You're correct that "auditing is not supergrep". However, you're missing the point. Microsoft is not <B>replacing</B> auditing with this "supergrep" approach. Rather, it is a complementary strategy -- vulnerability prevention rather than vulnerability discovery.<BR/><BR/>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.<BR/><BR/>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.<BR/><BR/>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.Matt Murphyhttps://www.blogger.com/profile/07213404538662394775noreply@blogger.comtag:blogger.com,1999:blog-14114712.post-17196378053878437312007-05-08T09:04:00.000-07:002007-05-08T09:04:00.000-07:00""Laurent: and then you can ban operating system k...""Laurent: and then you can ban operating system kernels and drivers, too! ""<BR/><BR/>I'm glad somebody pointed this out -Anonymoushttps://www.blogger.com/profile/07679491472819066807noreply@blogger.comtag:blogger.com,1999:blog-14114712.post-79518239122363567532007-05-06T15:49:00.000-07:002007-05-06T15:49:00.000-07:00retentive: what's the "safer alternative" to memcp...retentive: what's the "safer alternative" to memcpy you're thinking of?Thomas Ptacekhttps://www.blogger.com/profile/14479575601987181670noreply@blogger.comtag:blogger.com,1999:blog-14114712.post-5930480587585321092007-05-06T15:48:00.000-07:002007-05-06T15:48:00.000-07:00Laurent: and then you can ban operating system ker...Laurent: and then you can ban operating system kernels and drivers, too!Thomas Ptacekhttps://www.blogger.com/profile/14479575601987181670noreply@blogger.comtag:blogger.com,1999:blog-14114712.post-70266938626687054682007-05-05T00:39:00.000-07:002007-05-05T00:39:00.000-07:00Ban APIs?Just ban C and C++, way more efficient :)...Ban APIs?<BR/><BR/>Just ban C and C++, way more efficient :).Laurent GUERBYhttps://www.blogger.com/profile/07853443595550043492noreply@blogger.comtag:blogger.com,1999:blog-14114712.post-90874064802325123702007-05-03T14:25:00.000-07:002007-05-03T14:25:00.000-07:00Are you serious or kidding? I'm not sure whether ...Are you serious or kidding? I'm not sure whether to be disturbed or scared....<BR/><BR/>Are you rejecting the whole idea of replacing easily-misused API calls with "safer" alternatives, or memcpy() in particular?<BR/><BR/>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. <BR/><BR/>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.<BR/><BR/>I hope we'll be able to look back and say the same about efforts to make programming slightly/a lot safer.Andy Steingrueblhttps://www.blogger.com/profile/07177656204885181542noreply@blogger.com