RE: iSeries buffer overflow immunity?

Well in order to do any of this, you need to get a hold of the application,
reverse engineer it, identify the weakness, then build the program to
attach.  Easy to do with cheap MS applications that are generally available.
But to do so I the iSeries will take a lot of money and effort.  Yes it can
be done.  If I want to attach the Apache server on the iSeries, I could
start with the open source for Apache on my windows platform.  But will the
same attach on the same program work on the iSeries?  Now for my custom
socket server that does not reside on any computer outside of the
organization, well it would be more difficult to attach since you know
nothing about my application and cannot get the program object or source to
reverse engineer.

Most attacks are on wide spread internet services.  I.e. IIS, Exchange,
SMTP, Cisco Routers, VPN server, FTP servers and others.  So I would not
worry about custom applications that you put on the internet but on those
standard packages that are widely used.  I do not think that one can break
the actual IP stack provide by IBM that we all use.  But again, maybe there
are holes in the low level stuff that can be hacked.

Chris Bipes

-----Original Message-----
> Rich Duzenbury wrote:
> > ...
> > That's good news.  So, in my opinion, the likelihood that an attacker
> > could hit an exact byte in RPG static storage is getting extremely low -
> > The buffer has to be accessible via a pointer, unprotected by program
> > code, and the storage layout from the compiler is arbitrary, so the
> > important 'admin_flag' is not necessarily accessible past the end of the
> > buffer.
> > 
> 
> I'm can't imagine how it would be possible to make an attack through
> your program even if someone did know the variable name that would get
> affected by a buffer overflow.
So far, it's just a test to see if it's possible. My test program
doesn't take any external input (yet!).  What if it were changed to read
from a socket into an improperly protected buffer?  

> 
> But assuming that was possible, it just takes a bit more work to figure
> out where the buffer overflow occurs.  By comparing the addresses of the
> fields, you can see how storage is laid out.
Hmm. I was starting to think it would be *too* hard, are you saying it's
not necessarily hard?