[Info-vax] Should VSI create a security bug bounty program for VMS ?

[Stephen Hoffman]

On 2016-09-01 13:13:41 +0000, Simon Clubley said:

> I'm thinking more about what's going to attract security researchers to 
> invest time in looking at VMS in the first place and the fact it's 
> something different and with this strong security message from it's 
> vendors is really good motiviation for those researchers.

That there's financial data or credit card data or sensitive 
information on the platform is a larger incentive, these days.   
Attacks are increasingly financial.   Attacks are business.   Attackers 
can jump firewalls.

As for the future of OpenVMS and security, VSI has the talents to do a 
security review of the product, and there are external entities that 
offer that service.   But VSI has project priorities secondary to 
budget constraints, and— irrespective of the marketing, and outside of 
finally deprecating that mess with the ACME and non-ACME LOGINOUT 
images — I suspect security enhancements are not at the top of the 
development schedule.  Clair's (proverbial?) whiteboard of projects is 
undoubtedly a long one, and VSI is comparatively a very tiny team with 
comparatively tiny funding for a project of the scale of a proprietary 
server operating system.

Cleaning up some of the proverbial low-hanging fruit will help, as will 
migrating from cleartext to encrypted and authenticated data stores and 
network transports.    Just getting to current open source packages 
will take some hunks out of the list of CVEs applicable against 
OpenVMS.  CVEs that aren't listed on that VSI marketing page, BTW.

> I wasn't aware of that comment thanks. It confirms my position that if 
> VSI continue saying the kinds of things that they are currently saying, 
> then they need to be aware of what is going to happen and how they 
> _seriously_ need to up their game in preparation for when it does.

Ayup.  Why do you think I've been commenting about OpenVMS security in 
recent years?    Was that all too staid?   Too subtle?

The "integration" of certificates, SSL, encryption, TCP and related is 
a complete and utter disaster, but I'm being polite.

For those that don't believe me or that reasonably wish to 
independently verify my comments?   Go try to use it and see how well 
OpenVMS and TCP/IP Services and SSL and SSL1 and Apache and ENCRYPT and 
LDAP and Kerberos and password storage and disk encryption and CDSA and 
related pieces are all (not) integrated.    Use the tools.    I ran 
into problems with the CA tools in OpenVMS, and ended up writing my own 
to show how the pieces worked.   And getting a subset of the disjoint 
APIs semi-accessible from BASIC and Fortran is no joy, either.   
http://labs.hoffmanlabs.com/node/1853

There are other areas of OpenVMS that need careful investigation and 
remediation and/or updates, such as the now-seriously-far-too-efficient 
Purdy password hash (e.g. too fast means too weak) and which I've 
mentioned as one of the a compatibility-killing problems in OpenVMS.  
There's the baroque patch notification, distribution and installation 
process, and the lack of integrated (opt-in) system and application 
crash uploads, ASLR and sandboxes and related.    (System and 
application crashes can very much be security relevant, as well as to 
general stability and availability.)

Then ponder that HPE and VSI have reworked their own "secure 
distribution" — formerly built on CDSA — to avoid using CDSA, so what's 
that tell you about what HPE and VSI think about the security provided 
by CDSA?

Programming reasonably secure server and network apps on OpenVMS is 
comparatively difficult.   There are only comparatively limited means 
to isolate apps that are found vulnerable.  You have to build and 
maintain your own CA or your own root store.   There's also weak 
examples, and little in the way of documentation or a guide for 
application development, as the security manual and the programming 
concepts manual handling of app security is probably twenty years out 
of date.   That's before discussing the morass that is the security 
APIs and the lack of integration among the various pieces.

If there's an overarching design of how the application security APIs 
and tools are supposed to work, why are there so many different places 
I need to put the certificates?

SSL and SSL1 is a whole 'nother issue.  That adventure required more 
than a little rework in build procedures.

After using systems where this better integrated, with central password 
stores and integrated TLS networking and certificate verification and 
revocation mechanisms integrated, the OpenVMS approach to security is 
far from clear and far from simple.   Sure, you can build all this and 
all the pieces are certainly available, but — like working in machine 
code or assembler — it's way more work, and with few (and unfortunately 
very sketchy)  examples.    Complex and arcane and bespoke security 
code usually means there will be security problems, too.    That the 
clarity and simplicity of the OpenVMS APIs in general also needs more 
than a little remedial work work is another matter, and a different 
rant.






-- 
Pure Personal Opinion | HoffmanLabs LLC