Re: Cobol data protection? Get a dog...
From: John Ford (zjcf)
Date: 10/15/03
- Next message: Louis De Bevere: "pl/i"
- Previous message: KELLIE FITTON: "Anchor the ship of cobol..."
- In reply to: RKRayhawk: "Re: Cobol data protection? Get a dog..."
- Next in thread: RKRayhawk: "Re: Cobol data protection? Get a dog..."
- Reply: RKRayhawk: "Re: Cobol data protection? Get a dog..."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 15 Oct 2003 12:46:15 -0500
Regarding the technique of replacing a calling program's return
address (that normally would return to the operating system), such
that when the calling program returns to its caller, it instead
goes to malicious code: I would think that the outcome would be
highly platform dependent.
The only platform with which I'm intimately familiar is an IBM
mainframe. In that case, simply changing the return address will
not change the security/permissions/rights context. You're simply
diverting execution to the malicious code with the exact same
context that the program had. The fact that the program that
called the malicious code is now "returning" to malicious code
doesn't change anything except the address of the next instruction
to execute.
Which platforms let you change permissions by altering a return
address?
-jcf
"RKRayhawk" <rkrayhawk@aol.com> wrote in message
news:20031001164647.10007.00000087@mb-m21.aol.com...
|
| 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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- Next message: Louis De Bevere: "pl/i"
- Previous message: KELLIE FITTON: "Anchor the ship of cobol..."
- In reply to: RKRayhawk: "Re: Cobol data protection? Get a dog..."
- Next in thread: RKRayhawk: "Re: Cobol data protection? Get a dog..."
- Reply: RKRayhawk: "Re: Cobol data protection? Get a dog..."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
