[Info-vax] OpenVMS x64 Atom project

[Dave Froble]

On 6/7/2021 9:09 AM, Simon Clubley wrote:
> On 2021-06-06, Dave Froble <davef at tsoft-inc.com> wrote:
>>
>> Ok, a VMS question.
>>
>> What, other than getting to run a program, could be done by the bad guys
>> on a VMS system?  I confess, I have not studied the issue at all.
>>
>
> If _that's_ what you are thinking in terms of, then you need to do some
> serious reading.
>
> A common attack vector is to inject code into a running program via
> malformed inputs or malformed protocol packets.
>
> Another attack vector is to use malformed protocol packets to get more
> access than you should. That's how Heartbleed was able to read more
> memory than should have been possible.
>
>> If the bad guys need to get access and run a program, would defenses
>> that check for valid programs running be successful?
>>
>
> You are thinking at the wrong level. They already have access if
> they can get to a program running on a network port. They can then
> probe that program to see if they can compromise it in some way.
>
>> So, yeah, if I can get access and run a process on VMS, much can be
>> done.  And possible defenses could be set up.  But if there are other
>> possibilities, one would need to know about them before considering
>> defenses.
>>
>
> You have already seen this twice on VMS, both from me and from the
> DEFCON 16 researchers where we injected code we controlled into a
> running interactive process. That's bad enough but think about how
> devastating that could be if someone found a way to do that to a
> network process.
>
> You need to think a _lot_ wider than you appear to be currently thinking.
>
> Simon.
>

I'm not too sure just how much thinking I want to do.  However, it seems 
to me that access, while bad, cannot do much by itself.  I'm thinking 
that if someone with access cannot do anything, that might be a decent 
defense.

It seems to me, and no, I don't know, that running various "standard" 
software, such as a web server, offers the bad guys some possibilities, 
none of which I'm aware of.  So not using these standard products might 
be some defense.

Opportunity seems to be a part of reported break-ins.  Not much anyone 
can do from inside to prevent that, disgruntled or dishonest employees, 
same password used elsewhere, and such.  I'm not thinking about such, 
rather what might be possible to deflect internet based probes.

For what I'm looking at, I'm assuming that TCP/IP and sockets is the 
path most or all probes might use.  I'm not going to attempt to replace 
TCP/IP, and it would be worthless anyway, since the entire purpose is to 
talk to other computers.  However, my custom usage of sockets could be a 
fertile ground for looking for ways to prevent internet access.  I['m 
just not aware of how such could happen.  But, where to start?

But, back to actually doing anything.  If there was a database, the bad 
guys could not get to, (and that itself is an issue), that had a list of 
valid users and valid programs, with ways to verify the program was the 
intended one, then image activation might be able to determine whether a 
program, or process (have to think a bit more on processes) should be 
activated.

-- 
David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      E-Mail: davef at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486