How dangerous is it to be able to get into DCL supervisor mode ?

[Simon Clubley]

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

NOTE: we simply would not be having this discussion if the image in
question had kernel or executive mode access as I would be following
standard procedures while exploring it. However, DEC have always made
a point of saying that if DCL was compromised then it didn't really
matter anyway because it was only supervisor mode access.

OTOH, Stephen has commented a couple of times that there's a way to
get further access if you are in supervisor mode. As I don't know
the VMS source code internals (I've never seen it) I don't know
what the conditions on Stephen's statement might be.

So, how dangerous is it to be able to get into supervisor mode ?
I don't really want to spend a lot of time exploring only to find
out that even if I did manage to control the crash, it didn't matter
anyway because there was nothing you could do while you had supervisor
mode access.

Also note that since I am not in a position to judge how dangerous
it would be to release details on exactly how I did this, I will not
be releasing any details on how I did this for now just in case it
turns out to be something more dangerous than I realised.

Even if I did feel it was ok to disclose it, I'd also want to play
with it a bit more before reporting it anyway in order to see if
I could simplify the triggering mechanism.

If this were a normal kernel mode crash then the process would be
simple: report it via a secure mechanism and then release details
after the patch was released.

Unfortunately, with the supervisor mode access available on VMS
I am not really in a position to judge whether being able to get
into DCL supervisor mode is harmless and doesn't even warrant an
urgent patch or whether this could be something dangerous if it
did turn out to be exploitable.

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

[Simon Clubley]

On 2017-07-03, Simon Clubley <***@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.

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

[John Reagan]

On Monday, July 3, 2017 at 9:39:43 AM UTC-4, Simon Clubley wrote:
> On 2017-07-03, Simon Clubley <***@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".

[Simon Clubley]

On 2017-07-03, John Reagan <***@gmail.com> wrote:
> On Monday, July 3, 2017 at 9:39:43 AM UTC-4, Simon Clubley wrote:
>> On 2017-07-03, Simon Clubley <***@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.

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

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

[V***@SendSpamHere.ORG]

In article <ojdv9r$t4l$***@dont-email.me>, Simon Clubley <***@remove_me.eisner.decus.org-Earth.UFP> writes:
>On 2017-07-03, John Reagan <***@gmail.com> wrote:
>> On Monday, July 3, 2017 at 9:39:43 AM UTC-4, Simon Clubley wrote:
>>> On 2017-07-03, Simon Clubley <***@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.

[Simon Clubley]

On 2017-07-03, VAXman- @SendSpamHere.ORG <[e-mail]> wrote:
> In article <ojdv9r$t4l$***@dont-email.me>, Simon Clubley <***@remove_me.eisner.decus.org-Earth.UFP> writes:
>>On 2017-07-03, John Reagan <***@gmail.com> wrote:
>>> 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.
>

That's interesting Brian thanks.

You seem to be implying the situation with supervisor mode is closer
to what I've always believed until recently in that supervisor mode
is heavily restricted as far as the privileged modes go and that
even if you could get into it, there wasn't much damage you could on
a system-wide basis.

However Stephen has suggested more than once recently that if you
can get into supervisor mode, then there's a way to escalate your
access rights even further.

John above has just said pretty much the same thing as Stephen.

As I've mentioned previously, I have never had access to the VMS
source code so I don't know the VMS internals as well as you and
some other people around here do.

As such, I would like to ask those of you here who do have that
level of knowledge, what is the actual situation here ?

Once you manage to get into supervisor mode (regardless of how you
do it), are you constrained from doing any system wide damage
or can you elevate your privileges as John states above or
get into executive/kernel mode as Stephen has stated previously ?

Thanks,

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

[Hans Vlems]

I've always thought that DCL was the only program that runs in Supervisor mode, or should that be the only program bundled with VMS?
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?
What is worrying me is that you can only get to Supervisor mode through Kernel or Exec mode, so finding your way back might get you into one of these states. Again without a CLI present (and thus no way to run a handy tool ?) it seems difficult if not impossible to do.
This may prove I'm not a good hacker...
Hans

[V***@SendSpamHere.ORG]

In article <cddbfa94-37eb-4a56-95b5-***@googlegroups.com>, Hans Vlems <***@freenet.de> writes:
>I've always thought that DCL was the only program that runs in Supervisor
>mode, or should that be the only program bundled with VMS?

My DCL Debugger! Guess where it runs!

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

[Simon Clubley]

On 2017-07-03, Hans Vlems <***@freenet.de> 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

> What is worrying me is that you can only get to Supervisor mode through
> Kernel or Exec mode, so finding your way back might get you into one of
> these states. Again without a CLI present (and thus no way to run a handy
> tool ?) it seems difficult if not impossible to do.

I've detailed the answer to this in another posting.

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

[Bill Gunshannon]

On 7/3/2017 6:45 PM, Simon Clubley wrote:
> On 2017-07-03, Hans Vlems <***@freenet.de> 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

[David Froble]

Bill Gunshannon wrote:
> On 7/3/2017 6:45 PM, Simon Clubley wrote:
>> On 2017-07-03, Hans Vlems <***@freenet.de> 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.

It's been quite a while since I was into such things, and I haven't researched
it. Just depending on (increasingly poor) memory.

I'm willing to bet that something similar has been in VMS all along.

[Bill Gunshannon]

On 7/3/2017 8:34 PM, David Froble wrote:
> Bill Gunshannon wrote:
>> On 7/3/2017 6:45 PM, Simon Clubley wrote:
>>> On 2017-07-03, Hans Vlems <***@freenet.de> 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.
>
> It's been quite a while since I was into such things, and I haven't
> researched it. Just depending on (increasingly poor) memory.
>
> I'm willing to bet that something similar has been in VMS all along.

I realize your saying that's what handlers do, but, in this case there
apparently is no handler. Could someone write a nasty handler and get
it installed? I don't know VMS handlers at all so I have no idea how
one gets put n place. Now, if it were Unix... :-)

