RE: cobol language vulnerabilities

From: Michael Wojcik (Michael.Wojcik_at_microfocus.com)
Date: 04/26/04

  • Next message: keratox: "os/2 shellcode"
    To: vuln-dev@securityfocus.com
    Date: Mon, 26 Apr 2004 06:35:39 -0700
    
    

    > From: Kevin Partridge [mailto:kgp@nethere.com]
    > Sent: Thursday, April 22, 2004 9:03 PM
    >
    > I'm doing a paper on language issues in secure coding. ...
    > I'd like to know where I could start with Cobol. I've already gotten the
    > standard.

    That's a very broad subject, obviously. I'm certainly not a COBOL expert
    (or a security one), but here are a few thoughts which may be helpful:

    - Obviously, the standard is important. However, in practice, I think
    implementation and configuration details will have far greater impact on
    secure coding issues. For example, whether bounds checking is enabled for
    certain operations will obviously affect certain buffer overflow
    vulnerabilities. (The semantics specified in the standard are probably more
    important for questions of secure design rather than secure implementation;
    I assume by "secure coding" you're considering the latter.)

    For that reason, you may be better off selecting a particular implementation
    and build configuration, investigating that, and then speculating at the end
    of your investigation how much of it might typically apply to other
    implementations.

    - COBOL has a large run-time environment providing a wide array of
    facilities to the COBOL program: buffer manipulation (eg the MOVE verb),
    string operations (eg STRING or INSPECT), device and file I/O (eg DISPLAY or
    OPEN), and so on. It also has intrinsic functions (mathematical ones like
    MOD, and string ones like REVERSE). And any implementation will provide
    various system services; for example, Micro Focus COBOL has library routines
    for obvious things like memory allocation, threading, and filesystem
    operations; for things which aren't provided by the standard language like
    bit manipulation; and for all sorts of less-obvious functions.

    The run-time environment generally is not implemented in COBOL, and so is an
    important source of potential implementation vulnerabilities which are not
    inherent in the COBOL language itself but will apply in some degree to all
    COBOL programs. Since each COBOL vendor implements their own runtime, you
    can't draw firm conclusions in general about secure COBOL use of runtime
    facilities; the most you'd be able to say is that such-and-such an operation
    is potentially dangerous, since it lends itself to insecure implementation.

    - COBOL is a *big* language, and it's getting bigger (note the introduction
    of OO constructs a few years ago, for example). COBOL is a classic example
    of feature creep and the effects of late standardization; over the decades
    vendors added all sorts of extensions to address various COBOL development
    needs, and consequently the language is quite a mishmash of features. COBOL
    style varies tremendously because there are so many choices of control
    structures and the like (lurking on Usenet's comp.lang.cobol for a few days
    should give you a sense of the COBOL style wars).

    A few comments on specific areas:

    - COBOL has a unique data-typing model. Though this blurs into the area of
    secure design, it's worth looking at how edited and computational numeric
    items interact, for example, and what sort of security effects that has.

    - As you might expect, pointer arithmetic (see the SET verb and the USAGE
    POINTER data-item qualifier) and reference modification (ie array indexing)
    are common sources of error.

    - Some COBOL syntax constructs are dangerous because they can easily lead to
    hard-to-spot errors (similar to mistyping "==" as "=" in C). See for
    example the discussion of the use of COBOL "sentences" and the period
    character on alt.folklore.computers a couple of months back.[1]

    Hope that helps.

    1. http://groups.google.com/groups?selm=c0geo30vuq%40enews4.newsguy.com

    -- 
    Michael Wojcik                  Software Systems Developer, Comms 
    phone 517 676-0892              Micro Focus 
    mobile 517 862-9464             Mason, Michigan 
    

  • Next message: keratox: "os/2 shellcode"

    Relevant Pages

    • Re: Java compatibility issues (WAS: MF having issues?)
      ... syntax than add a standard XML library to COBOL. ... Adding "native language support" for IBM's Enterprise ...
      (comp.lang.cobol)
    • Re: Cobol language dictionary page -- assignment complete?
      ... > REMARKS Paragraph. ... >> an IBM-ism, it is, nonetheless, no longer standard COBOL ... >> representative of recent standard COBOL. ... COBOL is, is to do a disservice to the language and, ...
      (comp.lang.cobol)
    • Re: Where are spaces required in COBOL source code?
      ... Was this ever part of a COBOL standard? ... The basic concept stems from the historical fact that the rules for COBOL ... In the rules of the COBOL language, the concept of "separator" as a ... long as you have at least one space between the arguments, the compiler ...
      (comp.lang.cobol)
    • Re: Unicode setting question
      ... COBOL is an interesting language; it was 20 years ahead of its time, ... Trying to move toward standard instead of making it easier to create ... Windows programs will be the death of VC++ in my opinion. ...
      (microsoft.public.vc.mfc)
    • Re: Why C Is Not My Favourite Programming Language
      ... >:COBOL is very serious indeed. ... but a single standard) is quite important. ... support for XML parsing and generation in the language. ... developers have managed to deal with it. ...
      (comp.lang.c)