ET (Eric Thomas, the author of the Revised LISTSERV) told me on VMSHARE m any, many years ago that the underlying cause of most buffer overruns is the C language. The basic concept of moving characters until you find a x'00' (or CR or LF) will ALWAYS lead to buffe r overruns. (A number of the built-in functions in C have this problem, too.)
Of course, it's possible to write good code in C (and bad code in ANY lan guage) -- but the same damn errors keep popping up over and over and over again in C code in Uni x and Windows. To the extent that large parts of the VM TCP/IP stack are written in C, t he exposure exists. I'm sure that IBM is well aware of this, and I hope they have found and plugg ed all such holes, but there can be no guarantee. What does your security person propose you DO about this possibility? Wha t does he do for other operating systems? Usually the answer is, apply fixes in a timely manner. Tell him you do that. (You do, don't you?) Tell him that you keep in touch with your colleagues . Hint that going to SHARE would be a good idea, too. There is an issue here. When a security exposure is found, do you publish it or hide it? Most of the security world thinks it is better to publish the information -- once a f ix is available. They deride "security by obscurity". IBM, however, does not publish such information for VM -- the security or integrity APARs contain no information about what is being fixed. I'm not going to say this is good or bad -- but it sure makes it hard to answer a question such as "how common are buffer overruns in VM"? Personally, I've only seen two security exposures in VM. Neither was due to a buffer overflow. That's an awfully small sample, though. Alan Ackerman Alan -dot- Ackerman -at- Bank of America -dot- com
