In article <uoc3gf$2oe4i$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 1/18/2024 3:38 PM, Lawrence D'Oliveiro wrote:
>> DECnet had an address space so restricted, it make the 32-bit IP address
>> space seem expansive.
>
>16 bit is less than 32 bit.
>
>If DEC had known how large DECnet networks would become, then they
>would probably have chosen 32 bit.
>
>But it is difficult to predict the future.
>
>> And whose dumb idea was it to tie the DECnet address
>> to the MAC address?
>
>It is pretty smart. No need for an extra protocol.

IPv6 with SLAAC does the same thing. It's very convenient;
though of course the IPv6 address space is much larger than
either DECnet or IPv4.

- Dan C.

In article <uobmub$2m944$1@dont-email.me>,
Mark Berryman <mark@theberrymans.com> wrote:
>On 1/18/24 6:06 AM, Simon Clubley wrote:
>> On 2024-01-17, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>> On Wed, 17 Jan 2024 13:11:31 -0000 (UTC), Simon Clubley wrote:
>>>> The server software with the vulnerability could be the DECnet stack
>>>> running on that server.
>>>
>>> Any reason why you think DECnet is particularly prone to introducing
>>> security holes, per se?
>>
>> Because, at best, it has only had a very small fraction of the effort
>> spent on probing it that the mainstream network stacks have had.
>
>Simon's postings would tend to indicate that he believes that anything
>not subject to constant probing by hundreds or thousands of hack.., er,
>security researchers is just full of latent bugs waiting to be discovered.

History has shown that Simon is mostly correct in that belief.

>It might help to remember that the IP stack was designed by committee
>and implemented by an even more diverse group, some good at programming,
>some not so much. DECnet, however, was designed and implemented by a
>much smaller group, which often leads to much better code. I suspect,
>but don't know for sure, that the designers and implementers were also
>essentially the same people. (They were also very good).

Which IP stack are you referring to? IP has been implemented
many times by many different groups; even on VMS!

>Also, once upon a time, DECnet was a more diverse network than the
>internet. Until the internet went public in the early 90s, it was quite
>limited in scope, consisting mainly of some government institutions,
>some government contractors, and some universities. DECnet, however,
>was used to implement a number of world-wide networks consisting of many
>diverse endpoints. There was some probing that went on but not a whole
>lot. For one, with DECnet the source was too easy to trace and, for
>another, if any of the probes were successful I never heard of it (I was
>on SPAN at the time). This was all DECnet phase IV. After the internet
>went public, these networks ran multiple protocols in parallel,
>including TCP/IP and DECnet. As DEC equipment was phased out at these
>sites, so was DECnet. But it somehow managed to survive without issue
>all those years. (The only known problems were caused by local
>misconfigurations by people who didn't read the manual and simply
>accepted defaults that should have been better. None were cause by the
>stack itself.)
>
>Finally, as I mentioned in an earlier post, it is trivial in today's
>world to isolate one's DECnet stack from anything other than trusted
>hosts. On any network where I have been involved, it some host were
>compromised, and if that host were to try to probe DECnet, none of its
>packets would even reach the DECnet interface of any host that was
>actually running DECnet.
>
>There are, after all, many ways to implement security.
>
>My two cents.

I dunno. I'd bet a month's salary that more packets travel
across the Internet in a day than have transitted DECnet ever.
That's a lot of testing and hardening.

This of course doesn't mean that DECnet implementations are
insecure, but it does mean they are a _lot_ less tested. It
could be that they're insecure and no one realizes because no
one has tested sufficiently. That means there's an element of
risk there that doesn't exist with e.g. the Linux or BSD TCP/IP
stacks.

- Dan C.