bill

[David Froble]

Bill Gunshannon wrote:
> On 7/3/2017 8:34 PM, David Froble wrote:
>> Bill Gunshannon wrote:
>>> On 7/3/2017 6:45 PM, Simon Clubley wrote:
>>>> On 2017-07-03, Hans Vlems <***@freenet.de> 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.
>>
>> It's been quite a while since I was into such things, and I haven't
>> researched it. Just depending on (increasingly poor) memory.
>>
>> I'm willing to bet that something similar has been in VMS all along.
>
> I realize your saying that's what handlers do, but, in this case there
> apparently is no handler. Could someone write a nasty handler and get
> it installed? I don't know VMS handlers at all so I have no idea how
> one gets put n place. Now, if it were Unix... :-)
>
> bill
>

I don't know what happened, and neither does anyone without the design and
sources. But keep in mind, you can have, in descending priority:

1) Kernel mode handler

2) Exec mode handler

3) supervisor mode handler

4) user mode handler

Just as an example. Now, what caused the error message, don't know. Maybe no
supervisor mode handler?

[Bob Koehler]

In article <***@mid.individual.net>, Bill Gunshannon <***@gmail.com> writes:
>
> I realize your saying that's what handlers do, but, in this case there
> apparently is no handler. Could someone write a nasty handler and get
> it installed? I don't know VMS handlers at all so I have no idea how
> one gets put n place. Now, if it were Unix... :-)
>

Any user can install a user mode handler. In principle, installing
a mode-related handler should require being in that mode, or in a
more priviledged mode.

So you shouldn't be able to get there unless you already are.

[V***@SendSpamHere.ORG]

In article <ojenjf$iad$***@dont-email.me>, David Froble <***@tsoft-inc.com> writes:
>Bill Gunshannon wrote:
>> On 7/3/2017 6:45 PM, Simon Clubley wrote:
>>> On 2017-07-03, Hans Vlems <***@freenet.de> 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! ;)


--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

[David Froble]

VAXman- @SendSpamHere.ORG wrote:
> In article <ojenjf$iad$***@dont-email.me>, David Froble <***@tsoft-inc.com> writes:
>> Bill Gunshannon wrote:
>>> On 7/3/2017 6:45 PM, Simon Clubley wrote:
>>>> On 2017-07-03, Hans Vlems <***@freenet.de> 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?

