This is a complex and poorly-defined vulnerability.
Microsoft’s description from https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0668 is essentially useless:
“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. To exploit the vulnerability, a locally authenticated attacker could run a specially crafted application. “

There is little surprise that there exists some confusion about the vulnerability.

Contrary to the earlier poster, I do not believe that this is a System Orchestrator bug. I agree with https://packetstormsecurity.com/files/cve/CVE-2020-0668 and think the vulnerability is in the Remote Access Service. Part of the confusion is that the vulnerability is a file overwrite vulnerability, and many PoCs are leveraging a dll-hijacking vulnerability in the system orchestrator service to gain code execution after the trusted file write takes place.

The Remote Access Service runs as system and creates a log of its actions called RASTAPI.LOG. Once the RASTAPI.LOG reaches a defined size, the Remote Access Service copies RASTAPI.LOG to RASTAPI.OLD in the same directory.
The issue is twofold. First, the behavior of the Remote Access Service Tool API is defined by three registry keys:
HKLM\SOFTWARE\Microsoft\Tracing\RASTAPI\EnableFileTracing
HKLM\SOFTWARE\Microsoft\Tracing\RASTAPI\FileDirectory
HKLM\SOFTWARE\Microsoft\Tracing\RASTAPI\new_size
These three registry keys allow a user to turn on the RASTAPI and configure the size and location of the log file. These registry keys are writable by a regular user.
The second issue is that the RAST service performs only a trivial check on the filesystem location of the RASTAPI.OLD destination. If an attacker creates a filesystem link between the old log destination (i.e. C:\users\user\temp\RASTAPI.OLD) and a trusted location (C:\windows\system32\badfile.dll), RASDIALER will copy the old log file to the linked location as the SYSTEM user. Because there is a file hijacking vulnerability in the System Orchestrator service, many PoCs use the location C:\Windows\System32\WindowsCoreDeviceInfo.dll, which does not exist in a default configuration, but System Orchestrator Service will load if it does exist,

The attack looks something like:

1. Gain lower-privileged access to a vulnerable target.
   
2. Create a dummy directory to hold files.
   
3. Mount the dummy directory to \RPC Control
   
4. Upload a dll payload
   
5. Create a link between \RPC Control\RASTAPI.LOG and the uploaded payload
   
6. Create a link between \RPC Control\RASTAPI.OLD and the destination location the attacker would like to write (in this example, C:\Windows\system32\WindowsCreDeviceInfo.dll)
   
7. Write the registry keys to turn on FileTracing, set the file directory to the dummy directory, and set the max file size to one byte less than the size of the payload,
   
8. Upload a configuration file for the rasdialer
   
9. Launch the rasdialer. When RAST service kicks off, it tries to write a log file to the directory specified in the registry, but it finds one already exists, and it is already full, so RAST service then copies the file to the “old” location that’s linked to the trusted location. The result is an arbitrary file write to a trusted location.
   
10. At this point, the overwrite is complete. PoC’s leverage the System Orchestrator service to get execution of the overwritten dll file by launching the system orchestrator.
    

Many PoC exploits leverage https://github.com/googleprojectzero/symboliclink-testing-tools which allow for the manipulation of symbolic links and mount points and also https://github.com/itm4n/UsoDllLoader to start the System Orchestrator service to launch the dll.

While the exploit is difficult, there are several PoC exes out there, and a metasploit module in progress, so I consider the exploitability relatively easy, though the exploit itself is difficult.