On 1/18/24 11:38 AM, Simon Clubley wrote:
> On 2024-01-18, Mark Berryman <mark@theberrymans.com> wrote:
>>
>> Sorry, I am only infrequently on this forum.
>>
>> On my system EVL runs with exactly the privs I specified earlier but I
>> did do some digging.
>>
>> EVL is started by netacp in whatever account netacp is running using the
>> command file sys$system:evl.com. EVL neither raises nor lowers privs.
>> The startup command file normally looks like this:
>> $ ! Copyright (c) 1987 Digital Equipment Corporation. All rights reserved.
>> $ SET NOON
>> $ IF "''EVL$COMMAND'" .NES. "" THEN EVL$COMMAND
>> $ RUN SYS$SYSTEM:EVL
>> $ PURGE/KEEP=3 EVL.LOG
>> $ LOGOUT/BRIEF
>>
>> However, sometime in the dim and distant past (meaning I no longer
>> remember when or why) I inserted this line:
>>
>> $ SET PROCESS/PRIVILEGES=(NOALL,SYSNAM,OPER,SYSPRV,NETMBX,TMPMBX)
>>
>> which is why EVL is limited in privs on my system. Anyone concerned can
>> make the same edit.
>>
>
> Because that command is being run in the same process as the EVL listener
> it will not help constrain an attacker. This is because all an attacker
> needs to do in their shellcode is to reenable those privileges.

IIRC, you managed to crash EVL using an insecure setup. Crashing a
process is much different that convincing a process to run bogus code
and, of course, simply crashing EVL causes its process to exit.

With a secure setup, you can't get your malformed packets into EVL.
However, if you'd like to show how you can get EVL to run bogus code, in
any setup, then you will have raised a very valid concern. Until then,
I have addressed what concern you have raised.

Mark Berryman

On 2024-01-19, Mark Berryman <mark@theberrymans.com> wrote:
> On 1/18/24 11:38 AM, Simon Clubley wrote:
>> On 2024-01-18, Mark Berryman <mark@theberrymans.com> wrote:
>>>
>>> Sorry, I am only infrequently on this forum.
>>>
>>> On my system EVL runs with exactly the privs I specified earlier but I
>>> did do some digging.
>>>
>>> EVL is started by netacp in whatever account netacp is running using the
>>> command file sys$system:evl.com. EVL neither raises nor lowers privs.
>>> The startup command file normally looks like this:
>>> $ ! Copyright (c) 1987 Digital Equipment Corporation. All rights reserved.
>>> $ SET NOON
>>> $ IF "''EVL$COMMAND'" .NES. "" THEN EVL$COMMAND
>>> $ RUN SYS$SYSTEM:EVL
>>> $ PURGE/KEEP=3 EVL.LOG
>>> $ LOGOUT/BRIEF
>>>
>>> However, sometime in the dim and distant past (meaning I no longer
>>> remember when or why) I inserted this line:
>>>
>>> $ SET PROCESS/PRIVILEGES=(NOALL,SYSNAM,OPER,SYSPRV,NETMBX,TMPMBX)
>>>
>>> which is why EVL is limited in privs on my system. Anyone concerned can
>>> make the same edit.
>>>
>>
>> Because that command is being run in the same process as the EVL listener
>> it will not help constrain an attacker. This is because all an attacker
>> needs to do in their shellcode is to reenable those privileges.
>
> IIRC, you managed to crash EVL using an insecure setup. Crashing a
> process is much different that convincing a process to run bogus code
> and, of course, simply crashing EVL causes its process to exit.
>

By "insecure setup", you mean using a network stack as supplied out of
the box by a vendor selling "the world's most secure operating system" ?

> With a secure setup, you can't get your malformed packets into EVL.
> However, if you'd like to show how you can get EVL to run bogus code, in
> any setup, then you will have raised a very valid concern. Until then,
> I have addressed what concern you have raised.
>

For my concern to be handled, they would also have to be permanently
removed from the list of authorised privileges, not just the list of
currently enabled privileges.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On Fri, 19 Jan 2024 13:11:31 -0000 (UTC), Simon Clubley wrote:

> As I have already mentioned, that only protects data in transit.

Relevance being?

On Thu, 11 Jan 2024 13:48:37 -0000 (UTC), Simon Clubley wrote:

> Things like SSL only protect data in motion.

