[Qemu-devel] building a virus-proof PC with Qemu

[Qemu-devel] building a virus-proof PC with Qemu

[Piotras]

Hi!

Imagine that with every byte stored on disk image, the emulated 
memory and CPU registers we associate a flag indicating if the 
byte come from "trusted" source. This information would propagate 
with every memory/disk access (data-flow tracking).

Before Qemu would translate a block of code the trusted bits could 
be checked to see if the code is "trusted". Of course there are 
issues with dynamic loaders, dynamic compilers, etc. And it's not 
going to work well with scripted code.

Possible usage:
  * building virus-proof PC,
  * automate hunting for worms/exploits on Internet.


Opinions?

Piotrek

Re: [Qemu-devel] building a virus-proof PC with Qemu

[Bochnig, Martin]

Piotras wrote:

>Possible usage:
>  * building virus-proof PC,
>  
>
Hi,

most of you know that: The easiest and most secure (100.00%) option 
imaginable is to boot from cd/dvd and to keep the registry (in case of 
m$-win) - or other files requiring write access - inside of a ramdrive.
Works.


Regards,
Martin

>  * automate hunting for worms/exploits on Internet.
>
>
>Opinions?
>
>Piotrek
>
>
>_______________________________________________
>Qemu-devel mailing list
>Qemu-devel@nongnu.org
>http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
>
>  
>

Re: [Qemu-devel] building a virus-proof PC with Qemu

[Magnus Damm]

On Tue, 2004-11-23 at 13:44, Bochnig, Martin wrote:
> Hi,
> 
> most of you know that: The easiest and most secure (100.00%) option 
> imaginable is to boot from cd/dvd and to keep the registry (in case of 
> m$-win) - or other files requiring write access - inside of a ramdrive.
> Works.

Yeah, if your cdrom is lacking write support, the BIOS flash chips are
write-protected and the CMOS memory is handled with care. And if you are
certain that the RAM is cleared during the boot phase. =)

Or you could boot over the network to a RAM disk. But could you trust
your network? The DHCP server, the default gateway?

/ magnus

Re: [Qemu-devel] building a virus-proof PC with Qemu

[Magnus Damm]

Hello again,

On Tue, 2004-11-23 at 13:44, Bochnig, Martin wrote:
> Hi,
> 
> most of you know that: The easiest and most secure (100.00%) option 
> imaginable is to boot from cd/dvd and to keep the registry (in case of 
> m$-win) - or other files requiring write access - inside of a ramdrive.
> Works.

I think the idea is really nice, tried to convince some people employed
by the Swedish army about this two years ago. The Swedish army is very
picky about classified data and if a computer ever gets near classified
information the machine has to be marked as classified and then the
entire machine has to be handled very strictly. Booting from cdrom is
simple and effective.

Do you have any pointers how to do this with Windows (2k/XP) ?

Thanks!

/ magnus

Re: [Qemu-devel] building a virus-proof PC with Qemu

[Paul Brook]

On Tuesday 23 November 2004 14:56, Magnus Damm wrote:
> On Tue, 2004-11-23 at 13:44, Bochnig, Martin wrote:
> > Hi,
> >
> > most of you know that: The easiest and most secure (100.00%) option
> > imaginable is to boot from cd/dvd and to keep the registry (in case of
> > m$-win) - or other files requiring write access - inside of a ramdrive.
> > Works.
>
> I think the idea is really nice, tried to convince some people employed
> by the Swedish army about this two years ago. The Swedish army is very
> picky about classified data and if a computer ever gets near classified
> information the machine has to be marked as classified and then the
> entire machine has to be handled very strictly. Booting from cdrom is
> simple and effective.
>
> Do you have any pointers how to do this with Windows (2k/XP) ?

http://www.nu2.nu/pebuilder/

Paul

Re: [Qemu-devel] building a virus-proof PC with Qemu

[Piotras]

Hi!

In fact I thought about the idea in context of military/classified
environment. However the technology could be interesting to 
large corporations as well. Especially that Qemu performance 
may justify this in not-so-distant future.

The technology could be transparent to the operating system 
(build into qemu-softmmu). I don't see why this shouldn't work 
with Windows. The "trusted" flag is not visible for the guest 
(it's stored in "hidden" part of qemu disk image, "hidden" 
registers, and "hidden" RAM area). The flag could be handled 
transparently by Qemu, except that when trying to execute 
"untrusted" code it could just generate illegal opcode exception.

The extension to the original idea could be to trace sensitive 
(classified) data to for example block all ethernet frames that 
may contain sensitive data from leaving the system.

