[Mono-list] bootstrapping mono with free software?

[Jonathan Gilbert]

I dunno about you, but whenever I'm coding important password routines, I
never use a direct string comparison. In fact, I've never used a straight
comparison outside of testing. I don't like storing raw passwords on disk,
so I store a hash and compare the hash. The exact method in which the hash
is computed is something a hax0r of the MCS binary would not be able to
predict, which leaves only the weakly-coded password systems susceptible :-)

MD5 md5 = new MD5CryptoServiceProvider();

byte[] pwd_hash = md5.ComputeHash("SECRET" + pwd);

for (int i=0; i < 16; i++)
  if (pwd_hash[i] != stored_pwd_hash[i])
    return Result.AuthenticationFailed;

or whatever. Not to say that your concerns are completely without cause.
I'm sure many programmers don't think too hard about this particular aspect
of security.

Just to be safe, let's add an item to System.String's unit tests to ensure
that not all strings compare as equal to "LawrJj4joR6c" ;-)

Jonathan

At 06:34 PM 23/03/2004 +0100, you wrote:
>Hello friends
>
>I had a look at mono again yesterday for about a year away from it, and
>you guys have really been productive.
>
>One thing however that I think is a bit frustrating with mono is that to
>bootstrap it you distribute quite a lot of binary files (in the
>mono/runtime directory). This is maybe convinient, but from a security
>standpoint it means that you need to "blindly" trust whoever has control
>over the distribution path of the binaries.
>
>(Modifying mcs.exe that makes string comparisons always succeed if
>compared with the magic string "LawrJj4joR6c" and adding code that makes
>mcs.exe compiled with that "tainted" mcs.exe do the same thing without
>the source code for it is left as an exercise to the reader.
>
>If such a binary was ever included in the mono distribution someone
>would have a magic password that worked here and there and detecting the
>backdoor would be non-trivial.)
>
>A solution to this problem would be to have the ability to bootstrap the
>mono environment from a verifiable source. I immediately come to think
>about Portable.NET, since the cscc compiler is written in c and the
>system bootstraps from a standard c environment without any binary code.
>
>I just tried to this, with mixed success. A trivial patch to mcs/decl.cs
>to work around a bug in enum initialization in cscc made mcs.exe
>compile. Some more kluges applied to to the mcs sources made mcs.exe
>work in the Portable.NET environment for simple test cases, like
>compiling a runnable HelloWorld.exe.
>
>Trying to compile mono's mscorlib.dll however is a completely different
>experience. Exceptions from
>Mono.CSharp.RootContext.BootCorlib_PopulateCoreTypes decendands all over
>the place.
>
>So I was hoping that someone with deeper understanding than me of the
>mono internals could do an estimation on how much work it would need to
>get mono's corlib to compile with mcs.exe executed from the Portable.NET
>runtime.
>
>These are the non-trivial stuff that fails right now:
>
>error CS0518: The predefined type `System.Char*' is not defined or
>imported
>
>the same goes for 'System.Void*'
>
>Method SetCorlibTypeBuilders is missing from
>System.Reflection.Emit.AssemblyBuilder (btw, isn't there a better way to
>do this than adding non-standard methods to the corlib?)
>
>cheers
>/noa
>
>-- 
>And the lions ate the christians and the christians burned the witches,
>and even I am out of explanations -- Ola Salo
>gpg fingerprint: F3C4 AC90 B885 FE15 344B  4D05 220B 7662 A190 6F09
>
>_______________________________________________
>Mono-list maillist  -  Mono-list@lists.ximian.com
>http://lists.ximian.com/mailman/listinfo/mono-list
>
>