wayner@kama.cs.cornell.edu (Peter Wayner) (12/07/90)
This was posted today to the comp.risks newsgroup. Anyone with a slab care to check this out? ------------------ Date: Tue, 27 Nov 90 12:56 EDT From: "E. Loren Buhle, Jr. [215-662-3084]" <BUHLE@xrt.upenn.edu> Subject: NeXT microphone problem? THIS MESSAGE DEALS WITH A POSSIBLE "RISK" PERTAINING TO CONTROL OF THE INTEGRAL MICROPHONE IN THE LATEST NeXT MACHINE. FIRST, SOME DESCRIPTION: The newest NeXT machine has a microphone in the lower left portion of the CRT console (embedded in the plastic frame of the CRT). This integral microphone is an important input device for the voice annotation software running on the NeXT. It comes with all new NeXT machines. The software interface on the NeXT presents the user with keys corresponding to a tape recorder (e.g. record, stop, rewind, play, etc.). The user hits the record button, speaks for any length of time, hits stop, rewind, play and hears the conversation that was recorded to a disk file (and played back) . . . . very nice touch! The operating system on the NeXT machine is Mach UNIX, a multiuser environment. NOTHING APPEARS TO PREVENT REMOTE OPERATION OF THE MICROPHONE. There is NO INDICATION ON THE FRONT OF THE NeXT MACHINE THAT THE MICROPHONE IS LIVE OR DEAD! (Remember Ronald Reagan's problems with "supposedly dead" microphones?) Here is a scenario: A remote user turns on the microphone on the NeXT, recording the voice to a file (locally or remotely). Any sound in the proximity of the NeXT CRT is recorded. This file containing the conversation is then played back on a remote NeXT. Voila, a built-in office bug! While it can be argued that control of the microphone is by the console, anyone with superuser privs can undoubtable find a workaround. On the old (1988 vintage) NeXT box, the microphone was plugged into a jack on the back. Unplugging the microphone removed this problem. Cumbersome, but very effective. The new microphone is built into the CRT case. It is not trivial to detach/attach at will. So what can be done? One possibility would be to have a physical LED turn on whenever the microphone was active. This LED would be physically wired to the microphone and NOT be under program control. This possibility assumes the people carrying on the conversation are looking at the NeXT console. . . . Thoughts? Dr. E. Loren Buhle, Jr. INTERNET: BUHLE@XRT.UPENN.EDU University of Pennsylvania School of Medicine Phone: 215-662-3084 Rm 440A, 3401 Walnut St., Philadelphia, PA 19104-6228 FAX: 215-349-5978 Peter Wayner Department of Computer Science Cornell Univ. Ithaca, NY 14850 EMail:wayner@cs.cornell.edu Office: 607-255-9202 or 255-1008 Home: 116 Oak Ave, Ithaca, NY 14850 Phone: 607-277-6678
louie@sayshell.umd.edu (Louis A. Mamakos) (12/08/90)
In the 2.0 software, there is a new preferences item called something like "Public Sound Port" or some such. It is similar to the "Public Window Server" switch. Presumably, when you turn this off, the sound port is not accessable other than on the local machine. louie
Eric.Thayer@cs.cmu.edu (Eric H. Thayer) (12/08/90)
In article <1990Dec7.171128.1761@ni.umd.edu> louie@sayshell.umd.edu (Louis A. Mamakos) writes: > In the 2.0 software, there is a new preferences item called something like > "Public Sound Port" or some such. It is similar to the "Public Window Server" > switch. Presumably, when you turn this off, the sound port is not accessable > other than on the local machine. If you are still paranoid about interlopers, you could implement a program which acquires sound in. If you implement a negotiation function, you could release sound in when it was requested and have some notification signal (e.g. flaming ears dancing around the NeXT icon :-) during the time that the application did not have sound in acquired. You could probably bribe a NeXT guru to do it for some pizza or Coke. ---------------------------------- Replies can have NeXT attachments in them Phone: (412)268-7679
whelan@donald.wslab.Hawaii.Edu (The Obscure Guru) (12/08/90)
In article <49464@cornell.UUCP> wayner@kama.cs.cornell.edu (Peter Wayner) writes:
=> NOTHING APPEARS TO PREVENT REMOTE OPERATION OF THE MICROPHONE. There is NO
=> INDICATION ON THE FRONT OF THE NeXT MACHINE THAT THE MICROPHONE IS LIVE OR
=> DEAD! (Remember Ronald Reagan's problems with "supposedly dead" microphones?)
I believe this came up last summer. Someone stated that the
new slabs have something akin to the "public window server" option
in preferences for the microphone control. As a simple hardware
solution one could always plug a dud plug into the microphone
input on the back, as using that jack disables the built in
microphone.
--
-------------------------------------------------------------------------------
"I'm not sure what I mean, so I'm going to listen to what I say."
whelan@ (uhunix.uhcc.hawaii.edu || uhunix.BITNET || nextsrv.wslab.hawaii.edu)edwardm@hpcuhd.HP.COM (Edward McClanahan) (12/08/90)
Louis A. Mamakos writes: > In the 2.0 software, there is a new preferences item called something like > "Public Sound Port" or some such. It is similar to the "Public Window Server" > switch. Presumably, when you turn this off, the sound port is not accessable > other than on the local machine. Correct me if I am wrong, but doesn't "disabling" Public Window Server merely prevent processes running on other NeXT's (etc...) from openning the display on my local NeXT and posting a window to it? I suspect that Public Sound Port works the same way. Neither of these "settings" prevents the case where the snooper on a remote machine "logs in" to my NeXT and runs a process on my NeXT which attaches to the display or the microphone. I think this is the situation that the original poster felt there no defense for. For me, I don't intend on letting others run programs on my machine (:-)). =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Edward McClanahan Hewlett Packard Company -or- edwardm@cup.hp.com Mail Stop 42UN 11000 Wolfe Road Phone: (480)447-5651 Cupertino, CA 95014 Fax: (408)447-5039
wiml@milton.u.washington.edu (William Lewis) (12/08/90)
In article <10548@uhccux.uhcc.Hawaii.Edu> whelan@donald.wslab.Hawaii.Edu (The Obscure Guru) writes: >In article <49464@cornell.UUCP> wayner@kama.cs.cornell.edu (Peter Wayner) writes: > I believe this came up last summer. Someone stated that the >new slabs have something akin to the "public window server" option >in preferences for the microphone control. As a simple hardware >solution one could always plug a dud plug into the microphone >input on the back, as using that jack disables the built in >microphone. Indeed. I just played with a 68040 slab (monochrome, alas) demo unit this afternoon and Pref now has a switch for "Public Sound Port" or some such. By default, disabled. Of course, nothing prevents you from doing exactly this on an *old* 1.0 machine, which is a cause of endless *ahem* merriment around here... fortunately, people rarely leave microphones lying around plugged into their NeXTs. =8) -- wiml@milton.acs.washington.edu Seattle, Washington (William Lewis) | 47 41' 15" N 122 42' 58" W "These 2 cents will cost the net thousands upon thousands of dollars to send everywhere. Are you sure you want to do this?"
absinthe@milton.u.washington.edu (Daniel 'B' Faken) (12/09/90)
In article <12600@milton.u.washington.edu> wiml@milton.u.washington.edu (William Lewis) writes: > > Indeed. I just played with a 68040 slab (monochrome, alas) demo unit this >afternoon and Pref now has a switch for "Public Sound Port" or some such. >By default, disabled. > Of course, nothing prevents you from doing exactly this on an *old* >1.0 machine, which is a cause of endless *ahem* merriment around here... >fortunately, people rarely leave microphones lying around plugged into >their NeXTs. =8) > As I remember, the reply to the thread last summer was that the new 'Sound Boxes' (that include outputs for speakers, etc.) have a PHYSICAL switch to turn off the microphone.... I suppose you could write something to acquire the microphone input's port and feed them messages like "We've been waiting for you, <suspected person>" :) [including file: /altdimension7/'heaven'/God/Christian/.signature...] ----------------------------------------------------------------------------- Faithfully and unerringly saving our civilization from certain demise.. absinthe@milton.u.washington.edu | "Don't get Odd, get Even" ------------------------------------------------------------------------------ The opinions (and/or facts) expressed herein may represent most of the student body and administratium here at the UW. But then again, they may not.
scott@next-5.gac.edu (Scott Hess) (12/10/90)
In article <12634@milton.u.washington.edu> absinthe@milton.u.washington.edu (Daniel 'B' Faken) writes:
As I remember, the reply to the thread last summer was that
the new 'Sound Boxes' (that include outputs for speakers, etc.) have
a PHYSICAL switch to turn off the microphone....
But, can sounds boxes be used in a monochrome system? I would
suspect not, but what do I know . . .
I suppose you could write something to acquire the microphone input's
port and feed them messages like "We've been waiting for you, <suspected
person>" :)
Even better, you could use the DSP and appropriate sampling and create
a version of your boss singing the theme to "For Your Eyes Only". That
should confuse 'em . . .
--
scott hess
scott@gac.edu
Independent NeXT Developer (Stuart)
GAC Undergrad (Horrid. Simply Horrid. I mean the work!)
<I still speak for nobody>
Tried anarchy, once. Found it had too many constraints . . .bb@condo.cis.ufl.edu (Brian Bartholomew) (12/11/90)
In article <49464@cornell.UUCP> wayner@kama.cs.cornell.edu (Peter Wayner) writes: > Here is a scenario: A remote user turns on the microphone on the NeXT, > recording the voice to a file (locally or remotely). Any sound in the > proximity of the NeXT CRT is recorded. This file containing the > conversation is then played back on a remote NeXT. Voila, a built-in > office bug! I personally have been waiting nearly a year for someone to write "Bearcat.app". You know, like the shortwave scanner of the same name. It would put up a window with a couple rows of sequentially blinking lights corresponding to machines on a local network, and scan through all of them once every second or two. Every time a sound from a machine rose past a certain threshold ("broke squelch"), it would stop scanning, play the sound, and log it to disk. With the new color machines, the lights could even be the proper shade of red LED. 1/2 :-) -- "Any sufficiently advanced technology is indistinguishable from a rigged demo." ------------------------------------------------------------------------------- Brian Bartholomew UUCP: ...gatech!uflorida!mathlab.math.ufl.edu!bb University of Florida Internet: bb@math.ufl.edu
mcguire@cs.tamu.edu (Tim McGuire) (12/12/90)
NeXTologist wayner@kama.cs.cornell.edu (Peter Wayner) writes: > Here is a scenario: A remote user turns on the microphone on the NeXT, > recording the voice to a file (locally or remotely). Any sound in the > proximity of the NeXT CRT is recorded. This file containing the > conversation is then played back on a remote NeXT. Voila, a built-in > office bug! This is indeed a security hole under the present system. NeXT has been aware of this for some time, and steps are being taken to eliminate the problem. Briefly: the use of the speaker and microphone will be limited to the user logged on to the console. This will also eliminate my ability to "haunt" my friends machines by playing sound files :-( (Hello, Eldon!) Tim McGuire mcguire@cs.tamu.edu
louie@sayshell.umd.edu (Louis A. Mamakos) (12/14/90)
In article <108170004@hpcuhd.HP.COM> edwardm@hpcuhd.HP.COM (Edward McClanahan) writes: >Correct me if I am wrong, but doesn't "disabling" Public Window Server merely >prevent processes running on other NeXT's (etc...) from openning the display >on my local NeXT and posting a window to it? I suspect that Public Sound Port >works the same way. Yes, I presume that it prevent access via the Mach network messaging facility which make inter-machine Mach messaging look transparent. > Neither of these "settings" prevents the case where the >snooper on a remote machine "logs in" to my NeXT and runs a process on my NeXT >which attaches to the display or the microphone. Well, I just assumed that it was pretty obvious that if you were concerned about this type of "security", that you wouldn't let any random "snooper" log into your machine. > I think this is the situation >that the original poster felt there no defense for. For me, I don't intend on >letting others run programs on my machine (:-)). louie
eps@toaster.SFSU.EDU (Eric P. Scott) (12/15/90)
In article <108170004@hpcuhd.HP.COM> edwardm@hpcuhd.HP.COM (Edward McClanahan) writes: >Correct me if I am wrong, but doesn't "disabling" Public Window Server merely >prevent processes running on other NeXT's (etc...) from openning the display >on my local NeXT and posting a window to it? I suspect that Public Sound Port >works the same way. Neither of these "settings" prevents the case where the >snooper on a remote machine "logs in" to my NeXT and runs a process on my NeXT >which attaches to the display or the microphone. Well, at least as far as 1.0/1.0a go, WRONG!!! If Public Window Server is disabled, only descendents of loginwindow (and npd) get in. Someone who "logs in from a remote machine" most assuredly DOES NOT (without becoming superuser, and even then it takes effort)--they simply do not have access rights. I can't imagine NeXT relaxing this in 2.0, but I haven't actually tried. -=EPS=-