How exactly is a network protocol supposed to operate when not “in
motion”?

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>On Fri, 19 Jan 2024 13:11:31 -0000 (UTC), Simon Clubley wrote:
>
>> As I have already mentioned, that only protects data in transit.
>
>Relevance being?

Local attacks are still possible. Which is much less of a worry in most
environments, true. But it's an easy thing to avoid, and decnet did not.

I run phase IV on some machines that aren't critical and it works and is
convenient and well-integrated with the older VMS version in use. I would
not want to run it on a production system today but thanks to the efforts
of people at TGV and FTP Software I don't have to.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 2024-01-19 18:44:29 +0000, Simon Clubley said:

> By "insecure setup", you mean using a network stack as supplied out of
> the box by a vendor selling "the world's most secure operating system" ?

That DECnet uses cleartext credentials for network connections, both
within the cleartext network protocol, and usernames and passwords
stored within the hopefully-protected DECnet database, was straight out
of 1990.

--
Pure Personal Opinion | HoffmanLabs LLC

On 1/19/24 11:44 AM, Simon Clubley wrote:
> On 2024-01-19, Mark Berryman <mark@theberrymans.com> wrote:
..
..
..
>>> Because that command is being run in the same process as the EVL listener
>>> it will not help constrain an attacker. This is because all an attacker
>>> needs to do in their shellcode is to reenable those privileges.
>>
>> IIRC, you managed to crash EVL using an insecure setup. Crashing a
>> process is much different that convincing a process to run bogus code
>> and, of course, simply crashing EVL causes its process to exit.
>>
>
> By "insecure setup", you mean using a network stack as supplied out of
> the box by a vendor selling "the world's most secure operating system" ?

No, by insecure setup I mean you allowed an untrusted host, and one not
running DECnet, access to another host's DECnet stack.

Mark Berryman

On Fri, 19 Jan 2024 22:44:55 -0500, Stephen Hoffman wrote:

> That DECnet uses cleartext credentials for network connections, both
> within the cleartext network protocol, and usernames and passwords
> stored within the hopefully-protected DECnet database, was straight out
> of 1990.

We know how to mitigate that nowadays. Constrain it to a limited set of
mutually-trusted nodes, that cannot see anything else (via DECnet) anyway,
connected via trusted channels, most likely virtual.

On 2024-01-19, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Fri, 19 Jan 2024 13:11:31 -0000 (UTC), Simon Clubley wrote:
>
>> As I have already mentioned, that only protects data in transit.
>
> Relevance being?

In view of the existing discussion about attacking the stack itself
and not any existing data transfers, that question doesn't even make
any sense.