[John Reagan]

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 CMKRNL or CMEXEC.

[Jan-Erik Soderholm]

Den 2017-07-04 kl. 18:18, skrev John Reagan:
> 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 CMKRNL or CMEXEC.
>

$ install list loginout /full

[David Froble]

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 CMKRNL or CMEXEC.

We're dancing all around this. Might be nice for someone who actually knows to
explain a bit about how it works.

[V***@SendSpamHere.ORG]

In article <ojgp86$r7d$***@dont-email.me>, David Froble <***@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?


--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

[David Froble]

VAXman- @SendSpamHere.ORG wrote:
> In article <ojgp86$r7d$***@dont-email.me>, David Froble <***@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.

[o***@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$***@dont-email.me>, David Froble <***@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).

[Simon Clubley]

On 2017-07-05, David Froble <***@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. :-( :-(

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.

As such I am now being very careful about what I say until we know
for sure one way or another.

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

[Simon Clubley]

On 2017-07-05, Simon Clubley <***@remove_me.eisner.decus.org-Earth.UFP> wrote:
>
> 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).
>

Sorry. That should say "to be run", not "to run".

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

[David Froble]

Simon Clubley wrote:
> On 2017-07-05, David Froble <***@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).

Ok, short story. Back in the early 1980s I thought I needed to include some
exception handlers, in case of an exception happening. Thought I needed to do
some clean-up. Then I found out VMS did all that for me, and that's the last
looking at handlers that I did.

My memory, remember, we're talking over 30 years, is that if the conditions for
an exception handler were met, whatever they are, then the exception handler(s)
will be invoked.

From what I remember, the exception handlers can be set up in various processor
modes, and a lesser mode has no control of a handler running in a higher mode.
For example, if there is an exception handler set up in Kernel mode, unless
you're in Kernel mode, you can't touch it, stop it, and such.

So maybe I'm the culprit, but speculation began about exception handlers for a
crash in Supervisor mode. No real information. Perhaps someone at VSI, if they
had the time and desire, could clear this up. I cannot.

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

Key provision is "if you can control it".

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

Your "shellcode" doesn't matter, if you're no longer running in elevated mode.

