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

[David Froble]

VAXman- @SendSpamHere.ORG wrote:
> In article <ojdv9r$t4l$1 at dont-email.me>, Simon Clubley <clubley at remove_me.eisner.decus.org-Earth.UFP> writes:
>> On 2017-07-03, John Reagan <xyzzy1959 at gmail.com> wrote:
>>> 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.
>> Unfortunately, that's not how these attacks work.
>>
>> You already _are_ in supervisor mode by virtue of having run a DCL
>> command; there is no transition from user mode to supervisor mode
>> required.
>>
>> The idea is to (1) initially find a DCL command which you can make
>> crash while it's running in supervisor mode and then (2) try and
>> control the crash in such a way that you can get it to do what you
>> want, including running your own shellcode while in supervisor mode.
>>
>> If someone manages to pull off step (2) then they have a crash which
>> has now become an exploit running in supervisor mode.
>>
>> Don't forget that VMS has some attacker friendly features such as an
>> address space which is shared by both a program and the CLI, data only
>> areas which are executable and some buffers/data structures at well
>> known locations. This means the buffer/data structures can be used to
>> store your shellcode so that you don't even need to mess around with
>> placing your shellcode onto the stack.
>>
>>> 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.
>>>
>> If you can do _that_ in supervisor mode :-(, then I most certainly
>> am not releasing any more information until I've had a chance to
>> explore the crash further. Unfortunately, real life means it's
>> going to be a while before I can really look at it.
> 
> I've done an awful lot in supervisor mode.  Let me know if/when you think
> you've found something.
> 
> 
> 
>>> 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".
>>>
>> In light of the possible attack scenario I have just laid out above,
>> and in light of what you have said can be done in supervisor mode,
>> are you still sure about that ?
> 
> Let me know when you've figured out how to go from supervisor mode to kernel
> too.
> 

Well, if you can set priv bits, one of them  is CMKRNL.  I believe, and no, I 
haven't checked, that supervisor mode just may allow that.

That said, I'm going to make a bet that there is some rundown handler that gets 
invoked if there is a crash in supervisor mode and drops to user mode.  Haven't 
looked, but if I was designing things that handler would be there.  Now the 
question is, can one intercept the handler before it does it's thing.  Don't 
know, but, if I had to place a bet, I'd guess no.

The whole concept is meaningless, to me, and might take more brain power than I 
have anymore.