Have the NSA planted backdoors in VMS ?

[Simon Clubley]

IanD asked the following question in another thread:

> I asked the question before but never got a response - does any of the
> OpenVMS code have additional code inserted into it...

It's an interesting question, especially given how popular VAX/VMS
was in the old Soviet Union in the 1980s and especially given that
in those days shared interactive access to computers was the normal
state of affairs.

When looking at the vulnerability I found, there are times when
I have wondered if it was a backdoor deliberately planted by the NSA.

There are two things which make me say that:

1) The .cld buffer overflow vulnerability does not appear to exist
in VAX/VMS 3.x; my test CLD is correctly rejected by VAX/VMS 3.x.

That by itself probably doesn't prove anything as there were a number
of changes for VAX/VMS 4.x - that VMS 3.x UI was absolutely horrible BTW.
It's quite possible for there to have been a simple coding error with
all the work that was obviously done at that time.

OTOH, that would have been a perfect time to introduce a deliberate
backdoor - if it was found it would probably have been written off
as a simple developer mistake instead of a deliberately planted backdoor.

2) The _only_ parsing related buffer overflow I have been able to
find in a .cld file is the only one I can exploit from DCL.

There are a good number of possible other parsing related buffer
overflow errors which could exist in .cld files and which would
be benign, but _every_ _single_ _one_ I have tried has been
correctly rejected by CDU.

By today's standards, it would be a very crude backdoor indeed but
don't forget that it was very different in the 1980s. For example,
at the time that this vulnerability was introduced, there was
still several years to go until the Morris worm happened.

BTW, there's no implication in my statements that VMS Engineering
cooperated with the NSA. It's quite possible for someone like the
NSA to introduce this into VMS without the cooperation of DEC.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

[IanD]

I never expected a response from VSI

From what I understand, they can put a gag order on the company anyhow with threats of during it down or fining it out of existence

I'm sure I've read that the gag order can include disclosing whether you have even been approached or not

Considering hardware was directly added to the likes of IBM and HO servers, then I would say DEC was probably targeted back in the vax and alpha haydays

For those scoffing at the idea, Google the hardware that was on sale to the NSA as revealed by WikiLeaks and the like. Some of those cat5 cables with transmitters built into plug head were very impressive. The spreadsheet have quite a comprehensive list of goodies you can buy, as long as you're registered for that class of equipment that is

It's like many years ago when I disappointing found out I could not buy the highest resolution night vision equipment here in Nanny land, Australia. Thermal video imaging here is also not publicly purchasable easily either. You can of course buy Flir equipment for cable inspection but to buy the real good stuff that enables thermal video capture at great distances is not available to the public here in Nanny land

[dgordo...@gmail.com]

On Sunday, January 7, 2018 at 9:34:26 PM UTC-5, Simon Clubley wrote:

> When looking at the vulnerability I found, there are times when
> I have wondered if it was a backdoor deliberately planted by the NSA.
>

No. It was simple programming mistake. I can even identify the edit in which it was inserted and the responsible engineer.

Please recalibrate your tinfoil hat.

[VAXman-]

In article <d37c81a0-cf83-49b5...@googlegroups.com>, dgordo...@gmail.com writes:
>On Sunday, January 7, 2018 at 9:34:26 PM UTC-5, Simon Clubley wrote:
>
>> When looking at the vulnerability I found, there are times when
>> I have wondered if it was a backdoor deliberately planted by the NSA.
>>
>
>No. It was simple programming mistake. I can even identify the edit in which it was inserted and the responsible engineer.

;)

>Please recalibrate your tinfoil hat.

https://s3.amazonaws.com/static.funnyshirts.org/images/design/5d379bdd9d0cfd4ead34815764dd5d22_91839_0_big.jpg

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

[DaveFroble]

dgordo...@gmail.com wrote:
> On Sunday, January 7, 2018 at 9:34:26 PM UTC-5, Simon Clubley wrote:
>
>> When looking at the vulnerability I found, there are times when
>> I have wondered if it was a backdoor deliberately planted by the NSA.
>>
>
> No. It was simple programming mistake. I can even identify the edit in which it was inserted and the responsible engineer.

What shape are his fingers in, after you informed him of his mistake? :-)

> Please recalibrate your tinfoil hat.

Yeah, lot of that going around ....

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

[Simon Clubley]

