Re: Do and don't in programing (Security wise)
Itschak Mugzach wrote: Any other ideas? Don't write code that branches into the middle of an instruction - with proper choice of base registers and displacements, it's possible to write a chain of code contained in another, but definitely not recommended. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Do and don't in programing (Security wise)
On Tue, 3 Mar 2009 16:40:31 -0500, Gerhard Postpischil gerh...@valley.net wrote: Itschak Mugzach wrote: Any other ideas? Don't write code that branches into the middle of an instruction - with proper choice of base registers and displacements, it's possible to write a chain of code contained in another, but definitely not recommended. Gerhard Postpischil Bradford, VT Well, that defeats one of my forced abend techniques: BRC cond,*+2 This branches into the middle of the BRC (Jump) instruction, which in this case is always x'0001', resulting in an S0C1 abend. Other than that one instance, I totally agree with you. -- John -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Do and don't in programing (Security wise)
Itschak Mugzach wrote: I am looking for some rules of Thumb regarding what is improper to code in a program (say Cobol, but in general, any language) from security point of view. Are there any resources on that any where? Some examples: - Do nit use literals of variables containing Account numbers, SSNs, Etc. in your program. - Use pure programming (impure is a program that modifies it self) Any other ideas? Although I instinctively understand the 1st one, I'm having problems understanding the second one. What are the security implications of self modifying code (then again, it's hard to actually define self modifying code). I understand that Virii, Annelids Western Anatolian equines are species that sometimes do that, but does it mean that all programs that do so have malevolent intents or present a security risk ? Then again, depending on the scope of the 'self modifying' definition, it is very common use.. An operating system may alter portions of storage through I/O operations and then eventually alter (runtime link/edit) that storage area before transferring control to it.. A java program doing some reflection may load an arbitrary class from within that same program and again transfer control to it.. Even something as common as a 'bootstrap' or IPL program has to do that. However, here is my little catalog of 'bad practice' security wise (these are not really mainframe specific though !) - Assuming externally acquired data is safe, correct and reasonable - Using fixed buffer sizes with no boundary checking - Relying on obfuscation to implement security features - Leaving debugging back doors/test admin credentials - Logging too much information about incorrect credentials (ex: logging user name for an unknown user.. oops.. he typed his password instead of his user name !) - Relying on obscure and undocumented API behavior (it WILL change eventually.. And when it happens.. buffer overflows whatnot will happen !) - Assuming you can be lax because you are protected by a 3rd party protection mechanism (which never fails.. right ?) - Assuming in-storage data is private (of course, you will need to have sensitive data in storage at one time or another.. just discard/wipe it ASAP when you're done with it) - Generally, assuming a client will behave - Not testing for errors and ignoring exceptions - Giving too much authorization to a program because it is more practical There are probably 100s more.. but that are the one that I could think of at this moment. --Ivan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Do and don't in programing (Security wise)
On 3 Mar 2009 14:14:45 -0800, in bit.listserv.ibm-main (Message-ID:listserv%200903031608076036.0...@bama.ua.edu) joa...@swbell.net (John McKown) wrote: Well, that defeats one of my forced abend techniques: BRC cond,*+2 This branches into the middle of the BRC (Jump) instruction, which in this case is always x'0001', resulting in an S0C1 abend. SOC1s are too common to stand out. I prefer EX R15,*(Of course, it doesn't matter which register.) -- I cannot receive mail at the address this was sent from. To reply directly, send to ar23hur at intergate dot com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Do and don't in programing (Security wise)
On Tue, 3 Mar 2009 18:05:42 -0500 Arthur T. ibmm...@intergate.com wrote: :On 3 Mar 2009 14:14:45 -0800, in bit.listserv.ibm-main :(Message-ID:listserv%200903031608076036.0...@bama.ua.edu) :joa...@swbell.net (John McKown) wrote: : :Well, that defeats one of my forced abend techniques: : : BRC cond,*+2 : :This branches into the middle of the BRC (Jump) :instruction, which in this :case is always x'0001', resulting in an S0C1 abend. : :SOC1s are too common to stand out. I prefer :EX R15,*(Of course, it doesn't matter which :register.) Problem with EX * is that you need branch around it. I like John's idea. I still use an old fashioned branch to an odd address BCcond,0 org *-2 dcs(*+1) to force the most uncommon 0c6 -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Do and don't in programing (Security wise)
Arthur T. wrote: Well, that defeats one of my forced abend techniques: BRC cond,*+2 This branches into the middle of the BRC (Jump) instruction, which in this case is always x'0001', resulting in an S0C1 abend. SOC1s are too common to stand out. I prefer EX R15,*(Of course, it doesn't matter which register.) Yes.. But EX xx,* does require a base register, whereas BRC COND,*+2 doesn't (it's a relative instruction) Furthermore, BRC has the advantage of only raising a program interrupt if the condition is met (so it's a nice 'assert()' alternative). BRC COND,*+3 would generate a nice specification exception - which is a little less common than PIC 1, but the assembler would probably throw an alignment warning there ! You may also, in this case do a BC COND,1 which would generate a specification exception, requires no base register and also works reliably without needing the Branch Relative Feature to be installed - but still generates the unaligned warning in the assembler.. And unfortunately, you also lose the instruction address instruction that generated the problem.. come to think of it, it's a bad idea :P --Ivan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Do and don't in programing (Security wise)
I have To agree with Ben -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Binyamin Dissen Sent: Tuesday, March 03, 2009 3:19 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Do and don't in programing (Security wise) On Tue, 3 Mar 2009 18:05:42 -0500 Arthur T. ibmm...@intergate.com wrote: :On 3 Mar 2009 14:14:45 -0800, in bit.listserv.ibm-main :(Message-ID:listserv%200903031608076036.0...@bama.ua.edu) :joa...@swbell.net (John McKown) wrote: : :Well, that defeats one of my forced abend techniques: : : BRC cond,*+2 : :This branches into the middle of the BRC (Jump) :instruction, which in this :case is always x'0001', resulting in an S0C1 abend. : :SOC1s are too common to stand out. I prefer :EX R15,*(Of course, it doesn't matter which :register.) Problem with EX * is that you need branch around it. I like John's idea. I still use an old fashioned branch to an odd address BCcond,0 org *-2 dcs(*+1) to force the most uncommon 0c6 -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Do and don't in programing (Security wise)
I am looking for some rules of Thumb regarding what is improper to code in a program (say Cobol, but in general, any language) from security point of view. Are there any resources on that any where? Some examples: - Do nit use literals of variables containing Account numbers, SSNs, Etc. in your program. - Use pure programming (impure is a program that modifies it self) Any other ideas? Itschak -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
