[13466] in bugtraq
Re: Trusted process on an untrusted machine?
daemon@ATHENA.MIT.EDU (Pavel Machek)
Thu Jan 20 19:48:07 2000
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-Id: <20000119212309.C21802@atrey.karlin.mff.cuni.cz>
Date: Wed, 19 Jan 2000 21:23:09 +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: <200001181747.MAA13636@expert.cc.purdue.edu>; from
frantzen@EXPERT.CC.PURDUE.EDU on Tue, Jan 18,
2000 at 12:47:20PM -0500
Hi!
> Some of ways an attacker could bypass this protection:
> 4) Kernel wars! A SMP machine that boots an untrusted kernel. Have
> the APIC vector the attacking processor the timer interrupt then vector all
> other interrupts to the 'good' proc. The attacking proc then destroys
> the MP configuration table so the 'good' proc doesnt know it is an MP
> system. The attacking proc then tries to take over the system after X
> amount of time and steal the checksum/key.
> [It has been a few months since I've looked at x86 SMP]
> 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.
> 5) Hardware bus snooping. A PCI device on the memory bus to grab the
> checksum/key then give the key to another malicious machine.
> Solution: ???
[This is not really usefull attack, but it can be well used to screw
you]
Remove heatsink from the cpu. Watch your "trusted" program do
single-bit errors from time to time. Have fun.
Pavel
--
GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+
