The 'Security Digest' Archives (TM)

Archive: About | Browse | Search | Contributions | Feedback
Site: Help | Index | Search | Contact | Notices | Changes

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