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

[Bob Koehler]

In article <fb678556-5b58-4c45-99a6-19bac92019a2 at googlegroups.com>, johnwallace4 at yahoo.co.uk writes:
> 
> 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.
> 

   Sounds like the OS is helping the user mode code along in it's
   exploit.  I was not aware of that vector in Windows, but why am I not
   suprized?


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