[13461] in bugtraq
Re: Trusted process on an untrusted machine?
daemon@ATHENA.MIT.EDU (Pavel Machek)
Thu Jan 20 18:39:41 2000
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-Id: <20000120190339.C16932@atrey.karlin.mff.cuni.cz>
Date: Thu, 20 Jan 2000 19:03:39 +0100
Reply-To: Pavel Machek <pavel@SUSE.CZ>
From: Pavel Machek <pavel@SUSE.CZ>
X-To: Mike Frantzen <frantzen@expert.cc.purdue.edu>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <200001192100.QAA27523@expert.cc.purdue.edu>; from
frantzen@expert.cc.purdue.edu on Wed, Jan 19,
2000 at 04:00:36PM -0500
Hi!
> > > Some of ways an attacker could bypass this protection:
> > > Solution: There should be a LOCK pin on most processors that locks the
> > > memory bus. The kernel module can lock the bus and proceed to
> > > zero out all memory not used by the good kernels page tables.
> > No. You can't assume you know about all memory. (And I think LOCK does
> > not work the way you imagine it). Rogue second cpu could be hiding in
> > videoram of PCI card, for example.
>
> You shouldn't need to know about all the memory. Insert a TLB entry to map
> a page of virtual memory to the first page of physical memory. Zero it out.
> Proceed to zero out every physical page of memory. Who cares if there is a
> physical page there or not. You only have 4gb to go through. It may trash
> some device detection though.
BTW I forgot about trivial method to do this: put your rogue code into
boot-prom of your network card. It is quite easy to do, and you can't
zero ROM :-).
> > Remove heatsink from the cpu. Watch your "trusted" program do
> > single-bit errors from time to time. Have fun.
>
> Doh, I hadn't thought of that one ;)
This is really the worst of all, since it happens pretty often by
accidents. (You know, average live of cpu fan is 6 months or so.)
Pavel
--
The best software in life is free (not shareware)! Pavel
GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+
