Re: Cobol data protection? Get a dog...

From: RKRayhawk (rkrayhawk_at_aol.com)
Date: 10/01/03 

Date: 01 Oct 2003 20:46:47 GMT

KELLIEFITTON@YAHOO.COM (KELLIE FITTON)
Date: 10/1/03 12:08 PM EST
Message-id: <41758a6b.0310010908.185ca01@posting.google.com>

<<
according to the cobol book that I am reading, some Submodules that are called
in the computer's open environments memory that have "active components" or
"Java applets" can overwrite the working areas of my programs or even clobber
the global variables. Is there a way to protect my cobol's working area? should
I use win32 APIs to LOCK the memory heaps? should I get a german shepherd?

>>

This problem is universal and is not restricted to a COBOL caller. A submodule
can get to 'your' vaiables, 'your' code and global variables and even
supposedly secure executable code in memory (like the operating system itself)
.

You are doing quite well if your academic work has carried you to this
threshold already.

There is one critical factor and an important fact that will cast a perspective
on this issue for you as you start out.

The submodule needs an address to do damage. With an address it can start.
Amounts can be added to addresses or subtracted from addresses. Once a
submodule has an adress it can _potentially_ change whatever is there; code or
data, or _potentially_ change what is nearby.

You use the phrase 'open environment' I will let you define that so folks can
explore vulnerabilities in the particular kind of environment that you are
actually working with or that the book is explaining to you. 'Open' can mean a
lot of things. The only closed computer environment is one with the plug yanked
out and all batteries removed.

The basic issue is trusted computer environment versus not trusted computer
environment. Can the _humans_ who have access to your system be trusted?

The perspective is that in the olden days pieces of the systems were usually
only connected to devices in places where there were folks who could be
trusted, by and large.

Now, what is different, is that we are connecting many computer environments to
everyone.

If your schools system provides any email service for you outbound, that means
that it might actually sometimes relay email through
its memory and on to another system. It is not inconceivable that someone in a
cave on the otherside of the world could relay something through the system at
your academic institution.
It is possible that you would prefer that it not become active anywhere along
the line near you. So you have a need to understand 'active', but the issue
that has changed is proximity.

This did not used to happen. We are now connecting huge corporate information
repositories to the global net. That is a very big issue. It is a change.

A submodule, by the loose definition we may attribute to it here, has the
characteristic of being activated. An activated entity inside of a computer can
change data, code or addresses
of data or code. Because we have connected more computers to more persons with
unproven trustworthiness, anything that can become active is an important
management concern.

Active Controls, and Java Applets are only the begining. ANYTHING that can
become active is an issue. It does not matter what the source code language or
the development environment or even the runtime environment.

In addition to executable code and data, most modern systems have attributes
called privilege.
This is information that is associated with an executable, a thing which might
become active.

For example, the operating system, or even a productivity suite, might be
executed in an environment with very high privileges; allowing them to update
anything. Such high-level code may call your program (say a COBOL program),
setting you up with fairly low privileges.

When your code is invoked the operating context must hand you a return address
so that when you are done you can go home to the operating system (or Office
Suite program).

During processing you elect to invoke something. You activate by perhaps any
number of conventional strategies that are acceptable practices in your shop.
If you intend for that submodule to return to you when it is done you must pass
your return address to it. If you want that submodule do do anything to your
data you are likely to consider passing an address to your data. It is not
unlikely that the return address for the operating system was stored in a
memory location close to the data you want to
pass to the submodule.

The submodule is activated. It does many things so that the world will think it
is just real nice. But it has a malicious piece of code. It cannot execute the
bad code, because to do its evil it needs privileges it does not have and that
you do not have. It uses the address to your data that you want changed to hunt
around and find the return address that will ultimately leap from your code
back to the operating system, and switches it to the entry point for its own
malicious code.

So far no sign of trouble. The subprogram returns to you. You got great data
results from the submodule, you publish and present magnificent indications
that all is well, ... and then, .... drum roll please, ... and then you return
to the return address.

The hardware takes you now to the malicious code, and it now has the privileges
of the OS or productivity office suite that had invoked you.

This may even at first look to forensics like you did it!

There are many possibilities once you have an address.

The object oriented technologies are actually going to make this a little
worse, because they tend to cluster addresses of functions in memory. Once a
hacker finds a zone of interests there are then numerous addresses adjacent
that are of value. This will be true of COBOL object oriented code, just like
anyother. Object Orientation happens greatly modularizes code, and as a fact
collects addresses for those modules into arrays. Call them sitting ducks.

On PCs the stack pointer itself can be used to get to your stack, which is
where your invokers return address is ... there really isn't much chaining to
be done.

On a mainframe return addresses live briefly in one of the registers of the
architected register file (specifically R14). A module like your module will
must likely have saved that in a zone managed by another register (usually
R13). R13 chains are a bit more of a challenge then stack pointers. But the
technique is intended to be used by average programmers.

And more important, Intel devices are widely distributed, as are copies of the
MicroSoft packages, so bad people can experiment and research for hours on end
until they find an exploit path. The older equipment is not acutally
less vulnerable, it is just _less_ accessible for research purposes.

Eventually there will be german shepherds, but I am afraid that hardware and
software vendors are entirely prepared to see us pay a much heavy price before
any real change occurs.

Most systems do not treat addresses of code in any special way once it is
stored. That is a generic problem. If the address of executable code is stored,
and that location can be manipulated, then the system cannot be considered
secure.

Note that in object orientation, we can override methods. In some
implementations this means that the array with method addresses has selected
cells updated at instantiation time.

The larger the number of untrustworthy people connected to such a system, the
more the security decreases.

We eventually need to wrap every passed address and every stored address with
FITTON shepherd attributes. That is probably a long way off.

Best Wishes,
Bob Rayhawk
RKRayhawk@aol.com

Relevant Pages

  • Re: Cobol data protection? Get a dog...
    ... address (that normally would return to the operating system), ... to execute. ... | The submodule needs an address to do damage. ... | explore vulnerabilities in the particular kind of environment ...
    (comp.lang.cobol)
  • Re: C++ in the kernel
    ... M68K based STB with only 1.5 MB or flash and 1.5MB of RAM and no disks. ... What we got for that one engineers effort was a development environment ... STL is surprisingly damn useful. ... STL chunking of memory needs to be looked at, ...
    (freebsd-arch)
  • Re: Cool visual illusion
    ... > the environment which is important to a machine ... states (memory). ... product of our histories is a load of crock. ... It could be said that learning itself is a reward. ...
    (comp.ai.philosophy)
  • Re: PPC Write to memory in Linux
    ... a user mode program is running in it own address space, it complicates ... programmers anywhere around and they won't deal with environment specific C ... adjust a C pointer value to access a specific memory address. ...
    (alt.lang.asm)
  • Re: Kernel malloc/realloc?
    ... No, stupid is calling functions belonging to Win32, 'SYSTEM'. ... OS/2 environment at one time because the OS/2 Brief would run under NT4. ... about allocating and reallocating memory under Windows 2000+. ...
    (microsoft.public.development.device.drivers)