[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] WARNING: ~/.monotone/keys CONSIDERED HARMFUL
From: |
Daniel Carrera |
Subject: |
Re: [Monotone-devel] WARNING: ~/.monotone/keys CONSIDERED HARMFUL |
Date: |
Fri, 24 Oct 2008 10:47:10 +0200 |
User-agent: |
Thunderbird 2.0.0.17 (Macintosh/20080914) |
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.
- Re: [Monotone-devel] WARNING: ~/.monotone/keys CONSIDERED HARMFUL, (continued)
- Re: [Monotone-devel] WARNING: ~/.monotone/keys CONSIDERED HARMFUL, Markus Wanner, 2008/10/21
- Re: [Monotone-devel] WARNING: ~/.monotone/keys CONSIDERED HARMFUL, Daniel Carrera, 2008/10/21
- Re: [Monotone-devel] WARNING: ~/.monotone/keys CONSIDERED HARMFUL, Daniel Carrera, 2008/10/21
- Re: [Monotone-devel] WARNING: ~/.monotone/keys CONSIDERED HARMFUL, Richard Levitte, 2008/10/21
- Re: [Monotone-devel] WARNING: ~/.monotone/keys CONSIDERED HARMFUL, Daniel Carrera, 2008/10/21
- Re: [Monotone-devel] WARNING: ~/.monotone/keys CONSIDERED HARMFUL, Markus Wanner, 2008/10/21
- Re: [Monotone-devel] WARNING: ~/.monotone/keys CONSIDERED HARMFUL, Daniel Carrera, 2008/10/21
- Re: [Monotone-devel] WARNING: ~/.monotone/keys CONSIDERED HARMFUL, Brian May, 2008/10/23
- Re: [Monotone-devel] WARNING: ~/.monotone/keys CONSIDERED HARMFUL,
Daniel Carrera <=
- Re: [Monotone-devel] WARNING: ~/.monotone/keys CONSIDERED HARMFUL, Brian May, 2008/10/29
- Re: [Monotone-devel] WARNING: ~/.monotone/keys CONSIDERED HARMFUL, Daniel Carrera, 2008/10/20
- Re: [Monotone-devel] WARNING: ~/.monotone/keys CONSIDERED HARMFUL, Ethan Blanton, 2008/10/20
- Re: [Monotone-devel] WARNING: ~/.monotone/keys CONSIDERED HARMFUL, Markus Wanner, 2008/10/20
- Re: [Monotone-devel] WARNING: ~/.monotone/keys CONSIDERED HARMFUL, Timothy Brownawell, 2008/10/20
- Re: [Monotone-devel] WARNING: ~/.monotone/keys CONSIDERED HARMFUL, Markus Wanner, 2008/10/20
Re: [Monotone-devel] WARNING: ~/.monotone/keys CONSIDERED HARMFUL, Timothy Brownawell, 2008/10/19