|
|
ARCHIVE: Rutgers 'Security List' (incl. misc.security) - Archives (1990)
DOCUMENT: Rutgers 'Security List' for February 1990 (104 messages, 48187 bytes)
SOURCE: http://securitydigest.org/exec/display?f=rutgers/archive/1990/02.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.
START OF DOCUMENT
-----------[000000][next][prev][last][first]---------------------------------------------------- Date: 1 Feb 90 00:25:00 GMT From: CJS@cwru.BITNET To: misc.security Subject: DDN Security Bulletin 90-01
Just thought you all might find this of interest.
***********************************************************************
DDN Security Bulletin 90-01 DCA DDN Defense Communications System
25 Jan 90 Published by: DDN Security Coordination Center
(SCC@NIC.DDN.MIL) (800) 235-3155
DEFENSE DATA NETWORK
SECURITY BULLETIN
***********************************************************************
SECURITY VIOLATION REPORTING
a. Initial Notification. Any DDN user (person/department/agency)
having knowledge of a suspected network security violation must
contact the appropriate Defense Communications Agency OC/ACOC
(Operations Center/Area Communications Operations Center) to report
the violation. If possible, reporting should be via secure means.
Secure and commercial telephone numbers to DCA Operations Centers are:
WESTHEM/CONUS OC has KY3-2222; STU III (DSN) 312-746-1849;
(COMM) 202-692-5726/2268 or 1-800-451-7413.
PACIFIC ACOC has STU III (DSN) 315-456-2777; (COMM) 808-656-2777.
EUROPEAN ACOC has KY3-6429; STU III (DSN) 314-430-5703;
(COMM) 49-0711-680-5703.
The SCO or MC supervisor will request the following information:
(1) Identity of caller:
-What is caller's name and phone number
-Where is caller calling from (organization)
-Where is caller calling from (city & state)
-What is the caller's DDN network address
(2) Details about the incident:
-When did the violation occur
-What happened
-How did the violation occur (if known)
-What damage was done
-What has the subscriber done about the violation
-What networks are they connected to
-What software is being used - Version
-How many subscribers are known to be affected
-How many subscribers are vulnerable (if known)
-Who else has been notified - Names & phone
numbers
(3) Anything else the caller wishes to report
Once a suspected violation is reported and the above
information collected, the PACIFIC and EUROPEAN ACOCs will
immediately relay this information back to the DCAOC
(WESTHEM/CONUS) for action.
b. Follow-on Network Information via the Security Coordination
Center. DCA, through direction provided by the DDN Network Security
Officer (NSO), will provide rapid and reliable follow-on information
on security exposures, fixes, and concerns via the SCC. Distribution
of information is accomplished via DDN Security Bulletins. Network
security and management personnel are encouraged to pay close
attention to these bulletins as they may be of great assistance either
in preventing network security problems or in solving existing
problems. DDN Security Bulletins will be published on as "as needed"
basis.
Note: this bulletin starts a new numbering scheme for DDN Security
Bulletins. From now on, all bulletin numbers, including those of
previously issued bulletins, will follow the form YY-NN, where YY is
the year the bulletin is issued and NN is the number of the bulletin
for that year. Thus, this is DDN Security Bulletin 90-01; it is
online at NIC.DDN.MIL as SCC:DDN-SECURITY-90-01.
-----------[000001][next][prev][last][first]---------------------------------------------------- Date: Thu, 1 Feb 90 13:06:39 PST From: faigin@aerospace.aero.org To: security@rutgers.edu Subject: Call for Papers --> 6th Annual Computer Security Applications Conf.
CALL FOR PAPERS AND PARTICIPATION
Sixth Annual Computer Security
Applications Conference
December 3-7, 1990
Tucson, Arizona
The Conference
Operational requirements for civil, military, and
commercial systems increasingly stress the necessity for
information to be readily accessible. The Computer Security
Act of 1987 requires that all Federal agencies take certain
actions to improve the security and privacy provided by
federal computer systems. Accomplishing both operational and
security requirements requires the application of the
maturing technology of integrated information security to new
and existing systems throughout their life cycle.
This conference will explore technology applications for
both civil and military systems; the hardware and software
tools and techniques being developed to satisfy system
requirements; and specific examples of systems applications
and implementations. Security policy issues and standards
will also be covered during this five day conference.
Papers, Tutorials, and Vendor Exhibits
Technical papers and tutorials that address the
application of integrated information security technologies
in the civil, defense, and commercial environments are
solicited. Original research, analyses and approaches for
defining the computer security issues and problems identified
in the Conference's interest areas; secure systems in use or
development; methodological approaches for analyzing the
scope and nature of integrated information security issues;
and potential solutions are of particular interest. We are
also interested in vendor presentations of state-of-the-art
information security products.
INSTRUCTIONS TO AUTHORS:
Send five copies of your paper or panel proposal to Dr.
Ronald Gove, Program Chairman, at the address given below.
Tutorial proposals should be sent to Dr. Dixie Baker at the
address given below. We provide "blind" refereeing; put
names and affiliations of authors on a separate cover page
only. It is a condition of acceptance that manuscripts
submitted have not been published. Papers that have been
accepted for presentation at other conferences should not be
submitted.
Papers and tutorial proposals must be received by May 18,
1990. Authors will be required to certify prior to June 20,
1990, that any and all necessary clearances for publication
have been obtained, that they will attend the conference to
deliver the paper, and that the paper has not been accepted
elsewhere. Authors will be notified of acceptance by July
30, 1990. Camera ready copies are due not later than
September 19, 1990. Material should be sent to:
Dr. Ronald A. Gove Dr. Dixie B. Baker
Technical Program Chair Tutorial Program Chair
Booz-Allen & Hamilton Inc. The Aerospace Corporation
4330 East-West Highway P.O. Box 92957, MI/005
Bethesda, MD 20814 Los Angeles, CA 90009
(301) 951-2395 (213) 336-7998
Gove@dockmaster.ncsc.mil baker@aerospace.aero.org
Areas of Interest Include:
GOSIP C3I Systems
ISO/OSI Security Architecture Policy and Management Issues
Advanced Architectures SDNS
Trusted DBMSs and Operating Risk/Threat Assessments
Systems Network Security
Public Law 100-235 Medical Records Security
Current and Future Trusted State-of-the-Art
System Technology Trusted Products
Space Station Requirements Certification, Evaluation, and
Accreditation
Reviewers and Prospective Conference Committee Members
Anyone interested in participating as a reviewer of the
submitted papers, please contact Dr. Ron Gove at the address
given above. Those interested in becoming members of the
conference committee should contact Dr. Marshall Abrams at
the address below.
Additional Information
For more information or to receive future mailings,
please contact the following at:
The MITRE Corporation Marshall Abrams
7525 Colshire Drive Conference Chairman
McLean, VA 22102 (703) 883-6938
abrams@mitre.org
Diana Akers or Victoria Ashby
Publicity and Publication Chairs
(703) 883-5907 or (703) 883-6368
akers%smiley@gateway.mitre.org
ashby%smiley@gateway.mitre.org
-----------[000002][next][prev][last][first]---------------------------------------------------- Date: Thu, 1 Feb 90 15:14 CST From: david paul hoyt <YZE6041@vx.acs.umn.edu> To: security@pyrite.rutgers.edu Subject: RE: Request for help
> I would like to know the titles of a few books I would recommend browsing through the papers from the 'IEEE Symposium on Security and Privacy.' There are good survey articles, as well as more vertical papers. The (delivered) papers are also an excellent source of references to other articles. david | dhoyt@vx.acs.umn.edu
-----------[000003][next][prev][last][first]---------------------------------------------------- Date: 1 Feb 90 22:20:20 GMT From: simsong@prose.cambridge.ma.us (Simson L. Garfinkel) To: misc.security Subject: Sequential allocation of resource handles
Sequential allocation of UIDs is not a problem (UIDs are allocated by the system administrator, not by the kernel). On a computer system with mixed security levels (ie: running both top-secret and unclassified processes), you could use the fact that seqeuntial pid's are allocated as a means of communication between a covert process at the top-secret classification level and an unclassified process. The covert sending process could fork 20 times (killing the parent) in a 10 second period to signify a '1', and fork not at all to indicate a '0'. To receive the bits (assuming that the 'ps' command is forbidden for security reasons), the receiving process could fork once (killing the parent), and then measure what the increment of its pid is, comparing it with the background increment. You could use an error correction scheme to improve reliability. Not the highest baud rate, but it is information transfer. I do not think that you could earn a B2 rating if you had this chanel open. Simson L. Garfinkel The Christian Science Monitor simsong@prose.cambridge.ma.us 617-450-2480
-----------[000004][next][prev][last][first]---------------------------------------------------- Date: 2 Feb 90 21:53:50 GMT From: faatzd@TURING.CS.RPI.EDU (Don Faatz) To: misc.security Subject: Re: Blown Card Key Unit
Another interesting aspect of card key systems is determining what they should do if power to them does fail. Usually it is undesirable to have them power off to unlocked because that blows security. On the other hand, a very scary thing happened to me at one job site - the power failed, the key locks powered off to LOCKED - but there was no way to UNLOCK the doors manually from inside. 100 people were locked INSIDE the 4th floor of an office building - all fire exits were OUTSIDE the locked doors. We were very secure - but not very safe...... < <Don Faatz - Systems Engineer, RPI CSLab faatzd@cs.rpi.edu (518)276-2860 <
-----------[000005][next][prev][last][first]---------------------------------------------------- Date: 2 Feb 90 22:34:20 GMT From: virtech!jje@uunet.uu.net (Jeremy J. Epstein) To: misc-security@uunet.uu.net Subject: Re: Request for help
Try "Cryptography & Data Security" by Dorothy Denning, (c) about 1982 (Addison Wesley, I think, but I'm not sure). An excellent introduction to the subject, with many good references. I took it as a course from Dorothy at Purdue, and was not disappointed! -- Jeremy Epstein TRW Systems Division 703-876-4202 jje@virtech.uu.net
-----------[000006][next][prev][last][first]---------------------------------------------------- Date: 5 Feb 90 14:24:43 GMT From: AZM@CU.NIH.GOV To: misc.security Subject: Re: criminal intelligence
> I often wonder if there are people who make a living
> as a criminal and we just do not know it.
Now you've got the idea. If they are smart, and successful, then they
are also annonymous. Smart criminals don't make mistakes, don't get
caught, and live very comfortable lives.
As a sidecar to the above, consider the intelligent, capable burglar.
He breaks into homes that contain valuable artifacts, and usually
steals only the most valuable items. How does the burglar know where
the good stuff is, and how does he know which are the most valuable
items? That's the sort of information only an insurance company, or
a police force, through its Operation ID, would have available.
Kokkor Hekkus
-----------[000007][next][prev][last][first]---------------------------------------------------- Date: Wed, 07 Feb 90 10:15:06 EST From: "Paul T. Winkfield" <PAUL@duvm.bitnet> To: security@pyrite.rutgers.edu Subject: Re: criminal intelligence
I notice the same thing that Jim had mentioned, what criminals take
advantage of are people/organizations who often do stupid things that
allow crimes to be committed ie: leaving car keys in car; open windows;
faulty audit practices, etc. Here in Philly there are known families who's
sole career is thief. Who is less intelligent; the drug seller or user?
I hate people who goes around yelling about intelligence levels of any group;
in my book; getting caught committing the crime is stupidity. Now everyone
say Watergate!!!
<I'm not a number; I'm a free man!> No6..The Prisoner
-----------[000008][next][prev][last][first]---------------------------------------------------- Date: Wed, 7 Feb 90 22:04:04 PST From: Cassius_Gaius_Longinus@cc.sfu.ca To: security@pyrite.rutgers.edu Subject: cordless privacy
I am no lawyer, but I think you ony need the consent of one of the parties in order to legally record a phone conversation - at least that is the case here in Canada. So, if it's ok for the LEA to tape the end being 'broadcasted', the 'right' extends to the other party, no? ~~~~ BITNET: usereaxe@sfu; INTERNET/ARPA: cassius_longinus@cc.sfu.ca UUCP: ...!ubc-cs!cc.sfu.ca!cassius_longinus If all else fails: CIS: 73040,2210; or a1254@mindlink.uucp Disclaimer:I work for myself. I stand behind my words! SO THERE! 'Cute' remark:"Every law is an infraction of liberty." -- Jeremy Bentham ~~~~
-----------[000009][next][prev][last][first]---------------------------------------------------- Date: Wed, 07 Feb 90 21:20 CST From: GREENY <MISS026@ecncdc.bitnet> To: <security@pyrite.rutgers.edu> Subject: Remote Alarm systems
> ...connect to a central office via phone lines... Nope, not any more. Now Ademco has a long range wireless xmitter (two way, or one way) which hooks up to your alarm system and can act as the stand alone transmission device or as a redundant circuit to the phone line connection. Basically, in the one way connection, the xmitter sits idle if not triggered and does nothing (except send in an ACK signal to tell the receiver at the central station "I'm Here, everything's cool"), until the alarm is triggered. When the alarm is triggered it sends the account #, and "popped" zone over the radio waves (about 900 MHz), and is repeated by local "nodes" till received by the CS.... The two way model is continously sending Acks back and forth to the CS, but has a 6 minute "drop out" window in case of intereference.....costs more to monitor per month, but is twice as secure.....something like a UL AA rating... bye for ow but not for long... Greeny
-----------[000010][next][prev][last][first]---------------------------------------------------- Date: Thu, 8 Feb 90 10:48:11 -0500 (EST) From: Thomas Neudecker <tn07+@andrew.cmu.edu> To: security@pyrite.rutgers.edu Subject: Caller ID
Recently I have been having some annoying people trying to breakin to a BBoard. This/these people come in via a modem. Now that Bell is providing caller id service in some areas I was wondering if I could capture the number of the caller and add it to the activity log I keep. Most of the normal caller id boxes only store the last three numbers so adding it would only be a partial solution. How does caller id work? Can the signal be captured via a modem? Is it prefixed to the first or to all packets? Tom Neudecker Carnegie Mellon
-----------[000011][next][prev][last][first]---------------------------------------------------- Date: Thu, 8 Feb 90 10:23:13 EST From: shz@packard.att.com (Seth Zirin) To: misc-security@att.att.com Subject: Re: cop detectors
>Would it be possible to build a police radio detector that detected >the emissions from the local oscillators of the radios? This would be pretty sophisticated gear. Police use several VHF and UHF bands and civilian radios operate within fairly close range of the police frequencies. Detecting police while ignoring tow trucks, buses and utility company radios would require selective detection of many frequency ranges on several bands. Seth Zirin
-----------[000012][next][prev][last][first]---------------------------------------------------- Date: Thu, 08 Feb 90 12:00:50 CST From: Ed finnell <EFINNELL@ua1vm.bitnet> To: security@pyrite.rutgers.edu Subject: Re: RACF databases on electronic disk
SSD stands for solid state device as opposed to spinning ferrous oxide. Think STK SSD are backed by spinning Winchesters or the like. Anybody who puts precious stuff on this type device is asking for big trouble. They break a lot. If they insist on doing this,I can only address paging and RACF. Should use as secondary paging only, newer levels of VM figure out which devices are responding and eventually start using "better thruput" devices. If used as primary can't IPL when they fail(and they will). Haven't seen a shop where RACF was a large enough bottleneck to risk this. Don't think they're even going to put RACF on them just some "look up" files. Cached devices like IBM 3880-23 or 3990-3 provide sufficient performance for RACF datasets on a "properly tuned" storage farm. This type of outage is a small concern to us, but valid. RACF runs a secondary database that we can switch to on the fly should we lose the primary RACF volume. We also make regular copies of the databases and could do standalone restores if required. Further, a new feature of the 3990 is dual write capability. That is while updating files on a volume the same files are updated on the clone. Should anything happen to primary, the clone automagically kicks in. Being of the conservative ilk, waiting to see who's tried this(successfully)
-----------[000013][next][prev][last][first]---------------------------------------------------- Date: Thu, 8 Feb 90 12:45 EST From: WHMurray@dockmaster.ncsc.mil To: security@rutgers.edu Subject: Answerback
>This is a purplexing problem ... why do manufacturers still >put an answerback buffer in computer terminals ... The complete answer to this question will have to await a day when I have more time. The short answer is that both de facto and de jure standards require it. Note also that there are more than ten milllion terminals and another ten million terminal emulators with this "feature" already deployed; nothing that the vendors do now is likely to have any effect on the exposure for a decade or more. William Hugh Murray, Fellow, Information System Security, Ernst & Young 2000 National City Center Cleveland, Ohio 44114 21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840
-----------[000014][next][prev][last][first]---------------------------------------------------- Date: Thu, 8 Feb 90 15:45 CST From: douglas@ddsw1.mcs.com (Douglas Mason) To: misc-security@rutgers.edu Subject: Credit Card Fraud...
Something interesting that I heard was going on at [eastern college] was that a couple of students were able to get a hold of a credit-card magnetic stip recorder somehow. They also stole purses, wallets, anything that they could get their hands on that had credit cards in it. After doing the above, they would dig through dumpsters (we all know that story) and pick up carbons or other receipts that have credit card numbers on them, and make a list of valid card numbers. Using the encoding machine, they then erased the old card number off of the magnetic strip (which had probably been reported stolen by this time) and encoded on that same strip one of the card numbers that they had picked up out of the dumpsters. So now they have say a MasterCard with an invalid number embossed on the front of it, and a different-but-valid account on the magnetic strip. What good is this? Plenty good for the clever thief! They then went into shopping malls or anywhere that the credit-card validation machines were the all-too-familiar "slide the card through and read the number off the mag strip" type. The merchant would authorize the card successfully and get an approval code, then run the card though and get a paper receipt. The merchants never check the card number on the authorization machine display and compare it to that of the card! When the merchants send in the credit card slips to the bank, they of course come back, and I imagine it takes a long time to figure out what exactly happened. Merchants beware! -Douglas Mason -- Douglas T. Mason | douglas@ddsw1.UUCP or dtmason@m-net |
-----------[000015][next][prev][last][first]---------------------------------------------------- Date: 8 Feb 90 15:30:29 GMT From: shz@packard.att.com (Seth Zirin) To: misc.security Subject: Re: Break-In, Are You Vunerable ???
>They got in through the ceiling. Turns out that our walls only extended >up to the suspended ceiling, not the real ceiling a few feet above that. A motion detector like a curtain PIR (passive infrared) can easily detect this type of intrusion. Curtains can protect ceilings and walls and even create protected areas or zones within an otherwise open room. Seth Zirin
-----------[000016][next][prev][last][first]---------------------------------------------------- Date: 8 Feb 90 18:00:50 GMT From: EFINNELL@ua1vm.BITNET (Ed finnell) To: misc.security Subject: Re: RACF databases on electronic disk
SSD stands for solid state device as opposed to spinning ferrous oxide. Think STK SSD are backed by spinning Winchesters or the like. Anybody who puts precious stuff on this type device is asking for big trouble. They break a lot. If they insist on doing this,I can only address paging and RACF. Should use as secondary paging only, newer levels of VM figure out which devices are responding and eventually start using "better thruput" devices. If used as primary can't IPL when they fail(and they will). Haven't seen a shop where RACF was a large enough bottleneck to risk this. Don't think they're even going to put RACF on them just some "look up" files. Cached devices like IBM 3880-23 or 3990-3 provide sufficient performance for RACF datasets on a "properly tuned" storage farm. This type of outage is a small concern to us, but valid. RACF runs a secondary database that we can switch to on the fly should we lose the primary RACF volume. We also make regular copies of the databases and could do standalone restores if required. Further, a new feature of the 3990 is dual write capability. That is while updating files on a volume the same files are updated on the clone. Should anything happen to primary, the clone automagically kicks in. Being of the conservative ilk, waiting to see who's tried this(successfully)
-----------[000017][next][prev][last][first]---------------------------------------------------- Date: Thu, 8 Feb 90 23:48 EST From: Dan Wheeler <WHEELER@ucbeh.san.uc.edu> To: security@pyrite.rutgers.edu Subject: WordPerfect file encryption
An article by John Bennett (_Cryptologia_, October, 1987) showed that the encryption algorithm used by WordPerfect 4.2 was simple to break. It is equivalent to a Vigenere cipher with some minor complications added. I have verified that WordPerfect 5.0 uses the same algorithm. I don't yet have version 5.1, but I certainly don't expect it to be any different. Peace, Dan Wheeler ** Daniel D. Wheeler Internet: wheeler@ucbeh.san.uc.edu ** ** University of Cincinnati Bitnet: wheeler@ucbeh **
-----------[000018][next][prev][last][first]---------------------------------------------------- Date: 8 Feb 90 20:11:00 GMT From: tihor@ACF4.NYU.EDU (Stephen Tihor) To: misc.security Subject: Re: Computer Abuse / Product Liability / Criminal Statutes / ECPA
I am unsure of the vulnerability in DEC's standard software releases to the Morris worm. REgardless you message seems to imply that intent is a key. As with Trespass, Reckless Driving, Manslaughter, Vehicular Homicide, there are cases where intent is only an ameliorating condition, the underlying fault remains. If the result was minor no reasonable person prosecutes. If the impact was major then that level of negligence is still deserving of criminal penalties. In our society there is a requirement that we act responsibily. If we can not we should not participate or should expect to be punished for actions which harm others. All we need are some good electronic analogues for property rights in world of perfectly fungible and intangible documents and premises.
-----------[000019][next][prev][last][first]---------------------------------------------------- Date: 8 Feb 90 21:45:00 GMT From: douglas@ddsw1.mcs.com (Douglas Mason) To: misc.security Subject: Credit Card Fraud...
Something interesting that I heard was going on at [eastern college] was that a couple of students were able to get a hold of a credit-card magnetic stip recorder somehow. They also stole purses, wallets, anything that they could get their hands on that had credit cards in it. After doing the above, they would dig through dumpsters (we all know that story) and pick up carbons or other receipts that have credit card numbers on them, and make a list of valid card numbers. Using the encoding machine, they then erased the old card number off of the magnetic strip (which had probably been reported stolen by this time) and encoded on that same strip one of the card numbers that they had picked up out of the dumpsters. So now they have say a MasterCard with an invalid number embossed on the front of it, and a different-but-valid account on the magnetic strip. What good is this? Plenty good for the clever thief! They then went into shopping malls or anywhere that the credit-card validation machines were the all-too-familiar "slide the card through and read the number off the mag strip" type. The merchant would authorize the card successfully and get an approval code, then run the card though and get a paper receipt. The merchants never check the card number on the authorization machine display and compare it to that of the card! When the merchants send in the credit card slips to the bank, they of course come back, and I imagine it takes a long time to figure out what exactly happened. Merchants beware! -Douglas Mason -- Douglas T. Mason | douglas@ddsw1.UUCP or dtmason@m-net |
-----------[000020][next][prev][last][first]---------------------------------------------------- Date: Fri, 09 Feb 90 09:20:12 PLT From: "Craig A. Summerhill" <SUMMERHI@wsuvm1.bitnet> To: SECURITY@OHSTVMA Subject: <Ctrl>-<Alt>-<Del>
I'm interested in finding a piece of software which can be used on DOS machines and run from the AUTOEXEC.BAT on startup that will disable the <CTRL>-<ALT>-<DEL> key sequence on the keyboard and prevent a warm boot to a machine. Is there such a piece of software (hopefully in the public domain or shareware markets)? Please send responses directly to me. Thanx in advance. : Craig A. Summerhill BITNET: SUMMERHI@WSUVM1 : : Assistant Systems Librarian Internet: SUMMERHI@wsuvm1.csc.wsu.edu : [Moderator tack-on: I was recently cruising Simtel and saw reference to such an item, with .asm source, I believe.. _H*]
-----------[000021][next][prev][last][first]---------------------------------------------------- Date: Fri, 9 Feb 90 09:47:53 MST From: jimkirk@outlaw.uwyo.edu (James Kirkpatrick) To: security@pyrite.rutgers.edu, faatzd@turing.cs.rpi.edu Subject: Privacy and cordless phones (was Re: Privacy)
>A recent court decision held that conversations on cordless telephones are >not subject to "expected privacy" as are conversations on telephones with >cords. Hence, police can simply LISTEN to cordless telephone conversations The catch here is that it is not illegal to listen to the broadcast conversation, but it IS illegal to disclose any information you obtain. Reference the Communications Act of 1934. For example I can hear someone say "OK, drop the illegal controlled substance under the bridge and I will pick it up" but it is illegal for me to call the police and describe the pending transaction. Likewise it is illegal for the police to disclose, as evidence in court or for a search warrant, such information. It is not impossible for them to select their actions based on this info, though, such as stopping him for speeding on his way back from the pick-up and searching the car if he acts strangely. At least, that's my interpretation of the Act. It does not seem to be enforced very well of late. For example, when recording a phone call you are supposed to superimpose a beep to let the other party know the conversation is being recorded, but most (recorded) phone-in radio/TV shows do not do this (they did in the late 50's and early 60's). If my understanding of the Act is correct, the privacy is in fact surrendered but only as far as the person doing the original eavesdropping. It is illegal to record or disclose. But the first person might be taping the call or even pumping it over the company intercom, for all the second person knows!
-----------[000022][next][prev][last][first]---------------------------------------------------- Date: Fri, 9 Feb 90 07:55 EST From: Kilgallen@dockmaster.ncsc.mil To: security@pyrite.rutgers.edu Subject: Answerbacks / Vendor Liability
> o I believe the law should be changed to match the anti gun statutes > ... "USE A COMPUTER IN THE COMMISSION OF A FELONY: GO TO JAIL" ... Would not a simpler rule be "Commit a felony: go to jail"? Why involve computers in the discussion? > Obligatory hacking report: I am trying to fix a generic security problem > involving the triggering of data terminal answerback buffers by whatever DEC reported repairing this vulnerability somewhere in the VMS V3 time frame (at least 5 years ago) with respect to the MAIL utility by screening text and not transmitting arbitrary control characters to recipient terminals. Since the author suggests that the "user authorization program" was originally protected against end-user access, presumably the operating system environment is not standard VMS (where the *program* allows world read). Using that technique for any programs whose output can be controlled by another user would be my suggestion. Of course nothing is going to protect the privileged user who chooses to *run* a program from an untrusted source, since that program might trigger the answerback itself or might fail to screen user data for arbitrary control characters. > FINAL COMMENT: The INTERNET virus should be treated as a product liability > question. In my opinion, DEC and SUN should pay the cost of the cleanup I was under the impression that the released version of Ultrix (the version of UNIX sold by DEC) did not have the sendmail debugging feature turned on, while some other versions of UNIX which run on VAXen did have it turned on. Restricting discussion for a moment to the vulnerability introduced by that feature(?), "Who ya gonna sue?". Do UNIX fans think the Trustees of U.C. Berkeley would allow the organization to release any software if there were such financial risks involved? > another ... is only detracting from the central fact -- today's vendors are > incapable of producing computer products without significant security (and > for that mater day to day operational) defects. Not the least factor influencing vendors is user insistance on wart-for-wart compatibility between UNIX systems. Even VMS-only users get hit if they choose the C programming language because of many bugs/misfeatures which are present in the run-time library solely to make the environment "like-UNIX". Maintaining a particular operating system definition can be incompatible with avoiding security or operational defects. The customer base cannot constrain vendors with mutually exclusive conditions. Larry Kilgallen
-----------[000023][next][prev][last][first]---------------------------------------------------- Date: Fri, 09 Feb 90 10:42:58 MDT From: "Bruce A. Carter" <DUSCARTE@idbsu.idbsu.edu> To: security@pyrite.rutgers.edu Subject: Re: Home security
Regarding window grates, what are the options these days in security versus being able to get out from the inside quickly in case of fire or similar problem during which one would not want to be trapped inside the structure? It seems to me, in just a naive assessment, that anything that improves one of these criteria damages the other? Bruce A. Carter, Courseware Development Coordinator = Boise State University "It is intuitively obvious to the most casual observer"= 1910 University Drive ======================================================== Boise, ID 83725 InterNet/Domain: duscarte@idbsu.idbsu.edu = Office: (208) 385-1250 CREN (BITNet): duscarte@idbsu [] CompuServe: 76666,511 = Lab: (208) 385-1859
-----------[000024][next][prev][last][first]---------------------------------------------------- Date: 9 Feb 90 04:48:00 GMT From: WHEELER@UCBEH.SAN.UC.EDU (Dan Wheeler) To: misc.security Subject: WordPerfect file encryption
An article by John Bennett (_Cryptologia_, October, 1987) showed that the encryption algorithm used by WordPerfect 4.2 was simple to break. It is equivalent to a Vigenere cipher with some minor complications added. I have verified that WordPerfect 5.0 uses the same algorithm. I don't yet have version 5.1, but I certainly don't expect it to be any different. Peace, Dan Wheeler ** Daniel D. Wheeler Internet: wheeler@ucbeh.san.uc.edu ** ** University of Cincinnati Bitnet: wheeler@ucbeh **
-----------[000025][next][prev][last][first]---------------------------------------------------- Date: Fri, 09 Feb 90 13:45:31 CST From: Gregg Grosshans <AGME003@unlvm.bitnet> To: security@pyrite.rutgers.edu Subject: Re: Computer Abuse / Product Liability / Criminal Statutes / ECPA
Last fall at the Univ. of NE-Lincoln several students used there class (computer) accounts in one of the computer user rooms to telnet (via tcp/ip) to a computer over in Europe. That alone isn't a crime or illegal, anyone with an account can telnet where ever they want to as long as they have permission to use another computer. What they did though was play a computer game on this Europe computer (via telnet) with other users across the country and also Europe. They were caught and subjected to the Student Code conduct and the director of the University computing resources wasn't to happy that they were playing games. Now when one enters a computer user room s/he clearly sees bold sign posted stating that Hacking or game playing on university computers is more or less illegal. My thought is that those are loose terms and often applied and read in the general public. What is Hacking? Is it what people did in the late 70's with Apple II computers or Macs? Is it righting efficient code (theres plenty of people, to many that is, that right sloppy code)? Is it an intermidiate step between a new computer user and a computer guru? Is it somebody who writes in assembler or rights code(works) at very odd hours during the day? Hacking is a very non-descriptive word and must not be used or that the context its used in must be the descriptive part, which makes using the term "hacker" unnecessary. But the public has come to notice "hacker" as an icon for, corrupt, evil, criminal oriented, etc.... is what a believe a hacker was not in the mid and late 70's. ********************************************************** * : * * GREGG GROSSHANS :SR. METEOROLOGY / CLIMATOLOGY * * :___________________________________* * AGME003@UNLVM UNIV. OF NE-LINCOLN * * * **********************************************************
-----------[000026][next][prev][last][first]---------------------------------------------------- Date: 9 Feb 90 12:55:00 GMT From: Kilgallen@dockmaster.ncsc.mil To: misc.security Subject: Answerbacks / Vendor Liability
> o I believe the law should be changed to match the anti gun statutes > ... "USE A COMPUTER IN THE COMMISSION OF A FELONY: GO TO JAIL" ... Would not a simpler rule be "Commit a felony: go to jail"? Why involve computers in the discussion? > Obligatory hacking report: I am trying to fix a generic security problem > involving the triggering of data terminal answerback buffers by whatever DEC reported repairing this vulnerability somewhere in the VMS V3 time frame (at least 5 years ago) with respect to the MAIL utility by screening text and not transmitting arbitrary control characters to recipient terminals. Since the author suggests that the "user authorization program" was originally protected against end-user access, presumably the operating system environment is not standard VMS (where the *program* allows world read). Using that technique for any programs whose output can be controlled by another user would be my suggestion. Of course nothing is going to protect the privileged user who chooses to *run* a program from an untrusted source, since that program might trigger the answerback itself or might fail to screen user data for arbitrary control characters. > FINAL COMMENT: The INTERNET virus should be treated as a product liability > question. In my opinion, DEC and SUN should pay the cost of the cleanup I was under the impression that the released version of Ultrix (the version of UNIX sold by DEC) did not have the sendmail debugging feature turned on, while some other versions of UNIX which run on VAXen did have it turned on. Restricting discussion for a moment to the vulnerability introduced by that feature(?), "Who ya gonna sue?". Do UNIX fans think the Trustees of U.C. Berkeley would allow the organization to release any software if there were such financial risks involved? > another ... is only detracting from the central fact -- today's vendors are > incapable of producing computer products without significant security (and > for that mater day to day operational) defects. Not the least factor influencing vendors is user insistance on wart-for-wart compatibility between UNIX systems. Even VMS-only users get hit if they choose the C programming language because of many bugs/misfeatures which are present in the run-time library solely to make the environment "like-UNIX". Maintaining a particular operating system definition can be incompatible with avoiding security or operational defects. The customer base cannot constrain vendors with mutually exclusive conditions. Larry Kilgallen
-----------[000027][next][prev][last][first]---------------------------------------------------- Date: Fri, 9 Feb 90 18:30:52 EST From: Doug Humphrey <DIGEX@ai.ai.mit.edu> To: "kelly@UTS.AMDAHL.COM"@mintaka.lcs.mit.edu Cc: misc-security@ames.arc.nasa.gov Subject: vault doors, was: locks
One thing to watch out for with thermic lances and/or plasma things if you are trying to open a safe; it will blow your whole approach if you manage to set off the smoke/heat detectors and call the fire department...
-----------[000028][next][prev][last][first]----------------------------------------------------
Date: 9 Feb 90 16:42:58 GMT
From: DUSCARTE@IDBSU.IDBSU.EDU ("Bruce A. Carter")
To: misc.security
Subject: Re: Home securityRegarding window grates, what are the options these days in security versus being able to get out from the inside quickly in case of fire or similar problem during which one would not want to be trapped inside the structure? It seems to me, in just a naive assessment, that anything that improves one of these criteria damages the other? Bruce A. Carter, Courseware Development Coordinator = Boise State University "It is intuitively obvious to the most casual observer"= 1910 University Drive ======================================================== Boise, ID 83725 InterNet/Domain: duscarte@idbsu.idbsu.edu = Office: (208) 385-1250 CREN (BITNet): duscarte@idbsu [] CompuServe: 76666,511 = Lab: (208) 385-1859
-----------[000029][next][prev][last][first]---------------------------------------------------- Date: 10 Feb 90 02:46:00 GMT From: blackcat@NEURO.USC.EDU To: misc.security Subject: Re: Field service spying?
>I recently got a command file called SW_INVENTORY.COM which was written >by DEC to be run by field service people to give a complete inventory >of all DEC software running on a machine. It looks for images, IF DEC FIELD SERVICE ENGINEERS ARE USING THEIR ACCESS TO YOUR SYSTEM FOR ANYTHING OTHER THAN RUNNING HARDWARE/FIRMWARE DIAGNOSTICS AND PERFORMING ROUTINE SYSTEM MAINTENANCE THEY MAY BE CHARGED UNDER AN EVER INCREASING NUMBER OF STATE AND FEDERAL COMPUTER CRIME LAWS ... AS WELL AS SUFFERING CIVIL ACTION FOR UNAUTHORIZED ACCESS, INVASION OF PRIVACY AND DISCLOSURE OF CONFIDENTIAL INFORMATION. It is understandable that a computer vendor might seek to police unauthorized distribution of their software, gather intelligence about competing vendor software installations on their iron, and learn more about customer needs in general. However, DEC should come in the front door and request this information in a straightforward way; they should not sneak in the back door to steal data like thieves in the night. IF YOU FIND SOME DEC PERSON ACTUALLY RUNNING SUCH A SCRIPT ON YOUR MACHINE ... CALL YOUR REGIONAL MARKETING MANAGER RIGHT AWAY ... AND MAKE IT CLEAR THAT THERE IS NO ACCEPTABLE REASON FOR SUCH BEHAVIOUR ... BETTER YET, LOOK INTO THIRD PARTY MAINTENANCE FROM SOMEONE WHO HAS A BETTER UNDERSTANDING ABOUT THE MEANING OF CUSTOMER CONFIDENTIALITY.
-----------[000030][next][prev][last][first]---------------------------------------------------- Date: Sat, 10 Feb 90 15:58 PST From: "Ned Freed, Postmaster" <NED@hmcvax.claremont.edu> To: security@pyrite.rutgers.edu Subject: Re: Field service spying?
I'd very much like to have a copy of SW_INVENTORY.COM myself to aid in tracking software usage. We, like many other college sites, have blanket licenses for pretty much all the software DEC sells. We are, however, required to monitor its installation and usage on our various systems and report it to DEC. The problem is that our systems are managed by a large number of people, with varying degrees of ability/responsibility/ authority. It would be a real help if we could run something that would simply tell us what's installed, rather than relying on reports that are often forgotten or incorrect. PAKs don't help much since DEC in their wisdom provides product PAKs in an all-or-nothing fashion. It is the actual installation of the software that counts, not the PAK. As far as DEC is concerned, I fail to see how SW_INVENTORY.COM would tell them much. With the advent of CD-ROM distributions, you can install practically anything DEC sells without actually being able to use it. I suspect that this is the reason SW_INVENTORY.COM has fallen into disuse, rather than concerns about customer security. Insofar as this represents a breach of security, if you're relying on lack of physical access to prevent this sort of traffic analysis, you're dreaming. Assuming that you're honest and you're not running software you're not entitled to use, DEC's own records of software sales to you are probably a more reliable indication of what you're doing. I suppose you could pretend to buy the software for some other system (which may well be illegal), but in the long run, do you seriously think you can fool people? Note also that the software you have may in fact be a red herring; I think a look at stuff like the usernames, load averages, programs used (especially accounting logs), and so forth would be a much better place to start nosing around. And it may not be practical to deny your vendor access to this sort of information (e.g. a bug which only manifests itself under load -- I practically never see any other kind these days, now that static analysis of program code is so good). Ned Freed ned@ymir.claremont.edu
-----------[000031][next][prev][last][first]---------------------------------------------------- Date: 10 Feb 90 18:20 -0600 From: Ken Wallewein <kenw@noah.arc.cdn> To: <security@pyrite.rutgers.edu> Cc: <EVERHART@arisia.dnet.ge.com> Subject: Re: Field service spying?
> I recently got a command file called SW_INVENTORY.COM which was written I certainly wouldn't want such a program run on my system without my permission. On the other hand, there's not a lot that's beyond the reach of the FIELD account. Which is why ours is normally DISUSERed (disabled) -- that way, I know when it's being used, and why. A while ago I wrote a newsletter article lambasting DEC for not providing such tools as part of standard system software. If you know how I could get a copy, I'd appreciate the information. /kenw Ken Wallewein A L B E R T A kenw@noah.arc.cdn R E S E A R C H (403)297-2660 C O U N C I L
-----------[000032][next][prev][last][first]---------------------------------------------------- Date: Sun, 11 Feb 90 01:02:15 -0500 From: don@cs.umd.edu (Don Hopkins) To: blackcat@neuro.usc.edu Cc: security@pyrite.rutgers.edu Subject: Computer Abuse / Product Liability / Criminal Statutes / ECPA
>> [...] updating the old X10 server for the ibm/pc to work with X11R4, etc. Yeah, right. Might as well have them fill in the Grand Canyon using a pair of tweezers. How about having Robert Morris implement the Gnu kernel? I'm sure he's bright enough to come up with a very secure system (much to rms's disgust). So secure that only he would know the loopholes. Morris would be dead meat if his daddy didn't work for the NSA. One of the first patches for sendmail that was sent around to keep the Internet worm out was to edit the sendmail binary changing the 'D' in "DEBUG" to '\0', so the DEBUG command wouldn't work any more. Well that stopped the worm, but it made the null string invoke the debug command. I noticed this a couple days after the worm, when I telneted to sun.com port 25, to EXPN a user name of somebody on a mailing list I run, hit CR a couple of times to make sure sendmail was listening, and did the EXPN. It spit back huge ammounts of debugging information! Of course I promptly notified the appropriate people at Sun so they could put the right fix in. Sheez. -Don
-----------[000033][next][prev][last][first]---------------------------------------------------- Date: Sun, 11 Feb 90 00:02 EST From: <CJS@cwru.bitnet> To: hobbit@pyrite.rutgers.edu Subject: FOIA Jewel: Original Charter of the National Security Agency
At 12:01 ON the morning of November 4, 1952, a new federal
agency was born. Unlike other such bureaucratic births, however,
this one arrived in silence. No news coverage, no congressional
debate, no press announcement, not even the whisper of a rumor.
Nor could any mention of the new organization be found in the
Government Organization Manual of the Federal Register or the
Congressional Record. Equally invisible were the new agency's
director, its numerous buildings, and its ten thousand employees.
Eleven days earlier, on October 24, President Harry S Truman
scratched his signature on the bottom of a seven-page
presidential memorandum addressed to secretary of State Dean G.
Acheson and Secretary of Defense Robert A. Lovett. Classified
top secret and stamped with a code word that was itself
classified, the order directed the establishment of an agency to
be known as the National Security Agency. It was the birth
certificate for America's newest and most secret agency, so
secret in fact that only a handful in the government would be
permitted to know of its existence.
-James Bamford, The Puzzle Palace (1982) at 15.
*****************************************************************
A 20707 5/4/54/OSO
NSA TS CONTL. NO 73-00405
COPY: D321
Oct 24 1952
MEMORANDUM FOR: The Secretary of State
The Secretary of defense
SUBJECT: Communications Intelligence Activities
The communications intelligence (COMINT) activities of the
United States are a national responsibility. They must be so
organized and managed as to exploit to the maximum the available
resources in all participating departments and agencies and to
satisfy the legitimate intelligence requirements of all such
departments and agencies.
I therefore designate the Secretaries of State and Defense
as a Special Committee of the National Security Council for
COMINT, which Committee shall, with the assistance of the
Director of Central Intelligence, establish policies governing
COMINT activities. and keep me advised of such policies through
the Executive Secretary of the National Security Council.
I further designate the Department of Defense as executive
agent of the Government, for the production of COMINT
information.
I direct this Special Committee to prepare and issue
directives which shall include the provisions set forth below and
such other provisions as the Special Committee may determine to
be necessary.
1. A directive to the United States Communication
Intelligence Board (USCIB). This directive will replace the
National Security Council Intelligence Directive No. 9, and shall
prescribe USCIB's new composition, responsibilities and
procedures in the COMINT fields. This directive shall include
the following provisions.
a. USCIB shall be reconstituted as a body acting for
and under the Special Committee, and shall operate in
accordance with the provisions of the new directive. Only
those departments or agencies represented in USCIB are
authorized to engage in COMINT activities.
b. The Board shall be composed of the following
members:
(1) The Director of Central Intelligence, who shall be
the Chairman of the Board.
(2) A representative of the Secretary of State.
(3) A representative of the Secretary of Defense
(4) A representative of the Director of the Federal
Bureau of Investigation.
(5) The Director of the National Security Agency.
(6) A representative of the Department of the Army.
(7) A representative of the Department of the Navy.
(8) A representative of the Department of the Air Force.
(9) A representative of the Central Intelligence Agency.
c. The Board shall have a staff headed by an executive
secretary who shall be appointed by the Chairman with the
approval of the majority of the Board.
d. It shall be the duty of the Board to advise and make
recommendations to the Secretary of Defense, in accordance
with the following procedure, with respect to any matter
relating to communications intelligence which falls within
the jurisdiction of the Director of the NSA.
(1) The Board shall reach its decision by majority
vote. Each member of the Board shall have one vote
except the representatives of the Secretary of State
and of the Central Intelligence Agency who shall each
have two votes. The Director of Central Intelligence,
as Chairman, will have no vote. In the event that the
Board votes and reaches a decision, any dissenting
member of the Board may appeal from such decision
within 7 days of the Special Committee. In the event
that the Board votes but fails to reach a decision, any
member of the Board may appeal within 7 days to the
Special Committee. In either event the Special
Committee shall review the matter, and its
determination thereon shall be final. Appeals by the
Director of NSA and/or the representatives of the
Military Departments shall only be filed with the
approval of the Secretary of Defense.
(2) If any matter is voted on by the Board but -
(a) no decision is reached and any member
files an appeal;
(b) a decision is reached in which the
representative of the Secretary of Defense does
not concur and files an appeal;
no action shall be taken with respect to the subject
matter until the appeal is decided, provided that, if
the Secretary of Defense determines, after consultation
with the Secretary of State, that the subject matter
presents a problem of an emergency nature and requires
immediate action, his decision shall govern, pending
the result of the appeal. In such an emergency
situation the appeal may be taken directly to the
President.
(3) Recommendations of the Board adopted in
accordance with the foregoing procedures shall be
binding on the Secretary of Defense. Except on matter
which have been voted on by the Board, the Director of
NSA shall discharge his responsibilities in accordance
with his own judgment, subject to the direction of the
Secretary of Defense.
(4) The Director of NSA shall make such reports
and furnish such information from time to time to the
Board, either orally or in writing, as the Board my
request, and shall bring to the attention of the Board
either in such reports or otherwise any major policies
or programs in advance of their adoption by him.
e. It shall also be the duty of the Board as to
matters not falling within the jurisdiction of NSA;
(1) To coordinate the communications intelligence
activities among all departments and agencies
authorized by the President to participate therein;
(2) To initiate, to formulate policies concerning,
and subject to the provision of NSCID No. 5, to
supervise all arrangements with foreign governments in
the field of communications intelligence; and
(3) to consider and make recommendations
concerning policies relating to communications
intelligence of common interest to the departments and
agencies, including security standards and practices,
and, for this purpose, to investigate and study the
standards and practices of such departments and
agencies in utilizing and protecting COMINT
information.
f. Any recommendation of the Board with respect to the
matters described in paragraph e above shall be binding on
all departments or agencies of the Government if it is
adopted by the unanimous vote of the members of the Board.
Recommendations approved by the majority, but not all, of
the members of the Board shall be transmitted by it to the
Special Committee for such action as the Special Committee
may see fit to take.
g. The Board will meet monthly, or oftener at the call
of the Chairman or any member, and shall determine its own
procedures.
2. A directive to the Secretary of Defense. This
directive shall include the following provisions:
a. Subject to the specific provisions of this
directive, the Secretary of Defense may delegate in whole of
in part authority over the Director of NSA within his
department as he sees fit.
b. The COMINT mission of the National Security Agency
(NSA) shall be to provide an effective, unified organization
and control of the communications intelligence activities of
the United States conducted against foreign governments, to
provide for integrated operational policies and procedures
pertaining thereto. As used in this directive, the terms
"communications intelligence" or "COMINT" shall be construed
to mean all procedures and methods used in the interception
of communications other than foreign press and propaganda
broadcasts and the obtaining of information from such
communications by other than intended recipients, but shall
exclude censorship and the production and dissemination of
finished intelligence.
c. NSA shall be administered by a Director, designated
by the Secretary of Defense after consultation with the
Joint Chiefs of Staff, who shall serve for a minimum term of
4 years and who shall be eligible for reappointment. The
Director shall be a career commissioned officer of the armed
services on active or reactivated status, and shall enjoy at
least 3-star rank during the period of his incumbency.
d. Under the Secretary of Defense, and in accordance
with approved policies of USCIB, the Director of NSA shall
be responsible for accomplishing the mission of NSA. For
this purpose all COMINT collection and production resources
of the United States are placed under his operational and
technical control. When action by the Chiefs of the
operating agencies of the Services or civilian departments
or agencies is required, the Director shall normally issue
instruction pertaining to COMINT operations through them.
However, due to the unique technical character of COMINT
operations, the Director is authorized to issue direct to
any operating elements under his operational control task
assignments and pertinent instructions which are within the
capacity of such elements to accomplish. He shall also have
direct access to, and direct communication with, any
elements of the Service or civilian COMINT agencies on any
other matters of operational and technical control as may be
necessary, and he is authorized to obtain such information
and intelligence material from them as he may require. All
instruction issued by the Director under the authority
provided in this paragraph shall be mandatory, subject only
to appeal to the Secretary of Defense by the Chief of
Service or head of civilian department of agency concerned.
e. Specific responsibilities of the Director of NSA
include the following:
(1) Formulating necessary operational plans and
policies for the conduct of the U.S. COMINT activities.
(2) Conducting COMINT activities, including
research and development, as required to meet the needs
of the departments and agencies which hare authorized
to receive the products of COMINT.
(3) Determining, and submitting to appropriate
authorities, requirements for logistic support for the
conduct of COMINT activities, together with specific
recommendations as to what each of the responsible
departments and agencies of the Government should
supply.
(4) Within NSA's field of authorized operations
prescribing requisite security regulations covering
operating practices, including the transmission,
handling and distribution of COMINT material within and
among the COMINT elements under his operations or
technical control; and exercising the necessary
monitoring and supervisory control, including
inspections if necessary, to ensure compliance with the
regulations.
(5) Subject to the authorities granted the
Director Central Intelligence under NSCID No. 5,
conducting all liaison on COMINT matters with foreign
governmental communications intelligence agencies.
f. To the extent he deems feasible and in consonance
with the aims of maximum over-all efficiency, economy, and
effectiveness, the Director shall centralize or consolidate
the performance of COMINT functions for which he is
responsible. It is recognized that in certain circumstances
elements of the Armed Forces and other agencies being served
will require close COMINT support. Where necessary for this
close support, direct operational control of specified
COMINT facilities and resources will be delegated by the
Director, during such periods and for such tasks as are
determined by him, to military commanders or to the Chiefs
of other agencies supported.
g. The Director shall exercise such administrative
control over COMINT activities as he deems necessary to the
effective performance of his mission. Otherwise,
administrative control of personnel and facilities will
remain with the departments and agencies providing them.
h. The Director shall make provision for participation
by representatives of each of the departments and agencies
eligible to receive COMINT products in those offices of NSA
where priorities of intercept and processing are finally
planned.
i. The Director shall have a civilian deputy whose
primary responsibility shall be to ensure the mobilization
and effective employment of the best available human and
scientific resources in the field of cryptographic research
and development.
j. Nothing in this directive shall contravene the
responsibilities of the individual departments and agencies
for the final evaluation of COMINT information, its
synthesis with information from other sources, and the
dissemination of finished intelligence to users.
3. The special nature of COMINT actives requires that they
be treated in all respects as being outside the framework of
other or general intelligence activities. Order, directives,
policies, or recommendations of any authority of the Executive
Branch relating to the collection, production, security,
handling, dissemination, or utilization of intelligence, and/or
classified material, shall not be applicable to COMINT actives,
unless specifically so stated and issued by competent
departmental of agency authority represented on the Board. Other
National Security Council Intelligence Directive to the Director
of Central Intelligence and related implementing directives
issued by the Director of Central Intelligence shall be construed
as non-applicable to COMINT activities, unless the National
Security Council has made its directive specifically applicable
to COMINT.
/s/ HARRY S. TRUMAN
-----------[000034][next][prev][last][first]----------------------------------------------------
Date: 10 Feb 90 23:58:00 GMT
From: NED@HMCVAX.CLAREMONT.EDU ("Ned Freed, Postmaster")
To: misc.security
Subject: Re: Field service spying?I'd very much like to have a copy of SW_INVENTORY.COM myself to aid in tracking software usage. We, like many other college sites, have blanket licenses for pretty much all the software DEC sells. We are, however, required to monitor its installation and usage on our various systems and report it to DEC. The problem is that our systems are managed by a large number of people, with varying degrees of ability/responsibility/ authority. It would be a real help if we could run something that would simply tell us what's installed, rather than relying on reports that are often forgotten or incorrect. PAKs don't help much since DEC in their wisdom provides product PAKs in an all-or-nothing fashion. It is the actual installation of the software that counts, not the PAK. As far as DEC is concerned, I fail to see how SW_INVENTORY.COM would tell them much. With the advent of CD-ROM distributions, you can install practically anything DEC sells without actually being able to use it. I suspect that this is the reason SW_INVENTORY.COM has fallen into disuse, rather than concerns about customer security. Insofar as this represents a breach of security, if you're relying on lack of physical access to prevent this sort of traffic analysis, you're dreaming. Assuming that you're honest and you're not running software you're not entitled to use, DEC's own records of software sales to you are probably a more reliable indication of what you're doing. I suppose you could pretend to buy the software for some other system (which may well be illegal), but in the long run, do you seriously think you can fool people? Note also that the software you have may in fact be a red herring; I think a look at stuff like the usernames, load averages, programs used (especially accounting logs), and so forth would be a much better place to start nosing around. And it may not be practical to deny your vendor access to this sort of information (e.g. a bug which only manifests itself under load -- I practically never see any other kind these days, now that static analysis of program code is so good). Ned Freed ned@ymir.claremont.edu
-----------[000035][next][prev][last][first]---------------------------------------------------- Date: 11 Feb 90 00:20:00 GMT From: kenw@noah.arc.cdn (Ken Wallewein) To: misc.security Subject: Re: Field service spying?
> I recently got a command file called SW_INVENTORY.COM which was written I certainly wouldn't want such a program run on my system without my permission. On the other hand, there's not a lot that's beyond the reach of the FIELD account. Which is why ours is normally DISUSERed (disabled) -- that way, I know when it's being used, and why. A while ago I wrote a newsletter article lambasting DEC for not providing such tools as part of standard system software. If you know how I could get a copy, I'd appreciate the information. /kenw Ken Wallewein A L B E R T A kenw@noah.arc.cdn R E S E A R C H (403)297-2660 C O U N C I L
-----------[000036][next][prev][last][first]---------------------------------------------------- Date: Sun, 11-Feb-90 13:54:12 PST From: mmm@cup.portal.com To: misc-security@uunet.uu.net Subject: Fire Sprinkler Cameras
I had never heard of these things before. How can I tell the difference between a regular fire sprinkler and one of these things? I assume there must be some kind of lens, where is it located? For that matter, what are other common disguises for cameras or bugs? [Moderator add-on: I saw some of these at Surveillance Expo last December. They are built into regular sprinkler heads which have been slightly modified to fit a small mirror assembly. Basically it's a pinhole lens looking straight down through where the water would normally emerge, with a small mirror mounted in a holder at 45 degrees so the camera's view is out sideways and slightly downward [adjustable]. You would have to stare really hard at them, especially considering that sprinkler heads are normally mounted on the ceiling. The advantage besides unobtrusiveness is that the mirror assembly can turn, allowing a 360 degree scan which a normal camera needs a fancy motorized bracket for. The company there that was marketing the things is Visual Methods, in Westwood NJ. _H*]
-----------[000037][next][prev][last][first]---------------------------------------------------- Date: Sun, 11 Feb 90 15:03:38 MST From: jimkirk@outlaw.uwyo.edu (James Kirkpatrick) To: AGME003%UNLVM@outlaw.uwyo.edu, SECURITY@pyrite.rutgers.edu Subject: RE: WP5.0/5.1 file security
WordPerfect 5.0 still incorporates the same scheme and is indeed vulnerable. It is basically a Vigenere cipher. I have not had a chance yet to test version 5.1. I still have found out nothing about Lotus. DES encryption would probably be superior.
-----------[000038][next][prev][last][first]---------------------------------------------------- Date: 11 Feb 90 21:54:12 GMT From: mmm@cup.portal.com To: misc.security Subject: Fire Sprinkler Cameras
I had never heard of these things before. How can I tell the difference between a regular fire sprinkler and one of these things? I assume there must be some kind of lens, where is it located? For that matter, what are other common disguises for cameras or bugs? [Moderator add-on: I saw some of these at Surveillance Expo last December. They are built into regular sprinkler heads which have been slightly modified to fit a small mirror assembly. Basically it's a pinhole lens looking straight down through where the water would normally emerge, with a small mirror mounted in a holder at 45 degrees so the camera's view is out sideways and slightly downward [adjustable]. You would have to stare really hard at them, especially considering that sprinkler heads are normally mounted on the ceiling. The advantage besides unobtrusiveness is that the mirror assembly can turn, allowing a 360 degree scan which a normal camera needs a fancy motorized bracket for. The company there that was marketing the things is Visual Methods, in Westwood NJ. _H*]
-----------[000039][next][prev][last][first]---------------------------------------------------- Date: 11 Feb 90 22:03:38 GMT From: jimkirk@OUTLAW.UWYO.EDU (James Kirkpatrick) To: misc.security Subject: RE: WP5.0/5.1 file security
WordPerfect 5.0 still incorporates the same scheme and is indeed vulnerable. It is basically a Vigenere cipher. I have not had a chance yet to test version 5.1. I still have found out nothing about Lotus. DES encryption would probably be superior.
-----------[000040][next][prev][last][first]---------------------------------------------------- Date: Mon, 12 Feb 90 22:05:11 GMT From: Hans van Zanten <phigate!cnps!hansz@relay.eu.net> To: phigate!security@relay.eu.net Subject: Security Auditing
I have read a lot about security in the UNIX environment in the Newsgroup: misc.security. One of the things I am interested in I did not spot however and I am wondering whether you could help me. But first of all, I would like to tell you who I am and why I am interested in security. My name: Hans van Zanten My firm: Philips Netherlands The department I am working with is called "Communication and Processing Services" (about 1000 employees) and is the EDP department of Philips in the Netherlands. Although most of the Business processing done is still on IBM mainframes, UNIX is starting to rise. In technical environments however UNIX is, of course, becoming quite standard. One of the main problems I am facing at the moment is the lack of skill of UNIX system administrators in the Business environment. My work (software supporting just these system administrators) is to make sure that their UNIX system is configured properly secure. In order to be able to 'audit' their systems (preferably in an automated way) I would like to get hold of 'auditing tools' (e.g. for scanning all the s-bits in the file- system, or to report on permission settings of complete file-systems, etc.). My question to you is whether you know of such tools, do they exist, to whom should I address myself to obtain possibly some more information. I would be very greatfull to receive some information on this subject and I hope you do not mind me addressing these quetions to you, yours sincerely, Hans van Zanten C&P/LSS Manager Departmental Systems e-mail: hansz@cnps.philips.nl
-----------[000041][next][prev][last][first]---------------------------------------------------- Date: Tue, 13 Feb 90 11:01:35 EST From: shz@packard.att.com (Seth Zirin) To: misc-security@att.att.com Subject: Re: vault doors, was: locks
>I missed the first part of this thread... but THERMIC LANCES will normally >penetrate 3' of reinforced concrete within about 2 minutes... and if that Thermic Lances produce enormous amounts of smoke when they cut through concrete reinforced safe walls or doors. This is sure to set off fire alarms and thermal attack alarms. In addition, the large plume of smoke rising from a bank across town might tip off the police. These cutting tools produce blindingly bright light that is visible for great distances unless shielded. I've used mini-lances a few times and even they are not for the faint at heart. You can easily burn down the entire building with one of these.
-----------[000042][next][prev][last][first]---------------------------------------------------- Date: 13 Feb 90 09:14:26 GMT From: dlb!netcom!onymouse@ames.arc.nasa.gov (John Debert) To: misc-security@ames.arc.nasa.gov Subject: Re: cop detectors
> Would it be possible to build a police radio detector that detected > the emissions from the local oscillators of the radios? This would be > [Moderator tack-on: Professional rigs are normally pretty-well shielded.] I have found it very easy to detect police hand-helds, and, sometimes, mobile sets. Some of the recent Motorola hand-helds (the HT-220 series and on) emit such strong signals that I have picked them up as much as 200 feet away on my Pro-30 with it in my back pocket. The radios operate on UHF with repeaters and I pick up the signals on the repeater output frequency. Of course, there are those who would say that "That's impossible!" but it does in fact happen with my radios and I don't worry about whether it's possible or not. It happens, it works, no problem. I do not know if it works with all makes of radios, though. That is one method that may work. Others are to set your scanner to pick up the local oscillator frequency or even the transmit frequency in case the transmitter oscillator aways idles during receive. jd onymouse@netcom.UUCP
-----------[000043][next][prev][last][first]---------------------------------------------------- Date: Wed, 14 Feb 90 00:13 CST From: GREENY <MISS026@ecncdc.bitnet> To: <security@pyrite.rutgers.edu> Subject: re: 4D for the mac....
Howdy.....I was wondering if anyone had any knowledge of the System Designer passwords for the individual databases set up with 4th Dimension on the Mac really being secure....I seem to have forgotten the password for a database I set up for a friend and need to figure it out.....I could go with the "ole comparison" technique between an old file, and one with a modified password but if there is an easier way that someone knows of, I'd love to know it.. bye for now but not for long Greeny BITNET: MISS026@ECNCDC
-----------[000044][next][prev][last][first]---------------------------------------------------- Date: Wed, 14 Feb 90 00:19 CST From: GREENY <MISS026@ecncdc.bitnet> To: <security@pyrite.rutgers.edu> Subject: re: Thermic Lances
> Thermic lances willnormally penetrate 3' of reinforced concrete... yeah, true....but they DO NOT cut through wood...according to a close associate locksmith friend....."cram about 1" of wood in the safe/vault door.. poof, the lance goes out..." not too shabby..... C'est La Vie! bye for now but not for long Greeny
-----------[000045][next][prev][last][first]---------------------------------------------------- Date: Wed, 14 Feb 90 00:34 CST From: GREENY <MISS026@ecncdc.bitnet> To: <security@pyrite.rutgers.edu> Subject: re: Entry alarms
> ...inexpensive effective security device which would allow someone to tell > if a person has entered in ones apartment.... Yeah, the mod's wisecrack is one idea....and so is the infamous Radio Shack.. they sell an entry alarm that gets screwed/double stick taped onto the door... put in a chime mode it goes "ding/dong" when the door opens....or has a siren mode that blasts the hell out of an intruder. I successfully used the chime mode over a period of two months late at night to get a roommate in a college dorm to move out (*devilish smile*) and once when I left the siren mode on over vacation the device scared the Asst. Res. Hall Director out of her wits during vacation room checks (needless to say, they kept out of my room after that...). OR, you could wire up something with a latching relay and a magnetic contact that would trigger a small light or a counting module (radio shack again... about $14.99) so you could keep track of someone entering illegally....or a sign on the door saying "WARNING: THESE PREMESES ARE ELECTRONICALLY PROTECTED. ALL ENTRIES ARE RECORDED FOR INVOLVED PARTIES PROTECTION. DO NOT ENTER IF THE ROOM/APARTMENT RESIDENT(S) IS/ARE NOT HOME. THE POLICE WILL BE AUTOMATICALLY NOTIFIED UPON UNAUTHORIZED ENTRY..." A sign such as the above was quite successful in keeping a nosy landlord out of my apartment.....he asked for the "code" to the alarm, I told him he wasn't getting it....he said he'd kill the power....I said it had battery backup, he quoted the lease, I quoted it too and said he had to provide proper notice... Ok, so I'm rambling....stick with the mag contact, the latching relay, a 9V battery, a small led, and a reset switch to reset the relay (just have a N.C. switch on the neg. lead of the battery (in series). Then to reset it, press the switch....*poof* power gets cut, relay resets, you are set.. not bad? Hope the above helps... bye fo rnow but not for long Greeny
-----------[000046][next][prev][last][first]---------------------------------------------------- Date: 13 Feb 90 23:29:58 GMT From: spaf@cs.purdue.edu (Gene Spafford) To: misc-security@gatech.edu Subject: Re: Who (Specificly) has Morris' Worm Code?
Hundreds (maybe thousands) of people around the world have Morris's
worm code. Lots of people have the binaries, and many people have
reverse-engineered the code to C source. There has even been a book
published in England that has most of the code in it.
As far as people having the original source, well, folks at Cornell
have it. Printouts and tape copies were given to the FBI, and the
U.S. Attorney's office has copies. Some of the witnesses for the
prosecution got paper copies, too.
It's not all that surprising or entertaining....
--
Gene Spafford
NSF/Purdue/U of Florida Software Engineering Research Center,
Dept. of Computer Sciences, Purdue University, W. Lafayette IN 47907-2004
Internet: spaf@cs.purdue.edu uucp: ...!{decwrl,gatech,ucbvax}!purdue!spaf
-----------[000047][next][prev][last][first]---------------------------------------------------- Date: 14 Feb 90 06:34:00 GMT From: MISS026@ecncdc.BITNET (GREENY) To: misc.security Subject: re: Entry alarms
> ...inexpensive effective security device which would allow someone to tell > if a person has entered in ones apartment.... Yeah, the mod's wisecrack is one idea....and so is the infamous Radio Shack.. they sell an entry alarm that gets screwed/double stick taped onto the door... put in a chime mode it goes "ding/dong" when the door opens....or has a siren mode that blasts the hell out of an intruder. I successfully used the chime mode over a period of two months late at night to get a roommate in a college dorm to move out (*devilish smile*) and once when I left the siren mode on over vacation the device scared the Asst. Res. Hall Director out of her wits during vacation room checks (needless to say, they kept out of my room after that...). OR, you could wire up something with a latching relay and a magnetic contact that would trigger a small light or a counting module (radio shack again... about $14.99) so you could keep track of someone entering illegally....or a sign on the door saying "WARNING: THESE PREMESES ARE ELECTRONICALLY PROTECTED. ALL ENTRIES ARE RECORDED FOR INVOLVED PARTIES PROTECTION. DO NOT ENTER IF THE ROOM/APARTMENT RESIDENT(S) IS/ARE NOT HOME. THE POLICE WILL BE AUTOMATICALLY NOTIFIED UPON UNAUTHORIZED ENTRY..." A sign such as the above was quite successful in keeping a nosy landlord out of my apartment.....he asked for the "code" to the alarm, I told him he wasn't getting it....he said he'd kill the power....I said it had battery backup, he quoted the lease, I quoted it too and said he had to provide proper notice... Ok, so I'm rambling....stick with the mag contact, the latching relay, a 9V battery, a small led, and a reset switch to reset the relay (just have a N.C. switch on the neg. lead of the battery (in series). Then to reset it, press the switch....*poof* power gets cut, relay resets, you are set.. not bad? Hope the above helps... bye fo rnow but not for long Greeny
-----------[000048][next][prev][last][first]---------------------------------------------------- Date: FRI FEB 16, 1990 09.32.15 EST From: "Kathy Healy Brey" <KHB1@lehigh.bitnet> To: <security@ohstvma> Subject: Virus Scan on a LAN
Can anyone provide advice or information on the following:
CONFIGURATION
An ethernet LAN running NOVELL with 10 nodes.
Workstations are Zenith 286LP's with 20Meg hard drives & a 3.5" drive.
LAN is for student use.
PROBLEM
We would like to run a virus scan on any floppy inserted into the 3.5
inch drive AT INSERTION. Is this possible? If so, how?
The ideal scenario would be: Student inserts floppy in A:. System
recognizes presence of floppy and scans diskette for known viruses...
(a system-initiated scan, not an operator-initiated scan)
If diskette is O.K., student goes to work. If diskette is contaminated,
it's ejected(?) and student gets locked out of workstation and is
directed to LAN Administration. L.A. grabs diskette and does detective
and control work...
THANKS for any help.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
| Kathy Healy Brey, Manager Admin Environment: |
| KHB1@LEHIGH THE INFORMATION CENTER IBM 4381 VSE/SP 2.1.5 |
| 215-758-3006 Lehigh University IA Systems |
| Private U Fairchild-Martindale 8B IBM PCs & Compatibles |
| 6500 Students Bethlehem, PA 18015-3146 Novell LANs |
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-----------[000049][next][prev][last][first]---------------------------------------------------- Date: 15 Feb 90 01:24:38 GMT From: kelly@uts.amdahl.com (Kelly Goen) To: misc-security@ames.arc.nasa.gov Subject: Re: Home security
GE LEXAN in .25" thickness will generally repel anything iron bars will
and it WONT give you the feeling of being in jail(just how strong is it
well I tool a .125" thick sample and hit it with the pointed end of
a 20 lb sledge about 15 to 20 times... bent and scratched but that
damn plastic I swear was grinning at me and saying make my day... it
wouldnt break...)
cheers
kelly
-----------[000050][next][prev][last][first]---------------------------------------------------- Date: Thu, 15 Feb 90 11:22 MDT From: "David D. Grisham" <DAVE@unmb.bitnet> To: security@ubvm Subject: ACF2 query
WE are planning to implement ACF2 on our 3081-9370 setup. I am in the preliminary stages of the project and already see lots of problems. My two biggest problems are converting three (1 way) encrypted password files to one that ACF2 can use and establishing a common UID or LogonID from multiple operating systems which have different standards. Would anyone who has recently installed or coordinated an installation be willing to share some of the problems and solutions to getting this package up in a university environment? Thanks in advance. dave Dave Grisham, Security Administrator, CIRT Phone (505) 277-8032 University of New Mexico USENET DAVE@hydra.UNM.EDU Albuquerque, New Mexico 87131 BITNET DAVE@UNMB
-----------[000051][next][prev][last][first]---------------------------------------------------- Date: 15 Feb 90 08:41:29 GMT From: reynhout@WPI.WPI.EDU (Hagbard Celine) To: misc.security Subject: Re: Who (Specificly) has Morris' Worm Code?
Hmm... In order for the worm to proliferate, wouldn't it have to copy
itself into every infected system? Therefore, doesn't every system admin who
bothered to save it have a copy? (given a little reverse-engineering)
Andrew
--
Andrew Reynhout (Internet: reynhout@wpi.wpi.edu)
(BITNET: reynhout@wpi.bitnet)
All hail Eris! (uucp: uunet!wpi.wpi.edu!reynhout)
-----------[000052][next][prev][last][first]---------------------------------------------------- Date: 15 Feb 90 16:29:20 GMT From: waters@darla.sps.mot.com (Strawberry Jammer) To: misc.security Subject: Re: Field service spying?
I trust that no one who reads this leaves the account as Name: field
Password: service no matter what DEC says. At one time they insisted on this,
and refused to admit that it was a potential (HAH!) security problem.
I still find VAXes set up this way BTW, recently the one my stockbroker uses
to allow me to automate by stock transactions. Sigh.
*Mike Waters AA4MW/7 waters@dover.sps.mot.com *
The turtle lives 'twixt plated decks
Which practically conceal its sex.
I think it clever of the turtle
-----------[000053][next][prev][last][first]----------------------------------------------------
Date: 15 Feb 90 17:22:00 GMT
From: DAVE@unmb.BITNET ("David D. Grisham")
To: misc.security
Subject: ACF2 queryWE are planning to implement ACF2 on our 3081-9370 setup. I am in the preliminary stages of the project and already see lots of problems. My two biggest problems are converting three (1 way) encrypted password files to one that ACF2 can use and establishing a common UID or LogonID from multiple operating systems which have different standards. Would anyone who has recently installed or coordinated an installation be willing to share some of the problems and solutions to getting this package up in a university environment? Thanks in advance. dave Dave Grisham, Security Administrator, CIRT Phone (505) 277-8032 University of New Mexico USENET DAVE@hydra.UNM.EDU Albuquerque, New Mexico 87131 BITNET DAVE@UNMB
-----------[000054][next][prev][last][first]---------------------------------------------------- Date: Fri, 16 Feb 90 11:38:55 -0600 (CST) From: "Anthony A. Datri" <datri@convex.com> To: security@pyrite.rutgers.edu Subject: Re: Bill Changers
>Remind me to tell you an interesting way that con-artists can construct ... Easy -- chop the big numbers off the corners of a $20 bill, past them onto the corners of a $1 bill. Pass this as a $20 bill. Turn in the mutilated $20 for a fresh one. (no, I am not advocating the practice)
-----------[000055][next][prev][last][first]---------------------------------------------------- Date: Fri, 16 Feb 90 13:48 EST From: WHMurray@dockmaster.ncsc.mil To: security@rutgers.edu Subject: TEMPEST
>This note explores the legal status of a surveillance
>technology ruefully known as TEMPEST[2].
Sorry, Chris. TEMPEST is the name of a U. S. DoD standard
for permissable emanations from equipment to be employed in
processing certain classified information in certain environ-
ments. The name of the "surveilance" technology is called
television. You are correct only to the extent that the code
word is sometimes erroneously used to refer to the vulnerability.
I have never heard it, even erroneously, used to describe the
surveilance.
>Using TEMPEST
>technology the information in any digital device may be
>intercepted and reconstructed into useful intelligence
>without the operative ever having to come near his target.
Well, near is a relative term. With hundreds of dollars of
equipment, some luck, and some special knowledge, you might be
able to read a CRT at a distance of tens of meters. Other
equipment is significantly more expensive. It is a little easier
on the other side of the pond where the number of scan lines is
higher. However, to gain useful intelligence, you may also have
to expend tens to hundreds of hours.
Of course, with the resources of a nation state, you might get
the distance up to low hundreds of meters. Since the data
involved may have a very long life, the expenditure may be
justified.
>The technology is especially useful in the interception of
>information stored in digital computers or displayed on
>computer terminals.
Close; reading information displayed on CRT's is relatively
easy. Reading LCDs or gas-panel displays is relatively
difficult. Reading most storage is virtually impossible.
> The use of TEMPEST is not illegal under the laws of the
>United States[3], .......
Well, the use of radios and televisions is not illegal in the US.
As long as you keep everything that you here to yourself, you
have not likely broken any laws. However, if you use any of that
information to enrich yourself, you may well have. You may have
broken laws against espionage, copyright laws, or criminal fraud
laws.
US law makes it illegal for you to broadcast certain signals and
for me to sell you equipment that does so. Nonetheless, you
broadcast information bearing signals at you own risk.
>....or England.
Canada has specific laws
criminalizing TEMPEST eavesdropping but the laws do more to
hinder surveillance countermeasures than to prevent TEMPEST
surveillance.
>In the United States it is illegal for an
>individual to take effective counter-measures against
>TEMPEST surveillance. This leads to the conundrum that it
>is legal for individuals and the government to invade the
>privacy of others but illegal for individuals to take steps
>to protect their privacy.
That is, at best, an overstatement. As I have said, the law
makes it illegal for you to broadcast certain signals and
certainly does not force you to broadcast any. It permits you to
employ quiet equipment, such as LCD's or gas-panels. It permits
me to sell it to you. It permits you to use ultra-quiet, TEMPEST
capable equipment. I might even be able to sell you such
equipment, though you would not likely want to pay for most of
it. For example, certain models of the GRID Case computer were
TEMPEST capable off-the-shelf out-of the-box.
However, without the permission of the DoD, I cannot sell you
equipment which I assert to be TEMPEST qualified. If I did, and
it were, I might be guilty of compromising classified
information. If I did, and it were not, I would be guilty of
misrepresentation. Nonetheless, the intent of the law is to
protect national security interest, not to force you,
gratuitously, to compromise yours, or deny you access to
legitimate measures to do so.
> The author would like to suggest that the solution to
>this conundrum is straightforward. Information on
>protecting privacy under TEMPEST should be made freely
>available;
Well, you may suggest what you like; your suggestions may even
be straightforward. Nonetheless, neither the issue nor the
solution are as straightforward as you imply or as others might
infer.
First, most information is available; I have just given you some.
A great deal of the rest is special knowledge that would not be
meaningful to the average buyer. The only information that I am
aware of that is, de jure, not available is the TEMPEST standard.
This standard was developed by the US DoD at its own expense for
its own purpose. That purpose would not be served by its
disclosure. It is not clear that any public good would be served
by its disclosure. They are prohibited by a very complex law
from disclosing it to you. It is not likely that law will be
changed any time soon.
>TEMPEST Certified equipment should be legally
>available; ....
If you can convince anyone else that is useful, develop your own
standard and your own certification program for your own purpose.
You will not succeed in subverting TEMPEST to your purpose.
>...and organizations possessing private information
>should be required by law to protect that information
>through good computer security practices....
If you use "private" as opposed to public, then they must have
done so. If you use "private" as synonomous with sensitve, it
can reasonably expected that they will do so.
>.... and the use of TEMPEST Certified equipment.
Be careful what you ask for; you might get it.
(Thank heaven that the editor did not post the whold paper.)
William Hugh Murray, Fellow, Information System Security, Ernst & Young
2000 National City Center Cleveland, Ohio 44114
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840
-----------[000056][next][prev][last][first]---------------------------------------------------- Date: Fri, 16 Feb 90 21:21:36 EST From: meister@gaak.lcs.mit.edu (phil servita) To: marks@whoville.umiacs.umd.edu Cc: misc-security@uunet.uu.net Subject: Re: bill changers
The bill changer i took apart, (one of the newer types found on Coke machines)
scanned a strip of bill 1/4 inch from the top, for light transmission. there
was also a read head to check magnetic response. the rest of the bill could
have been construction paper, and it would not have cared.
-meister
-----------[000057][next][prev][last][first]----------------------------------------------------
Date: 16 Feb 90 17:38:55 GMT
From: datri@CONVEX.COM ("Anthony A. Datri")
To: misc.security
Subject: Re: Bill Changers>Remind me to tell you an interesting way that con-artists can construct ... Easy -- chop the big numbers off the corners of a $20 bill, past them onto the corners of a $1 bill. Pass this as a $20 bill. Turn in the mutilated $20 for a fresh one. (no, I am not advocating the practice)
-----------[000058][next][prev][last][first]---------------------------------------------------- Date: 17 Feb 90 11:04:05 GMT From: jcp@cgch.UUCP (Joseph C. Pistritto) To: misc.security Subject: Re: tapes and x-ray machines
Actually, I bet a lot of it isn't actually. (Xrayed that is). I always put
stuff I'd rather not have Xrayed in my luggage, and I've never lost anything.
This includes tapes, (vido, audio, reel-to-reel data, and cartridge data),
disks (floppies of all sizes), and in particular film. I have one of those
lead lined film bags, and normally use it when travelling internationally,
(which is anytime I get on a plane, as I live in Switzerland, kinda pointless
to fly inside the country...)
> For the record, X-ray machines will not damage film less than 1000 speed.
> Most film used is 200 or 400. I also sent all my (exposed and unexposed)
> film through the X-ray machines in multiple airports with no problems.
ditto. I've had filmed Xrayed, as well as video equipment, with no problems.
> If you are still worried, you can purchase a lead film bag. I would
> suspect traveling internationally, the bag might draw attention.
The only place I've ever been asked is in India, four days after one of their
747's was taken out by a luggage bomb. They were _seriously_ into security at
the time. Matter of fact, just about the only time I've ever felt security was
being taken seriously at an airport. (But I've never flown El Al...)
Even then, it wasn't a hassle, I just had to show the man with the submachine
gun what was inside the bag...
More amusing was being interviewed by a local TV crew at the airport, which
asked me "aren't you scared to be flying Air India now? I mean, you're a
foreigner, why don't you buy a ticket on some other airline..." (This was the
STATE RUN (and only) TV network in India, mind you...) Amusingly enough, the
flight was almost empty, (except for victims families being flown to Ireland
to identify the bodies, lotsa laughs on the plane... :-( )
-jcp-
======================================================================
Joseph C. Pistritto HB9NBB N3CKF
'Think of it as Evolution in Action' (J.Pournelle)
Ciba Geigy AG, R1241.1.01, Postfach CH4002 Basel, Switzerland
Internet: bpistr@cgch.uucp Phone: (+41) 61 697 6155
Bitnet: bpistr%cgch.uucp@cernvax.bitnet Fax: (+41) 61 697 2435
From US: cgch!bpistr@mcsun.eu.net
-----------[000059][next][prev][last][first]---------------------------------------------------- Date: Sat, 17 Feb 90 21:33:13 -0500 From: Mark A. Schleifer <marks@umiacs.umd.edu> To: meister@gaak.lcs.mit.edu (phil servita) Cc: marks@umiacs.umd.edu, misc-security@uunet.uu.net Subject: Re: bill changers
> The bill changer i took apart, (one of the newer types found on Coke machines) > scanned a strip of bill 1/4 inch from the top, for light transmission. there > was also a read head to check magnetic response. the rest of the bill could > have been construction paper, and it would not have cared. Quite right. The one I took apart was from a Rowe changer. We had a problem with people using xerox copies of dollars. They would tape pieces of real dollars to the copy and run it trough. At other arcades they would then cover the holes in the real dollars with copys and pass it to busy cashiers. As long as you have the important section of a real bill in place the machine can't tell the difference. Are you sure that the it scanned for light trasmission? On the models I'm used to the optics at the top are just used to sense when a bill is being inserted, they then activate the feed moter. - Mark ---- Spoken: Mark A. Schleifer Domain: marks@umiacs.umd.edu UUCP: uunet!mimsy!umiacs!marks Phone: +1-301-454-7678 USPS: UMIACS, Univ. of Maryland, College Park, MD 20742
-----------[000060][next][prev][last][first]---------------------------------------------------- Date: 17 Feb 90 12:04:05+0100 From: Joseph C. Pistritto <jcp@cgch.uucp> To: <MFOWLER@gtri01.bitnet> Cc: <security@pyrite.rutgers.edu> Subject: Re: tapes and x-ray machines
Actually, I bet a lot of it isn't actually. (Xrayed that is). I always put
stuff I'd rather not have Xrayed in my luggage, and I've never lost anything.
This includes tapes, (vido, audio, reel-to-reel data, and cartridge data),
disks (floppies of all sizes), and in particular film. I have one of those
lead lined film bags, and normally use it when travelling internationally,
(which is anytime I get on a plane, as I live in Switzerland, kinda pointless
to fly inside the country...)
> For the record, X-ray machines will not damage film less than 1000 speed.
> Most film used is 200 or 400. I also sent all my (exposed and unexposed)
> film through the X-ray machines in multiple airports with no problems.
ditto. I've had filmed Xrayed, as well as video equipment, with no problems.
> If you are still worried, you can purchase a lead film bag. I would
> suspect traveling internationally, the bag might draw attention.
The only place I've ever been asked is in India, four days after one of their
747's was taken out by a luggage bomb. They were _seriously_ into security at
the time. Matter of fact, just about the only time I've ever felt security was
being taken seriously at an airport. (But I've never flown El Al...)
Even then, it wasn't a hassle, I just had to show the man with the submachine
gun what was inside the bag...
More amusing was being interviewed by a local TV crew at the airport, which
asked me "aren't you scared to be flying Air India now? I mean, you're a
foreigner, why don't you buy a ticket on some other airline..." (This was the
STATE RUN (and only) TV network in India, mind you...) Amusingly enough, the
flight was almost empty, (except for victims families being flown to Ireland
to identify the bodies, lotsa laughs on the plane... :-( )
-jcp-
======================================================================
Joseph C. Pistritto HB9NBB N3CKF
'Think of it as Evolution in Action' (J.Pournelle)
Ciba Geigy AG, R1241.1.01, Postfach CH4002 Basel, Switzerland
Internet: bpistr@cgch.uucp Phone: (+41) 61 697 6155
Bitnet: bpistr%cgch.uucp@cernvax.bitnet Fax: (+41) 61 697 2435
From US: cgch!bpistr@mcsun.eu.net
-----------[000061][next][prev][last][first]---------------------------------------------------- Date: Sat, 17 Feb 90 20:29:20 EDT From: Iqbal Qazi <WQ956C@gwuvm.bitnet> To: security@pyrite.rutgers.edu Subject: Re: Bill Changers
My roommate tells me that you can take a bill apart into two halves,
then stick, say the front of a twenty on the back of a 1, and vise-
virsa. Then you'd have 1 real 20 front and 1 real 20 back which you
could pass off. Is this for real?
Iqbal Qazi
WQ956C at GWUVM
-----------[000062][next][prev][last][first]---------------------------------------------------- Date: 17 Feb 90 18:53:28 GMT From: gopstein@soleil.uucp (Rich Gopstein) To: misc-security@rutgers.edu Subject: Opening an old safe?
I friend of mine has an old Victor safe which she purchased from someone who didn't know the combination. She's interested in using it, so she would like to know if it can be opened without destroying it. Any help or pointers to other information would be appreciated. Thanks. -- Rich Gopstein ..!rutgers!soleil!gopstein
-----------[000063][next][prev][last][first]---------------------------------------------------- Date: 18 Feb 90 00:29:20 GMT From: WQ956C@gwuvm.BITNET (Iqbal Qazi) To: misc.security Subject: Re: Bill Changers
My roommate tells me that you can take a bill apart into two halves,
then stick, say the front of a twenty on the back of a 1, and vise-
virsa. Then you'd have 1 real 20 front and 1 real 20 back which you
could pass off. Is this for real?
Iqbal Qazi
WQ956C at GWUVM
-----------[000064][next][prev][last][first]---------------------------------------------------- Date: Sun, 18 Feb 90 14:12 EST From: <CJS@cwru.bitnet> To: hobbit@pyrite.rutgers.edu Subject: Wireless Home Security Systems
Does anyone know how hard it is to jam or fool these wireless home security systems? Couldn't one just use a spectrum analyzer to determine what sort of signals the sensors sent to the main control unit -- and then replicate these signals? For example if I pumped out the signal that meant "everything is OK" a three watts it would drown out the "door is open" signal when I broke open a door. That doesn't sound very secure. CJS cjs@cwru.cwru.edu p.s. I suppose the FEDS system being tested to protect nuclear weapon storage areas would fall at the other end of the spectrum. According to the specs, when it detect an intruder the system releases nerve gas. Now that's a serious system.
-----------[000065][next][prev][last][first]---------------------------------------------------- Date: Mon, 19 Feb 90 06:54 CST From: douglas@ddsw1.mcs.com (Douglas Mason) To: misc-security@rutgers.edu Subject: Re: tapes and x-ray machines
If this makes you sleep any better (ha!) I became paranoid about my film going through x-ray machines and purchased a 'lead film bag'. Since I have had it, I have been through Heathrow airport in London three times now, and have NEVER had it checked. I put it in with my carry-on and every time I watch myself as it goes through 2 different x-ray machines every time I depart and saw for myself that it shows up as a completely solid object - you can't see anything inside at all. Isn't Heathrow supposed to have beefed up their security? I was there over Christmas when the big hype of a bomb was at it's peak -- still didn't check. These bags are about the size of an average lunch sack. On the other hand, Chicago's O'Hare airport has checked it EVERY time that I have gone through there, and I frequent that place! -Douglas Mason -- Douglas T. Mason | douglas@ddsw1.UUCP or dtmason@m-net |
-----------[000066][next][prev][last][first]---------------------------------------------------- Date: Mon, 19 Feb 90 09:41:52 CST From: Kevin LaFata <S899229@umslvma.bitnet> To: security@pyrite.rutgers.edu Subject: Re: RE: Home Alarm Installations, R.S. Setups
As an owner of a security system company, I would highly discourage
any wireless alarm that has no form of supervision. There are many types
of alarms that send low battery signals, as well as an "all is well" signal
which, if not received by the control panel every x minutes, will also
sound some kind of alarm. This prevents signal jambing. Personally (insert
my opinion here) I do not like the AT&T wireless system. It seems they
created a lot of hype about it and have exclusive dealers, etc. On company
that installed them had to replace all but 6 (out of about one hundred) units
because of a malfuntion. Even thought they were under warranty, it is still
unreasonable to have to replace that many.
You may have trouble buying a professional wireless system from a whole-
saler yourself, but many alarm companies are happy to sell them to individuals.
Kevin LaFata s899229@UMSLVMA
-----------[000067][next][prev][last][first]---------------------------------------------------- Date: Mon, 19 Feb 1990 13:13:42 EST From: "Don Z. Eng" <U953005@rutvm1.bitnet> To: security@ohstvma Subject: LAN security & control review
Does anyone have, and willing to share, a program on LAN security and control review? I am starting my first LAN review and can use some guidance. We use Novell Netware. Thanks. Don Z. Eng Rutgers University U953005@RUTVM1
-----------[000068][next][prev][last][first]---------------------------------------------------- Date: Mon, 19 Feb 90 13:50:40 EST From: "Larry Margolis" <MARGOLI@ibm.com> To: security@pyrite.rutgers.edu Subject: Bicycle locks
The previous article on bicycle locks got me interested, so I've been examining different locks. (Living in Manhattan, I am able to come across many broken locks to play with.) It was mentioned that some bike locks had a rivet that could easily be removed, letting you pop out the lock cylinder. The Master brand Kryptonite-type lock (tube that locks over the open ends of a U-shaped round bar) has such a rivet, however removing it will not let you open the lock. If the lock is opened, you will be able to rotate the cylinder, but not if it's locked. In addition, there's a ring around the face of the cylinder that has to be removed in order to remove the cylinder (and the lock must be open). It's as easy to pick as your average Master padlock, so I wouldn't trust it too much, but it is safe from rivet removal. I found another one that I'd strongly recommend you avoid. The plastic was partly scraped off, so I couldn't make out the name, but it ends with NG-TAY. First, removing the rivet let the cylinder rotate which *did* let you open the lock. Second, instead of solid brass top pins, it used hollow shells that the springs rested in. This is apparently how the thief opened the lock - stuck in a screwdriver and gave it a good twist. The shells crumpled and the lock opened. Third, it looks like the serial number printed on the plastic is actually the key levels, so you could just look at the lock, then make a key to it with a key machine and a depth-key set. (I'd have to see another one of these locks to verify this last point.) Larry Margolis, MARGOLI@YKTVMV (bitnet), MARGOLI@IBM.COM (csnet)
-----------[000069][next][prev][last][first]---------------------------------------------------- Date: Mon, 19 Feb 90 19:17:17 -0500 (EST) From: Christopher Gene Behanna <cb2s+@andrew.cmu.edu> To: security@pyrite.rutgers.edu Subject: Honda motorcycle keys
Recently, a friend of mine bought a 1983 Honda Shadow 750. He tried his key in my 1985 Honda Shadow 700, and was able to unlock the forks as well as turn on the ignition circuit. Ditto my key in his bike. For laughs, we tried our keys on his roommate's 1983 Honda CB1000, and we were both able to turn the parking light on (we couldn't turn the cylinder the rest of the way to "on"). Now, what I want to know is, does Honda consider this a feature or a bug? IMHO, selling a bike that any owner of a similar bike can come along and steal (for parts or otherwise), is a great act of irresponsibility on the part of the manufacturer. I'm not terribly worried--I have an enormous folding steel lock that I use on my front wheel, but folks who don't have an extra $50 lying around to buy a similar lock SHOULD worry. Chris BeHanna behanna@reagan.psc.edu
-----------[000070][next][prev][last][first]---------------------------------------------------- Date: 19 Feb 90 15:41:52 GMT From: S899229@umslvma.BITNET (Kevin LaFata) To: misc.security Subject: Re: RE: Home Alarm Installations, R.S. Setups
As an owner of a security system company, I would highly discourage any wireless alarm that has no form of supervision. There are many types of alarms that send low battery signals, as well as an "all is well" signal which, if not received by the control panel every x minutes, will also sound some kind of alarm. This prevents signa