RE: cobol language vulnerabilities

[Michael Wojcik <Michael.Wojcik () microfocus com>]

> 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