Date: Fri, 16 Sep 2011 00:25:54 -0500
From: Tyler Borland <tborland1@...il.com>
To: paul.szabo@...ney.edu.au
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Microsoft's Binary Planting Clean-Up Mission

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@...ney.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@...hs.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/
>

Content of type "text/html" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists