Vulnerabilities > CVE-2018-0823 - Unspecified vulnerability in Microsoft Windows 10 and Windows Server 2016
Attack vector
LOCAL Attack complexity
MEDIUM Privileges required
NONE Confidentiality impact
PARTIAL Integrity impact
PARTIAL Availability impact
PARTIAL Summary
The Named Pipe File System in Windows 10 version 1709 and Windows Server, version 1709 allows an elevation of privilege vulnerability due to the way the Named Pipe File System handles objects, aka "Named Pipe File System Elevation of Privilege Vulnerability".
Vulnerable Configurations
| Part | Description | Count |
|---|---|---|
| OS | 2 |
Exploit-Db
| description | Microsoft Windows - NPFS Symlink Security Feature Bypass/Elevation of Privilege/Dangerous Behavior. CVE-2018-0823. Local exploit for Windows platform. Tags: ... |
| file | exploits/windows/local/44148.txt |
| id | EDB-ID:44148 |
| last seen | 2018-02-20 |
| modified | 2018-02-20 |
| platform | windows |
| port | |
| published | 2018-02-20 |
| reporter | Exploit-DB |
| source | https://www.exploit-db.com/download/44148/ |
| title | Microsoft Windows - NPFS Symlink Security Feature Bypass/Elevation of Privilege/Dangerous Behavior |
| type | local |
Nessus
| NASL family | Windows : Microsoft Bulletins |
| NASL id | SMB_NT_MS18_FEB_4074588.NASL |
| description | The remote Windows host is missing security update 4074588. It is, therefore, affected by multiple vulnerabilities : - A remote code execution vulnerability exists in the way that the scripting engine handles objects in memory in Internet Explorer. The vulnerability could corrupt memory in such a way that an attacker could execute arbitrary code in the context of the current user. An attacker who successfully exploited the vulnerability could gain the same user rights as the current user. (CVE-2018-0866) - A security feature bypass vulnerability exists in Windows Scripting Host which could allow an attacker to bypass Device Guard. An attacker who successfully exploited this vulnerability could circumvent a User Mode Code Integrity (UMCI) policy on the machine. (CVE-2018-0827) - A remote code execution vulnerability exists in the way that the scripting engine handles objects in memory in Microsoft Edge. The vulnerability could corrupt memory in such a way that an attacker could execute arbitrary code in the context of the current user. An attacker who successfully exploited the vulnerability could gain the same user rights as the current user. (CVE-2018-0834, CVE-2018-0835, CVE-2018-0836, CVE-2018-0837, CVE-2018-0838, CVE-2018-0856, CVE-2018-0857, CVE-2018-0859, CVE-2018-0860) - An information disclosure vulnerability exists when Microsoft Edge improperly handles objects in memory. An attacker who successfully exploited the vulnerability could obtain information to further compromise the users system. (CVE-2018-0763) - An information disclosure vulnerability exists when the Windows kernel fails to properly initialize a memory address. An attacker who successfully exploited this vulnerability could obtain information to further compromise the users system. (CVE-2018-0843) - An information disclosure vulnerability exists in the Windows kernel that could allow an attacker to retrieve information that could lead to a Kernel Address Space Layout Randomization (ASLR) bypass. An attacker who successfully exploited the vulnerability could retrieve the memory address of a kernel object. (CVE-2018-0832) - An information disclosure vulnerability exists when VBScript improperly discloses the contents of its memory, which could provide an attacker with information to further compromise the users computer or data. (CVE-2018-0847) - An information disclosure vulnerability exists when the Windows kernel improperly handles objects in memory. An attacker who successfully exploited this vulnerability could obtain information to further compromise the users system. (CVE-2018-0757, CVE-2018-0829, CVE-2018-0830) - A remote code execution vulnerability exists in StructuredQuery when the software fails to properly handle objects in memory. An attacker who successfully exploited the vulnerability could run arbitrary code in the context of the current user. If the current user is logged on with administrative user rights, an attacker could take control of the affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights. (CVE-2018-0825) - An elevation of privilege vulnerability exists when Storage Services improperly handles objects in memory. An attacker who successfully exploited this vulnerability could run processes in an elevated context. (CVE-2018-0826) - An elevation of privilege vulnerability exists when NTFS improperly handles objects. An attacker who successfully exploited this vulnerability could run processes in an elevated context. (CVE-2018-0822) - An elevation of privilege vulnerability exists when AppContainer improperly implements constrained impersonation. An attacker who successfully exploited this vulnerability could run processes in an elevated context. (CVE-2018-0821) - A remote code execution vulnerability exists when Windows improperly handles objects in memory. An attacker who successfully exploited these vulnerabilities could take control of an affected system. (CVE-2018-0842) - An elevation of privilege vulnerability exists when the Windows Common Log File System (CLFS) driver improperly handles objects in memory. An attacker who successfully exploited this vulnerability could run processes in an elevated context. (CVE-2018-0844, CVE-2018-0846) - An elevation of privilege vulnerability exist when Named Pipe File System improperly handles objects. An attacker who successfully exploited this vulnerability could run processes in an elevated context. (CVE-2018-0823) - An elevation of privilege vulnerability exists when the Windows kernel fails to properly handle objects in memory. An attacker who successfully exploited this vulnerability could run arbitrary code in kernel mode. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights. (CVE-2018-0809) - An elevation of privilege vulnerability exists in the way that the Windows Kernel handles objects in memory. An attacker who successfully exploited the vulnerability could execute code with elevated permissions. (CVE-2018-0742, CVE-2018-0756, CVE-2018-0820, CVE-2018-0831) - A remote code execution vulnerability exists in the way the scripting engine handles objects in memory in Microsoft browsers. The vulnerability could corrupt memory in such a way that an attacker could execute arbitrary code in the context of the current user. An attacker who successfully exploited the vulnerability could gain the same user rights as the current user. (CVE-2018-0840) |
| last seen | 2020-06-01 |
| modified | 2020-06-02 |
| plugin id | 106795 |
| published | 2018-02-13 |
| reporter | This script is Copyright (C) 2018-2019 and is owned by Tenable, Inc. or an Affiliate thereof. |
| source | https://www.tenable.com/plugins/nessus/106795 |
| title | KB4074588: Windows 10 Version 1709 and Windows Server Version 1709 February 2018 Security Update |
| code | |
Seebug
| bulletinFamily | exploit |
| description | Windows: NPFS Symlink Security Feature Bypass/Elevation of Privilege/Dangerous Behavior Platform: Windows 10 1709 (functionality not present prior to this version) Class: Security Feature Bypass/Elevation of Privilege/Dangerous Behavior Summary: It’s possible to create NPFS symlinks as a low IL or normal user and the implementation doesn’t behave in a similar manner to other types of Windows symlinks leading to dangerous behavior or EoP. Description: Windows 10 1709 introduced a new symlink feature to NPFS which is accessible from a FSCTL. From what I can see the implementation has a number of security issues which concern me: * 1) Creation of symbolic links is only limited to a user which can open the root named pipe device. I.e. \Device\NamedPipe. This users which can open the device includes restricted tokens with the RESTRICTED SID and Low IL tokens. * 2) Accessing a symlink results in the NPFS driver synthesizing a NTFS symlink reparse point which is passed back to the object manager. This allows the symlink to reparse to different devices. This is presumably by design but it’s dangerous behavior. * 3) Opening a symlink doesn’t respect the FILE_OPEN_REPARSE_POINT which could lead to some unusual behavior. The fact that you can create the symlink as a lower privileged user is bad enough, although I don’t believe it can be done from an AC so maybe you don’t care about it. But the other two issues are examples of dangerous behavior `which _will_ come` back to bite you at some point in the future. Let’s take point 2 as an example, up to this point NPFS hasn’t had the concept of symbolic links. Sure you could drop an appropriate object manager symlink somewhere and get a caller to follow it but you’d need to be able to influence the callers path or their DOS device directory. With this if a privileged caller is expecting to open a named pipe, say \\.\pipe\ABC then ABC could actually be a symbolic link to a normal file. If the caller then just writes data to the pipe expecting it to be a stream they could actually be writing data into a file which might result in EoP. Basically I see it’s a case of when not if that a EoP bug is found which abuses this behavior. Also, there’s no way I know of for detecting you’re opening a symbolic link. For example if you open the target with the FILE_OPEN_REPARSE_POINT flag it continues to do the reparse operation. Due to creating a normal NTFS symbolic link this might also have weird behavior when a remote system accessed a named pipe, although I’ve not tested that. Overall I think the behavior of the implementation has the potential for malicious use and should be limited to privileged users. I don’t know it’s original purpose, perhaps it’s related to Silos (there is a flag to make a global symlink) or it’s to make it easier to implement named pipes in WSL, I don’t know. If the purpose is just to symlink between named pipes then perhaps only allow a caller to specify the name relative to the NPFS device rather than allowing a full object path. Proof of Concept: I’ve provided a PoC as a C# project. The PoC will create a symlink called ABC which points to notepad.exe. It will check the file file it opens via the symlink matches the file opened directly. * 1) Compile the C# project. It will need to grab the NtApiDotNet from NuGet to work. * 2) Run the poc as Low IL (using say psexec). Expected Result: The creation of the symlink should fail with an error. Observed Result: The symlink is created, is valid and the poc printed ‘Success’ as it’s opened the copy of notepad.exe via the symlink. [poc.zip](https://bugs.chromium.org/p/project-zero/issues/attachment?aid=310808&signed_aid=TOkMtt03qDzMT41SCzwPSQ==) |
| id | SSV:97142 |
| last seen | 2018-02-25 |
| modified | 2018-02-24 |
| published | 2018-02-24 |
| reporter | Root |
| title | Windows: NPFS Symlink Security Feature Bypass/Elevation of Privilege/Dangerous Behavior(CVE-2018-0823) |