On 2018-01-08, dgordo...@gmail.com <dgordo...@gmail.com> wrote:
> On Sunday, January 7, 2018 at 9:34:26 PM UTC-5, Simon Clubley wrote:
>
>> When looking at the vulnerability I found, there are times when
>> I have wondered if it was a backdoor deliberately planted by the NSA.
>>
>
> No. It was simple programming mistake. I can even identify the edit in which
> it was inserted and the responsible engineer.
>

Thanks.

It's actually nice to see you can go that far back in the history.
I thought in the early days of VSI you had some problems with
getting everything from HPE.

> Please recalibrate your tinfoil hat.

Oh, _that's_ not tinfoil hat territory. :-)

Tinfoil hat territory would be to ask you how can you be sure the
engineer was the one to actually make the change just because that's
what the logs now say. :-)

[Simon Clubley]

On 2018-01-08, DaveFroble <da...@tsoft-inc.com> wrote:
> dgordo...@gmail.com wrote:
>> On Sunday, January 7, 2018 at 9:34:26 PM UTC-5, Simon Clubley wrote:
>>
>>> When looking at the vulnerability I found, there are times when
>>> I have wondered if it was a backdoor deliberately planted by the NSA.
>>>
>>
>> No. It was simple programming mistake. I can even identify the edit in which it was inserted and the responsible engineer.
>
> What shape are his fingers in, after you informed him of his mistake? :-)
>

VMS Engineers can be female as well...

>> Please recalibrate your tinfoil hat.
>
> Yeah, lot of that going around ....
>

Much of what would have been considered to be tinfoil hat territory
up to 5 years ago is now known to be established fact.

(And yes, in a few months, it really will be 5 years since Snowden
revealed what the NSA and GCHQ actually get up to. The innocent
time before that seems like another lifetime.)

[Stephen Hoffman]

On 2018-01-08 16:03:20 +0000, dgordo...@gmail.com said:

> On Sunday, January 7, 2018 at 9:34:26 PM UTC-5, Simon Clubley wrote:
>
>> When looking at the vulnerability I found, there are times when I have
>> wondered if it was a backdoor deliberately planted by the NSA.
>
> No. It was simple programming mistake. I can even identify the edit in
> which it was inserted and the responsible engineer.

Best case, you now know around when and who might get blamed, but not
who made the change, nor why the changes were made.

If I or any other privileged users were inclined, the checkin could
have been adjusted to track back to some other or some made-up user.

BTW: I'd be happy to explain how to edit source code check-ins while
they're pending review, or there's the simple expedite of making the
change in the original sources in the developer's own directories
before the checkin and without the developer likely realizing there's
even been a change. There are no cryptographic checksums in use in VDE
or CMS, no checksum chains and no blockchains of the changes, and few
(no?) folks extract and diff the changes they've made. Or that they
intended to make. I'd be happy to show you how to forge the records in
the database. It's not at all difficult. That's all presuming the
developer isn't explicitly making the changes with the intention of
introducing a backdoor, of which no database records will indicate.

It's not at all difficult to do any of this.

At its core, this is also why few folks will trust host-local logs on
compromised systems, and also why some folks are using or are seeking
to add distributed logging and checksum chains into logging
implementations.

Now before somebody suggests it, do I think that blockchains are
appropriate here? No. If that level of auditing and change-tracking
were a new requirement, I'd first look to use chained SHA-3 checksums
or digital signatures and with embedded timestamps, and with
distributed logging. Maybe with write-only auditing, but that's
problematic for many applications and environments. As part of
upgrading auditing and change tracking, I'd also look at what git and
other tools provide, and change and update and ignore that where
appropriate. https://gist.github.com/masak/2415865 Use of SHA-1
wouldn't be my preferred choice any more, either.

> Please recalibrate your tinfoil hat.

Do I think that's what happened here? No. Why would an agency
deliberately introduce intentional vulnerabilities before the
incidental and accidental vulnerabilities become more difficult to
locate? I'd expect attackers have already looked for existing holes
too, and this particular hole is a local privilege escalation and not a
rather more desirable remote command execution (RCE) flaw. As an
attacker intent on invoking clandestine means to gain access, I'd also
want something that led to an RCE, if I was going to go to the effort
involved.

Nor do I believe that the NSA is the only organization that might seek
to embed a backdoor, but that's fodder for another discussion or three.

Some related background on why some folks are paranoid:
https://falkvinge.net/2013/11/17/nsa-asked-linus-torvalds-to-install-backdoors-into-gnulinux/

https://freedom-to-tinker.com/2013/10/09/the-linux-backdoor-attempt-of-2003/
Etc.

