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

[Stephen Hoffman]

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.

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.

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




-- 
Pure Personal Opinion | HoffmanLabs LLC