paulgboul...@aim.com (Paul Gilmartin) writes: > And here, I find myself in rare agreement with John G.'s view > (if I understand correctly). A char[] containing no \0 is a perfectly > valid array of char. It is not a string, by C's convention, and there > is no requirement that a char[] represent a string.
in the 90s, C-language string related buffer exploits were top of internet attacks. I've been on campaign about this for long time. lots of past posts http://www.garlic.com/~lynn/subintegrity.html#overflow the mainframe TCP/IP stack from the 80s was done in vs/pascal and had none of the C-language buffer length related problems. The implementation had a few other performance issues ... getting 44kbytes/sec thruput using nearly whole 3090 processor. I did the changes for RFC1044 support and in some performance tests at cray research got channel media thruput between 4341 and cray using only modest amount of 4341 processor http://www.garlic.com/~lynn/subnetwork.html#1044 also, air force performance evaluation of Multics (implemented in PLI) noted that it had no buffer length related problems. Old post about IBM Research update of the Air Force Multics study http://www.garlic.com/~lynn/2002l.html#42 Thirty Years Later: Lessons from the Multics Security Evaluation This is post about analysis I did of the Mitre CVE exploit database ... looking for ways to improve my merged security taxonomy & glossary (and how you do you structure thinking about security) http://www.garlic.com/~lynn/2004e.html#43 security taxonomy and CVE I suggested to mitre that they start requiring reports to have a little more structured information since they were quite free-form at the time. Their response was that they were lucky to get reports in any form at all ... adding structure form requirements afraid some people would just not do the report (although they have since started advising about more structure in the reports). Later , NIST came out with analysis that exploits were approx. nearly 1/3rd buffer related, 1/3rd automated script execution, and 1/3rd social engineering (with various other misc.). I periodically mention this meeting in ellison's conference room http://www.garlic.com/~lynn/95.html#13 a couple weeks later cluster scaleup is transferred and we are told we couldn't work on anything with more than four processors ... motivating us to leave. A couple of the other people mentioned in the meeting, later leave and show up at small client/server startup responsible for something called "commerce server". We get brought in as consultants because they want to do payment transactions on the server, the startup had also invented this technology called "SLL" they want to use, the result is now frequently called "electronic commerce". Part of the deployment for "electronic commerce" was developing something called a "payment gateway" ... sits on the internet and handles transactions between webservers and the payment networks (we periodically refer to it as the original SOA). misc. past posts mentioning payment gateway http://www.garlic.com/~lynn/subnetwork.html#gateway Part of protection for the payment gateways there are multiple layers of firewalls and other kinds of filters. A common internet attack is long strings ... attempting to leverage buffer-overflow vulnerabilities found in about anything implemented in C-language ... so part of the intermediate security layers are checks for excessive long strings. We also have do do audits/reviews of SSL, digital certificates, certificate issuing authorities, etc ... and come up with some requirements about how things are deployed. Almost immediately the requirements are violated and we start referring to it as "comfort security" (aka security that provides feeling of comfort to all the users). -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
