|
|
ARCHIVE: Rutgers 'Security List' (incl. misc.security) - Archives (1987)
DOCUMENT: Rutgers 'Security List' for April 1987 (15 messages, 10229 bytes)
SOURCE: http://securitydigest.org/exec/display?f=rutgers/archive/1987/04.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.
START OF DOCUMENT
-----------[000000][next][prev][last][first]---------------------------------------------------- From: chuq@Sun.COM (Chuq Von Rospach) 3-Apr-1987 15:48:07 To: LINNIG@ti-eg.csnet, security@rutgers.edu
> Does anyone out there know anything about the photo sensors that you > can see on top of traffic lights? > > I have heard that they detect emergency vehicles (who use a special strobe) > and switch the traffic light to green. They use a strobe. If you have a nice, strong engine timing light and set it up so you can change the frequency, you adjust it so taht it'll set them off. I wouldn't let the cops catch you doing it, though...
-----------[000001][next][prev][last][first]---------------------------------------------------- From: Dick Peters <SPGRAP%UCBCMSA.BITNET@wiscvm.wisc.edu> 3-Apr-1987 18:12:46 To: SECURITY@RED.RUTGERS.EDU
Since we run PROFS ourselves, I do not think the problem was that stuff was not actually delete from the system when the files were erased. PROFS actually does erase mail files when they are discarded. From the sources I talked to at a recent conference, I believe they fell into the trap of good system management. In order to prevent massive data loss in case of a disaster, their system management does periodic backups of all files (including mail files) on the system. These tapes are retained for a period of time and then recycled. In fact, my source said that the critical tapes were almost ready to be recycled when they were examined. On the other side of the coin, One of IBM's big selling points on PROFS is that in a properly managed data center, PROFS prevents the loss of corporate assets (data) by accidental or intentional actions since the data is managed by a central site rather than being on a PC. All their documentation states that for non mail files (i.e. document files), that these files are maintained centrally and will not be lost even if removed by the user. My understanding was that the discovered files were, however, mail files rather than document files.
-----------[000002][next][prev][last][first]---------------------------------------------------- From: "Keith F. Lynch" <KFL@AI.AI.MIT.EDU> 4-Apr-1987 15:46:29 To: Security@RED.RUTGERS.EDU
I wouldn't be so sure that messages are really deleted. I understand there are ways to reconstruct OVERWRITTEN data on a disk, given sufficient time and resources. SECRET disks must be overwritten several times with various bit patterns before being unclassified, and SCI disks must be physically destroyed. Users desires are often in conflict. They may want deleted things to be really deleted, but they probably also want a way to recover something that was accidentally deleted. The usual resolution of this is to fix it so that deleted things are not really deleted, but can only be recovered by the vendor. This may be construed as dishonest, but the only way the client would ever find out that deleted things aren't really deleted is if he asks you to undelete something, or if the authorities ask you to undelete something. In the latter case, while you may lose the clients, it doesn't really matter since they are quite likely in jail. And what if you deliver a system which REALLY deletes things, but the local system staff does regular backups, or the end user reads his messages in hardcopy and then files them in a filecabinet or a dumpster? True deletion requires a complete overview, which neither the vendor nor the end user or the local system staff generally has. ...Keith
-----------[000003][next][prev][last][first]---------------------------------------------------- From: Douglas Humphrey <deh@eneevax.umd.edu> 4-Apr-1987 21:25:16 To: Security@RED.RUTGERS.EDU
In the system that we have here, you have the choice as the sender of the message to determine if you want the ARCHIVE bit set on or not. ARCHIVE function assures that the message will get logged as archived in a list online, and that the end of the day Archive tape will include this message. Note that the archival tapes are encrypted, and that two copies are kept, one onsite and one off. U can have the bit set automaticaly for certain classes of messages, but in all cases the system will remind you that the message is getting archived. As to erasure of deleted messages, the standard guidlines are followed for the deletion of Secret information. A number of passes are made on the file blocks, writting selected patters (patterns) of data. All to the recomendations of the folks up the Parkway from here (we are in Greenbelt MD). If the system were ever to handle SCI or higher data, then provisions would have to be made to destroy disk storage media when it had filled up, and of course to assure that once a disk block was used it was not used again. The system already has the capability to use a particular disk device for a particular class of message. Obviously, the important thing here is that the user needs to be very aware of exactly where their data is going, and what is being done with it when it is sensitive data. If North and company had known that all of their wonderful data was going to around for people to see, then I expect that there might have been held an emergency destruction drill at the NSC office that might have included the system hardware itself ! Since they are running IBM and PROFFS, this would seem to be no great loss.... Lets here it for a better educated user community !! Doug
-----------[000004][next][prev][last][first]---------------------------------------------------- From: Simson L. Garfinkel <simsong@MEDIA-LAB.MEDIA.MIT.EDU> 5-Apr-1987 11:54:24 To: security@red.rutgers.edu
From: codas!ki4pv!tanner@rutgers.edu I prefer the simpler policy of cutting off the fingers of anyone who leaves a trojan horse around without my permission. Assuming that you find out that somebody left the trojan horse around in the first place. The cleaver people who break security don't announce the fact -- they just use their extra access whenever necessary, always very discretely. If I have a setuid program that makes me you so I can do things like read your personal files, and I hid it in a protected sub directory, how are you doing to find out that I'm reading your personal files? How often to you look at the last access time on filestamps? Simson L. Garfinkel MIT Media Lab
-----------[000005][next][prev][last][first]---------------------------------------------------- From: E Gordon Strong <@EDDIE.MIT.EDU:GS@DEEP-THOUGHT.MIT.EDU> 6-Apr-1987 13:38:20 To: security@RED.RUTGERS.EDU
Could someone provide pointers to recent papers/books/etc addressing the question of security under unix? I am particularly interested in information relating to NCSC ratings of unix-based systems. Information on available security software (auditing programs, security kernels, etc) or any first-hand information on sites running "secure" installations would be very helpful. Any information would be appreciated. Please reply directly as I am not a regular reader of this list. Gordon Strong gs%ee@mit-xx (Arpa) gs@mit-eddie (uucp)
-----------[000006][next][prev][last][first]---------------------------------------------------- From: <SYSTEM%CRNLNS.BITNET@wiscvm.wisc.edu> 7-Apr-1987 10:24:35 To: security@red.rutgers.edu
There have been some security related discussions on the
TCP-IP mailing list recently, as a result of somebody
accidentally sending a message to just about every machine on
the internet.
I found the implications of the last part of the following
message rather disturbing, and thought it should be shared
with the readers of "security".
Selden Ball
system@crnlns.bitnet
------------------
Date: Mon, 06 Apr 87 10:55:12 -0800
From: Robert Allen <ROBERT@SPAM.ISTC.SRI.COM>
Subject: Re: My Broadcast
> Whoa!
>
> Encouraging people to find holes and then use them to make the local system
> programmers work on them is wrong. It is like encouraging people to find out
> if their neighbors lock their door during the day so they will. Do you really
> want that or do you want the theives to be caught? I want the theives to be
> caught and the ability to leave my door open. I don't want to fear my
> neighborhood or my users.
While this doesn't deal directly with TCP-IP, it is a *very* important
consideration in the Internet in particular, and any network in general.
Often a so-called 'breakin' does not even require that a user maliciously
"try their neighbors doors" to see if they can gain restricted permissions
or access. Often curiosity alone is enough to cause problems. Example 1:
a first-time UNIX user was learning about the file system, and in particular
how to delete files. He was told that he could only delete files owned by
him, and by way of counterexample his mentor typed "rm /etc/passwd".
Surprise, /etc was writeable and the file was gone. Example two: the recent
rlogin breakins at Stanford. Example 3: Obviously if you have hardware
access to the transmission medium you can unintentionally wreak havoc merely
by using someone elses IP address.
I too would like to live in a word where I can leave my "door unlocked".
Unfortunately it doesn't take more than a very few nasty or ignorant persons
to cause problems. Due to the fact that computers have evolved in an
atmosphere of sharing (time sharing, memory sharing, src sharing..)
we have yet to realize the responsibilities and risks of trusting them too
much. I.e., there is a big difference between leaving your door
unlocked but closed, and spreading $20.00 bills on your front lawn.
In the case of J. Hubbards 'wall' to the Net, the problem was not
caused by a malicious person, but by simple curiosity.
At the recent TCP/IP Conference in Monterey CA, some discussion was
given to "network security". From the military standpoint they want
the ability to send data through a network, such that anyone who
captures the data won't be able to read or use it. While this may
be a prerequisite for the military, I don't think that 'normal' users
should expect that their Email be any more secure than their USMail.
The best method of keeping something secure on a network is to physically
seperate it. Or, do what I do, and don't put anything on the system
which you wouldn't read by someone else under the worst case scenario.
Fixing security 'features' is obviously important, and should be pursued.
Catching malicious persons doing damage is also extremely important. But
"catching the theives" is not the answer to a lack of network security.
If your network rolls out a red-carpet to someone then don't be surprised
if you find muddy footprints on it the next morning. I leave you with
two examples quoted from the January 1987 issue of the ACM Software
Engineering Notes...
"The computer security administrator at Roche ... had been
plagued by a hacker who auto-dialed the entire Roche phone
system in sequence. .... They laid a hacker trap on one of
the PC's and traced the call. Once the suspect was found,
it was even harder to get him arrested since he was in
New York, and Roche in New Jersey (which got the FBI involved).
The perp was brought into the police station and had the riot
act read to him... He was not charged -- because there wasn't
a **no-trespassing** sign on the hacker trap identifying the
system as private proberty of Roche."
" "Welcome to the ______ System" ... A Mass. financial firm
that had attempted to prosecute a hacker who had penetrated
their system. The defense lawyer argued that the system had
a greeting that welcomed people to the system, and that was
tantamount to welcoming someone intor your home. The judge
threw out the case, accepting the arguments of the defense.."
Robert Allen,
robert@spam.istc.sri.com
-----------[000007][next][prev][last][first]---------------------------------------------------- From: *Hobbit* <AWalker@RED.RUTGERS.EDU> 8-Apr-1987 21:12:09 To: security
Resending has sagged a bit due to the domain-names-only host table conversion. I therefore had to fix *my* entire list so it would work again, and naturally there were some additional quirks. I think I have it straight now, but please notify security-request of any problems. Most mailer errors return to me, but if you get any consistent ones please forward them... Hang on, here comes lots of stuff! _H*
-----------[000008][next][prev][last][first]---------------------------------------------------- From: McNelly.OsbuSouth@Xerox.COM 9-Apr-1987 13:05:28 To: brock@pnet01.CTS.COM
You know, I heard about that, and I said to myself, boy that was stupid, if it had been ME... and I started thinking. If it had been me, first of all, I would have told the President what a stupid idea it was to provide Iran with arms in exchange for hostages. But NoooOOooOoo, he does it anyway, and now we've been found out. I would do what I could to protect the presidency. I would do that by shredding all the incriminating paper evidence. But I know there's going to be an investigation, and people are going to want to know why I shredded this stuff if there's nothing to hide. This is the beauty. I get the archived hard disks, and I patch the mail messages to say something that, while still incriminating, isn't so bad as the full-blown truth. I then wait for the disks to be discovered. The investigators eventually find the disks, and they laugh at me for being so stupid. But the jokes on them, if they think that archives can't be tampered with. John McNelly McNelly.osbuSouth@Xerox.COM
-----------[000009][next][prev][last][first]---------------------------------------------------- From: David M. Balenson <balenson@icst-ssi.ARPA> 10-Apr-1987 14:50:35 To: security@RUTGERS.EDU
For your information, here is a copy of the Federal Register Notice regarding the second review of Federal Information Processing Standard (FIPS) 46, Data Encryption Standard (DES). If interested, please submit your written comments by June 4, 1987. The more comments we receive, the better NBS will be able to take a stance regarding the future of DES. Please feel free to distribute this notice to all who may be interested. Thank you. David M. Balenson (DB) [balenson@icst-ssi.ARPA] Security Technology Group / Computer Security Division National Bureau of Standards Technology A216 Gaithersburg, Maryland 20899 (301) 975-2910 ---------------------------------------------------------------------- Federal Register / Vol. 52, No. 44 / Friday, March 6, 1987 / Notices ---------------------------------------------------------------------- National Bureau of Standards [Docket No. 70109-7009] Second Review of Federal Information Processing Standard 46, Data Encryption Standard (DES) AGENCY: National Bureau of Standards, Commerce. ACTION: Notice of second review of federal information processing standard (FIPS) 46, data encryption standard. ---------------------------------------------------------------------- SUMMARY: Federal Information Processing Standard 46, Data Encryption Standard, issued in 1977, provides an algorithm to be implemented in electronic hardware devices and used for the cryptographic protection of computer data. The standard provided that it be reviewed within five years to assess its adequacy. The first review was completed in 1983, and the standard was reaffirmed for Federal government use (48 FR 41062 dated September 13, 1983). The purpose of this notice is to announce the second review to assess the continued adequacy of the standard to protect computer data. Comments from industry and the public are invited on the following alternatives for FIPS 46. The costs (impacts) and benefits of these alternatives should be included in the comments. o Reaffirm the standard for another five (5) years. The National Bureau of Standards would continue to validate equipment that implements the standard. FIPS 46 would continue to be an approved method for protecting unclassified computer data against unauthorized modification or disclosure. o Withdraw the standard. The National Bureau of Standards would no longer continue to support the standard. Organizations could continue to utilize existing equipment that implements the standard, and non-government organizations could continue to develop new implementations as desired. Government organizations would begin to utilize new security devices as they become available through the Commercial Communication Security Endorsement Program of the National Security Agency. o Revise the applicability of the standard. The applicability statement of the standard would be changed to specify certain uses, such as using the standard for protecting Electronic Funds Transfers. Proposed technical changes to the algorithm will not be considered during this review. Interested parties may obtain a copy of FIPS 46 from the National Technical Information Service (NTIS), 5285 Port Royal Road, Springfield, VA 22161, telephone (703) 487-4650. DATE: Comments on this second review of FIPS 46 must be received on or before June 4, 1987. ADDRESS: Written comments concerning this standard should be submitted to the Director, Institute for Computer Sciences and Technology, ATTN: Second Review of FIPS 46, Technology Building, Room B154, Gaithersburg, MD 20899. Written comments received in response to this notice will be made part of the public record and will be made available for inspection and copying in the Central Reference and Records Inspection Facility, Room 6628, Herbert C. Hoover Building, 14th Street between Pennsylvania and Constitution Avenues NW., Washington, DC 20230. FOR FURTHUR INFORMATION CONTACT: Dr. Dennis Branstad, Institute for Computer Sciences and Technology, National Bureau of Standards, Gaithersburg, MD 20899, (301) 975-2913. Dated: February 26, 1987. Ernest Ambler, Director [FR Doc. 87-4707 Filed 3-5-87 8:45am] Billing Code 3510-CN-M ----------------------------------------------------------------------
-----------[000010][next][prev][last][first]---------------------------------------------------- From: ag@pnet01.CTS.COM (Keith Gabryelski) 11-Apr-1987 15:59:23 To: crash!security@rutgers.arpa@nosc.mil
Granted, your typical delete-a-file fuction does not actually erase the data from the disk, but actually marks the space as unused for later reallocation. This, however, has an easy remedy: You would simply modify your delete fuction to first overwrite the file with zeros, or your favorite ASCII character, before it marks the space as 'unused'. This process would ensure that a file that is deleted would be completely erased from the medium. Pax, Ag
-----------[000011][next][prev][last][first]---------------------------------------------------- From: bzs@bu-cs.bu.edu (Barry Shein) 12-Apr-1987 13:38:53 To: KFL@AI.AI.MIT.EDU
I've seen an amusing variation at some installations. Typically, for some reason (which seemed clever at the time), the system's mgt decides to use a tape archive (eg. UNIX CPIO or TAR) to do backups rather than some rational utility. A good example of a reason is that you can use a 'find' pipe with CPIO and back up files only if the meet some condition which, if you like, can be quite convuluted (> N days old, > N bytes, !owned by system etc), usually to save tape and backup time. Well, these utilities back up files, but not deletions. If a disaster occurs and the system has to be recreated one sees all the deleted files return to disk with whatever protections they happened to have when backed up. Needless to say someone who (eg) was going on sabbatical for a year and cleaned up all their sensitive files might be somewhat miffed to come back and find they had been sitting back on the disk for the past 11 months. Obviously the fix is to also backup recent copies of the state of the directories and apply those last, but this doesn't seem to be done by these sites when they report problems on the technical lists. -Barry Shein, Boston University
-----------[000012][next][prev][last][first]---------------------------------------------------- From: "Keith F. Lynch" <KFL@AI.AI.MIT.EDU> 12-Apr-1987 17:45:51 To: Security@RED.RUTGERS.EDU
I don't know exactly how. I think it involves careful measurement of residual magnetism. For instance if the magnetism of a binary 0 is nominally -100 and of a binary 1 is nominally +100, then a 0 overwritten with a 1 might be +98, a 0 overwritten with a 0 might be -102, a 1 overwritten with a 0 might be -98, and a 1 overwritten with a 1 might be +102. A normal disk drive might accept anything less than -30 as a 0 and anything more than +30 as a 1, but a special disk drive could be built which reads the actual amount of magnetism, and software could then be written to use this drive to reconstruct erased data. (The actual details would be a little different - I think most disk systems use a transition between magnetic domains to encode a bit, not the domains themselves.) I know there are similar devices in use for reconstructing data from a damaged or crashed disk. I understand they are extremely slow and very expensive, but they do exist, and they do work. The way to REALLY delete data is to overwrite it with all 0s, then overwrite it with all 1s, and then overwrite it with a random pattern of bits. This is how disks classified SECRET must be erased to be declassified. But apparently it is believed that a sufficiently determined person could even read through this, as disks containing data with a higher classification must be destroyed to be declassified. Of course most DELETE, KILL, PURGE, DEL and rm commands do not even overwrite the data, but simply remove the pointer to it. Which is how it is possible for programs like the Norton utilities to un- delete a deleted file. This was a major problem with VMS before version 4.0 - a user could (and still can if the system manager isn't on the ball) create a large file and not write into it and read lots of other people's deleted files. Everything above applies equally to hard disks, floppy disks, magnetic tapes, and magnetic core - not to RAM or ROM though. North, et al, had their mail files read not by any of these techniques but simply from backups that were routinely made. ...Keith
-----------[000013][next][prev][last][first]---------------------------------------------------- From: bzs@bu-cs.bu.edu (Barry Shein) 12-Apr-1987 21:19:25 To: Security@RED.RUTGERS.EDU
The other problem with backup procedures that don't backup deletions is lord help you if the disk was almost full when the disaster struck and the restoral exceeds 100% of the disk (as you needed those deletions to make it all fit, not uncommon as often almost full disks get preened constantly to fit the next thing on.) The resulting games when the restoral utility fails due to a full disk are generally not a pretty sight (site?) -Barry Shein, Boston University
-----------[000014][next][prev][last][first]---------------------------------------------------- From: Michael Robinson <MIKE%UTCVM.BITNET@wiscvm.wisc.edu> 14-Apr-1987 02:09:34 To: SECURITY@RED.RUTGERS.EDU
> From: codas!ki4pv!tanner@rutgers.edu > > I prefer the simpler policy of cutting off the fingers of anyone who > leaves a trojan horse around without my permission. > ^^^^^^^^^^^^^^^^^^^^^ Now there has to be some interesting psychology in that, although I'm sure that the writer didn't notice. What would prompt him to give his permission to anyone to do such a thing? And what would give him the authority to say? The best of security systems are viewed from the outside and pronounced invulnerable. But they are most easily attacked from the inside.
END OF DOCUMENT
| ISSN 1742-948X 01 (Online) | 2005/03/01 | Copyright 2002-2008 securitydigest.org. All rights reserved. |