The problem is that in many companies the pressure is to make the schedule rather than to write robust code. Additionally, the knowledge base of competent z/OS programmers grows smaller each year. I have encountered numerous cases of this and other 'appalling' coding practices during penetration/integrity testing engagements at customer sites. So whether it irks people, or it is not the correct way to do things is not the issue. The real concern is that it does happen in real life that not all code is written to comply with the rules and therefore security exposures exist.
Lou Artificial Intelligence is no match for Natural Stupidity On Thu, Sep 24, 2009 at 8:31 AM, Scott Rowe <[email protected]> wrote: > [rant] > This whole thread really irks me. Simply the idea that a program might > move a variable length string without first checking for limits is just > appalling. I would be pretty ashamed if I found I had done that in any of > my personal programs, let alone any code I wrote when I was working for an > ISV, authorized or not. This is the very type of sloppy code that causes > many of Microsoft's security exposures. I thought that we, as a community, > had better discipline than that. > > I know I would never assume that the parm string passed to one of my > programs was no longer than 100 bytes, even if there is a JCL limitation, > simply because I wouldn't assume that I was always being called from JCL. > Even if I checked to be sure I was being called from JCL I wouldn't skip > the check, I would still write the one or two more instructions to do the > check because I can't be sure that nothing will ever change. > [/rant] > We now return you to your previously scheduled programming. > > > CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains > confidential and privileged information intended only for the addressee. If > you are not the intended recipient, please be advised that you have received > this material in error and that any forwarding, copying, printing, > distribution, use or disclosure of the material is strictly prohibited. If > you have received this material in error, please (i) do not read it, (ii) > reply to the sender that you received the message in error, and (iii) erase > or destroy the material. Emails are not secure and can be intercepted, > amended, lost or destroyed, or contain viruses. You are deemed to have > accepted these risks if you communicate with us by email. Thank you. > > > ---------------------------------------------------------------------- > 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 > ---------------------------------------------------------------------- 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
