HDTenEightyP/NetNews huggingface dataset:
From: ca393@cleveland.Freenet.Edu (Scott D. Wells)
Newsgroups: comp.security.misc
Subject: Re: Need reference for court case
Date: 9 Oct 1992 00:09:58 GMT
Organization: Case Western Reserve University, Cleveland, OH (USA)
Reply-To: ca393@cleveland.Freenet.Edu (Scott D. Wells)
NNTP-Posting-Host: hela.ins.cwru.edu


In a previous article, fstuart@eng.auburn.edu (Frank Stuart) says:

>In article <Bvo9vF.JuL@cs.psu.edu> jim@math.psu.edu (Jim Duncan) writes:
>>In article <1992Oct5.024348.23203@msuinfo.cl.msu.edu> rjs@crs.cl.msu.edu
>>(Robert J. Stanton) writes:
>>> I heard or read of a case a while back where the hacker
>>> who was being proseuted was exonerated because the system
>>> that he broke into printed a "welcome" greeting.
>>> 
>>> Can anybody point me to some info about this, preferably 
>>> something in print?
>>
>>I asked about this at the USENIX Unix Computer Security Symposium in
>>Baltimore a few weeks ago and Gene Spafford told me that this appears to be
>>an urban legend.  I don't have the details, but I believe he cited a search
>>of LEXIS by some researchers looking for just the case you mention and
>>nothing was found.
>>
>>That's not to say that someone didn't start to bring the case and then
>>dropped it before it got to trial.
>>
>>Sorry I don't have some details for you.
>
>I've heard some version of this story.  As I recall, it was a voice-mail
>system.  Sorry, but I don't have details either.
>
>
>Frank Stuart           |   Slower traffic keep right.  |  Don't Panic
>fstuart@eng.auburn.edu |   MMMMMmmmmm lutefisk.        |  Never moon a werewolf
>


Yes, there was a hacker indicted.  The case was dropped...
The prosecuting attorneys said it was because there was a message on
login that welcomed users...welcoming hackers.  That was not the real 
reason though, they could not get anough log evidence to support their
case and prove the hacker guilty.  The login message thing was just 
said because they didn't want to admit they messed up.

Scott
ca393@po.cwru.edu

-- 
Krynn - ca393@po.cwru.edu 
         CyberGod
Newsgroups: comp.security.misc
From: rbalkenh@sookit.jpl.nasa.gov (robert balkenhol)
Subject: Re: B1security level
Organization: Jet Propulsion Lab
X-Newsreader: TIN [version 1.1 PL6]
Date: Wed, 14 Oct 1992 18:18:04 GMT

Artur Romao (artur@morgaine.puug.pt) wrote:
: Does anyone know if there is any version of UNIX that implements the
: B1 level.
: 
: thanks in advance.

Harris Computers offers the "Nighthawk" system
with their own flavor of UNIX.  I may be wrong, but I seem to recall
that it was either B1 or B2.
--
****************************
Robert Balkenhol
Jet Propulsion Laboratory
rbalkenh@sookit.jpl.nasa.gov



Newsgroups: comp.security.misc,alt.security,alt.sources.d,comp.sources.testers,comp.unix.admin
From: adair@eggo.tmc.edu (Jonathan Adair)
Newsgroups: comp.security.misc
Subject: Re: IBM password
Date: 8 Oct 92 20:53:07 GMT
Organization: University of South Florida, Department of Computer Science and Engineering

In article <1992Sep29.095334.20666@ghost.dsi.unimi.it> cotrozzi@ghost.dsi.unimi.it (Massimo Cotrozzi) writes:
>bill@chaos.cs.umn.edu ( Hari Seldon     psychohistorian ) writes:
>
>If you don't mind for people booting your PC with MSDOS 5.0,
>editing the disk and changing the line in config.sys that says
>DEVICE=C:\DRDOS\LOGIN.EXE to something like
>REM CE=C:\DRDOS\LOGIN.EXE
>and then boot your computer again.
>You could put a BIOS password but then if someone takes the battery out you're done
>again.
>There's no way to protect a PC from use by unauthorized users ..
>( I am not talking just for DOS, for UNIX too . Think about it !!!)


