[Info-vax] DCL vulnerability write up on The Register

[johnwallace4 at yahoo.co.uk]

On Sunday, 18 February 2018 13:06:48 UTC, Simon Clubley  wrote:
> On 2018-02-18, Richard Maher <maher_rjSPAMLESS at hotmail.com> wrote:
> > On 18-Feb-18 5:13 PM, Simon Clubley wrote:
> >> 3) A process space which is shared by the shell and a combination of
> >> privileged and non-privileged programs. This gives various attack
> >> possibilites which do not exist on Unix. When combined with data
> >> structures which are executable, this makes it easier to exploit any
> >> vulnerabilities found in programs and the shell.
> >> 
> >
> > I do not see protected memory in a single process space as an intrinsic 
> > problem/vulnerability but I'm willing to be enlightened.
> >
> 
> Ok.
> 
> One of the problems an attacker has on other operating systems when
> actually trying to exploit a vulnerability is finding somewhere to store
> the shellcode to be run.
> 
> A traditional method has been to use the compromised program to place
> the shellcode on the stack or in a permanent buffer in the program
> (for example) and then change whatever address you compromised to point
> to the shellcode.
> 
> This only works if the attacker knows where in memory the shellcode is
> and is the reason why every other modern operating system uses ASLR.
> 
> On VMS, an interactive attacker with access to DCL simply does not have
> this problem. A non-privileged program can write the shellcode into one
> of the user writable memory areas in process space and the contents of
> this memory area remains intact after the non-privileged program exits.
> 
> As the same address space is used by any subsequent privileged program
> or DCL (unlike on Unix), all you need to do on VMS is to compromise
> a return address either in DCL or in the privileged program you want to
> compromise.
> 
> As these user writable memory areas are at known addresses, and are
> executable even though they only hold non-executable data, faffing
> around with storing the shellcode somewhere and then trying to find it
> again simply isn't required on VMS.
> 
> Having executable user writable areas that persist after image rundown
> means that there's no point implementing ASLR on VMS (at least for an
> interactive attacker).
> 
> This is an attack method that simply isn't possible on Unix.
> 
> It's also an example of how VMS hasn't kept up with the times as those
> memory areas should have been marked as non-executable a long time ago.
> 
> Simon.
> 
> -- 
> Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
> Microsoft: Bringing you 1980s technology to a 21st century world

Readers who haven't yet seen reports that ASLR, 'as used by
every other modern operating system', is frequently an 
untrustworthy piece of security theatre in commodity systems, 
might want to dig around a bit, e.g. 

https://www.pcworld.com/article/3170583/security/javascript-based-aslr-bypass-attack-simplifies-browser-exploits.html

That article's from almost exactly a year ago. There are
others around too.

By coincidence, that article also references high resolution
timers and the use of cache timing as a side channel attack
mechanism, which might sound familiar in recent weeks.

Interesting times.