| CVE-2017-17482 | Derrell Piper | 26/01/18 14:19 | 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. |
| Re: CVE-2017-17482 | Simon Clubley | 26/01/18 18:18 | On 2018-01-26, Derrell Piper <derrel...@vmssoftware.com> wrote: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. 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 |
| Re: CVE-2017-17482 | geraldm...@gmail.com | 02/02/18 01:16 | It seems it is not exploitable on Itanium.
|
| Re: CVE-2017-17482 | Simon Clubley | 02/02/18 05:24 | On 2018-02-02, geraldm...@gmail.com <geraldm...@gmail.com> wrote:[snip] >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. |