How to mark data as "trusted"? There are many possibilities. 
For example when inserting CD-ROM we could have a checkbox
(handled by host) to mark all data read from CD-ROM as 
"trusted". Another possibility is to have a special utility running 
inside the guest that could tell Qemu that a given file (set of 
bytes on disk) contains classified data.


Regards,

Piotrek

On Tue, 23 Nov 2004 15:56:15 +0100, Magnus Damm <damm@opensource.se> wrote:
> Hello again,
> 
> On Tue, 2004-11-23 at 13:44, Bochnig, Martin wrote:
> > Hi,
> >
> > most of you know that: The easiest and most secure (100.00%) option
> > imaginable is to boot from cd/dvd and to keep the registry (in case of
> > m$-win) - or other files requiring write access - inside of a ramdrive.
> > Works.
> 
> I think the idea is really nice, tried to convince some people employed
> by the Swedish army about this two years ago. The Swedish army is very
> picky about classified data and if a computer ever gets near classified
> information the machine has to be marked as classified and then the
> entire machine has to be handled very strictly. Booting from cdrom is
> simple and effective.
> 
> Do you have any pointers how to do this with Windows (2k/XP) ?
> 
> Thanks!
> 
> / magnus

Re: [Qemu-devel] building a virus-proof PC with Qemu

[Bochnig, Martin]

Piotras wrote:

>
>How to mark data as "trusted"? There are many possibilities. 
>For example when inserting CD-ROM we could have a checkbox
>(handled by host) to mark all data read from CD-ROM as 
>"trusted". Another possibility is to have a special utility running 
>inside the guest that could tell Qemu that a given file (set of 
>bytes on disk) contains classified data.
>  
>

Hi,

sorry, but why don't you use/recommend Trusted Solaris (SPARC and i386)
http://wwws.sun.com/software/solaris/trustedsolaris/   ?
I hardly doubt that it will be too easy for anyone to clone the security 
mechanisms it provides.


Regards,
Martin

Re: [Qemu-devel] building a virus-proof PC with Qemu

[Karl Magdsick]

> sorry, but why don't you use/recommend Trusted Solaris (SPARC and i386)
> http://wwws.sun.com/software/solaris/trustedsolaris/   ?
> I hardly doubt that it will be too easy for anyone to clone the security
> mechanisms it provides.

I agree that making the operating system role-aware seems like a much
more tractable solution than trying to externally trace data flows. 
An external system would have to be extremely intelligent in order to
work out the Pi calculus from observing data and low-level CPU
operations. It is even more difficult to determine which information
flows are technically compromising information, but are generally
accepted as "safe". Classified processes will often block on file
descriptors, which will lead to a thread yielding, and a context
switch, perhaps to a non-classified process.  This represents a
leakage of information, but one that is generally considered
acceptable.  On the other extreme, a simple scan through memory will
not detect passwords being sent over an SSL connection.  A simple scan
also will not detect SHA-256 sums of passwords being transferred to
untrusted processes via shared memory.  It's a VERY complicated
problem.

That being said, a system capable of tracking data flows throughout a
system could be useful as a backup to secure operating systems.  For
instance, before Trusted Solaris was realeased a third party made a
hardware firewall product based on x86 Solaris with third-party kernel
modifications very similar to Trusted Solaris.  The Last Stage of
Dementia people were able to leverage a Solaris kernel vulnerability
that allowed arbitrary users to install arbitrary call gates.  Very
skilled coding allowed them to leverage this vulnerability to
completely bypass all OS security measures by modifying kernel data
structures related to tracking permissions (and win a large cash prize
the vendor offered in an attempt to gain publicity for the firewall's
"unbreakable" security).

There are other products that are very similar to Trusted Solaris. 
Security Enhanced Linux (SELinux), developed by the US National
Security Agency.  It also implements role-based mandatory access
security.  There's a neat demo where they run a vulnerable version of 
Apache as root and watch people break in to the machine, but the
attackers aren't able to do anything b/c the role being used doesn't
even allow outgoing TCP connections or reading files outside of the
Apache directory.

TrustedBSD works similarly to SELinux and Trusted Solaris.  I think
TrustedBSD is based on FreeBSD, however my only knowledge of
TrustedBSD comes from the SELinux mailing list.

The Common Criteria certified version of Trusted Solaris used to cost
an arm and a leg.  I'm not sure how much it costs now.  The main
reason to use Trusted Solaris is that you are doing work under a
government contract that requires a given level of Common Criteria
certification.  If you're only looking for role-based mandatory access
controls, you probably want to look at SELinux and TrustedBSD.