> 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. :-( :-(
>
> 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.
>
> As such I am now being very careful about what I say until we know
> for sure one way or another.
>
> Simon.
>

There were lots of VERY good software engineers at DEC. If I had to bet, I'd
bet they would have had this issue very well covered. Then again, maybe a horse
could learn to sing ....

[John Reagan]

On Wednesday, July 5, 2017 at 12:22:15 PM UTC-4, David Froble wrote:

>
> There were lots of VERY good software engineers at DEC. If I had to bet, I'd
> bet they would have had this issue very well covered. Then again, maybe a horse
> could learn to sing ....

https://www.youtube.com/watch?v=Ck43JCFAUR8

[Paul Sture]

On 2017-07-05, John Reagan <***@gmail.com> wrote:
> On Wednesday, July 5, 2017 at 12:22:15 PM UTC-4, David Froble wrote:
>
>>
>> There were lots of VERY good software engineers at DEC. If I had to bet, I'd
>> bet they would have had this issue very well covered. Then again, maybe a horse
>> could learn to sing ....
>
> https://www.youtube.com/watch?v=Ck43JCFAUR8

Beat me to it. :-)

--
Everybody has a testing environment. Some people are lucky enough to
have a totally separate environment to run production in.

[Simon Clubley]

On 2017-07-05, David Froble <***@tsoft-inc.com> wrote:
> Simon Clubley wrote:
>> On 2017-07-05, David Froble <***@tsoft-inc.com> wrote:
>>> 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 be run by the failing image (in this case DCL itself).
>

[Changed quote to "to be run" as in my corrected posting]

> Ok, short story. Back in the early 1980s I thought I needed to include some
> exception handlers, in case of an exception happening. Thought I needed to do
> some clean-up. Then I found out VMS did all that for me, and that's the last
> looking at handlers that I did.
>

In this particular approach, exception handlers are not involved until
(maybe) after the shellcode has finished executing.

The final status text I posted previously was due to it being an
uncontrolled crash due to how badly DCL was messed up internally.

The idea is that you look for a way to modify the conditions for the
uncontrolled crash so that DCL is messed up just enough to trick it
into running your shellcode. That way, there are no exception handlers
invoked until (maybe) after your shellcode has finished executing.

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

[V***@SendSpamHere.ORG]

In article <b9bd660a-cda4-407b-ad3b-***@googlegroups.com>, John Reagan <***@gmail.com> writes:
>On Wednesday, July 5, 2017 at 12:22:15 PM UTC-4, David Froble wrote:
>
>>
>> There were lots of VERY good software engineers at DEC. If I had to bet, I'd
>> bet they would have had this issue very well covered. Then again, maybe a horse
>> could learn to sing ....
>
>https://www.youtube.com/watch?v=Ck43JCFAUR8

Damn you! I'd totally forgotten that stupid show.

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

[V***@SendSpamHere.ORG]

In article <ojip9m$e76$***@dont-email.me>, Simon Clubley <***@remove_me.eisner.decus.org-Earth.UFP> writes:
>On 2017-07-05, David Froble <***@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.

[V***@SendSpamHere.ORG]

In article <ojijts$1u9$***@dont-email.me>, David Froble <***@tsoft-inc.com> writes:
>VAXman- @SendSpamHere.ORG wrote:
>> In article <ojgp86$r7d$***@dont-email.me>, David Froble <***@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 CMK
>>> 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.

Re-read the chapter on uniform exception handling. If DCL "aborts:, it's NOT
going to return to user mode.

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

[Stephen Hoffman]

On 2017-07-05 13:39:33 +0000, VAXman- @SendSpamHere.ORG said:

> Re-read the chapter on uniform exception handling. If DCL "aborts:,
> it's NOT going to return to user mode.

Crashes are commonly symptoms of attacks in development, or attacks
that are running up against ASLR or such. Attacks that are
successful don't crash. Or they crash after the exploit code has been
run.

This is part of why I've commented on opt-in, anonymized system and app
crash data collection, too. Akin to what CLUE and CCAT/CANASTA
provided in an earlier era. What Microsoft refers to as telemetry.

https://blogs.technet.microsoft.com/johnla/2015/09/26/the-inside-story-behind-ms08-067/




--
Pure Personal Opinion | HoffmanLabs LLC

[Bob Koehler]

In article <ojj3gf$ola$***@dont-email.me>, David Froble <***@tsoft-inc.com> writes:
>
> My memory, remember, we're talking over 30 years, is that if the conditions for
> an exception handler were met, whatever they are, then the exception handler(s)
> will be invoked.

There are many situations in which VMS will skip user mode handlers.

For example, if you stop a process with STOP, user mode handlers get
skipped. We had a utility program that would do a force exit on the
process instead.

[Robert A. Brooks]

On 7/5/2017 1:42 PM, Bob Koehler wrote:
> In article <ojj3gf$ola$***@dont-email.me>, David Froble <***@tsoft-inc.com> writes:
>>
>> My memory, remember, we're talking over 30 years, is that if the conditions for
>> an exception handler were met, whatever they are, then the exception handler(s)
>> will be invoked.
>
> There are many situations in which VMS will skip user mode handlers.
>
> For example, if you stop a process with STOP, user mode handlers get
> skipped. We had a utility program that would do a force exit on the
> process instead.

Which is why folks will frequently use an image rundown handler, which is created
by calling img$add_privileged_vector_entry(). See the Internal and Data Structures
manual for details.

--

-- Rob

[o***@gmail.com]

On Wednesday, July 5, 2017 at 4:04:45 PM UTC-4, Robert A. Brooks wrote:
> On 7/5/2017 1:42 PM, Bob Koehler wrote:
> > In article <ojj3gf$ola$***@dont-email.me>, David Froble <***@tsoft-inc.com> writes:
> >>
> >> My memory, remember, we're talking over 30 years, is that if the conditions for
> >> an exception handler were met, whatever they are, then the exception handler(s)
> >> will be invoked.
> >
> > There are many situations in which VMS will skip user mode handlers.
> >
> > For example, if you stop a process with STOP, user mode handlers get
> > skipped. We had a utility program that would do a force exit on the
> > process instead.
>
> Which is why folks will frequently use an image rundown handler, which is created
> by calling img$add_privileged_vector_entry(). See the Internal and Data Structures
> manual for details.
>
> --
>
> -- Rob

I had written a cool program for VAX/VMS, circa 1988, that added a permanent
routine to the CTL$GL_USRUNDWN rundown vector. The Alpha changed the format of
all that and learning the new scheme would have taken more time than I wanted
to devote to it.

[Jan-Erik Soderholm]

Den 2017-07-05 kl. 19:42, skrev Bob Koehler:
> In article <ojj3gf$ola$***@dont-email.me>, David Froble <***@tsoft-inc.com> writes:
>>
>> My memory, remember, we're talking over 30 years, is that if the conditions for
>> an exception handler were met, whatever they are, then the exception handler(s)
>> will be invoked.
>
> There are many situations in which VMS will skip user mode handlers.
>
> For example, if you stop a process with STOP, user mode handlers get
> skipped. We had a utility program that would do a force exit on the
> process instead.
>

"Forced exit". That looks like one of the the options when closing
an Rdb database. Forcex looks like the "softer" method...


$ RMU /CLOSE <database> /ABORT=DELPRC|FORCEX

[Hans Bachner]

Jan-Erik Soderholm schrieb am 05.07.2017 um 23:57:
> Den 2017-07-05 kl. 19:42, skrev Bob Koehler:
>> In article <ojj3gf$ola$***@dont-email.me>, David Froble
>> <***@tsoft-inc.com> writes:
>>>
>>> My memory, remember, we're talking over 30 years, is that if the
>>> conditions for
>>> an exception handler were met, whatever they are, then the exception
>>> handler(s)
>>> will be invoked.
>>
>> There are many situations in which VMS will skip user mode handlers.
>>
>> For example, if you stop a process with STOP, user mode handlers get
>> skipped. We had a utility program that would do a force exit on the
>> process instead.
>>
>
> "Forced exit". That looks like one of the the options when closing
> an Rdb database. Forcex looks like the "softer" method...

Yup. $FORCEX runs the user mode handlers allowing for a "cleaner" exit
of the image running in the target process. Bob already indicated that.

Hans.

[V***@SendSpamHere.ORG]

In article <ojg922$vm8$***@dont-email.me>, David Froble <***@tsoft-inc.com> writes:
>VAXman- @SendSpamHere.ORG wrote:
>> In article <ojenjf$iad$***@dont-email.me>, David Froble <***@tsoft-inc.com> writes:
>>> Bill Gunshannon wrote:
>>>> On 7/3/2017 6:45 PM, Simon Clubley wrote:
>>>>> On 2017-07-03, Hans Vlems <***@freenet.de> 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?

LOGINOUT.EXE must be because it is what creates the process and maps DCL!
Interactive, batch, or network process, it doesn't matter. If DCL is to be
a part of its life, LOGINOUT.EXE is what adds DCL fulfillment to its life.

DCL, BTW, is NOT installed with privies!

DCL;1 Open Hdr Shared Lnkbl

It is mapped ($IMGACT) by LOGINOUT. When all process activation has been
completed, LOGINOUT REIs to supervisor mode transferring control to DCL's
entry address. One can only REI to the same or an outer access mode.

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

[V***@SendSpamHere.ORG]

In article <oje7gq$riu$***@dont-email.me>, Simon Clubley <***@remove_me.eisner.decus.org-Earth.UFP> writes:
>On 2017-07-03, VAXman- @SendSpamHere.ORG <[e-mail]> wrote:
>> In article <ojdv9r$t4l$***@dont-email.me>, Simon Clubley <***@remove_me.eisner.decus.org-Earth.UFP> writes:
>>>On 2017-07-03, John Reagan <***@gmail.com> wrote:
>>>> 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.
>>
>
>That's interesting Brian thanks.
>
>You seem to be implying the situation with supervisor mode is closer
>to what I've always believed until recently in that supervisor mode
>is heavily restricted as far as the privileged modes go and that
>even if you could get into it, there wasn't much damage you could on
>a system-wide basis.
>
>However Stephen has suggested more than once recently that if you
>can get into supervisor mode, then there's a way to escalate your
>access rights even further.
>
>John above has just said pretty much the same thing as Stephen.
>
>As I've mentioned previously, I have never had access to the VMS
>source code so I don't know the VMS internals as well as you and
>some other people around here do.
>
>As such, I would like to ask those of you here who do have that
>level of knowledge, what is the actual situation here ?
>
>Once you manage to get into supervisor mode (regardless of how you
>do it), are you constrained from doing any system wide damage
>or can you elevate your privileges as John states above or
>get into executive/kernel mode as Stephen has stated previously ?

When in exec mode, one can invoke $CMKRNL and execute code in kernel
mode without possessing the privies needed for $CMKRNL because there
is a check for the previous mode being exec. There's nothing similar
for $CMEXEC from supervisor mode. It sure would have removed a few
hurdles for me when writing my DCL Debugger had that been the case.

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

[Simon Clubley]

On 2017-07-03, VAXman- @SendSpamHere.ORG <[e-mail]> wrote:
>
> When in exec mode, one can invoke $CMKRNL and execute code in kernel
> mode without possessing the privies needed for $CMKRNL because there
> is a check for the previous mode being exec. There's nothing similar
> for $CMEXEC from supervisor mode. It sure would have removed a few
> hurdles for me when writing my DCL Debugger had that been the case.
>

Thanks Brian.

There's still the bit about being able to set the privilege bits
in supervisor mode however.

However, if supervisor mode lets you do that, then that would seem to
defeat the whole point of actually _having_ a supervisor mode. :-)

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