FWIW, VSI/HPE/HP/Compaq/DEC C should flag the source code construct
behind that 2003-era backdoor, if the compiler check was not disabled.

Do I think government agency backdoors are the biggest concern for VSI?
No. Not even remotely. Finishing the port and building up the
general system security; server software updates, better APIs,
encryption everywhere, LDAP in place of SYSUAF/RIGHTSLIST, the woefully
outdated installation and patch and crash infrastructures, system and
app logging, etc. Lots of work. Lots and lots of work.




--
Pure Personal Opinion | HoffmanLabs LLC

[brendan welch]

I brought the subject up here, probably about 1995.
I was absolutely a neophyte, but surprisingly had
read an article about the subject which all the rest of
comp.os.vms had missed.

I am now not successful in Googling back to what I wrote.
Even at the time I could not remember where I had read
the article, but it probably was in the business pages
of the Boston Globe newspaper, the major New England
publisher (and my children had all been "paper-boys"
for them).
But I recall that the article COULD have appeared in one
of the DEC-related magazines, but then it would have been
even more unlikely that the veterans of c.o.v would
have missed it.

I was unable to satisfactorily answer any questions
from the more illustrious users here.

It was not even called a backdoor then. As written,
the article simply postulated the possibility that
an employee at DEC might have inserted the ability
of using a second, fantastically-secret system password,
and that this might have been done, or could have been
done, for the payment amount of $100,000.

I do not remember if the article was slanted toward
the payer being business-oriented (e.g. Mafia) or
government (e.g. CIA).

[John Reagan]

On Monday, January 8, 2018 at 1:25:53 PM UTC-5, Simon Clubley wrote:

Or if the engineer in question was a NSA sleeper agent

[Simon Clubley]

On 2018-01-08, Stephen Hoffman <seao...@hoffmanlabs.invalid> wrote:
> On 2018-01-08 16:03:20 +0000, dgordo...@gmail.com said:
>
>> Please recalibrate your tinfoil hat.
>
> Do I think that's what happened here? No. Why would an agency
> deliberately introduce intentional vulnerabilities before the
> incidental and accidental vulnerabilities become more difficult to
> locate? I'd expect attackers have already looked for existing holes
> too, and this particular hole is a local privilege escalation and not a
> rather more desirable remote command execution (RCE) flaw. As an
> attacker intent on invoking clandestine means to gain access, I'd also
> want something that led to an RCE, if I was going to go to the effort
> involved.
>

Today that would be true, but this vulnerability was introduced in the
middle 1980s. At that time, many systems were standalone systems with
networking being a (very) optional extra.

Many non-privileged interactive users would be using these systems as
well. In that environment, a known interactive privilege escalation
method would be a very valuable thing to have.

I wonder if SEVMS had the same vulnerability as well ?

BTW, let's assume that this was an accident and not a deliberate
backdoor. That means the next question is: did the NSA find out
about this during their normal evaluation of systems and then
decide not to tell DEC about it ?

[Bill Gunshannon]

On 01/08/2018 05:09 PM, Simon Clubley wrote:
> On 2018-01-08, Stephen Hoffman <seao...@hoffmanlabs.invalid> wrote:
>> On 2018-01-08 16:03:20 +0000, dgordo...@gmail.com said:
>>
>>> Please recalibrate your tinfoil hat.
>>
>> Do I think that's what happened here? No. Why would an agency
>> deliberately introduce intentional vulnerabilities before the
>> incidental and accidental vulnerabilities become more difficult to
>> locate? I'd expect attackers have already looked for existing holes
>> too, and this particular hole is a local privilege escalation and not a
>> rather more desirable remote command execution (RCE) flaw. As an
>> attacker intent on invoking clandestine means to gain access, I'd also
>> want something that led to an RCE, if I was going to go to the effort
>> involved.
>>
>
> Today that would be true, but this vulnerability was introduced in the
> middle 1980s. At that time, many systems were standalone systems with
> networking being a (very) optional extra.
>
> Many non-privileged interactive users would be using these systems as
> well. In that environment, a known interactive privilege escalation
> method would be a very valuable thing to have.
>
> I wonder if SEVMS had the same vulnerability as well ?

Once again, I remind people to read Ken Thompson's "Reflections
on Trusting Trust". Written and delivered in 1983. Talks of
a hidden backdoor in Unix from long before that. Tell me again
how you think it unlikely something like a backdoor could be
put into VMS.

>
> BTW, let's assume that this was an accident and not a deliberate
> backdoor. That means the next question is: did the NSA find out
> about this during their normal evaluation of systems and then
> decide not to tell DEC about it ?
>

