Post by John Reagan
What about user applications? It is all user-mode code right? You
want to jump into the middle of the Fortran RTL? Want to call some
private routine in the COBOL RTL? Have at it. The worst thing you'll
do is ACCVIO, corrupt your own data, delete a file you can already
access, etc. So having the image activator to load things at different
base addresses doesn't add any additional protection to the system.
This is why folks instrument and collect crashes. Why it'll be likely
VSI starts seeking to upload OpenVMS application and system crashes,
and potentially even end-user application failures, yes, opt-in,
encrypted, et al, yada yada. Because jumping around doesn't always
work, as John correctly indicates. Because ASLR and no-execute aren't
a panacea. But ASLR and no-execute does serve as an impediment.
Without ASLR, getting code executing using these approaches is easier.
It's code that's often stitched together from the instruction sequences
ending various subroutines or ending in a register-based jump,
subroutines and random code for a wide variety of purposes. (Without
no-execute coverage, it's feasible to load and execute code directly
without bothering to have to dig around for instructions, too. That's
easier.) With these instruction sequences, creating an attack becomes
feasible. A program based on the bad data that the attacker can
somehow feed in. This data whether from a buggy ASN.1 or JSON parser,
from a deliberately wonky executable or database, from network buffer
errors, maybe even into MOUNT from a deliberately corrupt file system.
Pretty much anything past plain text, and I wouldn't entirely write off
the possibility of latent bugs in a UTF-8 parser these days, and there
have been exploits against some RTF tools. (RTF is even sort-of
available on OpenVMS via at least one of the CDA toolkits around, too.)
Because once the attacker has that repurposed and now-hostile code
executing, the attacker can then write or modify memory elsewhere, or
write to files, or connect to a remote server and download something.
This all might seem an effort and it most certainly is, though there
are tools specifically created and intended to scan for these gadgets;
these instruction streams. It's all happening on Microsoft Windows,
too. Once some code is executing — and getting to this stage is
tougher on Itanium, due to the use of separate stacks for the call
frames and the stack frames — then the local system is going to permit
the attacker to execute whatever is permissible within the run-time
context. What can then be executed in that context can be constrained
by sandboxes/jails and by BSD-style pledge mechanisms. Sandboxes and
pledges are also not panaceas, though they too increase the cost of the
attack, they increase the likelihood of failures, and the likelihood
that the activities might be detected by either local folks watching
crashes — some OpenVMS environments do watch crashes, but those sites
have created their own infrastructure to do that as OpenVMS completely
Files can be more hazardous than many realize, parsers can be buggy,
and here's some information related to that Microsoft Wordpad RTF
Remote Command Execution (RCE) mentioned earlier:
Unzip and other archival tools have been targeted, too. I've certainly
not fuzzed BACKUP or PCSI, and the "secure" delivery implementation on
OpenVMS installers really... isn't. Sure, it checks. But I can print
an official-looking DVD or can generate a disk image that always passes
those checks. Or can change the binary checker to simply disable those
checks. These are not easy problems, either. It'll take time to sort
Like the tools to look for ROP gadgets, many of checks for security
errors are now automated, too. Here's one of many examples:
But all of this is somewhat ahead of where VSI and OpenVMS are.
Because details such as getting CVEs sorted out — VSI IP goes a long
way, but there'll be ongoing maintenance with that. Faster and more
efficient patches, when security problems are identified and need
faster patching. Encrypting application data. Authenticating
connections. Far slower and far less efficient password hashes.
Because no attacker is going to bother with a ROP gadget search or
compromising a tool download at Process Software or DECUServe
(developer signing, et al), or when the telnet and FTP servers and SCS
are open and spewing credentials around the 'net, or phishing for
credentials from VSI users, or can spoof other folks into thinking that
mail from or to ***@gmail.example.com or
***@gmail.example.com are folks that they can send OpenVMS
security reports or credentials to. There's more than a little work
involved with security on any operating system, it never ends, and the
attacks continue to evolve. ASLR and sandboxes and other pieces are
certainly parts of this puzzle, too, and VSI will likely be determining
whether or even if those or other updates are feasible, and are
marketable and profitable.
About the delay on getting the updated security page and related
posted, getting the security contact and related posted, and the delays
in getting important and good-news announcements and collateral such as
the 2L1 LP availability announcement posted? That might be necessary
for business or financial reasons — tradeoffs are never fun — but...
these are missed opportunities to show off the quality and efficacy and
effectiveness of VSI staff and of the OpenVMS products, and of making
it clear to all what VSI has already achieved through your substantial
Want more ideas? Discussions on how you can harden your OpenVMS
installation? Contact me offline.
Developers often like to think that they're creating programs to
manipulate data. But pragmatically, the data manipulates the programs.
Pure Personal Opinion | HoffmanLabs LLC