I used to use some cheap password program that went in the config.sys.
I didn't think of it, but they suggested it in the docs for the program,
but if you rearrange the jumpers/cables for the floppy drive(s), you
can move your A: drive to B: (if you only have one drive), and then
someone can't boot your machine off of floppy without actually opening 
it up.  It's not tremendously secure, but I think someone is a lot less 
likely to open a machine up than they are to put a bootable floppy in 
a drive.  And if you get seriously wierd with your case, like arc-welding
a new case from 1/4" steel...I guess you could actually approach real 
security.
From: rlee@csugrad.cs.vt.edu (Rich Lee)
Newsgroups: comp.security.misc
Subject: Re: HELP! (Re: IBM password)
Date: 16 Oct 92 19:46:23 GMT
Organization: Virginia Tech Computer Science Dept, Blacksburg, VA


This CANNOT be an undocumented BIOS "feature". First you got the computer
to boot with the floppy.  That would not have happened if the BIOS
was protected.  After you boot from floppy It is all text book.  
I would just format the sucker and clone it off of another lab machine.
(Easiest and normally student labs not have data on them anyway)

Also did you ever consider that it was someone outside the school??

To prevent this in the future.  Take out the HD and buy and network.
That's what Va Tech did .  It works pretty well.

-- 
 | What if life was |   Richard Lee               |                         |
 | an EtchaSketch   |   1711 Whipple Dr.          | rlee@csugrad.cs.vt.edu  |
 | and GOD decided  |   Apt 11                    |                         |
 | to start over    |   Blacksburg,Va 24060       | rlee@earth.tjhsst.edu   |
Newsgroups: comp.security.misc
From: mech@bluemoon.rn.com (Paul J. Mech)
Subject: Security problems with vendor supplied package
Organization: Blue Moon BBS ((614) 868-998[024])
Date: Fri, 16 Oct 92 01:41:06 EDT


I believe that I've got a security problem in the making and would
appreciate any advice that net.wisdom might be able to provide.  I
am administering a growing network of 386 machines running Sys V rel
4 UNIX.  We will likely form an internetwork with several other
companies in the next few months. (And I hope to have them connected
with the rest of the world in the near future.)
 
There is a product that, due to decisions made from on high, did not
receive more than cursory scrutiny before purchase.  Unfortunately,
this package, which "handles all of its security internally," specifies
that all of its files and directories must bear rwxrwxrwx permissions,
that is except for the two executables owned by root that have the 's'
bit set for the owner.  Perhaps I'm missing something, but not only
are they leaving the barn door open, they seem to have forgotten to
build the barn in the first place.
 
