[Info-vax] Planning for Upgrades, Migrations, and Vulnerabilities (was: Re: MYSQL error WWW.OPENVMS.ORG)

[Stephen Hoffman]

On 2019-04-15 04:54:08 +0000, Dave Froble said:

> I've had discussions here before about what I call services, and others 
> call "not standard".  (Hi Jan-Erik)  Well I'm rather happy to use 
> "non-standard" protocols when bringing in data.  My services know 
> exactly what they want, and if a communication is not exactly what's 
> required, PLONK, disconnected.  Then there is the vetting of the data, 
> not a valid customer, PLONK, disconnected.  And many other checks.  At 
> no time does a service attempt to use anything other than the expected 
> protocol and data.

Apache mod_security is handy for that.   But there are other steps 
available here.  And parser flaws tend to be a ripe target for 
exploration and potential exploitation.  How isolated are those 
net-facing parsers, too?

> The problem with using some "standard", such as Apache, is that as soon 
> as there is a web server exploit, you're toast.  There is something 
> that will get the web server to do something you do not want, and there 
> isn't much you can do about it.

Which gets to the need for faster updates.  Which involves VSI and app 
developers.

Ponder how fast a critical patch—OpenVMS itself, or in a local or 
ISV-developed app—can be deployed.

There's another parallel thread ("Multi-site OpenVMS field upgrade 
options?") that's effectively on exactly this topic, too.

> As far as I'm concerned, the only way our external connections could 
> have a problem is if it was internal to TCP/IP.  That's not my turf. 
> That's up to the OS and TCP/IP folks.  Can it happen?  Anything can 
> happen.  But it's much less unlikely that anyone from outside could 
> reach our data, or modify or delete it.  I'll hit the billion $ lottery 
> first.

Please don't assume that an attack will be linear; that an attacker 
will use any particular ingress path.

An attacker might target old Windows versions being used internally, 
for instance.  The most common path being targeted for exploitation 
right now is via Microsoft Office attachments, interestingly enough.  
That happens "behind" the firewall and behind the app-specific parsers.

Or exploitation can can happen via a weakness in a portal, such as this 
week's instance: 
https://motherboard.vice.com/en_us/article/ywyz3x/hackers-could-read-your-hotmail-msn-outlook-microsoft-customer-support 


Or can via account reset email happening via some other path or via 
some other breached portal, as reportedly arose with the Sony Pictures 
breach a while back.

> If one wishes to run a standard web server, place your data and 
> anything important elsewhere.  It's only prudent.  Then make sure 
> anything that can reach the data is as secure as you can make it.

I'll leave discussions of backups and backup errors aside, as I've seen 
and have made more than a few of those in my time.  Whether the trigger 
for the recovery is a corruption or crash or whatever.

OpenVMS still doesn't have a way to integrate app-specific backups into 
a more general backup, for that matter.  Much less a recovery.  On 
OpenVMS, that's all hand-built.  And usually with latent errors.

And yes, sort-of-write-only backup storage—backup storage that requires 
a second set of access credentials to access and to modify or to 
delete—can be handy to have.  That typically involves a second and 
separate storage server, and with some processing running on that or on 
another server.  The second server to reduce the exposure to a systemic 
breach.   OpenVMS doesn't have a particularly easy-to-use file creation 
completion event notification either, so tends to use polling and 
delays for that processing, sometimes with "clever" discretionary 
access control settings and/or subsystem identifiers.

> Is it more custom work?  Yes it is.  Do the benefits outweigh the work? 
>   I'll leave that up to the reader, and how they feel about their data.

Writing even a million lines of code for a bespoke content management 
system and a bespoke web server is no small investment.

BTW, there's another Tomcat exploit active, if you're not writing all 
of your own web server.  This one targeting Apache Tomcat on Windows.  
CVE-2019-0232

Drupal core is just shy of two million lines of code, and Apache HTTP 
is just shy of 1.5 million lines of source code.

Does any one particular site need all of that code?  No.  But then 
owning the need to make updates when new capabilities are designed or 
are needed is no fun, either.  Not when you want or need capabilities.

Securing and then keeping that all secure is no fun, either:  
https://www.owasp.org/index.php/Testing_for_Weak_SSL/TLS_Ciphers,_Insufficient_Transport_Layer_Protection_(OTG-CRYPST-001) 


>From a few years ago, to help get the scale of modern software 
projects...   https://www.visualcapitalist.com/millions-lines-of-code/

No easy answer here.  Just a whole lot of work for app developers, 
whether replicating existing services, securing existing services, or 
upgrading   A whole lot of OpenVMS folks have become enamored with 
brute-force uptime, and many of us haven't yet gotten to the era of 
server and app migrations, and of the need for rapid patch deployments.





-- 
Pure Personal Opinion | HoffmanLabs LLC