[Arne Vajhøj]

On 7/3/2017 6:36 PM, Simon Clubley wrote:
> On 2017-07-03, VAXman- @SendSpamHere.ORG <[e-mail]> wrote:
>> When in exec mode, one can invoke $CMKRNL and execute code in kernel
>> mode without possessing the privies needed for $CMKRNL because there
>> is a check for the previous mode being exec. There's nothing similar
>> for $CMEXEC from supervisor mode. It sure would have removed a few
>> hurdles for me when writing my DCL Debugger had that been the case.

> There's still the bit about being able to set the privilege bits
> in supervisor mode however.

I don't think S mode allows changing stuff like that.

> However, if supervisor mode lets you do that, then that would seem to
> defeat the whole point of actually _having_ a supervisor mode. :-)

Well a separate mode with a separate stack pointer is very practical
for the don't start a new process to run a program paradigm.

Arne

[V***@SendSpamHere.ORG]

In article <ojegsn$kf$***@dont-email.me>, Simon Clubley <***@remove_me.eisner.decus.org-Earth.UFP> writes:
>On 2017-07-03, VAXman- @SendSpamHere.ORG <[e-mail]> wrote:
>>
>> When in exec mode, one can invoke $CMKRNL and execute code in kernel
>> mode without possessing the privies needed for $CMKRNL because there
>> is a check for the previous mode being exec. There's nothing similar
>> for $CMEXEC from supervisor mode. It sure would have removed a few
>> hurdles for me when writing my DCL Debugger had that been the case.
>>
>
>Thanks Brian.
>
>There's still the bit about being able to set the privilege bits
>in supervisor mode however.
>
>However, if supervisor mode lets you do that, then that would seem to
>defeat the whole point of actually _having_ a supervisor mode. :-)

