Full Disclosure mailing list archives
Re: Microsoft's Binary Planting Clean-Up Mission
From: Tyler Borland <tborland1 () gmail com>
Date: Fri, 16 Sep 2011 00:25:54 -0500
I really don't want to talk more about this because everyone seems to be hating on this. However... ld_preload has to be set locally by the user or somehow remotely pass and set ld_preload environment variable. Not only that, but it has to be in the trusted path. This search path problem would be consistent with the default search path of linux, which would be (according to man ld.so/ld-linux.so and man 3 dlopen's search path): o (ELF only) If the executable file for the calling program contains a DT_RPATH tag, and does not contain a DT_RUNPATH tag, then the directories listed in the DT_RPATH tag are searched. o If the environment variable * LD_LIBRARY_PATH* is defined to contain a colon-separated list of directories, then these are searched. (As a security measure this variable is ignored for set-user-ID and set-group-ID programs.) o (ELF only) If the executable file for the calling program contains a DT_RUNPATH tag, then the directories listed in that tag are searched. o The cache file * /etc/ld.so.cache* (maintained by *ldconfig<http://linux.die.net/man/8/ldconfig> (8)*) is checked to see whether it contains an entry for *filename*. o The directories */lib* and */usr/lib* are searched (in that order). Now, the issue with Microsoft is that by simply using loadlibrary* (or by using anything that follows the default search path like CreateProcess*<http://msdn.microsoft.com/en-us/library/ms682425%28VS.85%29.aspx>, ShellExecute*<http://msdn.microsoft.com/en-us/library/bb762153%28VS.85%29.aspx>, WinExec <http://msdn.microsoft.com/en-us/library/ms687393%28VS.85%29.aspx>, LoadModule<http://msdn.microsoft.com/en-us/library/ms684183%28VS.85%29.aspx>, _spawn*p*<http://msdn.microsoft.com/en-us/library/20y988d2%28v=VS.80%29.aspx>and _exec*p* <http://msdn.microsoft.com/en-us/library/431x4c1w%28VS.80%29.aspx>)in your code and not specifying a full path, the search path can hit a remote directory to pull and execute the file. http://msdn.microsoft.com/en-us/library/ms682586%28v=vs.85%29.aspx "Safe DLL search mode is enabled by default." If *SafeDllSearchMode* is enabled, the search order is as follows: 1. The directory from which the application loaded. 2. The system directory. Use the *GetSystemDirectory*<http://msdn.microsoft.com/en-us/library/ms724373%28v=vs.85%29.aspx>function to get the path of this directory. 3. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched. 4. The Windows directory. Use the *GetWindowsDirectory*<http://msdn.microsoft.com/en-us/library/ms724454%28v=vs.85%29.aspx>function to get the path of this directory. 5. The current directory. <---------------- 6. The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the *App Paths* registry key. The *App Paths* key is not used when computing the DLL search path. Of course, different functions have different search paths. Take a look at some more interesting example issues: *CreateProcess*, WinExec and LoadModule search paths* 1. The directory from which the application loaded 2. Current working directory 3. etc..... In Windows's case, no one needs to do anything extra like set a problem environment variable or developer make some stupid mistake. Instead, it's just default behaviour when you load a library without specifying the full path. Again, with Linux, the default search path is going to be local unless otherwise specified compile-time with something like run_path and its $origin expansion. But even then you're restricted to trusted search path which is all local full path locations. As far as I know, you can't change a default search path to a remote location. But I haven't researched into it that much and this is a field of doing things in ways it shouldn't. The interesting part about this type of attack is that the attacker can run a webdav server to run the exploit. This is a normal looking url, not some incredibly obvious UNC path to an SMB share. Yes, like most client-side attacks, it may require some social engineering, hijacking of a domain, and etc. However, there's more to it than just downloading some random file from a stranger, it can be used in a decent combination by a well-designed attack. A good example is one that ACROS actually reported on (haven't verified myself, so going on their word). Check it out: "The current Oracle's Java Runtime Environment<http://www.java.com/en/download/>(version 6, update 26) - just like its previous versions - supports so-called Hotspot configuration files<http://blogs.oracle.com/javawithjiva/entry/hotspotrc_and_hotspot_compiler> .hotspotrc and .hotspot_compiler. These files are loaded when Java virtual machine is initialized and can specify (or override) the VM settings that are usually provided as command-line parameters for java.exe or exclude chosen methods from compilation, respectively. " They then go on to explain: "OnOutOfMemoryError. This setting allows one to specify user-defined commands that get ran in case JRE runs out of memory, or more specifically when the OutOfMemoryError<http://download.java.net/jdk7/docs/api/java/lang/OutOfMemoryError.html>error is thrown for the first time." Or how about a problem in a browser with an html format or any other automatic client downloaded format like .js? http://www.securityfocus.com/archive/1/519367 Movie players, flash files, music plugins, etc.? Of course, it's not all about attacks. Certain malware has already used this technique, but it's not exactly wide-spread. I've already talked about how continued exploitation and local exploitation can be done by infecting a host, scanning for all open smb/webdav shares with write access, finding any vulnerable extensions, and dropping files to exploit the issue. This does not effect the file format in any way, so you don't need to trojan, bind, or modify the file. Instead, you just verify a file format exists and drop your shit on the share. Think of businesses who share documents between employees, open music shares for streaming, and etc. Next time someone grabs that file, they may be exploited. I can also tell you that current Snort signatures detect !$HOME_NET -> $HOME_NET for these bugs and I'm sure most ids/ips vendors providing signature solutions also do this. Also, given that this is usually normal flow of an application to request these dll's, it nets many false positives. So reliance on saying 'that\'s strange' to a webdav/smb share or an a/v engine picking it up (lol) is really the only reactive saviour. I know you all think that this isn't a good bug or exciting, but there are ways that it can be used and I don't like that a plausible bug gets downplayed to something like 'you must get the person to download a file, then why not just have them download an exe?'. This, in my mind, is the same lack of creativity as people categorizing denial of service bugs as low priority until someone smarter turns it into an RCE. *sorry for the long email* On Thu, Sep 15, 2011 at 7:21 PM, <paul.szabo () sydney edu au> wrote:
Dear Mitja, In your blog http://blog.acrossecurity.com/2011/09/microsofts-binary-planting-clean-up.html you wrote: Change #1: No "file://" Inside "http://" Microsoft changed the behavior of Internet Explorer such that a web page (served via http://) can't display the content of a shared folder (served via file://) in a frame/iframe. This is good ... Change #2: No "file://" From "http://" Not allowing a web page loaded via http:// to open a file:// URL blocks this attack vector and this is good. ... When were those IE changes made: as part of MS11-057 maybe? I could not find any references to such a change. Thanks, Paul Paul Szabo psz () maths usyd edu au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of Sydney Australia _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Current thread:
- Re: Microsoft's Binary Planting Clean-Up Mission, (continued)
- Re: Microsoft's Binary Planting Clean-Up Mission ACROS Security Lists (Sep 15)
- Re: Microsoft's Binary Planting Clean-Up Mission adam (Sep 15)
- Re: Microsoft's Binary Planting Clean-Up Mission Michael Schmidt (Sep 16)
- Re: Microsoft's Binary Planting Clean-Up Mission Jeffrey Walton (Sep 16)
- Re: Microsoft's Binary Planting Clean-Up Mission ACROS Security Lists (Sep 15)
- Re: Microsoft's Binary Planting Clean-Up Mission Mikhail A. Utin (Sep 16)
- Re: Microsoft's Binary Planting Clean-Up Mission Pedro B (Sep 16)
- Re: Microsoft's Binary Planting Clean-Up Mission ACROS Security Lists (Sep 16)
- Re: Microsoft's Binary Planting Clean-Up Mission Tyler Borland (Sep 15)
- Re: Microsoft's Binary Planting Clean-Up Mission Thor (Hammer of God) (Sep 16)
- Re: Microsoft's Binary Planting Clean-Up Mission ACROS Security Lists (Sep 16)