RE: iSeries buffer overflow immunity? -- MIDRANGE-L

Amen to that Scott and thanks for the enlightening bunch of information !

Chuck

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Wednesday, November 03, 2004 8:03 PM
To: Midrange Systems Technical Discussion
Subject: Re: iSeries buffer overflow immunity?


> Is the iseries invulnerable to buffer overflows?

Not exactly, but what you can exploit with a buffer overflow is different
than it would be for Windows or Unix.

First of all, it's important to realize that memory on a computer is not
only used for a program's variables or other data -- it's also used for
executable code.  A program is loaded into memory before running it, and
the instructions that make up that program are executed from that memory.
That means that if you can get a pointer to the code of a program, you can
potentially change what it does -- making it do something else, such as
send you a file, give you a command prompt, send out mass e-mails, or
if the program is running with enough authority, upgrade your security
priveledges.

Now, my knowledge of how Windows works is dated.  I know that back in the
old days, once you managed to find a way to write data outside of the
current buffer, you could pretty much access everything. All programs
running on the same computer shared the same RAM, so you could change what
other programs did as well as the current one.  If there is a program
running as administrator, changing that one -- or changing Windows itself
-- allows you to do all sorts of nifty things. So, a buffer overflow in
that scenario is particularly heinous.

In Unix-like systems like FreeBSD or Linux, each process has it's own
memory. Not exactly true -- I mean, it's the same RAM bank and all -- but
the system creates a logical addressing situation where a pointer to
memory is mapped from that process' memory to the actual physical memory.
That way, a program couldn't access another program's memory, it is locked
into it's own little world.  (Unless, of course, you could find a buffer
overflow in the kernel itself.)  However, a buffer overflow can still do
lots of damage. You can still insert code that can be executed in the
current process, and if the current process every upgrades it's authority
(kinda like adopting authority on the iSeries, but it can be done in the
middle of a program) then you can do fun things like changing people's
authority level, etc.

The iSeries has two memory models -- one is a "mapped" model like Unix
(called "teraspace") and in the other model called "single-level store" is
able to access any memory on the system, plus it's able to access disk.
At first glance, this seems like it would be even worse than Windows --
but it's not because of the way pointers work on the iSeries.

A pointer on the iSeries isn't just an integer, as it is on those other
systems. It has permissions embedded into it, as well as special "tag
bits."  The tag bits are designed to make it impossible for you to
"manufacture" your own pointers so that you can only get them from the
system's routines.  (Though, there are ways to disable those checks by
using SST's "display/alter/dump" utility to edit the machine code of your
program.)

Since you must go through IBM's routines to create a pointer, it has the
ability to do some security checking. For example, it doesn't allow you to
make a pointer to executable code unless your program runs in the system
domain.

There are also different TYPES of pointers on the iSeries. A system
pointer points to programs or other executable code, and a space pointer
points to data in variables and things like that. Since you can't
artificially create a system pointer, a buffer overflow will always be
using a space pointer. This makes it just about impossible to modify the
code of a program in memory using a buffer overflow.

Anyway -- getting back to the original question "is the iSeries
invulnerable to buffer overflows?". No. You can overflow a buffer,
causing other variables in the job to be wrong.  This might be used to
cause a web server to crash, or something like that.

But, you can't change a running program, which really limits what you can
do.  And you run the risk of hitting memory that you don't have permission
to, which will cause the program to crash.

About the best you can do is a denial of service attack.

The design of the iSeries is really an incredible thing.  It's just one of
the best designed systems out there!  Unfortunately, very few people
understand and appreciate this...
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.