[Mono-dev] Possible security issue with Mono's dllmaps in etc/config

[Sebastien Pouliot]

On Mon, 2007-01-08 at 12:17 +0100, Marek Habersack wrote:
> Hello everybody,

Please send an email to mono at novell.com when/if you think you found an
security related issue within Mono.
http://www.mono-project.com/Vulnerabilities

>   Today while looking at the ODBC code in Mono, it occurred to me that
> there might be a possible security problem with the way DLL maps are
> specified in the default $prefix/etc/mono/config file. Given entries
> like,
> 
> <dllmap dll="libxslt.dll" target="libxslt.so" os="!windows"/>
> <dllmap dll="libmySQL.dll" target="libmysqlclient.so" os="!windows" />
> <dllmap dll="odbc32.dll" target="libodbc.so" os="!windows"/>

I don't think we'll find a single answer to all possible mapping issues
but your first case, ODBC, is probably the easiest one (for me ;-)

AFAIK libodbc copies the API from odbc32.dll from Microsoft, which is
"stable" in the sense that new additions (e.g. to structures) will be
binary compatible with existing structures. This is (probably) a case
where SO numbers aren't required. 

I suspect some other libraries, that want to keep an easy win32/unix
mapping, follows the same win32 rule (i.e. change the library name,
ODBC32.dll versus ODBC.dll when breaking binary compatibility).

> we may encounter two issues. First (not security related, just usage
> annoyance) is that on some Linux distributions the lib*.so file won't
> exist unless there are devel packages installed for the library in
> question. So unless the mono library mapper automatically appends the
> soversion to the .so name and looks for files of the lib*.so.X form,
> the library map will fail and the corresponding managed code won't work.

I'll let someone else answer that (but I'm pretty sure you'll find this
discussed many times in the archives).

> Second issue, this time security related, is with the library ABI. Say
> that managed code uses a C structure in libsome.so whose field
> types/field order/whatnot were changed in the newer library versions,
> which were not released when the managed code was created (for instance

	keyword: "newer", "not released"

> managed code was created with libsome.so.1 being the released version,
> while the current libsome.so symlink points to libsome.so.3 - new ABI).
> Such situation can introduce the possibility for buffer overruns,
> variable overwrites, stack destruction - with the smallest impact on the
> application being segfaults. 

You're right that a bad mapping, if one exists, could lead to those
problems. Note that the same (bad) things could happen for every
p/invoke signature, offset errors, unsafe code, marshaling error... in
mono (C or C#) source code. "dllmap" are just one possible thing that
could go bad.

> If I'm talking nonsense, just lart me and
> ignore :), but if the above is correct reasoning, then I propose to add
> a feature to <dllmap> to specify the expected soversion for the map,
> like so:
> 
> 1. Consider only libxslt.so.1
> <dllmap dll="libxslt.dll" target="libxslt.so" soversion="1"
> os="!windows"/>

This looks identical to what we're already using for some libs, e.g.

 <dllmap dll="cygwin1.dll" target="libc.so.6" os="!windows" />

So it looks like we already deal with this (at least for some cases)

> 2. Consider several libxslt.so.X, in the order given
> <dllmap dll="libxslt.dll" target="libxslt.so" soversion="1,2,3"
> os="!windows"/>

I can't say (I never had to add anything to dllmap) if this is a case we
encountered (or not).

> 3. Consider any soversion, starting from 0 and counting upwards
> <dllmap dll="libxslt.dll" target="libxslt.so" soversion="any"
> os="!windows"/>

This looks identical to the current usage (i.e. without adding a
soversion attribute)

> 4. Consider any soversion within the ranges (normal comparison
> operators could also be used - eg. >4,<7)
> <dllmap dll="libxslt.dll" target="libxslt.so" soversion="4-7,8-10"
> os="!windows"/>

Your sample doesn't match your description, but I think #2 already
covers it (it's unlikely we'll have so much revisions).

> What do you think about the idea? Does it make sense?

I think the right question should be: 

	Does adding soversion solve the *issue* ?

I'm not sure it does. First it doesn't make the dllmap future-proof so
it doesn't *solve* the case of newer, not released, (the keywords)
libraries. 

The safest *solution* is to use *very specific* (e.g. fully specified)
version numbers. No one does that because it would become a maintenance
nightmare. So we fallback to something more simpler, and hopefully,
stable.

Now I can't say if our dllmap entries are correct (precise enough) or
not. Some have a major SO version specified, some have not. I can
*guess* at some reasoning (e.g. odbc32) but I can't vouch for them.

Your idea can make "more precise" version numbers but I don't know if
the problem it solve (version ranges) is one Mono as encountered or not.
In the later case it doesn't solve anything ;-) at least until we need
"range support".

Also note that this idea doesn't change the fact that dllmap needs, like
many things, to be correct (i.e. adding "range support" won't, by
itself, make me feel more secure). So adding/editing this file (to
change a version number) is a little more involving that using a text
editor!
-- 
Sebastien Pouliot  <sebastien at ximian.com>
Blog: http://pages.infinit.net/ctech/