WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xense-devel

[Xense-devel] PoC of Covert Channel

To: xen-devel@xxxxxxxxxxxxxxxxxxx, xense-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xense-devel] PoC of Covert Channel
From: "Mickaël Salaün" <mickael.salaun@xxxxxxxxxxx>
Date: Wed, 23 Jul 2008 19:19:20 +0200
Cc:
Delivery-date: Wed, 23 Jul 2008 10:19:25 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=4DOnSgemVoD/PagaakIsIWlae7XTwyItFgK9oVHT/Bk=; b=qdYTrqH8B4gFPa93sEJj/qXjKXbJnOOGfo2MmkUPYhBVDPjWA828hLIeKjWeKdTIpg fqh4fsTvE9obdsWHv4UeTBo9CftVdgRG/yjsW1FNWLLuk9Xc3kWhgFmwvIDdTTAB8R3Y iD4KlH4/qE0Kx6Q4S2K6jtEQV401RNAOGaGZc=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=d1J3SlvgNyI0yC9avogOifYn1eBZOVcWdWQvBOgQ4nvNPj/Sj6ahzxs4khguYx7Qnm 4QxGpBvXzqIJuWzQ1CGlI+/3vsSC28//HzMeO+Ld6mjMxH6uU6Acsuc4RF+xfKNfbJQQ bv7GuZ5oaIMfFOIesiFLHiIHoeXm0Hmia4/eQ=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <9ad012770807230723w4887ebe4ta794bf245336e2b@xxxxxxxxxxxxxx>
List-help: <mailto:xense-devel-request@lists.xensource.com?subject=help>
List-id: "A discussion list for those developing security enhancements for Xen." <xense-devel.lists.xensource.com>
List-post: <mailto:xense-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xense-devel>, <mailto:xense-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xense-devel>, <mailto:xense-devel-request@lists.xensource.com?subject=unsubscribe>
References: <9ad012770807230723w4887ebe4ta794bf245336e2b@xxxxxxxxxxxxxx>
Sender: xense-devel-bounces@xxxxxxxxxxxxxxxxxxx
Hi all,
I created a proof of concept to communicate between guests (inside
dom0 or domU) in a Xen environment. You need to have kernel rights
(hypercalls are needed).
It use the machine-to-physical table to store informations. This table
is readable for all guests and writable for the part's guest. The
principle is simple: write a tag and your data instead of addresses.
Other guests can read what you wrote and extract data. An half-duplex
channel can be created to share information between OS (Linux 2.6
x86-32 for now).

This PoC is not a new idea[1] but a practical issue. This one bypass
the Xen Policy checks as knew by developers[2].

The machine-to-physical table is really good for the performance
mapping but it would be a good idea to have one table for each guest
and protect it. I think it is not a big problem, it can be fast
(memory size and switch time). Another solution is to use a full
shadow page tables, but with a lower speed if it is a software
translation. If it is done like this, my PoC will be unusable. It will
also be good to prevent other guests to read the table and infer (with
Xen interrupts) a (basic) map of the physically mapped memory.

The code is a device driver who create /dev/xencc. The communication
protocol is based on tags. You need a different tag for each guest
(look at the source and change it for the second guest). For now, you
can only communicate between two guests. If you have not udev install
on your system, the device will not be created when you insert the
specific module[3]. In this case you need to create it by hand[4].
You can write[5] and read[6]. If you are risky you can change the
limit buffer size in the source. The channel bandwidth seams to be
good because it use an hypercall (mmu_update) to copy an entire range
of data at the same time. The drawback of this method is the consuming
memory. We are allocating addresses instead of 4 bytes (in x86-32
architecture), so we need to transmit data step-by-step. With a good
scheduling you can have a quick channel.

This is an unstable version, use it with caution!

Best regards,
Mickaël Salaün


1. 
http://lists.xensource.com/archives/cgi-bin/mesg.cgi?a=xense-devel&i=003501c63303%245209cbd0%241c02000a%40Myong1
2. 
http://lists.xensource.com/archives/cgi-bin/mesg.cgi?a=xen-devel&i=39CC97884CA19A4D8D6296FE94357BCB019EB0B2%40swsmsx404
3. insmod xencc.ko
4. mknod /dev/xencc c `grep misc /proc/devices | awk '{print $1}'`
`grep xencc /proc/misc | awk '{print $1}'`
5. echo your msg > /dev/xencc
6. dd if=/dev/xencc count=1

Attachment: Makefile
Description: Binary data

Attachment: xencc.c
Description: Text Data

_______________________________________________
Xense-devel mailing list
Xense-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xense-devel
<Prev in Thread] Current Thread [Next in Thread>