[PB x.x] stack and callback pointers exposed to injection?

[Rescator]

Not really sure where to post this, hope it's ok here.

PureBasic compiled programs (including the IDE btw) uses window properties to store stack pointers and callback pointers.
Another process could change the window property and change a callback pointer, a very quick and easy way for code injection isn't it?!

Some of you might be thinking.."Hey! if the nasty program is already running, what's the point of injecting this at all there's no need right?"
Kinda! Provided they both have the same privilege then yes!

But image if one is a admin privilege process?
Imagine if a user level app, altered the props of say something like pb_statusbar_callback or PB_GadgetStack_4194304 or pb_menu_callback or pb_toolbar_callback,
and these props are in a admin privilege app.
I'm not saying these props in particular can be exploited, but I don't know how they are used internally in PB's libs so I have no idea.

Starting with Vista, MicroSoft changed the way SetProp_() works:

Windows Vista: SetProp is subject to the restrictions of User Interface Privilege Isolation (UIPI). A process can only call this function on a window belonging to a process of lesser or equal integrity level. When UIPI blocks property changes, GetLastError will return 5.

Which still leaves possible headache for NT 5.x based Windows (like XP,2003 etc).

So if the PureBasic team could look through the props PB uses and if there is a risk factor and maybe do things slightly different.
I.e: a ID instead of the actual pointer is obviously safer, the program can still be crashed by changing the ID, but at least any potential for code injection is at least reduced.

Obviously if this is the case already then excuse my ignorance, and accept my thanks for having great foresight

[freak]

Given the fact that you can just as easy call SetWindowLongPtr() to replace any window's main callback or use a window hook to inject code, i don't see how this is any more of a security problem.

[Thorium]

Given the fact that you can just as easy call SetWindowLongPtr() to replace any window's main callback

No, thats secure:

[in] Handle to the window and, indirectly, the class to which the window belongs. The SetWindowLongPtr function fails if the process that owns the window specified by the hWnd parameter is at a higher process privilege in the User Interface Privilege Isolation (UIPI) hierarchy than the process the calling thread resides in.

On older OS's than Vista you even can't call it if the hWnd not belongs to the calling process.