From owner-freebsd-security Wed Mar 6 19:53:54 2002 Delivered-To: freebsd-security@freebsd.org Received: from mired.org (dsl-64-192-6-133.telocity.com [64.192.6.133]) by hub.freebsd.org (Postfix) with SMTP id 938AD37B417 for ; Wed, 6 Mar 2002 19:53:12 -0800 (PST) Received: (qmail 81467 invoked by uid 100); 7 Mar 2002 03:53:11 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15494.58407.33613.314390@guru.mired.org> Date: Wed, 6 Mar 2002 21:53:11 -0600 To: Terry Lambert Cc: Mike Meyer , Peter Leftwich , Miguel Mendez , Cliff Sarginson , freebsd-security@FreeBSD.ORG, chat@FreeBSD.ORG Subject: Re: http://users.uk.freebsd.org/~juha/ In-Reply-To: <3C86D7D6.C11D7E@mindspring.com> References: <20020306191854.C2150-100000@earl-grey.cloud9.net> <3C86C11C.8A31C8BB@mindspring.com> <15494.52528.125952.145716@guru.mired.org> <3C86D7D6.C11D7E@mindspring.com> X-Mailer: VM 6.90 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ From: "Mike Meyer" X-Delivery-Agent: TMDA/0.48 (Python 2.2 on freebsd4) Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Terry Lambert types: > Mike Meyer wrote: > > While Heisenberg's uncertainty doesn't apply as described to macro > > events, the concept certainly works. If you instrument a kernel to > > find performance problems, you've just slowed the kernel down, and > > changed what routines get used when. And I'm sure we've all had the > > experience of adding a print to try and catch a bug, and the bug > > vanishes. > This only happens if you don't know what you are doing. > It's very easy to do instrumentation which subtracts > itself out of the overall count, if the instrumentation > is for profiling. For debugging of timing sensitive > problems, you have to use non-invasive techniques in > order to avoid changing the timing. It isn't rocket > science. Of course it's not rocket science. It's computer science. You haven't got it right yet. To make sure you're not changing the paging behavior of the system, you can't use any memory on the system, meaning you have to be watching it on a hardware monitor. And even that isn't good enough in all cases. I had bugs in horizontal microcode that the extra timing to grab the trace information hid, because the time used to sample the lines allowed the bus to settle before the next subword executed, so it read the correct values when run that way, but read random values run at full speed. > As to the idea that the observer always changes the thing > being observed, that's silly. It's only true if the > observer isn't copetent, until you get down to the quantum > level. I'll grant you that a sufficiently careful observer can probably get away without changing what's being observed above the quantum level. I wouldn't guarantee it until someone conclusively disproves the Bell hypothesis. If you are a careful enough hacker that you don't even leave footprints on the instruction trace of the machine you're breaking into, I'll grant you're probably not a cracker. I also want to know how you did it. > > Given that computers are so blasted cheap these days, and the > > availability of open source software, there's a lot of learning that > > can be done without stealing cycles from someone else. > Actually, the use of individual equipment is one of the > things that's wrong with todays CS classes. If you do > your work on your own machine at home, rather than using > shared resources, you never learn to "play nice" with > other software on the system that you didn't plan on. > It's one of the reasons Windows Systems are so fragile > these days, when programs from different vendors are loaded > on them: the programmers responsible never had to learn > to "play nice with the other kids". Can't argue with that. I'd place it right behind sharing code being considered cheating in school as a problem. But we're talking about people breaking into computers to ostensibly "learn things". Given that they can buy a used computer for a lot less than a used car, if not get them for free when their parents upgrade, why are they breaking into other people systems? > > No, they'll just slow them donw, possibly screw up the accounting, and > > similar things that can make peoples lifes miserably. Read the book by > > the guy at LBL who helped track down a couple of crackers, even though > > they mostly used a "look but don't touch" methodology on his > > computers. His web site seems to be gone, or I'd send over there to > > order a Kleine bottle from him as well. > You mean Clifford Stoll's "The Cuckoo's Egg: Tracking a Spy > Through the Maze of Computer Espionage", in which he used > non-invasive observational teqniques that did not impact > what he was observing? 8-). Yes, that's the book. And what he did wasn't non-invasive, it was just below the level of the people breaking into his system noticed. > PS: The people he was writing about in "The Cuckoo's Egg" > we definitely not just observers... True. They were hopscotching to another system. But the clue that started him on the case was simply cycles that hadn't been accounted for. So even if they had done nothing more than look around for $.75 cents worth of cpu time (about 10 minutes back then), he would have noticed them. http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message