> One of the management types near me is concerned about TCPIP "buffer > overrun security exposure" on our ZVM 5.2 Z890 system. > Should I be concerned with buffer overrun security exposures? If I > should not be concerned, how would I go about giving comfort to the > concerned management types?
1) The VM TCPIP stack is not based on the common BSD roots of the Unix and Windows TCP implementations. It is not susceptible to attacks based on code analysis of the BSD code. 2) The stack, event and buffer structure used in the VM TCP code is so dramatically weird/different that even if a attacker were to be able to insert code, it would: a) be unlikely to be valid executable code (typically the script kiddie tools only understand Intel CPUs, which don't mean diddly on a zSeries) b) the stack structure is completely different, forcing the code to at worst abend due to jumping off into hyperspace, which kicks you back out, and is kind of obvious. 3) The stack and applications using the stack are in separate virtual machines, allowing enforcement of code separation by the zSeries hardware. It is probably(*) impossible to overwrite the stack in the application from the TCP virtual machine (the only path between them is IUCV or VMCF communications, which are mediated by CP). 4) Aside from the somewhat antique server application implementations supplied (IMHO, a much larger hazard than the stack itself), a goodly majority of the stack code is written in languages that enforce strict type and buffer range checking (Pascal and PL/X don't let you play fast and loose with that kind of stuff). 5) The portions of the VM TCP code that perform multitasking do not operate in a shell environment. There's no command line or shell to compromise or take control of -- at best, you can kill the compromised service, which promptly kicks you back out. 6) Even if you did somehow manage to get access at a console: a) the system password database is not inside the filesystem, and cannot be accessed without generating a loggable event b) Most of the VM TCP servers run as class G users, without privileges. c) The few services that do have privileges (FTP, NFS) require code to authorize their privileged access that is not executable from the command line w/o program development (yes you can assume an id's authority to link stuff, but you have to write a program to do it, and most TCP service machines do not have access to compilers). d) (bad to rely on, but included for completeness) CMS is a very foreign environment for your average script kiddie. If it doesn't look like bash, most of them are hopeless. Short version: it ain't your common garden-variety TCP stack. The common attacks don't work. -- db (*) = I can't think of a way to do it. Some smart person probably could, but I think you'd be back at breaking the app kicking you out when the app died.
