[Info-vax] How would you load balance excess webserver traffic between multiple OpenVMS servers?

[Chris Scheers]

In a similar vein, there was a bug in about the VMS 4.4 (4.6?) time 
frame that allowed an unprivileged user to gain write access to SYSUAF.

I had a FORTRAN program that was about 20 lines long that could modify 
any user record, including granting privileges.


Stephen Hoffman wrote:
> On 2021-01-12 13:52:49 +0000, Simon Clubley said:
> 
>> If that's what you think security is all about in 2021 Bob, then you 
>> simply don't have a clue about what is involved.
> 
> Bob has an unshakable confidence in the validity of his one answer to 
> any and all computing requirements: OpenVMS.
> 
> That answer might have been ~feasible ~30 years ago.
> 
> Tasks and requirements and expectations and competition and pricing and 
> apps are all very different now.
> 
>> BTW, you don't even have to go through security, you can go around it. 
>> That's exactly what I did and all the protections and ACLs would have 
>> made absolutely no difference.
> 
> A local-privilege escalation is a local-privilege escalation. OpenVMS 
> has had a few.  I've attached one of the more famous (earlier) examples 
> below.
> 
> This is where jails / sandboxes and app isolation is expected. OpenVMS 
> doesn't particularly isolate apps, and trying to use ACLs gets... 
> interesting.  I've had DECinspect break my configurations, when the 
> lock-down tooling was used. (Back when DECinspect was in more common 
> usage, too.) A fair chunk of work atop SEVMS would be required from VSI 
> to add jails/sandboxes/isolation, particularly with integrity and 
> signing—secure delivery is rather more involved when the apps themselves 
> cannot be trusted to be free of malware and free of flaws. And then 
> there's app auditing and app provisioning and app updates and a variety 
> of other topics. Getting this all configured and going is the smaller 
> part of the work too. Keeping this going and keeping this secure and 
> apps current and isolated and secure is no small investment in time and 
> tooling and focus.
> 
> There's also little app development guidance available for writing 
> secure apps for OpenVMS, which doesn't help. The security manual omits 
> much that is expected of apps in this networked era.
> 
>> To everyone else: I keep warning you about security researchers 
>> possibly taking a serious interest in probing VMS at some point in the 
>> future and about everything that could come from that.
>>
>> If Bob sets up some kind of conservative social networking environment 
>> using VMS (which it is a poor choice for anyway), then that is 
>> _exactly_ what is going to happen.
> 
> Bob and the particular "maybe" project most recently now seems moot, as 
> the "maybe" customer has reportedly acquired different hosting.  
> Ignoring that for the moment, and reviewing some other of Bob's 
> discussions for those that are unfamiliar...
> 
> Bob has previously recommended replacing Microsoft Windows desktops with 
> OpenVMS, had widely recommended OpenVMS be used within voting machinery, 
> and now as a high-profile and contentious "maybe" hosting project.
> 
> Could OpenVMS do these tasks? Given far too much budget and far too much 
> time and far too much retraining and a whole lot of work prolly yes, but 
> all that very far from economically and easily, and likely not securely.
> 
> Desktop: Approximately no desktop apps and no Office compatibility and 
> no two-factor and no modern browser for OpenVMS—that'd all have to be 
> found or built or added.
> 
> Embedded: Approximately no benefit and a whole lot of cost for embedded 
> usage, and which fundamentally doesn't address the issues and risks 
> involved with any embedded software.
> 
> Web hosting: Little tooling is available for running a high-profile and 
> contentious website and one with other issues as discussed in that 
> thread as well as an app that is a DDoS and intelligence service target, 
> and one that reportedly has problems with payment gateways and with 
> getting their client apps onto the major app stores. Though Bob has the 
> opportunity to create the necessary prototypes here, using real data 
> from the "maybe" API.
> 
> VSI has piles of work ahead with the x86-64 port. Little of which 
> includes OpenVMS for desktop and updates to the apps and tooling that 
> everybody* expects to have access to, little includes OpenVMS for 
> embedded—seL4 was previously recommended for a secure host platform for 
> embedded use though that too necessarily requires knowledge of and 
> integration with election auditing (and approximately none of this 
> addresses the issues Bob believes it would), and little includes OpenVMS 
> for high-end web hosting and related services and which typically 
> involves keeping a current Apache and related tooling and prolly nginx 
> or other web server, as well as one or more application servers (Twisted 
> and/or Tornado and/or Zend, etc), as well as Python. And for sites that 
> can be subject rapid scaling, there'll be the need for tooling to keep 
> OpenVMS current across a variable and potentially increasing number of 
> hosts, to quickly deploy patches, for geographic server distribution for 
> robustness and recovery and latency, log collection and analysis and 
> intrusion detection, and that'd have to be locally written and/or 
> acquired and integrated. Little of which includes app isolation, R^X, 
> jails, etc. And that's all before we discuss the carrying costs of 
> having hardware available for high or peak loads. Approximately none of 
> which is in the plans, and all of which already exists on other 
> platforms and products and apps that target these disparate markets. The 
> x86-64 port will have some benefits around using hosting for added 
> capacity and for peak loading, though that necessarily means hosting, 
> and it means you'll have to expect insecure or hostile peers, though 
> it's wise to assume your local networks also have hostile peers connected.
> 
> Can OpenVMS do this stuff?  Sure. Cost-effectively, and with a 
> reasonable deployment timeline? Nope. VSI is working to address some of 
> this, and particularly for existing OpenVMS customers. The folks running 
> "maybe", not so much.
> 
> 
> Local-privilege escalation:
> 
> OPERATING SYSTEM:  VAX/VMS V2.1
>         PRODUCT:  VAX/VMS
>       COMPONENT:  LOGINOUT
> 
> 
> GRPNAM SECURITY HOLE IN LOGIN
> 
> PROBLEM STATEMENT:
> 
> The GRPNAM privilege is an evil demon, allowing the user to
> invoke its secret entrance for all manner of nefarious
> purposes not originally intended.
> 
> 
> RESPONSE FROM DEC:
> 
> The great wizard VMS confronted the demon, raised his great
> oaken staff carved in ancient runes, and spoke the magic
> incantation:
>     "$SETPRV IMAGEACTIVATIONENHANCEDPRIVILEGES $CMKRNL!!"
> There was a blinding flash of light and puff of smoke, and
> the demon, reduced to harmlessness, scurried off into the
> distance.
> 
> Where his secret entrance had been was naught but a little
> pile of ashes, which the wind slowly drifted into letters
> spelling the words "FIXED IN V2.3".
> 
> 


-- 
-----------------------------------------------------------------------
Chris Scheers, Applied Synergy, Inc.

Voice: 817-237-3360            Internet: chris at applied-synergy.com
   Fax: 817-237-3074