I think people here give the NSA more credit than they deserve.
They are dangerous, but they are not gods.

bill

[Paul Sture]

On 2018-01-08, John Reagan <xyzz...@gmail.com> wrote:
> On Monday, January 8, 2018 at 1:25:53 PM UTC-5, Simon Clubley
> wrote:
>>
>> Tinfoil hat territory would be to ask you how can you be sure the
>> engineer was the one to actually make the change just because that's
>> what the logs now say. :-)
>>
>

> Or if the engineer in question was a NSA sleeper agent

Or if the engineer in question was a KGB sleeper agent...

(FWIW an article I read in the 80s pointed out that Western university
libraries were chock full of scientific research papers, all accessible
to enrolled students; little or no cloak and dagger stuff required)

--
Macs. They used to smile at you.

[Stephen Hoffman]

On 2018-01-08 22:09:40 +0000, Simon Clubley said:

> Many non-privileged interactive users would be using these systems as
> well. In that environment, a known interactive privilege escalation
> method would be a very valuable thing to have.

I'd rather have a path through LOGINOUT or via DECnet, that far back.

There was a hilariously stupid GRPNAM security hole back in the early 1980s.

And many OpenVMS systems and many networks were wide open, as well.

> I wonder if SEVMS had the same vulnerability as well ?

SEVMS was identical to OpenVMS in this and in most other areas. SEVMS
activated some latent capabilities, and added a fairly small number of
executable images, and documented added commands and features.

> BTW, let's assume that this was an accident and not a deliberate
> backdoor. That means the next question is: did the NSA find out about
> this during their normal evaluation of systems and then decide not to
> tell DEC about it ?

If any national intelligence agency is relevant to you and to your
systems, then you're probably already toast. Anybody that's really
interested can "black bags" your servers directly. Or can compromise
your systems through your supply chain, or by directly accessing your
data center, by co-opting your networking, or by co-opting existing
staff with the necessary access. Etc. As for your question? Any
discussions and debates of VEP aside, that's not something that anybody
that knows will likely answer. Whether it's NSA, GCHQ, FSB or
otherwise. Various end-users can and did send in bug reports, and
still do. Exploits are valuable to a number of folks and
organizations well beyond NSA, and with interests in vulnerabilities
and exploits for both legal and illegal purposes. VSI hasn't decided
to set a floor on exploit prices yet, but that's fodder for a different
discussion. Folks that are interested in exploits will review the
source listings and will fuzz the APIs. Same as usual. Some agencies
have other options and alternatives within their jurisdictions.

GRPNAM: http://www.netfunny.com/rhf/jokes/89q4/evild.693.html
VEP: https://www.eff.org/document/vulnerabilities-equities-process-january-2016

[onewing...@gmail.com]

On Monday, January 8, 2018 at 3:14:45 PM UTC-7, Bill Gunshannon wrote:
>
> Once again, I remind people to read Ken Thompson's "Reflections
> on Trusting Trust". Written and delivered in 1983. Talks of
> a hidden backdoor in Unix from long before that. Tell me again
> how you think it unlikely something like a backdoor could be
> put into VMS.

Actually, this is one spot Ada explicitly addresses in its standards -- Annex H (High Integrity Systems) provides the "Reviewable" [H.3.1] and "Inspection_Point" [H.3.2] pramas/aspects -- see: http://www.ada-auth.org/standards/rm12_w_tc1/html/RM-H.html (Use the ">> Next" button to navigate to the next subsection.)

[Derrell Piper]

On Monday, January 8, 2018 at 2:14:45 PM UTC-8, Bill Gunshannon wrote:

> Once again, I remind people to read Ken Thompson's "Reflections
> on Trusting Trust". Written and delivered in 1983. Talks of
> a hidden backdoor in Unix from long before that. Tell me again
> how you think it unlikely something like a backdoor could be
> put into VMS.

Also read David A. Wheeler's 2009 PhD dissertation:

https://www.dwheeler.com/trusting-trust/

[Dennis Boone]

> >Please recalibrate your tinfoil hat.

> https://s3.amazonaws.com/static.funnyshirts.org/images/design/5d379bdd9d0cfd4ead34815764dd5d22_91839_0_big.jpg

http://web.archive.org/web/20100708230258/http://people.csail.mit.edu/rahimi/helmet/

[John Reagan]

http://cdn.trendblog.net/wp-content/uploads/2017/04/tinfoil.jpg