I gave you the benefit of the doubt (I'm like that :-)), but it is
clear you are either a troll or simply do not understand the issues
involved (and if it's the latter case, you probably don't even realise
fully what is it you don't understand).

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2024-01-19, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Thu, 11 Jan 2024 13:48:37 -0000 (UTC), Simon Clubley wrote:
>
>> Things like SSL only protect data in motion.
>
> How exactly is a network protocol supposed to operate when not ?in
> motion??

Yes, you are either trolling or simply do not understand.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2024-01-20, Mark Berryman <mark@theberrymans.com> wrote:
> On 1/19/24 11:44 AM, Simon Clubley wrote:
>> On 2024-01-19, Mark Berryman <mark@theberrymans.com> wrote:
> .
> .
> .
>>>> Because that command is being run in the same process as the EVL listener
>>>> it will not help constrain an attacker. This is because all an attacker
>>>> needs to do in their shellcode is to reenable those privileges.
>>>
>>> IIRC, you managed to crash EVL using an insecure setup. Crashing a
>>> process is much different that convincing a process to run bogus code
>>> and, of course, simply crashing EVL causes its process to exit.
>>>
>>
>> By "insecure setup", you mean using a network stack as supplied out of
>> the box by a vendor selling "the world's most secure operating system" ?
>
> No, by insecure setup I mean you allowed an untrusted host, and one not
> running DECnet, access to another host's DECnet stack.
>

Oh, I see Mark. So you mean just like every public node on the Internet is
supposed to handle without instantly falling over ? :-) (And which gets
fixed when something unexpected is found ?)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 1/22/24 6:12 AM, Simon Clubley wrote:
> On 2024-01-20, Mark Berryman <mark@theberrymans.com> wrote:
>> On 1/19/24 11:44 AM, Simon Clubley wrote:
>>> On 2024-01-19, Mark Berryman <mark@theberrymans.com> wrote:
>> .
>> .
>> .
>>>>> Because that command is being run in the same process as the EVL listener
>>>>> it will not help constrain an attacker. This is because all an attacker
>>>>> needs to do in their shellcode is to reenable those privileges.
>>>>
>>>> IIRC, you managed to crash EVL using an insecure setup. Crashing a
>>>> process is much different that convincing a process to run bogus code
>>>> and, of course, simply crashing EVL causes its process to exit.
>>>>
>>>
>>> By "insecure setup", you mean using a network stack as supplied out of
>>> the box by a vendor selling "the world's most secure operating system" ?
>>
>> No, by insecure setup I mean you allowed an untrusted host, and one not
>> running DECnet, access to another host's DECnet stack.
>>
>
> Oh, I see Mark. So you mean just like every public node on the Internet is
> supposed to handle without instantly falling over ? :-) (And which gets
> fixed when something unexpected is found ?)
Most likely, every public node on the Internet is behind a firewall,
which severely limits what packets can reach a given node and, depending
on the quality of the firewall, the nature of those packets (i.e. good
firewalls can detect and reject malformed packets).

Sadly, when an IP-based attack makes it through the firewall and into a
host, the host typically does worse than "fall over". It lets the
attacker in where the attacker can then do all kinds of nefarious
things. This is often not detected until long after the fact. If there
has ever been a successful attack from an external source on a VMS
system that allowed the attacker to muck around on that system, I am not
aware of it. Are you?

The purpose of a firewall is to protect the IP stack of the hosts behind
it. I merely suggested a couple of ways one can firewall one's DECnet
traffic, and thereby protect that stack. Nothing unusual or exceptional
about it.

I ran a VMS host fully exposed to the Internet with DECnet phase V on it
for years without issue. It was a honeypot so it wanted to see as many
attack attempts as possible. It was running WASD instead of Apache so
none of the attacks on the web port succeeded and none of the attacks on
the ports used by DECnet ever caused an issue. So, real word
experience, not guess work. And, no, I wouldn't try this with any other
platform.

Mark Berryman

On 2024-01-22, Mark Berryman <mark@theberrymans.com> wrote:
>
> Sadly, when an IP-based attack makes it through the firewall and into a
> host, the host typically does worse than "fall over". It lets the
> attacker in where the attacker can then do all kinds of nefarious
> things. This is often not detected until long after the fact. If there
> has ever been a successful attack from an external source on a VMS
> system that allowed the attacker to muck around on that system, I am not
> aware of it. Are you?
>

I know that Stephen has mentioned he has had to clean up compromised VMS
systems for clients, but I don't recall him stating the infection origin.
I suspect, given the nature of VMS systems and the people who manage them,
such details are kept private however.

The biggest external problem I have ever had to personally deal with was
that the UCX stack still had an SMTP open relay with no way of restricting
it, when the rest of the world had moved on and this was very, very, no
longer acceptable.

It's been too long, so I don't recall how I fixed that. I could have waited
for a later version of UCX before enabling this, or I could have put a Linux
email server in front of the VMS system.

I do know this was about the time I finally abandoned the idea of directly
attaching a webserver running on a VMS system to the Internet and placing
it instead behind a Linux webserver, but I can't remember how I fixed the
open relay issue.

> The purpose of a firewall is to protect the IP stack of the hosts behind
> it. I merely suggested a couple of ways one can firewall one's DECnet
> traffic, and thereby protect that stack. Nothing unusual or exceptional
> about it.
>
> I ran a VMS host fully exposed to the Internet with DECnet phase V on it
> for years without issue. It was a honeypot so it wanted to see as many
> attack attempts as possible. It was running WASD instead of Apache so
> none of the attacks on the web port succeeded and none of the attacks on
> the ports used by DECnet ever caused an issue. So, real word
> experience, not guess work. And, no, I wouldn't try this with any other
> platform.
>

