Date: Sat, 2 Jun 2001 08:32:08 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.ORG> To: Kris Kennaway <kris@obsecurity.org> Cc: "Peter C. Lai" <sirmoo@cowbert.2y.net>, freebsd-security@FreeBSD.ORG Subject: Re: Apache Software Foundation Server compromised, resecured. (fwd) Message-ID: <Pine.NEB.3.96L.1010602082351.65702H-100000@fledge.watson.org> In-Reply-To: <20010601141916.A88206@xor.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 1 Jun 2001, Kris Kennaway wrote: > You should just accept the fact that it's not possible to run trusted > software in an untrusted environment, and if the system wants to > compromise your software badly enough they can. There have been some > interesting mathematical steps in this direction (involving computing of > a certain class of function which are "encrypted" but in an isomorphic > form, where the desired computation commutes with the operation of > encryption so the untrusted system can perform the computation without > knowing what it's doing) -- but nothing remotely usable. That work's very interesting, but as you say, I have yet to see anything indicating it can be used in a practical manner yet. There is, however, some ongoing research at NAI Labs on protecting mobile agents from the hosts that they execute on. The work has only just begun, but my understanding is that they're taking a number of approaches, including a replication/fault tolerant approach in which you run on a number of hosts and assume that not all will be malicious, performing distributed decision making/consistency checks to reduce the security failure scenario to a byzantine failure scenario. You can dig up a little (but not much) more at: http://www.pgp.com/research/nailabs/secure-execution/self-protecting.asp Of course, that scenario doesn't rely apply to the "hello, I'm on an untrusted and potentially malicious/compromised workstation". I recommend a Palm with serial IP and an SSH client or bringing your notebook :-). One-time passwords have the advantage of revocation, but won't help you with someone who is actively attacking and has the right tools. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1010602082351.65702H-100000>