Oh no, you're thinking, yet another cookie pop-up. Well, sorry, it's the law. We measure how many people read us, and ensure you see relevant ads, by storing cookies on your device. If you're cool with that, hit “Accept all Cookies”. For more info and to customize your settings, hit “Customize Settings”.

Review and manage your consent

Here's an overview of our use of cookies, similar technologies and how to manage them. You can also change your choices at any time, by hitting the “Your Consent Options” link on the site's footer.

Manage Cookie Preferences
  • These cookies are strictly necessary so that you can navigate the site as normal and use all features. Without these cookies we cannot provide you with the service that you expect.

  • These cookies are used to make advertising messages more relevant to you. They perform functions like preventing the same ad from continuously reappearing, ensuring that ads are properly displayed for advertisers, and in some cases selecting advertisements that are based on your interests.

  • These cookies collect information in aggregate form to help us understand how our websites are being used. They allow us to count visits and traffic sources so that we can measure and improve the performance of our sites. If people say no to these cookies, we do not know how many people have visited and we cannot monitor performance.

See also our Cookie policy and Privacy policy.

This article is more than 1 year old

Google Project Zero reverse-engineers Windows path hacks for better security

Undocumented API features and security

If you're tearing your hair out trying to make sure your Windows 8 / 8.1 /10 application isn't attackable through the filename structure, a Google security engineer has penned a long look at the API to try and help.

The reason behind the long explanation is simple, from Google's point of view: “path'ological reverse engineer” James Forshaw writes that because documentation for Windows 32 paths is incomplete, there's lots of room for mistakes that lead to security vulnerabilities.

“How the Win32 APIs process file paths on Windows NT is a tale filled with backwards compatibility hacks, weird behaviour, and beauty. Incorrect handling of Win32 paths can lead to security vulnerabilities,” Forshaw writes here.

The number of backwards compatibility hacks that must exist is hinted at by the output of the NTDLL pathname export call, which refers to “DOS paths” – RtlDosPathNameToRelativeNtPathName_U.

There's all sorts of places you can get caught, Forshaw notes. For example, any developer familiar with Microsoft's drive naming probably works on the ancient assumption that drivenames are letters between A and Z.

No more: “It turns out the RtlGetFullPathName_U API does not enforce this requirement, although the Explorer shell and command prompt almost certainly do”, he notes (the qualifier “almost” shows how hard reverse engineering this stuff can be).

Windows Environment drives

Even default drive naming isn't always what you expect.

Newcomers to Windows development probably don't expect that =::=::/

Image: James Forshaw, Google Project Zero

Why does all this matter? Because anybody trying to avoid exploits being deployed against mistakes in drive and file handling needs to validate a hugely complex set of inputs.

“There are so many quirks and weird behaviors it's very difficult to write code that validates all possible outcomes,” Forshaw writes.

“Converting everything to NT paths helps slightly as they are less prone to misbehaviour, but even then through symbolic link abuse or changing drive letters it's still possible to be confused. If you ever encounter an application trying to validate a Win32 path, be very skeptical”.

There's also a C# example program he's written to help programmers test his examples – and their own – to look at the results. ®

Similar topics

TIP US OFF

Send us news


Other stories you might like