-Karl

Re: [Qemu-devel] building a virus-proof PC with Qemu

[Magnus Damm]

On Tue, 2004-11-23 at 23:41, Karl Magdsick wrote:
> > sorry, but why don't you use/recommend Trusted Solaris (SPARC and i386)
> > http://wwws.sun.com/software/solaris/trustedsolaris/   ?
> > I hardly doubt that it will be too easy for anyone to clone the security
> > mechanisms it provides.
> 
> I agree that making the operating system role-aware seems like a much
> more tractable solution than trying to externally trace data flows. 
> An external system would have to be extremely intelligent in order to
> work out the Pi calculus from observing data and low-level CPU
> operations.

Extremely intelligent? The theory seems pretty simple to me.
Maybe we are talking about different things?

What about this: Analyze the code block that is translated from
guest-instructions to micro operations. If any of the guest-instructions
are data that is either unmodified untrusted data or data that is the
result of any operation involving untrusted data, then create a block of
illegal instructions. Or handle the violation in a smarter way.

This assumes that it is to possible mark RAM bytes as untrusted, and a
code flow analyzer keeping track if resources (registers, flags) contain
trusted or untrusted data. Maybe something like this:

http://lists.gnu.org/archive/html/qemu-devel/2004-08/msg00285.html

/ magnus

Re: [Qemu-devel] building a virus-proof PC with Qemu

[Andreu Escudero]

Seems absurd to me...
Haw will you now if a byte comes from a "trusted source"?
And if you know what is a trusted source and what is not... you don't
need anything like extrange imformation propagation...



On Tue, 23 Nov 2004 13:31:59 +0100, Piotras <piotras@gmail.com> wrote:
> Hi!
> 
> Imagine that with every byte stored on disk image, the emulated
> memory and CPU registers we associate a flag indicating if the
> byte come from "trusted" source. This information would propagate
> with every memory/disk access (data-flow tracking).
> 
> Before Qemu would translate a block of code the trusted bits could
> be checked to see if the code is "trusted". Of course there are
> issues with dynamic loaders, dynamic compilers, etc. And it's not
> going to work well with scripted code.
> 
> Possible usage:
>   * building virus-proof PC,
>   * automate hunting for worms/exploits on Internet.
> 
> Opinions?
> 
> Piotrek
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 


-- 
Das Experimental Kunstwerk

Re: [Qemu-devel] building a virus-proof PC with Qemu

[Philipp Gühring]

[-- Attachment #1: Type: text/plain, Size: 513 bytes --]

Am Dienstag, 23. November 2004 13:46 schrieb Andreu Escudero:
> Seems absurd to me...
> Haw will you now if a byte comes from a "trusted source"?

I can´t say for sure, whether a byte comes from a trusted source.
But I have a way so say for sure where an evil byte comes from.

By the way, someone already did that successfully for Bochs.
Having it for qemu would be really great, because the performance gain would 
make it possible to use it for real-life systems!

Many greetings,
Philipp Gühring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Qemu-devel] building a virus-proof PC with Qemu

[Magnus Damm]

On Tue, 2004-11-23 at 14:41, Philipp Gühring wrote:
> Am Dienstag, 23. November 2004 13:46 schrieb Andreu Escudero:
> > Seems absurd to me...
> > Haw will you now if a byte comes from a "trusted source"?
> 
> I can´t say for sure, whether a byte comes from a trusted source.
> But I have a way so say for sure where an evil byte comes from.

So, you mean that each input device in the system emulator could be
marked as trusted or untrusted, and the data from untrusted input
sources is kept track of. Any calculations that use untrusted in-data
results in untrusted out-data. But then what do we do with the all the
untrusted data? Refuse to store it? Or just limit the network bandwidth
for untrusted data to cope with worms?

/ magnus

Re: [Qemu-devel] building a virus-proof PC with Qemu

[Paul Brook]

On Tuesday 23 November 2004 12:31, Piotras wrote:
> Hi!
>
> Imagine that with every byte stored on disk image, the emulated
> memory and CPU registers we associate a flag indicating if the
> byte come from "trusted" source. This information would propagate
> with every memory/disk access (data-flow tracking).
>
> Before Qemu would translate a block of code the trusted bits could
> be checked to see if the code is "trusted". Of course there are
> issues with dynamic loaders, dynamic compilers, etc. And it's not
> going to work well with scripted code.

I'd expect you could do most of this on real hardware with the NX bit. You're 
going to need OS support in either case, so AFAICS all your qemu hack gives 
you is finer granularity (per-byte rather than per-page).

Paul