Re: iSeries buffer overflow immunity?

[Barbara Morris <bmorris@xxxxxxxxxx>]

Rich Duzenbury wrote:
> 
> On Mon, 2004-11-08 at 13:28, Barbara Morris wrote:
> > ...
> > 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?
> 

Then it would be possible to overwrite that buffer.  But it would be
unlikely to affect the program fields.

> >
> > 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?
> 

I think it's probably impossible. I can't even begin to imagine how it
could be done.

I was working on your implied assumption that it would be possible to
attack the program if you did somehow know from the source code what
fields would be affected by a buffer overflow from a given field.  But I
don't know if that assumption is correct - if it is, I have no idea how
to do it.

But working from that assumption, and further assuming you aren't going
to recompile the program before attacking it, you could still figure out
the storage layout by using %ADDR in the debugger.  This could be done
non-interactively using the debugger APIs.  (If you are going to
recompile the program as part of the attack, might as well just write a
new program.)