I assume this was way after the DECnet worms were no longer a thing... :-)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2024-01-23 13:29:56 +0000, Simon Clubley said:

> The biggest external problem I have ever had to personally deal with
> was that the UCX stack still had an SMTP open relay with no way of
> restricting it, when the rest of the world had moved on and this was
> very, very, no longer acceptable.

Last I checked, the 💩 default for TCP/IP Services SMTP mail server was
a 💩 open relay. With no diagnostics. Reproducer was trivially simple:
delete (or mis-locate) the SMTP configuration file.

With no TLS and no STARTTLS support to be found anywhere in the TCP/IP
mail server, last I checked.

--
Pure Personal Opinion | HoffmanLabs LLC

On 1/22/2024 2:40 PM, Mark Berryman wrote:
> Most likely, every public node on the Internet is behind a firewall,
> which severely limits what packets can reach a given node and, depending
> on the quality of the firewall, the nature of those packets (i.e. good
> firewalls can detect and reject malformed packets).
>
> Sadly, when an IP-based attack makes it through the firewall and into a
> host, the host typically does worse than "fall over".  It lets the
> attacker in where the attacker can then do all kinds of nefarious
> things.  This is often not detected until long after the fact.  If there
> has ever been a successful attack from an external source on a VMS
> system that allowed the attacker to muck around on that system, I am not
> aware of it.  Are you?

Long time ago: yes.

> The purpose of a firewall is to protect the IP stack of the hosts behind
> it.  I merely suggested a couple of ways one can firewall one's DECnet
> traffic, and thereby protect that stack.

Internet is IP only and firewalls does never pass DECnet traffic, so
no DECnet attacks that way.

DECnet attacks has to either be local or get in via IP and propagate
via DECnet.

> I ran a VMS host fully exposed to the Internet with DECnet phase V on it
> for years without issue.  It was a honeypot so it wanted to see as many
> attack attempts as possible.  It was running WASD instead of Apache so
> none of the attacks on the web port succeeded and none of the attacks on
> the ports used by DECnet ever caused an issue.

I was not even aware that DECnet used ports.

And how did DECnet traffic come in via the internet?

Arne

Arne Vajhøj schrieb am 24.01.2024 um 01:01:
> On 1/22/2024 2:40 PM, Mark Berryman wrote:
>> Most likely, every public node on the Internet is behind a firewall,
>> which severely limits what packets can reach a given node and,
>> depending on the quality of the firewall, the nature of those packets
>> (i.e. good firewalls can detect and reject malformed packets).
>>
>> Sadly, when an IP-based attack makes it through the firewall and into
>> a host, the host typically does worse than "fall over".  It lets the
>> attacker in where the attacker can then do all kinds of nefarious
>> things.  This is often not detected until long after the fact.  If
>> there has ever been a successful attack from an external source on a
>> VMS system that allowed the attacker to muck around on that system, I
>> am not aware of it.  Are you?
>
> Long time ago: yes.
>
>> The purpose of a firewall is to protect the IP stack of the hosts
>> behind it.  I merely suggested a couple of ways one can firewall one's
>> DECnet traffic, and thereby protect that stack.
>
> Internet is IP only and firewalls does never pass DECnet traffic, so
> no DECnet attacks that way.
>
> DECnet attacks has to either be local or get in via IP and propagate
> via DECnet.
>
>> I ran a VMS host fully exposed to the Internet with DECnet phase V on
>> it for years without issue.  It was a honeypot so it wanted to see as
>> many attack attempts as possible.  It was running WASD instead of
>> Apache so none of the attacks on the web port succeeded and none of
>> the attacks on the ports used by DECnet ever caused an issue.
>
> I was not even aware that DECnet used ports.
>
> And how did DECnet traffic come in via the internet?
Mark mentioned DECnet phase V which often/mostly uses DECnet over IP
enabled and so uses IP ports.

