Poupou's Corner of the Web

Looking for perfect security? Try a wireless brick.Otherwise you may find some unperfect stuff here...

Weblog

More weekend hacking

So I started adding a
Gtk#
GUI on top of my previous
Cecil /
Dot
graph hacks (see
here
and
here
to see them).
Nothing extraordinary about it, in fact nothing interesting enough to show yet ;-)

Actually most of my weekend hacking wasn't GUI related at all. Most of it has gone into refactoring
the existing source code to reduce duplication (as they all evolved from the same code base, the new
permview.exe
tool) and to move the different tools into plugins.

Plugins are often overrated, and overused, but in this case I know some of them requires
quite a lot of memory (e.g. finding all public callers) and many planned (i.e. in a dark corner of my mind)
plugins will too have high memory requirements. How much ? well probably more than I have right now, so there's
no point having all plugins around at the same time unless necessary (or for a limited number of assemblies).

To make this easier the tool operates on working sets which are simply a list of assemblies
and a list of plugins (with their options) to load. So it's possible to work with few assemblies
(e.g. mscorlib.dll) in more details or work with all (e.g. every dll under
/mcs/class/lib/default/) with fewer plugins.

I also did some low-level class to help generating dot files and couldn't resist trying them
off for a new kind of graph (funnier than refactoring the existing ones :-). This graph shows the dependencies
between assemblies, in this case the
Mono.Security.dll
dependencies.

The graph shows all assemblies referenced by Mono.Security.dll either directly
(like mscorlib.dll and System.dll) or indirectly (System.Xml.dll
being loaded by System.dll). It also shows the references between the referenced assemblies,
so we can clearly see the cyclic dependency that exists between the System.dll and
System.Xml.dll assemblies. Assemblies loaded via reflection (e.g. via CryptoConfig)
are missing as they can't be (in most case) known until runtime.

From a security point of view the graph adds two major informations.

First the type of caller that can call into the assembly. By default strongnamed assemblies
can only be used by fully-trusted code. The CLR enforce this by adding an invisiblelinkdemand to all publicly
methods/classes. Adding a [AllowPartiallyTrusterCallers] attribute at the assembly-level
makes the assembly available to partially trusted callers (e.g. code coming from the internet). This can
be dangerous if the assembly API isn't designed for such use - which means that most assemblies do not
support partial trust.

Also assemblies compiled with unsafe code, which means that the compiler inserted a
[UnverifiableCode] attribute in the unsafe module, are shown in red. The CLR cannot ensure
the code in those assemblies isn't messing up your system, so it's nice to know who they are.

And, of course, being both red (unsafe) and accessible from
partially trusted callers is far more risky than only one of them could be.

Like the previous graphs assembly dependencies can get very ugly. In fact the worst cases I've seen
is for data providers.
They have a lot of dependencies themselves (and some even have unmanaged dependencies not
show in the graphs) and they often links to System.Windows.Forms.dll to include
design-time support (which adds a lot more dependencies).