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

[Richard Maher]

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.

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?