Vulnerability exploits the difference between DOS and NT paths
When someone is asked to type the path to a file on a Windows system, they are likely to type something of the form C:\directory\subdirectory\file.txt. This is known as a DOS-style file path and has been the most common way to represent a file’s location ever since the first Windows version. It still remains a common way that many applications address files on Windows when they want to perform operations on them.
However, ever since Windows NT there is another way to represent file paths. The NT path equivalent of the above DOS path would be \??\C:\directory\subdirectory\file.txt. You might think that’s not much of a difference, and for this particular example, you’d be right, but what actually happens is that NT Paths support Unicode, so a larger number of characters, compared to DOS paths that only support the ANSI character set.
The issue is that WindowsAPI file operation functions, which many applications such as CreateFile call, actually work with NT Paths. If presented with a DOS path, they will first convert it to an NT Path using a function called RtlpDosPathNameToRelativeNtPathName. There are many rules applied to this conversion, but two that are relevant for Yair’s research are the removal of trailing dots from any of the path elements and the removal of empty space trailing the last element.