{"id":45024,"date":"2015-05-27T07:00:00","date_gmt":"2015-05-27T21:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/2015\/05\/27\/dubious-security-vulnerability-luring-somebody-into-your-lair\/"},"modified":"2019-03-13T12:15:46","modified_gmt":"2019-03-13T19:15:46","slug":"20150527-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20150527-00\/?p=45024","title":{"rendered":"Dubious security vulnerability: Luring somebody into your lair"},"content":{"rendered":"<p>A security report was received that went something like this: <\/p>\n<blockquote CLASS=\"q\"><p>The XYZ application does not load its DLLs securely. Create a directory, say, <code>C:\\Vulnerable<\/code>, and copy <code>XYZ.EXE<\/code> and a rogue copy of <code>ABC.DLL<\/code> in that directory. When <code>C:\\Vulnerable\\XYZ.EXE<\/code> is run, the XYZ program will load the rogue DLL instead of the official copy in the System32 directory. This is a security flaw in the XYZ program. <\/p><\/blockquote>\n<p>Recall that <a HREF=\"http:\/\/blogs.msdn.com\/b\/oldnewthing\/archive\/2011\/06\/20\/10176772.aspx\">the directory is the application bundle<\/a>, The fact that the <code>XYZ.EXE<\/code> program loads ABC.DLL from the application directory rather than the System32 directory is not surprising because the ABC.DLL has been placed inside the <code>XYZ.EXE<\/code> program&#8217;s trusted circle. <\/p>\n<p>But what is the security flaw, exactly? <\/p>\n<p>Let&#8217;s identify the attacker, the victim, and the attack scenario. <\/p>\n<p>The attacker is the person who created the directory with the copy of <code>XYZ.EXE<\/code> and the rogue <code>ABC.DLL<\/code>. <\/p>\n<p>The victim is whatever poor sap runs the <code>XYZ.EXE<\/code> program from the custom directory instead of from its normal location. <\/p>\n<p>The attack scenario is <\/p>\n<ul>\n<li>Attacker creates a directory, say, <code>C:\\Vulnerable<\/code>. \n<li><code>copy C:\\Windows\\System32\\XYZ.EXE C:\\Vulnerable\\XYZ.EXE<\/code> \n<li><code>copy rogue.dll C:\\Vulnerable\\ABC.DLL<\/code> \n<li>Convince a victim to run <code>C:\\Vulnerable\\XYZ.EXE<\/code>. <\/ul>\n<p>When the victim runs <code>C:\\Vulnerable\\XYZ.EXE<\/code>, the rogue DLL gets loaded, and the victim is pwned. <\/p>\n<p>But the victim was already pwned even before getting to that point! Because the victim ran <code>C:\\Vulnerable\\XYZ.EXE<\/code>. <\/p>\n<p>A much simpler attack is to do this: <\/p>\n<ul>\n<li>Attacker creates a directory, say, <code>C:\\Vulnerable<\/code>. \n<li><code>copy pwned.exe C:\\Vulnerable\\XYZ.EXE<\/code> \n<li>Convince a victim to run <code>C:\\Vulnerable\\XYZ.EXE<\/code>. <\/ul>\n<p>The rogue <code>ABC.DLL<\/code> is immaterial. All it does is <a HREF=\"http:\/\/blogs.msdn.com\/b\/oldnewthing\/archive\/2009\/04\/09\/9539191.aspx\">crank up the degree of difficulty<\/a> without changing the fundamental issue: If you can trick a user into running a program you control, then the user is pwned. <\/p>\n<p> This is another case of <a HREF=\"http:\/\/blogs.msdn.com\/b\/oldnewthing\/archive\/2007\/08\/07\/4268706.aspx\">if I can run an arbitrary program, then I can do arbitrary things<\/a>, also known as <a HREF=\"http:\/\/blogs.msdn.com\/b\/oldnewthing\/archive\/2007\/08\/07\/4268706.aspx#4282521\">MS07-052: Code execution results in code execution<\/a>. <\/p>\n<p>Note that the real copy of <code>XYZ.EXE<\/code> in the System32 directory is unaffected. The attack doesn&#8217;t affect users which run the real copy. And since <code>C:\\Vulnerable<\/code> isn&#8217;t on the default <code>PATH<\/code>, the only way to get somebody to run the rogue copy is to trick them into running the wrong copy. <\/p>\n<p>It&#8217;s like saying that there&#8217;s a security flaw in Anna Kournikova because people can create things that look like Anna Kournikova and trick victims into running it. <\/p>\n","protected":false},"excerpt":{"rendered":"<p>Constructing an insecure directory.<\/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-45024","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-other"],"acf":[],"blog_post_summary":"<p>Constructing an insecure directory.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/45024","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=45024"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/45024\/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=45024"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=45024"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=45024"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}