[Info-vax] Unexpected DECnet Phase IV functionality with possible captive account implications
Simon Clubley
clubley at remove_me.eisner.decus.org-Earth.UFP
Thu May 13 00:14:35 EDT 2021
On 2021-05-12, Tad Winters <tad.vms at gmx.com> wrote:
> On 5/12/2021 5:10 AM, Simon Clubley via Info-vax wrote:
>> On 2021-05-11, Dave Froble <davef at tsoft-inc.com> wrote:
>>> On 5/11/2021 10:44 AM, Stephen Hoffman wrote:
>>>>
>>>> It's a way of directly activating hunks of a captive environment that
>>>> might not be accessible directly.
>>>
>>> Only if those "hunks" exist.
>>>
>>
>> As I have already mentioned, someone can also copy a command procedure
>> of their choosing to the captive account using FAL and then execute the
>> command procedure using one of the two methods.
>>
>> Simon.
>>
>
> If you don't want that, set the ownership/protection on the command
> procedure so that it cannot be overwritten.
>
But the attacker gets to create a filename of their own choosing.
They don't have to replace an existing command procedure because
both methods work on the attacker-chosen name, not an existing filename.
The point is that if they have network access, they can copy over
a filename of their choosing to the captive account and then execute
that file while still in network access mode, without ever having
to go anywhere near an interactive login in order to execute the
command file they have just transferred.
> Certainly you don't expect FAL to be implemented to determine if the
> target file is a command procedure used as part of the potential group
> of command procedures called from a CAPTIVE account, do you?
>
No way. :-)
The real problem I have is with the active features of DECnet and that
they are enabled by default for captive accounts. To me, that violates
the principle of least astonishment:
https://en.wikipedia.org/wiki/Principle_of_least_astonishment
and VMS is supposed to be built around that principle.
What I would like to see is for FAL to go back to being the passive
data access mechanism by default that the specification says it should be.
I would also like to see the active features of DECnet (ie: task-to-task
communications) disabled by default for captive accounts until explicitly
enabled by the system manager.
If you protect the login command procedures sufficiently (along with
any associated data files) then the worst that can happen then if you
don't have things sufficiently locked down is that someone can write
passive junk into the captive account directory.
Network protocols need to be tightened up over time as new issues
are discovered. This happens to TCP/IP and it should happen to DECnet
as well. Just because something was once acceptable, does not mean it
is acceptable today.
Simon.
--
Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
More information about the Info-vax
mailing list