> they relied on well-documented limitations which have been around for decades.
Not so. The restriction is in JCL, not in the program entry linkage. It has always been possible to call any program - including any program normally executed as a jobstep program (PGM=) - and pass any length of parameters up to 32,767. In fact, if you write a program, you really should be prepared that the caller may have passed you utter nonsense (or something that made sense to the programmer who wrote it but is not what you expected). As Gil pointed out, the ONLY new exposure is for authorized programs. Formerly, an authorized program could be confident that it's caller was either JCL or another trusted (authorized) program. It would thus be a reasonably valid assumption that the authorized program would either get >= 100 bytes of parms from JCL or something "proper" (however that might be defined) from an authorized caller. For non-authorized programs, a buffer overflow might produce a S0C1 or the like, but so might any user error - say specifying a PDS when it expected a QSAM file, or a parameter card in a bad format. With PARM= >100 characters, for the first time, the authorized program expecting <= 100 bytes might be subject to malicious buffer overflow from an untrusted source. The solution is a linker set bit similar to AC=1 that says "this authorized program expects that it might get > 100 bytes if invoked from JCL." Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Arthur T. Sent: Friday, May 13, 2005 12:57 PM To: [email protected] Subject: Re: PARM= On 13 May 2005 11:21:51 -0700, in bit.listserv.ibm-main (Message-ID:<[EMAIL PROTECTED]>) [EMAIL PROTECTED] (Shmuel Metz , Seymour J.) wrote: >In <[EMAIL PROTECTED]>, on >05/12/2005 > at 10:19 PM, "Arthur T." <[EMAIL PROTECTED]> said: > >> At first, I agreed with this, for two reasons >> (details below): > >>1. It obviates the buffer overflow problem. > >How? If the data from the DD are moved into the first >parameter with a >halfword length, then the effect is the same as simply >allowing a >longer PARM. Anything else and existing programs won't be >able to >handle the new keyword. You are correct. I'm not sure what I was thinking. However, I'd like to say a bit more about the potential for buffer overflow. Bob Rutlege wrote that he doesn't expect his shop to have a problem. However, there are a lot of z/OS shops. If there's a security breach in *any* of them because of a buffer overflow problem, z/OS will seem, to the average news consumer, no more secure or stable than those other operating systems. Managers who make platform decisions based on airline magazines will see even less benefit from the mainframe than they did before. Letting the end-user dictate whether he'll send more than 100 bytes of parm data to a program could break existing programs. Those programs shouldn't be called badly-written; they relied on well-documented limitations which have been around for decades. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
