[Info-vax] How dangerous is it to be able to get into DCL supervisor mode ?

[John Reagan]

On Monday, July 3, 2017 at 9:39:43 AM UTC-4, Simon Clubley wrote:
> On 2017-07-03, Simon Clubley <clubley at remove_me.eisner.decus.org-Earth.UFP> wrote:
> > This weekend, I found a way to crash DCL on VMS Alpha v8.4 which causes
> > the process to terminate with a register dump. The PS register confirms
> > the process was in supervisor mode when it failed.
> >
> > I don't know if the crash is controllable let alone if it's exploitable
> > and it looks like it's going to be quite a bit of work to be able to
> > get further clues.
> >
> >==> TO REPEAT: at the moment, this is nothing more than a way to be
> > able to take down a specific version of DCL running on a specific
> > architecture (Alpha).
> >
> 
> Just to confirm for the people not familiar with the implications of
> the above terminology. I am saying I have a way to crash a specific
> version of DCL on Alpha. I do not currently have a way to get into
> supervisor mode with my own code but additional research may possibly
> reveal a way to control the crash in such a way that I might be able
> to get my own shellcode running in supervisor mode.
> 
> That's what the additional work and the exploitable comment above is
> referring to.
> 

There is no direct way from user-mode to supervisor-mode.  You have to change to kernel or exec mode and then "downgrade" to supervisor.  Kernel and exec mode access is controlled by the CMKRNL and CMEXEC privileges and you get into them from the SYS$CMKRNL and SYS$CMEXEC services.  Steve's comment is that once in K,E, or S modes, you have the ability to turn on any privilege you like which will stay enabled even after you return back to user mode.

Taking out the process with DCL bugs has happened from time to time.  You don't get to take out the whole system or access data/files that you don't have access to.  It pretty much is a "you can shoot yourself in the foot, but can't shoot anyone else's feet".