Re: iSeries buffer overflow immunity?

On Fri, 2004-11-05 at 17:59, Barbara Morris wrote:
> Rich Duzenbury wrote:
> > 
> > ...  My experiments
> > with RPG bear this out - I wasn't been able to craft a buffer overflow
> > using a variable (which I expected), nor a variable pointed at by a
> > pointer (which I did not expect).
> > 
> 
> You can easily get a buffer overflow in RPG using a pointer - declare a
> 5A based field and set the basing pointer to the address of something 4
> bytes long, and write to the 5A field - it will write to the 4 bytes you
> know about and then one byte that you don't know about.
> 
> It might not always cause a direct crash at the time of overflowing the
> buffer.  You would only get a direct crash if you tried to reference
> past the end of a physical segment.  But you can easily trash storage
> that someone else (even your program) might be using, and cause
> unspecified bad things to happen.
> 
> Our old friend, "parameter mismatch" is a great example of buffer
> overflow.
That's what I had initially thought, too, but my experimental code did
not fail:

D admin_flag0     s              1    inz('N')
D buffer          s              5
D admin_flag1     s              1    inz('N')

D ptr             s               *
D memory          s              6    based(ptr)
 /free
     ptr = %addr(buffer);
     memory = '12345Y';

     if admin_flag0 = 'Y' or admin_flag1 = 'Y';
         dsply 'Uh-Oh';
     endif;
     *inlr = '1';
 /end-free

What did I do wrong?  Can I not be sure that the admin_flag0 and
admin_flag1 are located next to the unprotected buffer?  

I am only looking to prove or disprove cases where a buffer overflow
could allow an attacker to alter the flow of program execution within
the framework of the existing code _in a meaningful and pre-planned
way_, for both RPG and C.  

If I make a mistake and don't protect a buffer, I deserve to get DOS'd,
fine.  But, I'd rather like to be able to sleep at night knowing that
even an attacker with a copy of my program source and the object can't
gain *any* type of surreptitious access.

I'm much less worried about RPG code than I am about C code, but that is
just my perception, perhaps not reality.

--
Regards,
Rich

Current Conditions in Des Moines, IA
Clear
Temp 46.4F
Winds out of the Southwest at 7mph