CVE-2017-17482

[Derrell Piper]

From: Eddie Orcutt <eddie....@vmssoftware.com>
Date: Friday, January 26, 2018 at 4:27 PM
To: Eddie Orcutt <eddie....@vmssoftware.com>
Subject: OpenVMS Security Notice

Dear VSI OpenVMS Customer;

A potential security vulnerability has been found in which a malformed
DCL command table may result in a buffer overflow allowing a local
privilege escalation in non-privileged accounts. This bug is exploitable
on VAX and Alpha and may cause a process crash on IA64. All versions of
VMS and OpenVMS after and including VAX/VMS 4.0 are affected.

A patch kit (DCL100) is available for all VSI versions of OpenVMS.

For Alpha customers running VSI OpenVMS V8.4-2L1 or VSI OpenVMS V8.4-2L2
for Alpha, contact VSI support to obtain the appropriate patch version.

For IA64 customers running VSI OpenVMS V8.4-1H1, VSI OpenVMS V8.4-2, or
VSI OpenVMS V8.4-2L1, if you have a support contract with HPE for your
version, contact HPE customer support to obtain the patch; otherwise,
contact VSI support.

Customers running HPE OpenVMS versions prior to and including V8.4 must
contact HPE customer support.

The Common Vulnerabilities and Exposures (CVE) project has assigned the
ID CVE-2017-17482 to this issue. This is an entry on the CVE List
(http://cve.mitre.org/cve/index.html), which standardizes names for
security problems.

Please note that future CVE notifications will be sent from the
secu...@vmssoftware.com account.

If you have any questions, please email VSI at secu...@vmssoftware.com.
If you are reporting a security vulnerability, please use the secure VSI
web page, when available.

Thank you,

Eddie Orcutt
VP Software Engineering
(978) 451-0118 (o)
(601) 946-8420 (c)
www.vmssoftware.com

This E-mail is covered by the Electronic Communications Privacy Act, 18
U.S.C. §§ 2510-2521 and is legally privileged. This information is
confidential information and is intended only for the use of the
individual or entity named above. If the reader of this message is not
the intended recipient, you are hereby notified that any dissemination,
distribution or copying of this communication is strictly prohibited.

Disclaimer: comp.os.vms is not an official support channel for VMS Software, Inc. Statements made here represent only the opinions of the people who post them. For official VMS support, contact either VSI Software, Inc. or HPE Customer Support through official channels.

[Simon Clubley]

On 2018-01-26, Derrell Piper <derrel...@vmssoftware.com> wrote:
> From: Eddie Orcutt <eddie....@vmssoftware.com>
> Date: Friday, January 26, 2018 at 4:27 PM
> To: Eddie Orcutt <eddie....@vmssoftware.com>
> Subject: OpenVMS Security Notice
>
> Dear VSI OpenVMS Customer;
>
> A potential security vulnerability has been found in which a malformed
> DCL command table may result in a buffer overflow allowing a local
> privilege escalation in non-privileged accounts. This bug is exploitable
> on VAX and Alpha and may cause a process crash on IA64. All versions of
> VMS and OpenVMS after and including VAX/VMS 4.0 are affected.
>

First off, thanks to Derrell for working behind the scenes to get
certain things done at VSI. Thank you Derrell.

Hopefully, the process for the next CVE will now flow more smoothly.

I'm still planning on releasing the details at the beginning of March
but I also still plan to _not_ release any code which shows the actual
exploit itself.

However, based on the discussion we need to have, experienced people
around here will almost certainly be able to fill in the missing pieces
and create their own exploit. We are having this discussion because
there's something about your existing VMS systems I think you need
to know about.

>
> If you are reporting a security vulnerability, please use the secure VSI
> web page, when available.
>

Yes, there's a web page _finally_ coming; it's currently being tested
so thanks again Derrell.

Simon.

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

[geraldm...@gmail.com]

It seems it is not exploitable on Itanium.

[Simon Clubley]

On 2018-02-02, geraldm...@gmail.com <geraldm...@gmail.com> wrote:
> On Friday, 26 January 2018 22:19:36 UTC, Derrell Piper wrote:
>> From: Eddie Orcutt <eddie....@vmssoftware.com>
>> Date: Friday, January 26, 2018 at 4:27 PM
>> To: Eddie Orcutt <eddie....@vmssoftware.com>
>> Subject: OpenVMS Security Notice
>>
>> Dear VSI OpenVMS Customer;
>>
>> A potential security vulnerability has been found in which a malformed
>> DCL command table may result in a buffer overflow allowing a local
>> privilege escalation in non-privileged accounts. This bug is exploitable
>> on VAX and Alpha and may cause a process crash on IA64. All versions of
>> VMS and OpenVMS after and including VAX/VMS 4.0 are affected.
>>

[snip]

>
> It seems it is not exploitable on Itanium.

Yes and no.

As you can see from the above text it still causes a process crash on
Itanium. The only reason Itanium is not compromisable with this specific
version of the exploit is because the return address is handled very
differently on Itanium.

It is not beyond the bounds of possibility that someone could find
a different variant that could be used to compromise an Itanium system.
For example, if you can overwrite a pointer to a data structure then
you can force code within DCL to process memory that you control.

I don't easily know if such pointers can be reached by a malformed .cld
definition as I do not have access to the VMS source code (all my
research and exploit development has been done without access to the
VMS source code). And before anyone asks, I don't want access to the VMS
source code as that would be illegal without the source code licences.

I do know however that it is still possible to indirectly compromise
some Itanium systems using this exploit.

For example, if your Itanium systems are part of a mixed-architecture
cluster, then you can use the vulnerability to compromise a vulnerable
cluster member and then use that cluster member to compromise your
Itanium systems.

So no, you can't say that Itanium is not exploitable. The best you can
say is that Itanium is not _directly_ exploitable with _this_ specific
version of the vulnerability.