Because I'm already in supervisor mode with the debugger, I'll check on
this but I have some other issues that I need to focus on first. Also,
it's US In-Dependence Day here.

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

[David Froble]

VAXman- @SendSpamHere.ORG wrote:
> In article <ojegsn$kf$***@dont-email.me>, Simon Clubley <***@remove_me.eisner.decus.org-Earth.UFP> writes:
>> On 2017-07-03, VAXman- @SendSpamHere.ORG <[e-mail]> wrote:
>>> When in exec mode, one can invoke $CMKRNL and execute code in kernel
>>> mode without possessing the privies needed for $CMKRNL because there
>>> is a check for the previous mode being exec. There's nothing similar
>>> for $CMEXEC from supervisor mode. It sure would have removed a few
>>> hurdles for me when writing my DCL Debugger had that been the case.
>>>
>> Thanks Brian.
>>
>> There's still the bit about being able to set the privilege bits
>> in supervisor mode however.
>>
>> However, if supervisor mode lets you do that, then that would seem to
>> defeat the whole point of actually _having_ a supervisor mode. :-)
>
> Because I'm already in supervisor mode with the debugger, I'll check on
> this but I have some other issues that I need to focus on first. Also,
> it's US In-Dependence Day here.
>

What do you do in the DCL debugger when the image is interrupted? Such as
CTRL-Y? I'm going to assume that you don't leave the process in supervisor mode?

