[Info-vax] DCL vulnerability write up on The Register

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax-bounces at rbnsn.com] On Behalf Of
> Stephen Hoffman via Info-vax
> Sent: February 21, 2018 4:26 PM
> To: info-vax at rbnsn.com
> Cc: Stephen Hoffman <seaohveh at hoffmanlabs.invalid>
> Subject: Re: [Info-vax] DCL vulnerability write up on The Register
> 
> On 2018-02-21 20:57:16 +0000, Mark Berryman said:
> 
> > On 2/21/18 11:39 AM, Stephen Hoffman wrote:
> >> On 2018-02-18 21:45:03 +0000, Jan-Erik Soderholm said:
> >>
> >>> Now, am I correct that, *if* you have a system where no non-
> priv'ed
> >>> users has access to the DCL command line, then you do not have any
> >>> problems with this? Becuse you cannot "use" this vulnerability if
you
> >>> do not have access to the DCL command line?
> >>
> >> Not that I'd bet any particular OpenVMS system isn't leaking
> >> credentials or access somewhere.   SCS. DECnet. FTP. telnet.
> leaked
> >> private keys.  Etc.  That's all before an attacker even has to get
> >> sneaky.
> >>
> >>
> >
> > Oh, there are some that aren't leaking.  One of the first ways to
> > ensure a secure VMS system is that you don't go anywhere near HP's
> IP
> > stack.
> > ...
> > Properly done, a VMS system can certainly be made secure...
> 
> Sure.  No doubt.   There are some OpenVMS systems that are secure.
> But please show me the guide to securing your OpenVMS server.   Show
> me
> where in the guide that describes how to monitor and keep both the
> server and a private LAN secured over time, and the tools intended to
> ensure that really does happen.   Show me where the insecure protocols
> are getting deprecated and removed, for that matter.  It's not just
the
> process involved in configuring an OpenVMS system securely, it's also
> keeping the OpenVMS systems secure and keeping private the network
> underneath an otherwise insecure protocol such as SCS.  And that's an
> ongoing effort.  You're left with home-grown tools, or with a
> third-party offering, or both.  And with process questions around
> backups, key changes, and a whole host of other topics.
> 

Properly securing any system on any platform is always a custom work
activity.

There is no magic pixie dust that can do this without a good
understanding of the local network, firewall zones, and protection of
data at rest and in-flight.

For those that want to take securing OpenVMS to the next level, they
should consider adding PointSecure's "System Detective"
< http://pointsecure.com/products/system-detective/>

> My comment around the DCL flaw was that various system managers
> and
> many developers perceive that there's a single and direct path through
> system security, while attackers don't care which path they use.  Many
> folks make the mistake of assuming that patches can avoid becoming
> knowledgeable about your own systems and your own network really
> work,
> and are really configured.   I certainly wouldn't want any flaw
> lurking, whether it's a local escalation as discussed here, or whether
> there's a remote privilege escalation or (worse) one with a remote
code
> execution around.   But many of us do end up with flaws lurking.
This
> because some well-intentioned staffer installed a printer on the
> cluster LAN, 
> and never bothered to upgrade the firmware, nobody
> noticed, and it's now a very tidy network probe operating on behalf of
> some attackers because somebody received a printer exploit in a PDF
> attachment and printed it.  A couple of decades ago, we used to find
> modems on office telephone lines.  Now we find Wi-Fi devices, IoT
> widgets, printers, remotely-accessible client systems, or whatever.
> From there, sniff a telnet packet somebody was erroneously using, or
> whatever.   One of the widely-reported network penetrations a while
> back was reportedly via AppleID, for instance.
> 

This is why med-large enterprises have FW zones. You would never install
a printer in the same FW zone as a server.

> And there are a *lot* of people using the HPE IP stack.  Among other
> issues.
> 

Agree, but like Mark stated, there are alternatives like Multinet
available that meets latest standards and even has added value security
features like an integrated IPS function:
(coming in the new IP stack as well from what I understand)
< http://h41379.www4.hpe.com/openvms/journal/v13/multinet_intrusion.pdf>


Regards,

Kerry Main
Kerry dot main at starkgaming dot com