[Info-vax] How dangerous is it to be able to get into DCL supervisor mode ?
VAXman- at SendSpamHere.ORG
VAXman- at SendSpamHere.ORG
Wed Jul 5 10:05:08 EDT 2017
In article <ojip9m$e76$1 at dont-email.me>, Simon Clubley <clubley at remove_me.eisner.decus.org-Earth.UFP> writes:
>On 2017-07-05, David Froble <davef at tsoft-inc.com> wrote:
>>
>> 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.
>>
>
>No, when DCL crashes badly enough to take out the process, then the
>process crashes while in supervisor mode. That was confirmed by the
>PS register in the register dump.
>
>> I believe that Simon started out questioning whether he could retain supervisor
>> mode. Then the guessing started, I guess.
>
>Correct. You generally need to be able to cause a crash in the
>first place to be able to use this kind of approach. The question
>then becomes if the environment can be changed in a way which allows
>you to be able to control the crash in such a way as to allow your
>shellcode to run by the failing image (in this case DCL itself).
>
>Only a subset of crashes can be controlled in this way and I do not
>know yet if this crash is one of them.
>
>If you can control it, the idea is to get DCL to jump to your shellcode
>which you have previously loaded into memory before causing the crash.
>There is no switching of modes involved at this point; this is a simple
>jump to your shellcode by DCL while it is in supervisor mode.
>
>VMS makes things easier here than some other operating systems because
>you have a shared address space and data only structures which can
>become executable if jumped to. This means you can load your shellcode
>at a known location before causing your crash instead of having to faff
>around with getting your shellcode onto the stack (for example).
>
>If you get this far, then at this point all you have is shellcode running
>in supervisor mode and if you believe what DEC had been saying all the
>years it was around then there's little you could do because supervisor
>mode was supposed to be this limited environment.
>
>However, Stephen has been dropping hints that once you get into
>supervisor mode, there's a way to escalate things further, but
>I thought, if this was the case, then it was some super weird obscure
>thing which required deep internals knowledge.
>
>I was absolutely stunned by the suggestion by John however that you
>can set privilege bits while in supervisor mode because if that's true
>then it's an utterly insane thing to allow in an access mode which
>the _CLI_ runs in. :-( :-(
I'd like to know how! I had to go OUT OF MY WAY by making the DCL debugger
image a protected shareable image providing internal pathways to enable non-
existent/necessary privileges. They're enabled, used, and then, immediately
disabled.
DISK$OpenVMSAXP84:<SYS0.SYSCOMMON.SYSEXE>.EXE
TMESIS$DCLDEBUG;7
Open Hdr Shared Prot Lnkbl
Entry access count = 141
Current / Maximum shared = 1 / 2
Global section count = 4
>If you want to know how insane, try to imagine what the reaction
>would be if bash was installed as suid root on Linux because this
>is the same.
;)
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
I speak to machines with the voice of humanity.
More information about the Info-vax
mailing list