Discussion:
Using RTERM from OpenVMS ALPHA
(too old to reply)
Tony Nicholson
2020-09-02 23:53:23 UTC
Permalink
I recently upgraded one of my hobbyist OpenVMS Alpha systems
from HP OpenVMS V8.4 to VSI OpenVMS V8.4-2L1 (VSI Community
License) using an AlphaVM-Free emulation.

When I try connecting to a SIMH PDP-11 simulation using
RTERM protocol (the PDP-11 system runs RSTS/E V10.1 and
doesn't support CTERM) I get an ACCVIO -

[From VSI OpenVMS Alpha V8.4-2L1]

$ set host/app=rterm dingo
%REM-I-CONNECTION, connection made using RTERM protocol
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual
address=0000517000008AA4, PC=0000517000008AA4, PS=0000001B

Improperly handled condition, image exit forced.

[I've omitted register dump details]

I know I have used this previously from OpenVMS VAX V7.3 and
have verified just now that it works.

[From OpenVMS VAX V7.3]

$ set host /app=rterm dingo
%REM-I-CONNECTION, connection made using RTERM protocol
%REM-I-REMOTE, connection established to remote node DINGO::
RSTS V10.1-L 03-Sep-20 08:41 AM
User: 1,2
Password:
Last interactive login on 02-Sep-20, 04:51 PM at KB13:
Last non-interactive login on 25-Aug-20, 03:46 PM
1 other user is logged in under this account


I've also checked by booting older versions of OpenVMS
back to OpenVMS V7.3-1 on Alpha and they all seem to fail
in the same way.

I know there's some other hobbyists lurking here and running
RSTS/E too. Does anyone have the same issue with RTERM
from OpenVMS Alpha?

I haven't yet verified this fails using real Alpha hardware;
so it could be an emulator issue.

Tony
Tony Nicholson
2020-09-03 01:59:10 UTC
Permalink
On Thursday, September 3, 2020 at 9:53:25 AM UTC+10, Tony Nicholson wrote:

[snip]
Post by Tony Nicholson
When I try connecting to a SIMH PDP-11 simulation using
RTERM protocol (the PDP-11 system runs RSTS/E V10.1 and
doesn't support CTERM) I get an ACCVIO -
[snip]
Post by Tony Nicholson
I haven't yet verified this fails using real Alpha hardware;
so it could be an emulator issue.
It does this on real hardware too.

HP OpenVMS V8.4 on a Jensen (DEC 2000 model 300) -

$ multi show /ver
Process Software MultiNet 5.5 Rev A-X, DEC 2000 Model 300, OpenVMS AXP V8.4
TAIPAN $ set host /app=rterm dingo
%REM-I-CONNECTION, connection made using RTERM protocol
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=000051700000
8AA4, PC=0000517000008AA4, PS=0000001B

Improperly handled condition, image exit forced.
Signal arguments: Number = 0000000000000005
Name = 000000000000000C
0000000000010000
0000517000008AA4
0000517000008AA4
000000000000001B

Register dump:
R0 = 0000000000000003 R1 = 0000000000008F50 R2 = 0000000000008134
R3 = 0000000000034804 R4 = 000000007FFCF814 R5 = 0000000000009AEF
R6 = 0000000000000000 R7 = 0000000000000001 R8 = 000000000003481C
R9 = 000000007FF9DDF0 R10 = 000000007FFA4F28 R11 = 000000007FFCDC18
R12 = 000000007FFCDA98 R13 = 0000000000005170 R14 = 0000000000008E28
R15 = 0000000000008E28 R16 = 0000000002A83089 R17 = 0000000000200000
R18 = FFFFFFFF80904A20 R19 = FFFFFFFF81D45050 R20 = 0000000000000002
R21 = 0000000000000000 R22 = 000000007ADC7A54 R23 = FFFFFFFF80182FD0
R24 = 0000000000000001 R25 = 0000000000000003 R26 = FFFFFFFF8018300C
R27 = 000000007ADC7A54 R28 = 0000000000000006 R29 = 000000007ADC7A60
SP = 000000007ADC7A30 PC = 0000517000008AA4 PS = 300000000000001B


Tony
G.
2020-09-04 06:17:52 UTC
Permalink
Post by Tony Nicholson
I know there's some other hobbyists lurking here and running
RSTS/E too. Does anyone have the same issue with RTERM
from OpenVMS Alpha?
It's been a (long) while but IIRC the problem arose sometime after OpenVMS
Alpha V7.2 which I'm almost sure worked as expected. I do not remember if
vanilla OpenVMS Alpha V7.3 (i.e. not V7.3-1) had the problem or not but for
sure V8.x had it.

I've just found some old message of mine about the very same issue that I
sent to the HECnet mailing list seven (!) years ago. Here it is.

| RTPAD.EXE on OpenVMS V8.3 for both Alpha and Itanium (IIRC) has some serious
| bug that prevents it from connecting to such older OSes using the old RTERM
| protocol: actually it ACCVIOs before doing any useful work.
|
| The RTERM protocol can be used to connect to VMS too, and when connecting to
| another VMS node using RTERM, the V8.3 RTPAD.EXE works as expected. So, either
| some older OSes are sending out-of-standard packets (and the older RTPAD.EXE
| were more forgiving), or the new RTPAD.EXE cannot understand all the protocol
| variants and intricacies (as the older versions did).
|
| I tried exchanging V8.3 RTPAD.EXE (ident X-10) with a couple of older versions
| (idents X-8, X-9) and even with the V8.4 one (ident X-10 too, so should be the
| same as V8.3), to no avail: every one of them ACCVIOs as well. The oldest I
| tried (X-8) comes from plain vanilla V7.2 (and does not work), but I'm almost
| sure (I cannot swear on it, though) that RTERM worked fine in V7.2, so I'm
| stuck: the same image (X-8) was working on V7.2 but it's not in V8.3.
|
| I know that testing by exchanging images among different VMS versions is not
| bulletproof, but considering that I didn't get any error like SHRIDMISMAT and
| such, I feel confident about thinking that they are compatible. So maybe the
| problem is somewhere else, probably in some shared library.

Someone with access to sources found that in V8.3 the stack dump pointed to
module RSTSRT in RTPAD.EXE and also that the virtual address and the PC in
there looked odd as if there were some bad stack manipulation.

HTH,
G.
Simon Clubley
2020-09-04 12:09:56 UTC
Permalink
Post by G.
Someone with access to sources found that in V8.3 the stack dump pointed to
module RSTSRT in RTPAD.EXE and also that the virtual address and the PC in
there looked odd as if there were some bad stack manipulation.
I saw the PC contents in the original posting.

If I were still looking for vulnerabilities on VMS, I would currently
be taking a very close look at this.

I hope someone here from VSI has realised the possible implications of
that PC value and I hope that VSI are currently taking a close look at
the source code as a matter of urgency.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
John Reagan
2020-09-04 14:00:14 UTC
Permalink
Post by Simon Clubley
Post by G.
Someone with access to sources found that in V8.3 the stack dump pointed to
module RSTSRT in RTPAD.EXE and also that the virtual address and the PC in
there looked odd as if there were some bad stack manipulation.
I saw the PC contents in the original posting.
If I were still looking for vulnerabilities on VMS, I would currently
be taking a very close look at this.
I hope someone here from VSI has realised the possible implications of
that PC value and I hope that VSI are currently taking a close look at
the source code as a matter of urgency.
Simon.
--
Walking destinations on a map are further away than they appear.
Since RTPAD is a user-mode image that has no privs, (it is INSTALLED with just TMPMBX), it doesn't have much leverage.
It isn't a shareable image that might be mapped by a priv'd program.

Want to crash it, go ahead. Want to find an exploit in the protocols and server at the other end? Write you own RTPAD and go for it.
Simon Clubley
2020-09-04 17:13:58 UTC
Permalink
Post by John Reagan
Since RTPAD is a user-mode image that has no privs, (it is INSTALLED with
just TMPMBX), it doesn't have much leverage.
It isn't a shareable image that might be mapped by a priv'd program.
Want to crash it, go ahead. Want to find an exploit in the protocols and
server at the other end? Write you own RTPAD and go for it.
What you have failed to consider John is the possibility that the
server might be able to send suitably malformed packets that cause
attacker-controlled code to execute within the user's process.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Richard Brodie
2020-09-04 20:30:24 UTC
Permalink
Post by Simon Clubley
What you have failed to consider John is the possibility that the
server might be able to send suitably malformed packets that cause
attacker-controlled code to execute within the user's process.
A bit of a niche attack, if it requires one to setup a host reachable via
DECnet to affect the three people still using RTERM.
V***@SendSpamHere.ORG
2020-09-04 21:17:40 UTC
Permalink
Post by Richard Brodie
Post by Simon Clubley
What you have failed to consider John is the possibility that the
server might be able to send suitably malformed packets that cause
attacker-controlled code to execute within the user's process.
A bit of a niche attack, if it requires one to setup a host reachable via
DECnet to affect the three people still using RTERM.
ROTFLMFAO! I'd had similar thoughts but sometimes it's more fun to sit back
to allow sufficient time for the thought processes to permeate the stupidity
membrane.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.
Simon Clubley
2020-09-07 12:21:07 UTC
Permalink
Post by V***@SendSpamHere.ORG
Post by Richard Brodie
Post by Simon Clubley
What you have failed to consider John is the possibility that the
server might be able to send suitably malformed packets that cause
attacker-controlled code to execute within the user's process.
A bit of a niche attack, if it requires one to setup a host reachable via
DECnet to affect the three people still using RTERM.
ROTFLMFAO! I'd had similar thoughts but sometimes it's more fun to sit back
to allow sufficient time for the thought processes to permeate the stupidity
membrane.
And you have all completely and utterly missed the point. :-(

RTERM is only one of the protocols implemented in this code.

What if the same changes that stopped RTERM from working also introduced
an exploitable bug into the CTERM code so that the CTERM code only
_appears_ to be working correctly ?

So the next time you all think something like this can be easily dismissed,
try thinking through the larger picture and possibilities instead, because
that's exactly what an attacker would do.

They would see a flaw in one area and wonder if there were exploitable
flaws in related areas, such as the CTERM code in this case.

Like I said, I hope VSI are looking at the code urgently. I doubt that
is happening however based on the comments so far.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Dave Froble
2020-09-07 17:20:44 UTC
Permalink
Post by Simon Clubley
Post by V***@SendSpamHere.ORG
Post by Richard Brodie
Post by Simon Clubley
What you have failed to consider John is the possibility that the
server might be able to send suitably malformed packets that cause
attacker-controlled code to execute within the user's process.
A bit of a niche attack, if it requires one to setup a host reachable via
DECnet to affect the three people still using RTERM.
ROTFLMFAO! I'd had similar thoughts but sometimes it's more fun to sit back
to allow sufficient time for the thought processes to permeate the stupidity
membrane.
And you have all completely and utterly missed the point. :-(
RTERM is only one of the protocols implemented in this code.
What if the same changes that stopped RTERM from working also introduced
an exploitable bug into the CTERM code so that the CTERM code only
_appears_ to be working correctly ?
So the next time you all think something like this can be easily dismissed,
try thinking through the larger picture and possibilities instead, because
that's exactly what an attacker would do.
They would see a flaw in one area and wonder if there were exploitable
flaws in related areas, such as the CTERM code in this case.
Like I said, I hope VSI are looking at the code urgently. I doubt that
is happening however based on the comments so far.
Simon.
I'd guess the issue was attached to some list. (I'd hope so.)

It would not make much sense to expect VSI to drop everything and jump
on some new issue immediately. Yes, there might be such issues, but
highly unlikely.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Simon Clubley
2020-09-08 12:07:10 UTC
Permalink
Post by Dave Froble
I'd guess the issue was attached to some list. (I'd hope so.)
It would not make much sense to expect VSI to drop everything and jump
on some new issue immediately. Yes, there might be such issues, but
highly unlikely.
Didn't Stephen once report a RCE or similar in some VMS related product
that VSI were taking ages to fix ?

I wonder if VSI ever got around to fixing that ?

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Stephen Hoffman
2020-09-08 15:34:55 UTC
Permalink
Post by Simon Clubley
Didn't Stephen once report a RCE or similar in some VMS related product
that VSI were taking ages to fix ?
I wonder if VSI ever got around to fixing that ?
Swapped some mail with VSI on the topic some years ago, but haven't
poked at that whole area again since then.

I've come around to the viewpoint that most (all?) of the OpenVMS
server networking and that some of the hardware either leaks
information (e.g. DECnet, SCS LAN, etc) or is insecure, or is best
presumed to be insecure, and that the OpenVMS servers are best
isolated, VLAN'd, or otherwise protected. Configuring some of this away
is certainly possible, like expunging DECnet and telnet, and locking
down SCS. And I'd definitely prefer to be wrong here with my
assumptions of vulnerability, too.

And as for migrating everything to IPsec as has occasionally been
proposed around here, implementations of that too have had some issues:
CVE-2019-14899
--
Pure Personal Opinion | HoffmanLabs LLC
Scott Dorsey
2020-09-08 20:50:24 UTC
Permalink
Post by Stephen Hoffman
I've come around to the viewpoint that most (all?) of the OpenVMS
server networking and that some of the hardware either leaks
information (e.g. DECnet, SCS LAN, etc) or is insecure, or is best
presumed to be insecure, and that the OpenVMS servers are best
isolated, VLAN'd, or otherwise protected. Configuring some of this away
is certainly possible, like expunging DECnet and telnet, and locking
down SCS. And I'd definitely prefer to be wrong here with my
assumptions of vulnerability, too.
Well, yes.

But really, this should be considered to be the case for any system today.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
Simon Clubley
2020-09-09 12:17:36 UTC
Permalink
Post by Scott Dorsey
Post by Stephen Hoffman
I've come around to the viewpoint that most (all?) of the OpenVMS
server networking and that some of the hardware either leaks
information (e.g. DECnet, SCS LAN, etc) or is insecure, or is best
presumed to be insecure, and that the OpenVMS servers are best
isolated, VLAN'd, or otherwise protected. Configuring some of this away
is certainly possible, like expunging DECnet and telnet, and locking
down SCS. And I'd definitely prefer to be wrong here with my
assumptions of vulnerability, too.
Well, yes.
But really, this should be considered to be the case for any system today.
The difference is that those other systems experience a lot of active
probing which helps to expose issues and to tighten security generally,
thereby making them more secure.

VMS these days doesn't get to see much of that type of probing, so
VMS is actually more vulnerable than those other systems for that reason.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
abrsvc
2020-09-04 14:57:40 UTC
Permalink
Post by G.
Post by Tony Nicholson
I know there's some other hobbyists lurking here and running
RSTS/E too. Does anyone have the same issue with RTERM
from OpenVMS Alpha?
It's been a (long) while but IIRC the problem arose sometime after OpenVMS
Alpha V7.2 which I'm almost sure worked as expected. I do not remember if
vanilla OpenVMS Alpha V7.3 (i.e. not V7.3-1) had the problem or not but for
sure V8.x had it.
I've just found some old message of mine about the very same issue that I
sent to the HECnet mailing list seven (!) years ago. Here it is.
| RTPAD.EXE on OpenVMS V8.3 for both Alpha and Itanium (IIRC) has some serious
| bug that prevents it from connecting to such older OSes using the old RTERM
| protocol: actually it ACCVIOs before doing any useful work.
|
| The RTERM protocol can be used to connect to VMS too, and when connecting to
| another VMS node using RTERM, the V8.3 RTPAD.EXE works as expected. So, either
| some older OSes are sending out-of-standard packets (and the older RTPAD.EXE
| were more forgiving), or the new RTPAD.EXE cannot understand all the protocol
| variants and intricacies (as the older versions did).
|
| I tried exchanging V8.3 RTPAD.EXE (ident X-10) with a couple of older versions
| (idents X-8, X-9) and even with the V8.4 one (ident X-10 too, so should be the
| same as V8.3), to no avail: every one of them ACCVIOs as well. The oldest I
| tried (X-8) comes from plain vanilla V7.2 (and does not work), but I'm almost
| sure (I cannot swear on it, though) that RTERM worked fine in V7.2, so I'm
| stuck: the same image (X-8) was working on V7.2 but it's not in V8.3.
|
| I know that testing by exchanging images among different VMS versions is not
| bulletproof, but considering that I didn't get any error like SHRIDMISMAT and
| such, I feel confident about thinking that they are compatible. So maybe the
| problem is somewhere else, probably in some shared library.
Someone with access to sources found that in V8.3 the stack dump pointed to
module RSTSRT in RTPAD.EXE and also that the virtual address and the PC in
there looked odd as if there were some bad stack manipulation.
HTH,
G.
Can you post the stack dump info?
Volker Halle
2020-09-04 15:21:38 UTC
Permalink
The ACCVIO shown is caused by an invalid PC value and occurs during the instruction fetch (reason mask = 00010000).

The return address in R26 points into system space, try

$ ANALYZE/SYS
SDA EXA/INS 8018300C-30;40

To produce a process dump, issue a

$ SET PROC/DUMP

before the SET HOST command.

Look at the RTPAD.DMP process dump with ANALYZE/PROCESS or SDA

Volker.
Loading...