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

[osuvman50 at gmail.com]

On Wednesday, July 5, 2017 at 7:56:21 AM UTC-4, David Froble wrote:
> VAXman- @SendSpamHere.ORG wrote:
> > In article <ojgp86$r7d$1 at dont-email.me>, David Froble <davef at tsoft-inc.com> writes:
> >> John Reagan wrote:
> >>> On Tuesday, July 4, 2017 at 10:38:33 AM UTC-4, David Froble wrote:
> >>>> VAXman- wrote:
> >>>>> In article <o>, David Froble <> writes:
> >>>>>> Bill Gunshannon wrote:
> >>>>>>> On 7/3/2017 6:45 PM, Simon Clubley wrote:
> >>>>>>>> On 2017-07-03, Hans Vlems <> wrote:
> >>>>>>>>> If I understand you well then after crashing DCL your process is left in
> >>>>>>>>> Supervisor mode. Without a CLI how can you exploit that privileged 
> >>>>>>>>> position?
> >>>>>>>> You don't have a process after DCL crashes. The idea is to try and 
> >>>>>>>> corrupt
> >>>>>>>> DCL just enough to be able to execute your shellcode without corrupting
> >>>>>>>> it enough to actually crash and terminate your process.
> >>>>>>>>
> >>>>>>>> If you find manage to find a way to obtain this level of control then
> >>>>>>>> that's the point at which a crash becomes an exploit.
> >>>>>>>>
> >>>>>>>> However, at the moment, the process crashes with the following final
> >>>>>>>> status (from the accounting log):
> >>>>>>>>
> >>>>>>>> Final status text: %SYSTEM-F-NOHANDLER, no condition handler found
> >>>>>>>>
> >>>>>>> Just playing devil's advocate.....
> >>>>>>>
> >>>>>>> If you can determine the condition is there any way you could install
> >>>>>>> a handler?  That might lead to some interesting situations.
> >>>>>>>
> >>>>>>> bill
> >>>>>>>
> >>>>>> Ok, just speculating, the sequence might be CMKRNL then dropping to supervisor 
> >>>>>> mode.  Now, when in kernel mode, you queue a handler, then go to supervisor 
> >>>>>> mode.  That handler takes priority over anything you can do from supervisor 
> >>>>>> mode, and the first thing it does is drop you to user mode.  You're done at that 
> >>>>>> time.
> >>>>> Right but you've got to get there first! ;)
> >>>>>
> >>>>>
> >>>> Quite right!
> >>>>
> >>>> I'm assuming that the DCL utilitys are installed as privilidged.
> >>>>
> >>>> $ install list
> >>>>
> >>>> DISK$VMS072:<SYS0.SYSCOMMON.SYSEXE>.EXE
> >>>>
> >>>>     LOGINOUT;1       Open Hdr Shar Prv
> >>>>
> >>>> As in this example.  Therefore they can execute CMKRNL, CMEXEC and such.  And 
> >>>> they can set up handlers while in elevated mode.  So, they are already there.
> >>>>
> >>>> I believe you got the sources, can you confirm what I'm suggesting?
> >>> The "Prv" doesn't mean "can set any privilege bit".  It just means it was installed with privs but you can't see the exact privilege mask from that output display.  For exmample, installing something with OPER priv does not give it the ability to CMKRN
> >> We're dancing all around this.  Might be nice for someone who actually knows to 
> >> explain a bit about how it works.
> > 
> > How WHAT works?  Privileges?
> > 
> > 
> 
> No, the subject of this thread, just what happens when DCL running in supervisor 
> mode aborts on an error, and the process returns to user mode.  At least I 
> thought that was the subject.  Sometimes I get confused.
> 
> I believe that Simon started out questioning whether he could retain supervisor 
> mode.  Then the guessing started, I guess.

If DCL crashes, you don't get back to user mode.  The speculation is that there is a privilege elevation bug in OpenVMS that lets supervisor mode execute arbitrary code in kernel mode.  The threat from being able to crash DCL at will is you can control the conditions of the crash to exploit this supposed bug. Once you get into kernel mode, all bets are off and you don't need the process to survive (i.e. you can change the privilege mask of another process).