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

[neillclift at gmail.com]

On Sunday, February 18, 2018 at 5:51:27 AM UTC-8, Richard Maher wrote:
> On 18-Feb-18 9:06 PM, 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.
> > 
> 
> 
> All good thanks for explaining. The bit I'm interested in is how you get 
> to EXEC/KRNL from SUPER but more importantly how do you get DCL to 
> execute code at the COMMON address.

This will be documented in internals and data structures I would expect.
If you have code running in supervisor mode then you pick a privileged image with a nice privilege using the install utility. Activate that with $IMGACT and I seem to remember you have to fix it up with $IMGFIX and then your code will have the privilege.
> 
> My contention/hope is that this is a bug that can be plugged rather than 
> a fundamental unpluggable attack vector due to dicky memory page protection?

The memory page he talks about is likely the common area. That just makes it easier to exploit bugs rather than being the bug itself. In general mitigation's suffer a problem were attackers defeat them since when code goes wrong attackers have a lot of degrees of freedom available.