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

VAXman- at SendSpamHere.ORG VAXman- at SendSpamHere.ORG
Mon Jul 3 14:04:55 EDT 2017


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.

-- 
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