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

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax-bounces at rbnsn.com] On Behalf
> Of Johnny Billquist via Info-vax
> Sent: 28-Nov-16 1:06 PM
> To: info-vax at rbnsn.com
> Cc: Johnny Billquist <bqt at softjar.se>
> Subject: Re: [Info-vax] Calling standards, was: Re: Byte range
> locking - was Re: Oracle
> 
> 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

Re: counter argument to this Microsoft statement that its only
because of the volume that it has more breaches

This is like saying the only reason corner stores / gas stations
are broken into more often than banks is because there are more
corner stores / gas stations than banks.

Architecture, design and culture from the platforms very
beginning also has a lot to go with the security and stability of
a platform.


Regards,

Kerry Main
Kerry dot main at starkgaming dot com