Which causes me to be curious. What happens after CTRL-Y and then "CONTINUE"?

[V***@SendSpamHere.ORG]

In article <ojg99i$vm8$***@dont-email.me>, David Froble <***@tsoft-inc.com> writes:
>VAXman- @SendSpamHere.ORG wrote:
>> In article <ojegsn$kf$***@dont-email.me>, Simon Clubley <***@remove_me.eisner.decus.org-Earth.UFP> writes:
>>> On 2017-07-03, VAXman- @SendSpamHere.ORG <[e-mail]> wrote:
>>>> When in exec mode, one can invoke $CMKRNL and execute code in kernel
>>>> mode without possessing the privies needed for $CMKRNL because there
>>>> is a check for the previous mode being exec. There's nothing similar
>>>> for $CMEXEC from supervisor mode. It sure would have removed a few
>>>> hurdles for me when writing my DCL Debugger had that been the case.
>>>>
>>> Thanks Brian.
>>>
>>> There's still the bit about being able to set the privilege bits
>>> in supervisor mode however.
>>>
>>> However, if supervisor mode lets you do that, then that would seem to
>>> defeat the whole point of actually _having_ a supervisor mode. :-)
>>
>> Because I'm already in supervisor mode with the debugger, I'll check on
>> this but I have some other issues that I need to focus on first. Also,
>> it's US In-Dependence Day here.
>>
>
>What do you do in the DCL debugger when the image is interrupted? Such as
>CTRL-Y? I'm going to assume that you don't leave the process in supervisor mode?

*I* don't do anything! DCL does it! ;) The debugger is a tiny, relatively
speaking, piece of code that is actived by LOGINOUT.EXE instead of DCL. It
then activates DCL with a simple intercept in one strategic location. Save
for that, you have DCL running. Whatever it does, it does; nothing changes
because of the debugger. I took extreme precautions to INSURE that there's
no way to exploit my DCL debugger for nefarious malfeasance!



>Which causes me to be curious. What happens after CTRL-Y and then "CONTINUE"?

The image, assuming it had no CTRL-Y handler if its own to invoke its rundown
or exit, will continue running where it was interrupted.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

[Stephen Hoffman]

On 2017-07-03 22:36:08 +0000, Simon Clubley said:

> There's still the bit about being able to set the privilege bits in
> supervisor mode however.
>
> However, if supervisor mode lets you do that, then that would seem to
> defeat the whole point of actually _having_ a supervisor mode. :-)

Supervisor mode is a way to use the VAX hardware memory management
model to perform image rundowns, and a way to limit access to the
interpreter code and data structures. This approach was particularly
useful on older hardware, as the overhead of VAX/VMS process creation
was a common cause for application and/or system performance problems
for many folks on that older and more resource-constrained hardware.

Unix uses a separate process for similar isolation, and runs down
entire processes rather than running down the user mode memory within
the same process. This avoids having a dependency on a processor mode
in the hardware, and also prevents the command interpreter from being
able to directly rummage and potentially corrupt kernel code or data.
This had the interpreter been implemented in the same process context
and executing in kernel mode.

Two different approaches toward the same sorts of housekeeping tasks.

Having a direct change-mode gate between supervisor and exec mode —
akin to the implicit CMKRNL available in exec mode — wouldn't
appreciably change the security of OpenVMS command interpreters, either.

This all touches on kernel designs and assumptions, and how difficult
changing those assumptions can sometimes be. For some completely
different approaches to these same tasks:
https://sel4.systems
http://www.sture.ch/vms/Usenix_VMS-on-Mach.pdf
etc.





--
Pure Personal Opinion | HoffmanLabs LLC

