Stephen Dennis (sdennis@svdltd.com)
Sun, 5 Apr 1998 23:27:36 -0700
Ok, I'll bite.
I. Linux is a hotfix for Windows 95? Umm...there is this Windows NT
thing you might want to look at.
Windows NT won't let one application get it's hooks into another that
easily. The ways of doing it are the same as Linux: Boot disk,
administrator lets you, debug an application, permissions on files, etc.
I think you should have been comparing Linux to Windows NT.
In Windows 95, you can capture the screen. In Windows NT, you can only
capture the windows that you own. In Windows 95, memory protection is
designed primarily to keep applications from -accidentally- stepping on
each other's toes. If you really want to get a dump of another
application, it's easy -- in a 16-bit application, construct a FAR
pointer and allocate/initialize it's descriptor or just use one of the
ones already there. 32-bit applications are even simpler. The network
stuff is appropriately wary, but Windows 95 and it's predecessors have
always given applications that are already running on your machine the
benefit of the doubt. If you installed it and ran it, it must be
something you trust with -all- of your machine. If there are bugs,
Windows 95 is more able than its predecessors to shut the buggy
application down without bringing the other applications down with it,
but it doesn't even try to prevent a malicious application.
II. You left out the problem of how this malicious program would start
running on your machine in the first place?
In general, how do you decide when to run someone else's code on your
machine?
a. Java-style: put it into a padded room and let it trash itself
and everything else in the room..hoping that the room doesn't have any
holes.
b. Application/component-style: signatures so that if anything bad
does happen, at least you know who to start a class action lawsuit
against.
Of course, there are pros and cons to both: A perfectly safe padded-room
may not be particular useful in all the ways traditional applications
are. A java word processor would need the ability of either: reading
files on your hard drive (security risk), -or- face the performance
penalty of storing those files on the server (who already has your
credit card number because you are paying them for server space or for a
service that includes server space).
On the other hand, a signature approach doesn't even try to -guarantee-
that nothing bad will happen ... only that if something bad does happen,
you know who is liable. And of course, liability is only useful when you
have a country with fairly good access to adjudication, and now I think
I've stepped over the line between the technical discussions here and a
more general crypto-political-policy discussion which should rightfully
be elsewhere.
On Tuesday, April 07, 1998 8:06 PM, staym@accessdata.com
[SMTP:staym@accessdata.com] wrote:
> I'm not sure if this is appropriate for CodherPlunks; if not, sorry.
And
> please don't respond just to flame microsoft.
>
> Under windows 95, various hooks can be installed to intercept *any*
kind
> of message. The computer-based training hook can intercept the
> WM_CREATE message. If a password-box is created, the hook procedure
> could note it and poll it for its text, then write the information to
> disk (or do anything else it wanted) when the window is destroyed.
Same
> thing goes for edit boxes in web browsers: if one contains a
> sixteen-digit number, odds are it's a credit card number and the rest
of
> the information is in the boxes around it. All the crypto in the
world
> won't help if they can (effectively) watch you type in the information
> in the first place.
>
> Is there any defense to this sort of attack other than switching to
> Linux?
> --
> Mike Stay
> Cryptographer / Programmer
> AccessData Corp.
> mailto:staym@accessdata.com
The following archive was created by hippie-mail 7.98617-22 on Fri Aug 21 1998 - 17:16:51 ADT