Re: [Monotone-devel] WARNING: ~/.monotone/keys CONSIDERED HARMFUL

[Daniel Carrera]

Brian May wrote:
> Unfortunately, e17e2bdd1721ad25f2c439a6e7df12d8b6f141b6 means nothing to 
> most people. If you added e17e2bdd1721ad25f2c439a6e7df12d8b6f141b6 to 
> ~/./monotone///read/-/permissions or /~/./monotone//write-/permissions 
> it means nothing. Just who is allowed access? Maybe you know when you 
> added the entry, but maybe several years later./ If you see 
> e17e2bdd1721ad25f2c439a6e7df12d8b6f141b6 signed a certificate, just what 
> does that mean? Nothing.

The system I proposed would retain a user name. I proposed that each key 
have fields for the name, email and a comment. Like this:

Daniel Carrera <address@hidden> (Foo Inc)  e17e2bdd1721ad25f...


Monotone could extract this information, even if the file name is 
e17e2b... I think this system would be an improvement over the current 
system that simply uses address@hidden as the file name.


> /So you need to identify the user associated with key 

Depending on what you mean by identify. If you are happy with:

Matz <address@hidden> (Real name withheld)


Then I agree. You don't care what Matz' real name is, as long as you 
know that this patch was signed by the guy who uses the handle Matz on 
the list and whom you trust.


> ///The problem is there is no security in mapping the key to the keyid. 
> If I look at the output of / "ls certs <revision>" and see that it was 
> signed by "/address@hidden" how do I know it was signed by keyid 
> e17e2bdd1721ad25f2c439a6e7df12d8b6f141b6? I don't. More importantly, how 
> do I know it really was signed by /"/address@hidden"? I don't.

I understand. The system should (and currently does) do access control 
based on the keyid (e17e2bdd17...) regardless of what name the key 
claims to correspond to. If someone uploads e17e2bdd17... to the server 
and I (evil cracker) make another key (2f0399e...) claiming to be Brian, 
the server won't trust me.



> As far as I am aware, there is nothing to stop an attacker changing the 
> mappings in the database, to look like, maybe:

If anyone with write access can insert a new trusted key, that is a 
security hole. But at this point, it doesn't matter if the key says 
Brian or Dr. Evil. The guy is in.


> Now everything that was signed by key 
> e17e2bdd1721ad25f2c439a6e7df12d8b6f141b6 will look like it was signed by 
> address@hidden, and everything that appears to be signed by 
> "address@hidden" is actually signed by a key that only the 
> attacker was the corresponding private key.


What kind of access do you need to mount this attack?


> This isn't a problem so far - the attacker has only stuffed up his 
> database - however the attacker can trick other people into 
> synchronising from his database...

A malicious developer (or an attacker with his credentials) can sync 
with the server. Would that distribute the change to everyone? If so, 
that is pretty serious.


> Ok, so its not quite as smooth as I suggested above; monotone stores the 
> keyid with every certificate, and "mtn log" gets upset when they don't 
> match. This might give the game away. Lets fix that:
>
> sqlite> UPDATE revision_certs SET keypair="address@hidden" WHERE 
> keypair="address@hidden";
>
> Now, "mtn log" is happy and "mtn ls certs <revision>" is also happy to 
> display the wrong value:
>
> address@hidden:~/au.com.microcomaustralia.wiki$ mtn ls certs 
> 1d5a9e4d5f38145d96b4703be7c14bbc9c827a05

And now when you sync to the central server everyone gets the changes 
too? That's a serious attack. Do some damage and frame another developer 
(e.g. a co-worker you don't like).


> To answer the question somebody else asked, note that it would not be 
> sufficient to sign the public key with a trusted GnuPG key. Monotone 
> displays the key was signed by address@hidden, and address@hidden may have 
> a perfectly good GnuPG signature that asserts that the hash 
> 44af5cdd1394964a2adc4de086234c1a76f94a18 belongs to address@hidden

Yes. The alias (Brian, Matz, Dr Evil) has to be signed as well, 
alongside the hash.

> I am going to delete this archive pretty soon just to make sure I don't 
> stuff myself up. So if you want me to run any additional tests on it, 
> better ask soon...

I guess we can't ask you to sync with the server :-)  But you could 
setup a local server with a copy of the good database and see what 
happens when you sync with it.

Daniel.