I tried to point out the dangers involved with such permissions, not
only for direct attacks on root, but due to the very fact that all
the accounting data is world accessable and easily vulnerable to
corruption and erasure attacks, even if they bothered to encrypt their
data.  I suggested some simple solutions (eg: setuid to their specified
uid rather than root), but was told that it was "not an application
problem" but a "system problem."  Furthermore, I was told that "all
users access a UNIX system through a menuing program" and that they
should "never have shell access!"  I gather that these are nice DOS
and Novell people, that have done the minimum to get their package
running under UNIX. ( To quote the nice lady, "I've never heard of
TCP/IP." )
 
I am limited by lack of handy reference materials at this job, and
was wondering if some folks could provide a few pointers to published
(via network or book) materials that I might point them to for an
education, or suggest ways to adaquately encapsulate this nightmare.
(I'm toying with a couple of ideas, but am by no means satisfied with
them yet.  I'm really leaning toward having them return the package.)
 
Thanks in Advance,
Paul J. Mech


 This is from
     mech@bluemoon.rn.com
who doesn't have his (or her) own obnoxious signature yet
Newsgroups: comp.security.misc
From: sharen@iscnvx.lmsc.lockheed.com (Sharen A. Rund)
Subject: Re: B1security level
Organization: Lockheed Missiles and Space Co.
Date: Wed, 14 Oct 92 17:17:17 GMT

In article <1992Oct14.112536.16722@puug.pt> artur@morgaine.puug.pt (Artur Romao) writes:
>Does anyone know if there is any version of UNIX that implements the
>B1 level.
>
I understand that CRAY tried to do something like that and found they
bit off more than they could chew - in the meantime Convex has a C2
that has been approved


-- 
________________       __        ________________   "They that can give up
\_________      \     /_ \      /      _________/  essential liberty to 
 \_________      \_____/  \____/      _________/  obtain temporary safety
  \___________________      __________________/  deserve neither liberty 
                     /______\                   nor safety."  
ALL disclaimers apply ....                           --Benjamin Franklin
	  
Newsgroups: comp.security.misc,alt.security
From: uri@watson.ibm.com (Uri Blumenthal)
Subject: Re: IBM password
Date: Thu, 08 Oct 1992 18:50:37 GMT
Distribution: usa
Reply-To: uri@watson.ibm.com
Disclaimer: This posting represents the poster's views, not necessarily those of IBM
Organization: Do you care? Why?

In article <1992Oct6.153908.1597@infodev.cam.ac.uk>, 
rja14@cl.cam.ac.uk (Ross Anderson) writes:
|> In <bontchev.718376938@fbihh>, bontchev@fbihh.informatik.uni-hamburg.de 
|> (Vesselin Bontchev) writes:
|> > DES is strong enough. In fact, you have to choose very carefully, if
|> > you want to get weak keys... :-) There are only 4 weak keys in the
|> > whole 2^56 keyspace...
|> 
|> I looked at what a PC dealer said was the top-selling office automation 
|> suite. It was called Da Vinci or something like that. Look, it's even 
|> got DES encryption!
|> .................
|> Until I had a closer look, that is. It takes one password of up to eight
|> characters and produces a ciphertext file with visible eight-byte block
|> patterns - must be ECB (or something similar but homemade).
|> 
|> Looks like a PC will be enough to do keysearch on this one: just encrypt
|> a null string with all the passwords in a dictionary, and sort the list.

Looks like that? OK, try to break it on your PC and post the result (:-).

Now seriously - it's still unfeasible to break on your home PC,
or on your business supercomputer. There still are those 2^56
space for the key, though that stupid ECB mode definitely
makes it easier for various attacks (and I thought that
nobody is using ECB in the real world :-). Those
patterns you spotted aren't going to help you
much - in order to be able to apply those
you'll have to have more than 2^40 of
those 8-bytes blocks with known
corresponding plaintext (:-).

Newsgroups: comp.security.misc
From: howesb@monashee.sfu.ca (Charles Howes)
Subject: Re: Secure shell by mail
Organization: Simon Fraser University, Burnaby, B.C., Canada
Distribution: usa
Date: Wed, 14 Oct 1992 07:06:34 GMT

In article <1bfo95INN6a4@nym.ossi.com> aegl@ossi.com (Tony Luck) writes:
>barmar@think.com (Barry Margolin) writes:
>>In article <1992Oct13.172459.28720@zip.eecs.umich.edu> ayman@eecs.umich.edu (Ayman I. Kayssi) writes:
>>>I posted a question on comp.unix.questions about how to get a shell by email,
>>>that is a shell that would execute what's in the body of an email message.
>>>All the details have been worked out except for one thing: security.
>
>>How about this:
>
>>Include in the header a string in both plaintext and encrypted form.  The
>>receiving system would decrypt the encrypted form and compare it to the
>>plaintext.
>
>>One problem with this is that it's quite amenable to known-plaintext
>>attacks.  And it also requires a decryption key to be stored on the
>>destination system, unless you use a public-key encryption system.
>
>Such a system would be easily spoofed by a "replay" attack.  If I ever get
>hold of one of the messages, I just take the header (which has a valid key
>on it) attach a different shell script, and send it!  Bang!

How about encode a sequence number, and disallow repeated sequence numbers?

The replay attack goes away.  However, a sysop on the route your message
travels could copy your message, replace the commands, and send his message
*before* your message.  Significantly harder, but it's not A1 security.
Newsgroups: comp.security.misc
From: markh@wimsey.bc.ca (Mark C. Henderson)
Subject: Re: Secure shell by mail
Organization: BC News and Mail
Distribution: usa
Date: Thu, 15 Oct 1992 00:46:26 GMT

In article <1992Oct13.172459.28720@zip.eecs.umich.edu> ayman@eecs.umich.edu (Ayman I. Kayssi) writes:
>I posted a question on comp.unix.questions about how to get a shell by email,
>that is a shell that would execute what's in the body of an email message.
>All the details have been worked out except for one thing: security.
>Currently, security is obtained using the following:
>1- the subject of the message is a certain (fixed) special string
>2- a header line is added which contains an encrypted string
>You can see that the problem is that the message itself contains the security
>keys, and therefore anyone can intercept the email and fake a message...
>So, are there any suggestions on how to make this more secure?
>Email or post...

Sounds like an application of RSA digital signatures to me.

Have all of your "authorised users" generate a keypair. They each give
you their public keys, which you store in some sort of database.

Then the "authorised users" can sign the list of commands (script) they want
to have executed and mail it in.

You check the signature when the mail is received before you run
the script they send you. 

This scheme is such that, if the message is altered, or an unauthorised
user (without access to a secret key corresponding to a public key you
have on file) sends a script the signature shouldn't verify.

Problems:
1. You have to trust your authorised users to keep their private keys
secret.
2. Potential legal problems due to the fact that RSA is patented.
For commercial use, you'll certainly have to pay a licence fee.
3. You may have problems if the script is such that, if run more than
once, may do something you don't want. Nothing prevents some malicious
person from intercepting the mail and resending it some number of times.
4. others I haven't thought of.

PGP is an example of a program which could be used to implement this.
RSA Data Security, Inc. also sells tools which will enable you to do this.

Mark
-- 
Mark Henderson
markh@wimsey.bc.ca
RIPEM key available by key server/finger/E-mail
From: jfh@rpp386.lonestar.org (John F. Haugh II)
Newsgroups: comp.security.misc
Subject: Re: IBM password
Date: 14 Oct 92 00:56:52 GMT
Reply-To: jfh@rpp386.cactus.org (John F. Haugh II)
Organization: River Parishes Programming, Austin, Republic of Texas

In article <MARC.92Oct13132406@marc.watson.ibm.com> marc@watson.ibm.com (Marc Auslander) writes:
>Not always true.  For example, the IBM RS/6000 has a key lock.  In the
>locked position, the system will only boot from the internal hard
>drive.  It doesn't matter what you put in the diskette slot.  So if
>its unix, and you don't know the root password, you can't easily break
>in.  Since the key lock also physically locks the box, you can't mess
>with the disk drives either.
>
>Can you overcome this.  OF COURSE.  But not without some skill and
>effort and time.

Actually you can overcome this with little skill and time, but it
requires you break something with a hammer.  Some of the chassis
don't require the hammer, but a coat hanger works just as well.

The purpose of the key is not so much to insure protection, but
rather insure that you know if someone broke in.  It's kinda like
the physical equivalent of event auditing ...
-- 
John F. Haugh II                  [  TSAKC  ] !'s: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 251-2151           [ DoF #17 ]        @'s: jfh@rpp386.cactus.org
Newsgroups: comp.security.misc
From: vanepp@fraser.sfu.ca (Peter Van Epp)
Subject: Re: HELP! (Re: IBM password)
Organization: Simon Fraser University, Burnaby, B.C., Canada
Date: Fri, 16 Oct 1992 01:02:07 GMT

doug@cc.ysu.edu (Doug Sewell) writes:

>If we do this, then the machine will boot completely from a floppy disk.
>But we can't access the hard drive to fix it.  If the HD is configured
>in, then the machine will NOT complete a floppy-disk boot.

I sent a reply by mail, but maybe it didn't make it. If you can boot from a 
floppy, then by using BIOS calls (specifically int26, Absolute disk write)
you should be able to write either 0s or E5s (which I believe is the format
data string) onto the first track of the hard disk. This of course will
destroy any data on the hard disk, but I assume you don't care. Haveing done
that, you should be able to enable the hard drive in the CMOS ram and 
partition and format the disk manually.
	If there is data you want on the disk, then you might try reading
the first few sectors (with int25) to get the partition table and then
write a valid partition table from another drive on a working machine onto
the broken drive again using int26.

Peter Van Epp / Operations and Technical Support 
Simon Fraser University, Burnaby, B.C. Canada
Newsgroups: comp.security.misc
From: joepepin@cbnewsl.cb.att.com (joseph.pepin)
Subject: Re: B1security level
Organization: AT&T
Distribution: usa
Date: Thu, 15 Oct 1992 12:09:37 GMT
Summary: AT&T System V/MLS is B1

Artur Romao (artur@morgaine.puug.pt) wrote:
: Does anyone know if there is any version of UNIX that implements the
: B1 level.
: thanks in advance.

AT&T System V/MLS is B1.
From: hendrick@ctron.com (Jim Hendrick)
Newsgroups: comp.security.misc
Subject: Question re: Xterminals
Date: 10 Oct 92 14:22:40 GMT
Distribution: comp
Organization: Cabletron Systems Inc.

Hi,
	I am looking for information on the security problems with
using Xterminals to access "realtively secure" machines. By this I
mean machines that act as access points to a database containing
critical resources. These access machines have been physically
"secured" in a minimal sense, locked cabinets, no terminals
considered secure in the /etc/ttytab file including the console. As
part of the duties of several administrators, they are required to log
into these "trusted" machines and occasionally su to root or other
more priviliged accounts. My question relates to the ability (or
inability) to safely use Xterminals to access these "trusted"
machines. Specifically, does anyone know of a way to secure the
transmissions from these Xterminals such that a network "snooper"
could not obtain the cleartext passwords as they fly by? I am moving
towards using Kerberos as the authentication service for these
machines so that one could (from a workstation running K.) use the
encrypted mode of transmission for sensitive login sessions and to
generally keep cleartext passwords off the wire but now I have been
asked to set up Xterminals for the administrative staff to use and
think that this might pose a problem. {whew, how's that for a sentence :-}

Please reply via email any questions, answers, comments or pointers to
further information sources. I will summarize if there appears to be
the desire.

Thanks!!

Jim

--
###########################################################################
### Jim Hendrick (hendrick@ctron.com)   ###                             ###
### Cabletron Systems Inc.              ###   " My opinions, etc are    ###
### P. O. Box 5005                      ### exclusively the property    ###
### Rochester, NH 03867-5005            ### of nobody in particular."   ###
### (603) 332-9400 x1457                ###                             ###
### fax:(603)332-1019                   ###                             ###
###########################################################################
From: faigin@aero.org (Daniel P. Faigin)
Newsgroups: comp.security.misc
Subject: Re: B1 Security
Date: 15 Oct 92 04:59:19
Organization: The Aerospace Corporation, El Segundo, CA
NNTP-Posting-Host: solarium.aero.org
In-reply-to: pasq@cup.hp.com's message of Thu, 15 Oct 1992 00:32:11 GMT

On Thu, 15 Oct 1992 00:32:11 GMT, pasq@cup.hp.com (Mark Di Pasquale) said:

> HP has B1-Level security on the HP9000 Series 8x7 systems and the
> HP 9000 Series 7xx systems.  The operating system releases are
> HP-UX BLS Release 8.08 (for Series 800s) and HP-UX BLS 8.09 (for
> Series 700s).

Note that these systems are not yet on the Evaluated Products List, although a
Product Bulletin has been issued. They are currently in the formal evaluation
phase.

Daniel
--
[W]:The Aerospace Corp. M1/055 * POB 92957 * LA, CA 90009-2957 * 310/336-8228
[Email]:faigin@aerospace.aero.org              [Vmail]:310/336-5454 Box#13149
   "You can't be a rationalist in an irrational world. It isn't rational!"
	       Dr. Rance, in Joe Orton's "What the Butler Saw"
From: faigin@aero.org (Daniel P. Faigin)
Newsgroups: comp.security.misc
Subject: Re: C2 security specification - where to get a copy?
Date: 16 Oct 92 06:46:50
Organization: The Aerospace Corporation, El Segundo, CA
Distribution: na
NNTP-Posting-Host: solarium.aero.org
In-reply-to: bguest@ateam.ems.cdc.com's message of 15 Oct 92 19:18:38 GMT

On 15 Oct 92 19:18:38 GMT, bguest@ateam.ems.cdc.com (Brandon Guest) said:
> My personal recommendation is save your money on the Orange Book and
> go buy yourself a copy of Deborah Russell's book from O'Reilly.

Much as I like Debby's book (I recommend it heartily), if you are in the US
you can obtain a complete set of the Rainbow Series, including the TCSEC, by
writing:

	National Computer Security Center
	Attn: Director, Infosec Publications
	9800 Savage Road
	Ft. Meade MD 20755-6000

I don't have the phone number handy.

Daniel
--
[W]:The Aerospace Corp. M1/055 * POB 92957 * LA, CA 90009-2957 * 310/336-8228
[Email]:faigin@aerospace.aero.org              [Vmail]:310/336-5454 Box#13149
   "You can't be a rationalist in an irrational world. It isn't rational!"
	       Dr. Rance, in Joe Orton's "What the Butler Saw"
Newsgroups: comp.security.misc
From: roihar@cc4.crl.aecl.ca
Subject: RE: Looking for UNIX SECURITY papers/reference
Organization: AECL RESEARCH
Date: Wed, 7 Oct 1992 15:17:08 GMT

cwns2.ins.cwru.edu (129.22.8.44) has a unix-security.ps file
(274262 bytes long) in it's /pub directory. I cannot seem to get at it
as user anonymous, however...
Newsgroups: comp.security.misc
From: sharen@iscnvx.lmsc.lockheed.com (Sharen A. Rund)
Subject: Re: some disk degaussing questions
Organization: Lockheed Missiles and Space Co.
Distribution: usa
Date: Wed, 14 Oct 92 17:11:38 GMT

In article <1992Oct12.173957.20772@SSD.intel.com> cower@ssd.intel.com (Rich Cower) writes:
>
>I've got some questions about degaussing disks, maybe someone can help.
>
>1. Are there degausing devices available that will degauss disks that
>   are over 120mb? Does the size matter? Who makes them? How much do they cost?
>
one of our organizations has a RIMAGE unit - its like a big microwave oven -
that degausses any and everything

>2. Will degaussing these larger disks in any way make them not useable?
>   We've heard that the field required to degauss these large disks will
>   somehow damage the servo, and make the disk unuseable.
>
that's the one thing bad about the RIMAGE, we have to get the disk 
re-formatted - but, it's either that or 'eat' it, e.g., buy new disks
and destroy the existing one(s)

>3. Do other sites worry about sending disks out for repair that might
>   contain sensitive data?
>
yep, that's why we need to use the RIMAGE unit - it is approved by DIS
for use - round tapes and cartridge tapes get degaussed and are ready
for use right away - it does a good job and can do a lot of them at one
time as opposed to the older tape degaussers that do one tape at a time


-- 
________________       __        ________________   "They that can give up
\_________      \     /_ \      /      _________/  essential liberty to 
 \_________      \_____/  \____/      _________/  obtain temporary safety
  \___________________      __________________/  deserve neither liberty 
                     /______\                   nor safety."  
ALL disclaimers apply ....                           --Benjamin Franklin
	  
Newsgroups: comp.security.misc