[Spice-devel] Questions on security.

[Robert Relyea]

On 05/17/2010 06:01 AM, Alexander Larsson wrote:
> On Mon, 2010-05-03 at 16:56 -0700, Robert Relyea wrote:
>   
>> Hi all,
>>
>> I've been asked to look at the security of the spice protocol. I've
>> looked at the project a bit already and have a few potential things to
>> talk about, but I wanted to understand some of the underlying
>> assumptions before I get too far into it.
>>
>>     
> Sorry for the late answer. We were a bit busy with team meetings and
> whatnot.
>
>   
>> First, I want to confirm that the protocol itself is not meant to be
>> 'secure' (resistant to active and passive attacks)  unless secured by
>> some higher level channel protocol (like SSL). NOTE: this is not
>> unusual, most internet protocols are not secured unless transported
>> through a trusted pipe like SSL. -- It's usually considered better to
>> use an existing security protocol for a transport than to create a
>> brand new secure protocol from scratch. The chances of getting
>> something wrong is pretty high even for security protocol experts.
>>
>>     
> It depends on what you mean. Spice is a somewhat complex protocol that
> uses multiple tcp connections per client connection, so there is no
> simple layering of "spice over ssl". However, spice itself does
> (optionally) support encrypting some or all of the channels using ssl.
> This all depends on how you launch/configure it.
>   
It's OK to have multiple SSL connections per client, as long as we
handle authentication properly so that if the server treats the 2
connections as from the same client, both have been authenticated properly.
>   
>> If it is meant to be secure, what types of attacks is it supposed to
>> prevent without a secure channel? Is it, for instance, meant to have
>> strong authentication?
>>
>> There will probably be some more questions depending on the answers to
>> these. I couldn't find any security deployment guide (not surprising
>> at this stage), which would answer these questions.
>>     
> I don't think we ever sat down and discussed this, but I think these are
> the kinds of things we expect spice to be robust against:
>
> * Software running inside the guest trying to attack the host that runs
> the guest os instance
>
> * When the client connects to the server there is some form of
> authentication so that not anyone can connect to a "private" guest
> instance. This is atm done via password set at the server side which the
> client must supply (i'm not sure how exactly this is implemented, i hope
> its not passing the password over the net)
>   
OK, this is one of the areas of concern. It appears the protocol is
accepting a public key from the server, then encrypting the password
with that public key.

This has a couple of issues:
    1) A MITM could supply his own public key, and the client would
happily encrypt the password and send it to him. This can be resolved
using SSL (which would prevent MITM to begin with), or by authentication
the public key (either with a certificate or ad hoc such as ssh).
   2) It's vulnerable to replay. If the attacker can snoop the channel,
he can acquire the encrypted password. Even though the attacker can't
decrypt this password, he can replay it to the server whenever he want.
This can be resolved using SSL (which would prevent snooping), or by
rotating the public key the server uses on each connection (which would
be expensive and defeat any mitigation of issue 1).

In short the current scheme is little better than passing the password
in the clear (which would also be safe is you are using SSL). I would
almost rather see that.

The better plan would be to piggyback on some well defined
authentication scheme, like SASL. (That also gives you the flexibility
to go from username/password at the low end to kerberos or on the high
end). The other option is to use SSL native authentication (both
kerberos and client auth) could be used. This has the advantage the SSL
automatically connects multiple connections from the same client for
you, the down side is it requires SSL, so I don't think it's a general
solution for you.

> * When a client is active we (optionally) don't want anyone to be able
> listen to the data, or hijack the connection. This is done by allowing
> channels to be secured via ssl.
>   
OK, this is good. This means that I don't need to worry about the lack
of MACing in the protocol.
> * When we're migrating the guest os to another server we automatically
> have the client connect to the new server, and we need to ensure that
> the client doesn't connect to some rouge server but really to the
> "same" (migrated) guest.
>   
OK, I'll definitely look at that scenario. SSL can help here make sure
you are connecting to the correct server.

bob




-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6650 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.freedesktop.org/archives/spice-devel/attachments/20100518/fdcce9bf/attachment.bin>