RE: iSeries buffer overflow immunity?

[CWilt@xxxxxxxxxxxx]

> -----Original Message-----
> From: Chris Bipes [mailto:chris.bipes@xxxxxxxxxxxxxxx]
> Sent: Monday, November 08, 2004 4:58 PM
> To: 'Midrange Systems Technical Discussion'
> Subject: RE: iSeries buffer overflow immunity?
> 
> 
> Well if my home grown application did a swap profile API 
> after you logon.
> If you know where the user profile handles are stored, you 
> can change them
> to something with more authority, if you can figure out what 
> is what, then
> execute the swap again to the profile with more authority.  
> Possible, yes,
> probable, no.  Especially if the listening job hands off to a 
> prestart job
> after your logon and them clears the logon variables.  As far 
> as using a
> home grown security model is well a waste of time when OS400 
> provides so
> many security features.
>  
> 


Not sure I'm following what exactly you are saying.  Granted, I've not
really worked with the profile swapping APIs as of yet.

However, I don't see how you could change the handle to one with more
authority.  
First off, it seems that the handle is only usable by the job that created
it.  So, the listening job can't create it, the prestart job has to.

Now, lets assume that the prestart job has a buffer overflow vulnerability
and that by coincidence, the buffer is right next to the variable that holds
the handle.  OS/400 apparently keeps track of the currently created handles
( why else would you need a QsyReleaseProfileHandle?) since the handle is a
random 12-char value, the only way to get a valid handle is through the
correct API.  Unless your application doesn't release that handles properly
and somehow an attacker has managed to find out one of those older handles
that used by the pre-start job he was attacking.  The only way I can think
of for that to happen is if your application had another buffer overflow
problem that sent out the handle as part of an output stream.

Profile tokens are even better.  Though they apparently can be used by other
jobs, they live at maximum only 3600 seconds.  Not to mention that you can
have multiple types including a single use token.


Charles