[David Froble]

VAXman- @SendSpamHere.ORG wrote:
> In article <ojdv9r$t4l$***@dont-email.me>, Simon Clubley <***@remove_me.eisner.decus.org-Earth.UFP> writes:
>> On 2017-07-03, John Reagan <***@gmail.com> wrote:
>>> On Monday, July 3, 2017 at 9:39:43 AM UTC-4, Simon Clubley wrote:
>>>> On 2017-07-03, Simon Clubley <***@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.

[Stephen Hoffman]

On 2017-07-03 14:23:52 +0000, John Reagan said:

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

What Simon is referencing may be that path into supervisor mode. An
access violation points to a condition in the code that was not
expected by the developer. An access violation can sometimes be
exploited to provide additional access, such as reading or writing to
otherwise protected memory. That might expose sensitive data, or it
might allow the attacker to modify the data or even the code of the
process. Attacks on various platforms increasingly involve chaining
several vulnerabilities together too, which is why there've been
mentions of ASLR/NX, sandboxes/jails, static and dynamic code coverage
tools, looking at the programming languages involved, etc.



--
Pure Personal Opinion | HoffmanLabs LLC

[j***@yahoo.co.uk]

On Monday, 3 July 2017 14:27:34 UTC+1, Simon Clubley 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).
>
> NOTE: we simply would not be having this discussion if the image in
> question had kernel or executive mode access as I would be following
> standard procedures while exploring it. However, DEC have always made
> a point of saying that if DCL was compromised then it didn't really
> matter anyway because it was only supervisor mode access.
>
> OTOH, Stephen has commented a couple of times that there's a way to
> get further access if you are in supervisor mode. As I don't know
> the VMS source code internals (I've never seen it) I don't know
> what the conditions on Stephen's statement might be.
>
> So, how dangerous is it to be able to get into supervisor mode ?
> I don't really want to spend a lot of time exploring only to find
> out that even if I did manage to control the crash, it didn't matter
> anyway because there was nothing you could do while you had supervisor
> mode access.
>
> Also note that since I am not in a position to judge how dangerous
> it would be to release details on exactly how I did this, I will not
> be releasing any details on how I did this for now just in case it
> turns out to be something more dangerous than I realised.
>
> Even if I did feel it was ok to disclose it, I'd also want to play
> with it a bit more before reporting it anyway in order to see if
> I could simplify the triggering mechanism.
>
> If this were a normal kernel mode crash then the process would be
> simple: report it via a secure mechanism and then release details
> after the patch was released.
>
> Unfortunately, with the supervisor mode access available on VMS
> I am not really in a position to judge whether being able to get
> into DCL supervisor mode is harmless and doesn't even warrant an
> urgent patch or whether this could be something dangerous if it
> did turn out to be exploitable.
>
> Simon.
>
> --
> Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
> Microsoft: Bringing you 1980s technology to a 21st century world

To avoid unnecessary duplication of effort, can you summarise
what resources are readily available (and comprehensible :))
to you at the moment?

E.g. VMS Internals and Data Structures as relates to memory
management and to DCL - any version? relevant Alpha version?
(the Alpha versions don't seem to be readily available for free,
I thought I'd seen VAX versions, ie antiques, somewhere).
Probably a bit OTT for this though.

[Simon Clubley]

On 2017-07-03, ***@yahoo.co.uk <***@yahoo.co.uk> wrote:
>
> To avoid unnecessary duplication of effort, can you summarise
> what resources are readily available (and comprehensible :))
> to you at the moment?
>
> E.g. VMS Internals and Data Structures as relates to memory
> management and to DCL - any version? relevant Alpha version?
> (the Alpha versions don't seem to be readily available for free,
> I thought I'd seen VAX versions, ie antiques, somewhere).
> Probably a bit OTT for this though.

In addition to a full set of the VMS PDF documentation and various
hardware/architecture related PDFs, I also have most of the printed
books including the earlier Alpha I&DS.

I do not have access to the VMS source code and since there's
no legal way for me to get access to the source code without
paying a licence fee, I do not want access to the VMS source code.

Every piece of documentation I do have (both electronic and printed)
is fully understandable to me when I read the material.

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world