While there will be rarely incoming DECnet traffic, the ports for DECnet
over IP may be attacked.

Hans.

On 2024-01-23, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 1/22/2024 2:40 PM, Mark Berryman wrote:
>> I ran a VMS host fully exposed to the Internet with DECnet phase V on it
>> for years without issue.  It was a honeypot so it wanted to see as many
>> attack attempts as possible.  It was running WASD instead of Apache so
>> none of the attacks on the web port succeeded and none of the attacks on
>> the ports used by DECnet ever caused an issue.
>
> I was not even aware that DECnet used ports.
>

They are called objects, but they are really numbered ports, just like
TCP/IP. However, I suspect Mark is talking about the TCP/IP ports used
as a transport for DECnet packets, in the same way as SSH can be used
to transport X11 traffic.

> And how did DECnet traffic come in via the internet?
>

I suspect the implementation Mark is using encapsulates the DECnet
traffic in a little custom TCP/IP-based protocol, which is then routed
over one or more TCP/IP ports to its destination before the encapsulation
is reversed and the DECnet packets delivered to the target DECnet stack.

That means the attacks would be limited to malformed TCP/IP packets
unless the attacker was also running a DECnet stack and the same TCP/IP
DECnet encapsulation protocol.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 1/24/24 6:11 AM, Simon Clubley wrote:
> On 2024-01-23, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 1/22/2024 2:40 PM, Mark Berryman wrote:
>>> I ran a VMS host fully exposed to the Internet with DECnet phase V on it
>>> for years without issue.  It was a honeypot so it wanted to see as many
>>> attack attempts as possible.  It was running WASD instead of Apache so
>>> none of the attacks on the web port succeeded and none of the attacks on
>>> the ports used by DECnet ever caused an issue.
>>
>> I was not even aware that DECnet used ports.
>>
>
> They are called objects, but they are really numbered ports, just like
> TCP/IP. However, I suspect Mark is talking about the TCP/IP ports used
> as a transport for DECnet packets, in the same way as SSH can be used
> to transport X11 traffic.
>
>> And how did DECnet traffic come in via the internet?
>>
>
> I suspect the implementation Mark is using encapsulates the DECnet
> traffic in a little custom TCP/IP-based protocol, which is then routed
> over one or more TCP/IP ports to its destination before the encapsulation
> is reversed and the DECnet packets delivered to the target DECnet stack.
>
> That means the attacks would be limited to malformed TCP/IP packets
> unless the attacker was also running a DECnet stack and the same TCP/IP
> DECnet encapsulation protocol.

No, as I mentioned in a previous message, it was DECnet Phase V, which
supports DECnet over IP. An attacker would not need to be running
DECnet. The attacks simply tried to attack the ports used by DECnet
phase V. And, as I mentioned, none of those attack attempts caused an
issue for the DECnet stack.

Mark Berryman

On 1/23/24 3:15 PM, Stephen Hoffman wrote:
> On 2024-01-23 13:29:56 +0000, Simon Clubley said:
>
>
>
>> The biggest external problem I have ever had to personally deal with
>> was that the UCX stack still had an SMTP open relay with no way of
>> restricting it, when the rest of the world had moved on and this was
>> very, very, no longer acceptable.
>
> Last I checked, the 💩 default for TCP/IP Services SMTP mail server was
> a 💩 open relay. With no diagnostics. Reproducer was trivially simple:
> delete (or mis-locate) the SMTP configuration file.
>
> With no TLS and no STARTTLS support to be found anywhere in the TCP/IP
> mail server, last I checked.

The applications that come with TCP/IP Services are but one of the many
reasons that I have stated in the past that, if you are really concerned
about security, you don't run TCP/IP Services, you run Multinet. And,
at least for mail, if Multinet is not an option then try PMDF.

I no longer have the resources to bang on TCP/IP Services V6 that I once
had but, for any earlier version, yes - there were issues. I really
hope VSI has, or will, address them in the new version.

Mark Berryman