I've heard C referred to as a glorified assembler. That's no insult. Fond as I am of IBM assembler, it's useless on PA-RISC, Power, INTeL, so on. Fond as I am of assembler (more control, more efficient) I use C as often as I can because it approaches the capabilities of assembler but wider applicability.
The IBM (VM) TCP/IP stack was originally all written in Pascal. Someone who knows its innards (ie: Endicott) will have to say what percentage of that remains. I believe that the MVS TCP/IP stack was entirely re-written (most likely in Poughkeepsie), possibly in C.
-- R,
| Alan Ackerman
<[EMAIL PROTECTED]>
Sent by: The IBM z/VM Operating System <[email protected]> 07/20/2006 01:40 AM Please respond to The IBM z/VM Operating System <[email protected]> |
|
ET (Eric Thomas, the author of the Revised LISTSERV) told me on VMSHARE many, 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 buffer 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 language) -- but the same
damn errors keep popping up over and over and over again in C code in Unix and Windows.
To the extent that large parts of the VM TCP/IP stack are written in C, the exposure exists. I'm
sure that IBM is well aware of this, and I hope they have found and plugged all such holes, but
there can be no guarantee.
What does your security person propose you DO about this possibility? What 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 fix 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
