[Info-vax] Calling standards, was: Re: Byte range locking - was Re: Oracle

[johnwallace4 at yahoo.co.uk]

On Monday, 28 November 2016 14:20:21 UTC, Bob Koehler  wrote:
> In article <o16tjq$e4b$1 at dont-email.me>, "Craig A. Berry" <craigberry at nospam.mac.com> writes:
> > 
> > The chances that a simple mistake will have you stomping on memory that
> > doesn't belong to you or corrupting the stack.
> 
>    User mode code doesn't get to stomp on any memory that doesn't belong
>    to it under any OS using an MMU that I've looked at in a long, long
>    time.
> 
>    Corrupting the stack is a lot less likely when you explicitly know
>    you're using the stack.  How many C programmers do I have to deal
>    with that have no concept of the implications that local variables
>    default to the stack and calling arguments generally do, too?

Have you come across Shatter (and friends) attacks on any 
old Window box, Bob?

They seemed (and to an extent may still seem) quite
capable of allowing user mode code - an unprivileged
process - to deposit arbitrary data somewhere it will be
readily accessible to another process, and subsequently
execute arbitrary code in the context of that other
process. Is that close enough for you?

NB Shatter attacks weren't due to coding errors, it was
a design error.

"Shatter attacks became a topic of intense conversation
in the security community in August 2002 after the
publication of Chris Paget's paper titled, "Exploiting
design flaws in the Win32 API for privilege escalation".[2] 

The paper, which coined the term "shatter attack",
explained the process by which an application could execute
arbitrary code in another application. This could occur
because Windows allows unprivileged applications to send
messages to message loops of higher-privileged application -
and some messages can have the address of a callback
function in the application's address space as its parameter.
If an attacker manages to put his own string into the memory
of the higher-privileged application (say by pasting
shellcode to an edit box) at a known location, they could
then send WM_TIMER messages with callback function
parameters set to point to the attacker's string.

[continues]"

https://en.wikipedia.org/wiki/Shatter_attack

In my book, that's three things, maybe more:
(1) user mode code (unprivileged process) putting
arbitrary data somewhere where another process can
readily get at it.
(2) causing that unauthorised code to execute in
the context of that other process.
(3) in the right circumstances, unauthorised elevation of
privilege.

This worked pretty much *intentionally*, not as a result
of a coding error.

Maybe it's better than it used to be. Or maybe it's just
better hidden (less talked about) than it briefly was.

Either way there still seem to be plenty of ways to get
unauthorised code execution and unauthorised privilege
escalation in "modern" high volume OSes.