Re: Cobol malicious code lookup
It's only possible to automate what can be formally described. Unless a programmer conveniently comments his sections of "malicious" code as such, I can think of no criteria that would make "malicious" COBOL code (or code in any other language) readily distinguishable by manual or automatic scanning from normal complex business logic. Some coding practices jump out visually as "bad" because they are highly unstructured and and difficult to maintain, or because of repeated use of constructs that are known to be inefficient; but this only relates to programming competence, not malicious intent. If the original program requirements specifications were so precise and complete as to leave nothing to the discretion of the programmer, then there might be some hope of verifying that everything in the actual code had a one-to-one relationship with the specifications - but then you would simply move the search for malicious intent from the source code to the design specifications, and in effect have the same problem. Your best bet for catching malicious code is for 3rd-party review/testing/auditing of code by someone familiar with the intended function of the code and who understands what result fields and related manipulation are especially sensitive and deserve special close examination. It goes without saying that an application should not be accessing files or database tables that are unrelated to the functional specifications of the application, but that requires an understanding of the explicit and implicit requirements of the design, not just an examination of the code. Application design, implementation, and code analysis continue to be complex tasks requiring both art and science. There are good philosophical and logical reasons why after many decades of interest in automated programming it continues to prove impossible to eliminate humans from the programming design and implementation process. Automation for detection of "malicious" code in the PC world - and we all know this malware detection is imperfect - is only possible because the definition has been narrowed considerably to (1) detection of code signatures unique to programs that have been found by empirical evidence to do bad things; (2)heuristic detection of programs that modify or access files and/or system data to which they should not have access. Security systems on MVS pretty well shut the door on these generic kinds of attacks. JC Ewing Itschak Mugzach wrote: I've tried iehiball many times in the past ;-) There must be a way to automate it. On 8/11/08, Chase, John <[EMAIL PROTECTED]> wrote: -Original Message- From: IBM Mainframe Discussion List On Behalf Of Itschak Mugzach I know some products that checks program complexity, and even those who look into specific command usage. But this time I am looking for a product to analyse mainframe traditional language (Cobol, PLI, etc) for malicious code. I have some ideas like the usage of string command, Input that come outside a file record, etc. What are you using to analyse your code? IEHIBALL. -jc- ... -- Joel C. Ewing, Fort Smith, AR[EMAIL PROTECTED] -- 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
Re: Cobol malicious code lookup
Actually, I'd -much- prefer some way to spot bugs. Didn't I read just recently about some such product inducing a bug that opened a gaping security hole? -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Itschak Mugzach Sent: Monday, August 11, 2008 2:31 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Cobol malicious code lookup I know some products that checks program complexity, and even those who look into specific command usage. But this time I am looking for a product to analyse mainframe traditional language (Cobol, PLI, etc) for malicious code. I have some ideas like the usage of string command, Input that come outside a file record, etc. What are you using to analyse your code? NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- 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
Re: Cobol malicious code lookup
Pat Sorry about the previous response. I tend to agree with you - it can be a simple matter to "scan" for "known criteria". To find items (e.g. blowing an array in CICS transaction) - that would have other consequences would be a tough chore to handle. Regards Brian Fitzgibbon SEGUS Inc On Mon, Aug 11, 2008 at 4:53 PM, Brian Fitzgibbon <[EMAIL PROTECTED]>wrote: > Pat, > > > > On Mon, Aug 11, 2008 at 3:59 PM, Patrick O'Keefe <[EMAIL PROTECTED]>wrote: > >> On Mon, 11 Aug 2008 17:12:57 +0200, Dr. Stephen Fedtke >> <[EMAIL PROTECTED]> wrote: >> >> >... >> >we are specialized in runtime-related z/OS malicious code detection, >> and >> >programcode scan for virus/malicious code on load module level >> ... >> >> Interesting. Your system can determine intent just by reading load >> modules?That's neat. I'm about to maliciously use IEBGENER >> to wipe out the directory of a library and you can detect that. >> Or I'm going to embezzle gobs of money by rounding up rather >> truncating (or whatever that technique is). >> >> Looking for a virus with an obvious signiture is maybe not too >> hard. Looking for "non normative code, a code that makes things >> not allowed or planned intentionally or not" is another matter >> altogether. I'm willing to be proven wrong, but I suspect any >> system that claims to do that would be so plagued with false >> positives (and probably false negatives) that it would be next >> to useless. >> >> Pat O'Keefe >> >> -- >> 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 >> >> > > > -- > Regards > > Brian Fitzgibbon > SEGUS Inc > (800)-327-9650 > www.segus.com > > For support: > [EMAIL PROTECTED] > > > The information contained in this e-mail and any accompanying documents may > contain information that is confidential or otherwise protected from > disclosure. If you are not the intended recipient of this message, or if > this message has been addressed to you in error, please immediately alert > the sender by reply e-mail and then delete this message, including any > attachments. Any dissemination, distribution or other use of the contents of > this message by anyone other than the intended recipient is strictly > prohibited. > -- Regards Brian Fitzgibbon SEGUS Inc (800)-327-9650 www.segus.com For support: [EMAIL PROTECTED] The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. -- 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
Re: Cobol malicious code lookup
Pat, On Mon, Aug 11, 2008 at 3:59 PM, Patrick O'Keefe <[EMAIL PROTECTED]>wrote: > On Mon, 11 Aug 2008 17:12:57 +0200, Dr. Stephen Fedtke > <[EMAIL PROTECTED]> wrote: > > >... > >we are specialized in runtime-related z/OS malicious code detection, > and > >programcode scan for virus/malicious code on load module level > ... > > Interesting. Your system can determine intent just by reading load > modules?That's neat. I'm about to maliciously use IEBGENER > to wipe out the directory of a library and you can detect that. > Or I'm going to embezzle gobs of money by rounding up rather > truncating (or whatever that technique is). > > Looking for a virus with an obvious signiture is maybe not too > hard. Looking for "non normative code, a code that makes things > not allowed or planned intentionally or not" is another matter > altogether. I'm willing to be proven wrong, but I suspect any > system that claims to do that would be so plagued with false > positives (and probably false negatives) that it would be next > to useless. > > Pat O'Keefe > > -- > 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 > > -- Regards Brian Fitzgibbon SEGUS Inc (800)-327-9650 www.segus.com For support: [EMAIL PROTECTED] The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. -- 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
Re: Cobol malicious code lookup
On Mon, 11 Aug 2008 17:12:57 +0200, Dr. Stephen Fedtke <[EMAIL PROTECTED]> wrote: >... >we are specialized in runtime-related z/OS malicious code detection, and >programcode scan for virus/malicious code on load module level ... Interesting. Your system can determine intent just by reading load modules?That's neat. I'm about to maliciously use IEBGENER to wipe out the directory of a library and you can detect that. Or I'm going to embezzle gobs of money by rounding up rather truncating (or whatever that technique is). Looking for a virus with an obvious signiture is maybe not too hard. Looking for "non normative code, a code that makes things not allowed or planned intentionally or not" is another matter altogether. I'm willing to be proven wrong, but I suspect any system that claims to do that would be so plagued with false positives (and probably false negatives) that it would be next to useless. Pat O'Keefe -- 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
Re: Cobol malicious code lookup
Stephen, I looked into your site. It doesn't cover 3rd generation languages like Cobol. Is this true? Please suply a link. Regards, ITschak On 8/11/08, Dr. Stephen Fedtke <[EMAIL PROTECTED]> wrote: > > if malicious code is generally your concern, i apologize for recommend > reading "it sec forum" at www.enterprise-it-security.com > > we are specialized in runtime-related z/OS malicious code detection, and > programcode scan for virus/malicious code on load module level > (unfortunately, not on source code level). > > best > stephen > > -- > 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
Re: Cobol malicious code lookup
if malicious code is generally your concern, i apologize for recommend reading "it sec forum" at www.enterprise-it-security.com we are specialized in runtime-related z/OS malicious code detection, and programcode scan for virus/malicious code on load module level (unfortunately, not on source code level). best stephen -- 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
Re: Cobol malicious code lookup
No, I don't mean bugs. I mean something that programmer can put into hus program that will cause a theft of money. for example, back door that can be ised to eliminate part or all services, etc. ITschak On 8/11/08, Binyamin Dissen <[EMAIL PROTECTED]> wrote: > > On Mon, 11 Aug 2008 11:01:57 +0200 Itschak Mugzach <[EMAIL PROTECTED]> > wrote: > > :>malicious code = non normative code, a code that makes things not allowed > or > :>planned intentionally or not. > > If you can define what "normative" is, you can scan for the other. > > :>Moving literals into record is suspected, not always a malicious code. > > Why? > > I do not understand your use of the term "malicious". You seem to be > referring > to possible bugs. > > :>On 8/11/08, Binyamin Dissen <[EMAIL PROTECTED]> wrote: > > :>> On Mon, 11 Aug 2008 09:30:57 +0200 Itschak Mugzach <[EMAIL PROTECTED] > > > :>> wrote: > > :>> :>I know some products that checks program complexity, and even those > who > :>> look > :>> :>into specific command usage. But this time I am looking for a product > to > :>> :>analyse mainframe traditional language (Cobol, PLI, etc) for > malicious > :>> code. > :>> :>I have some ideas like the usage of string command, Input that come > :>> outside > :>> :>a file record, etc. > > :>> :>What are you using to analyse your code? > > :>> Define "malicious code". > > :>> Why is "input that come outside a file record" malicious? > > -- > Binyamin Dissen <[EMAIL PROTECTED]> > 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 [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
Re: Cobol malicious code lookup
On Mon, 11 Aug 2008 11:01:57 +0200 Itschak Mugzach <[EMAIL PROTECTED]> wrote: :>malicious code = non normative code, a code that makes things not allowed or :>planned intentionally or not. If you can define what "normative" is, you can scan for the other. :>Moving literals into record is suspected, not always a malicious code. Why? I do not understand your use of the term "malicious". You seem to be referring to possible bugs. :>On 8/11/08, Binyamin Dissen <[EMAIL PROTECTED]> wrote: :>> On Mon, 11 Aug 2008 09:30:57 +0200 Itschak Mugzach <[EMAIL PROTECTED]> :>> wrote: :>> :>I know some products that checks program complexity, and even those who :>> look :>> :>into specific command usage. But this time I am looking for a product to :>> :>analyse mainframe traditional language (Cobol, PLI, etc) for malicious :>> code. :>> :>I have some ideas like the usage of string command, Input that come :>> outside :>> :>a file record, etc. :>> :>What are you using to analyse your code? :>> Define "malicious code". :>> Why is "input that come outside a file record" malicious? -- Binyamin Dissen <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Cobol malicious code lookup
> -Original Message- > From: IBM Mainframe Discussion List > [mailto:[EMAIL PROTECTED] On Behalf Of Chase, John > Sent: Monday, August 11, 2008 6:50 AM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: Cobol malicious code lookup > > > -Original Message- > > From: IBM Mainframe Discussion List On Behalf Of Itschak Mugzach > > > > I know some products that checks program complexity, and even > > those who look into specific command usage. But this time I > > am looking for a product to analyse mainframe traditional > > language (Cobol, PLI, etc) for malicious code. > > I have some ideas like the usage of string command, Input > > that come outside a file record, etc. > > > > What are you using to analyse your code? > > IEHIBALL. > > -jc- Nah! We just assume the code is 100% perfect. Until it actually runs in production for the first time. Then it usually abends and we just whine at somebody. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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
Re: Cobol malicious code lookup
I've tried iehiball many times in the past ;-) There must be a way to automate it. On 8/11/08, Chase, John <[EMAIL PROTECTED]> wrote: > > > -Original Message- > > From: IBM Mainframe Discussion List On Behalf Of Itschak Mugzach > > > > I know some products that checks program complexity, and even > > those who look into specific command usage. But this time I > > am looking for a product to analyse mainframe traditional > > language (Cobol, PLI, etc) for malicious code. > > I have some ideas like the usage of string command, Input > > that come outside a file record, etc. > > > > What are you using to analyse your code? > > IEHIBALL. > >-jc- > > -- > 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
Re: Cobol malicious code lookup
> -Original Message- > From: IBM Mainframe Discussion List On Behalf Of Itschak Mugzach > > I know some products that checks program complexity, and even > those who look into specific command usage. But this time I > am looking for a product to analyse mainframe traditional > language (Cobol, PLI, etc) for malicious code. > I have some ideas like the usage of string command, Input > that come outside a file record, etc. > > What are you using to analyse your code? IEHIBALL. -jc- -- 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
Re: Cobol malicious code lookup
malicious code = non normative code, a code that makes things not allowed or planned intentionally or not. Moving literals into record is suspected, not always a malicious code. ITschak On 8/11/08, Binyamin Dissen <[EMAIL PROTECTED]> wrote: > > On Mon, 11 Aug 2008 09:30:57 +0200 Itschak Mugzach <[EMAIL PROTECTED]> > wrote: > > :>I know some products that checks program complexity, and even those who > look > :>into specific command usage. But this time I am looking for a product to > :>analyse mainframe traditional language (Cobol, PLI, etc) for malicious > code. > :>I have some ideas like the usage of string command, Input that come > outside > :>a file record, etc. > > :>What are you using to analyse your code? > > Define "malicious code". > > Why is "input that come outside a file record" malicious? > > -- > Binyamin Dissen <[EMAIL PROTECTED]> > 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 [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
Re: Cobol malicious code lookup
On Mon, 11 Aug 2008 09:30:57 +0200 Itschak Mugzach <[EMAIL PROTECTED]> wrote: :>I know some products that checks program complexity, and even those who look :>into specific command usage. But this time I am looking for a product to :>analyse mainframe traditional language (Cobol, PLI, etc) for malicious code. :>I have some ideas like the usage of string command, Input that come outside :>a file record, etc. :>What are you using to analyse your code? Define "malicious code". Why is "input that come outside a file record" malicious? -- Binyamin Dissen <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Cobol malicious code lookup
I know some products that checks program complexity, and even those who look into specific command usage. But this time I am looking for a product to analyse mainframe traditional language (Cobol, PLI, etc) for malicious code. I have some ideas like the usage of string command, Input that come outside a file record, etc. What are you using to analyse your code? -- 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
