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

[Johnny Billquist]

On 2016-11-28 18:33, johnwallace4 at yahoo.co.uk wrote:
> 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.

Windows have for the longest time been considered a very bad and unsafe 
OS, for this very reason, no matter the amount of FUD from Microsoft, 
claiming that all problems are just because Windows is more widespread, 
and thus being more exposed to attacks.

	Johnny