{"id":103685,"date":"2020-04-20T07:00:00","date_gmt":"2020-04-20T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=103685"},"modified":"2020-04-20T05:52:03","modified_gmt":"2020-04-20T12:52:03","slug":"20200420-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20200420-00\/?p=103685","title":{"rendered":"It rather involved being on the other side of this airtight hatchway: Planting files onto a custom PATH"},"content":{"rendered":"

For some reason, we get lots of reports about DLL planting that basically boil down to this:<\/p>\n

\n

Program X is susceptible to a DLL planting attack because it loads the DLL TOTALLYSAFE.DLL<\/code> without a full path. If I put a rogue TOTALLYSAFE.DLL<\/code> on the system PATH<\/code> ahead of its actual location, then the rogue copy is loaded into the service, and I have gained elevation of privilege.<\/p>\n<\/blockquote>\n

When we dig into the report, we find that the directory into which TOTALLYSAFE.DLL<\/code> was planted is not one of the directories that are on the PATH<\/code> by default. It’s some custom directory that was added by a third-party program’s installer. And that third-party program added a directory that granted write access to non-administrators.<\/p>\n

So what we have here is a case of creating an insecure system and then being surprised that it’s insecure<\/a>.<\/p>\n

Creating this insecure system was done by editing the global PATH<\/code>, which requires administrator permission. Therefore, we are already on the other side of the airtight hatchway. There is no elevation of privilege, because you need to have administrator privileges to create the insecure system in the first place.<\/p>\n

The third-party program decided to install itself into a directory directly off the root of the C:<\/code> drive. If you create your own subdirectory as a direct child of the root, the default security grants Modify access to all authenticated users, and that’s dangerous if you’re going to add that directory to the PATH<\/code>.<\/p>\n

This is one of the reasons why the long-standing recommendation has been to install programs into a subdirectory of %ProgramFiles%<\/code>. The security for %ProgramFiles%<\/code> is set so that only administrators have write access, which means that if you install into a subdirectory of %ProgramFiles%<\/code>, you will get a directory that by default grants write access only to administrators. You can then safely add that directory to the PATH<\/code>.<\/p>\n

In many of the cases I’ve seen, the rogue unsafe directory on the PATH<\/code> belongs to a variety of popular developer tools. My guess is that the finders install these programs by habit into all of their systems, and when they find an issue, it never occurs to them that it was their insecure customizations that was the source of the vulnerability.<\/p>\n

Bonus chatter<\/b>: In one of the cases, the developer tool indeed protects its directories by limiting write access only to administrators. That didn’t stop the finder from “planting” a DLL in that protected directory and then “discovering” a vulnerability. So not only did they require elevation to install the developer tool, they also required elevation in order to “plant” the DLL into the protected directory. I guess that puts them on the other side of two<\/i> airtight hatchways.<\/p>\n

 <\/p>\n","protected":false},"excerpt":{"rendered":"

Adding a directory to the PATH comes with obligations.<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[26],"class_list":["post-103685","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-other"],"acf":[],"blog_post_summary":"

Adding a directory to the PATH comes with obligations.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/103685","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=103685"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/103685\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=103685"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=103685"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=103685"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}