HDTenEightyP/NetNews huggingface dataset:
From: kuhn@swe.ncsl.nist.gov (Rick &)
Newsgroups: comp.sw.components
Subject: Re: Standard SW Interfaces (Was: Reuse Discussion Topics)
Date: 5 Nov 92 19:00:41 GMT
X-Newsreader: TIN [version 1.1 PL6]


My previous followup got clobbered somehow; sorry for the empty posting.

Rick Kuhn



Joseph F. (Jeff) Hull (jhull@thor.NoSubdomain.NoDomain) wrote:
: 
: Are there any generalizations we can make (with any degree of 
: assurance) about what constitutes a "good" standard interface?
: Or a bad one?
: 
One characteristic of a good interface (i.e. good w.r.t. a particular
problem) is that it provides a collection of services that are "close
to the problem domain", i.e., neither too high or too a level of
abstraction.  (Lots of people have written about this, so
what I've said isn't particularly new.)  For example, Xlib might be
considered a good interface for dealing with the X protocol, but not
for doing higher level things like writing a menu driven package, where
you want widgets to do menu bars, etc.

..


: |> 
: |> These are major research questions, of course, but one problem with 
: |> such interfaces today is lack of rigorous definition of the services 
: |> provided.  ...  Formal descriptions would be even better.  
:  
: Who is proposing formal systems for such descriptions? How can I 
: get in touch with them?  How do we get them involved in this thread?  
: How do we get copies of their proposals posted here so we can read 
: them?

There are a variety of formal description techniques that are suitable
for these interface descriptions; VDM and Z are becoming well known.
The programming research group at Oxford has specified some UNIX
interfaces using Z.  However, the IEEE Tech. Committee on Operating
Systems (TCOS), the parent body of the POSIX standards, does not plan
to write formal descriptions of the POSIX interfaces.  TCOS has decided
that formal interface descriptions would, in most cases, require too
much effort to write, and there are relatively few people knowledgable
enough to either write them or use them if they were provided.
Although I think formal descriptions would be beneficial, I think the
TCOS view is probably valid.  What might make formal descriptions cost
effective would be tools to generate conformance tests from the
descriptions, since building conformance tests is currently very labor
intensive.  I've heard talk of some efforts in that direction and have
been meaning to track down the details, but don't know much more now.

The situation is different for protocols.  There are some formal
descriptions of OSI protocols; NIST and other organizations have built
tools for generating code from specifications written in Estelle.  
Some of this stuff can be ftp'ed from osi.ncsl.nist.gov.

--

Rick Kuhn                                   Telephone: +1 301 975 3337       
Natl Institute of Standards & Technology    Fax:       +1 301 590 0932      
Technology Bldg. B266                       Internet: kuhn@swe.ncsl.nist.gov
Gaithersburg, Md.  20899  USA                       DRKuhn@dockmaster.ncsc.mil
From: lyndon@unbc.edu (Lyndon Nerenberg)
Newsgroups: comp.security.misc
Subject: Re: NEED GENERAL INFORMATION ON WIRELESS LANS
Summary: Just some clarification ...
Date: 5 Nov 92 17:42:57 GMT
Organization: University of Northern B.C.

jon_care@hicom.lut.ac.uk writes:

> 1) Wireless LANS, at frequencies below 10GHz, are easy to monitor relatively
> cheaply. (At the 10Ghz range, one has to intercept the path of the microwave
> signal).

Yes and no. There are LANs operating at 23 GHz that transmit an omni-directional
signal. As you increase frequency it is easier to narrow the beamwidth of a
point-to-point link, however a wireless LAN by definition wants wide area
coverage, not PTP. Even fixed PTP links are easy to intercept.

> Commercial receivers are available that will happily monitor any frewuency
> up to about 950 Mhz - If a TNC (with modem chip set for the correct baud rate)
> is then connected in to a PC, packets received can be decoded and analysed
> very easily.

Well, sort of. This isn't your basic 1200 bps AX.25 packet radio that you find
on 145.01. The 900 MHz systems all run spread spectrum. To intercept a signal
you require the same brand of LAN transciever (or at least one that uses the
same modulation encoding scheme), and you must then determine which particular
spreading code is being used. The former is relatively easy due to the limited
number of products currently available. The latter can be dealt with using a
brute force approach if you're patient.

> An answer to this could be to use some form of publickey encryption.

This is the obvious solution, and a good one. I'm curious why more vendors
don't provide this. Is it simply due to the silly DES export restrictions?

--lyndon
Newsgroups: comp.security.misc
From: gvm@nemesys.demon.co.uk (Granville Moore)
ReplyTo: gvm@nemesys.demon.co.uk
Subject: Re: GNU su doesn't restrict root access? Why?
Distribution: world
X-Mailer: cppnews $Revision: 1.19 $
Organization: Dis-organisation
Date: Wed, 4 Nov 1992 14:26:36 +0000


In article <21805@rpp386.lonestar.org> jfh@rpp386.cactus.org (John F. Haugh II) writes:

> In article <720491579snx@Nemesys.demon.co.uk> gvm@nemesys.demon.co.uk (Granville Moore) writes:
> >Aren't you assuming that you can check each dictionary word against
> >the list of 10 encrypted passwords in the same amount of time as you can
> >check it against 1 encrypted password?  This isn't the case with Unix,
> >since the `salt' used in the encryption process means that the encryption
> >will (in the vast majority of cases) have to be performed 10 times.
> 
> Without addressing the other issue, there is no assurance that the
> salts will be different.  The odds are much better that 1 in 4096 (or
> even 10 in 4096) that two will be the same (It's about 1 in 75) assuming
> salts are completely random.  And if you have a non-distributed system
> as the earlier poster does, it's quite possible that each system has a
> different salt for each encrypted password ...
> -- 

So what you are saying is that you have a 1 in 75 chance (I make it
about 1 in ~91, but we won't quibble) that two out of the 10
will be the same.  So, if the cracker is lucky (just over 1% of
the time) then he/she'll only have to perform 9 encryptions
instead of 10 - he/she has two which match, but he/she still has 8 different
other ones.  He/she would probably decide to concentrate only on the two that
match, effectively getting almost a 50% speed-up, but this will only work
in about 1% of cases.

I'm not sure what you mean by a non-distributed system, here.  Assuming
you mean "distributed", then if it uses NIS, or similar, then only
the encrypted passwords are copied to the other systems, so each one
will have exactly the same salt as it had before, and there is no
change in vulnerabilty (from this point of view, anyway).  If the
systems don't use NIS, then the password lists are independent, and
your cracker has a list of 20 to work with, rather than 10.  He/she
therefore naturally has a better chance of getting 2 salts which
coincide.  It still doesn't help a lot, though - about a 1 in 20
chance of getting 2 the same, and 18 different.  The chances of 3
the same will be about 1 in 4000ish.

In summary, some speed-up can be obtained, in some "lucky" cases, but
it's nowhere near the factor of 10 in every case which you implied.

I'd still use this method rather than try to get 10 users to share
a password, change it regularly, and keep it secret.


Regards,

Granville









Newsgroups: comp.security.misc
From: michalj@fuw.edu.pl (Michal Jankowski)
Subject: Re: Setuid script - is this unsecure?
Organization: Warsaw University Physics Dept.
Date: Sat, 7 Nov 1992 15:36:44 GMT

>>>>> On 5 Nov 92 23:15:51 GMT, carl@montebello.ecom.unimelb.EDU.AU
>>>>> (Carl Brewer) said:

>In: (mount script)

Carl> 	[irrelevant script contents deleted]

Carl> this is the oldest crack trick in the book, and is in the FAQ
Carl> Suggest you read it, the bit on creating a symbolic link 
Carl> to the script from a file called "-i" ...
Carl> you may find that informative

Well, it is NOT irrelevant that his scripts start with

         #!/bin/sh --

Please note the '--'. The '-i' trick won't work.
There are however other ways to break his scripts.

   Michal

Newsgroups: comp.security.misc
From: rosenthl@faith.mcc.com (Doug Rosenthal)
Subject: Re: Window watching programs
Organization: MCC
Distribution: na
Date: Mon, 9 Nov 1992 16:31:27 GMT

> 
>  Scott> I have recently come across a program on the net that will allow
>  Scott> a user to continuously monitor a window (including the root
>  Scott> window) on another machine.  The disturbing part of it is that
>  Scott> you seem to be able to do this to any machine without even
>  Scott> having an account on it or having to set up permission to do so
>  Scott> with xhost.  Is there a way to protect a machine from people
>  Scott> using such programs? If so, how?
> 
> Note that just using xhost/xauth won't do it all, if you're on a Sun.
> You also need to set up /etc/fbtab (see fbtab(5)) so that raw access to
> the frame buffer is blocked out.

Will use of the xterm "secure keyboard" option take care of the situation Scott
describes, at least for a given window?

-- 
Doug Rosenthal
MCC EINet                    |  email: rosenthal@mcc.com
3500 W. Balcones Center Dr.  |  phone: 512-338-3515
Austin, TX USA 78759         |  fax:   512-338-3897
Newsgroups: comp.security.misc
From: cotrozzi@ghost.dsi.unimi.it (Massimo Cotrozzi)
Subject: Re: BAFFELED ??#@# !! CONFUSED !!#@@!!!!!
Organization: Computer Science Dep. - Milan University
Date: Thu, 12 Nov 1992 14:19:02 GMT

probreak@kitty.ksu.ksu.edu (James Michael Chacon) writes:

>873nikorawal@gw.wmich.edu writes:

>>  What I do not understand is that how a user can send mail to a different user
>>on the same system, and make it appear as though it has been sent by the
>>operator or any other user on the system. Unless Of-course he has access to the
>>operator/other persons account !!!!!

>>							Curiocity !!!!!!

>Its a rather simple exercise to forge email from anyone at anywhere.
>I of course am not going to say how its done, other than to say it's
>pretty trivial to accomplish this. Basically I could send you mail from
>root on your machine without ever having logged in or been near that 
>machine.

>James
Even if I installed tcp wrapper ?
	Mx
-- 
 -- Massimo Cotrozzi  Computer Science Dept. Milan Italy
            cotrozzi@ghost.dsi.unimi.it  +39-2-27201253
 #include     <std/disclaimer.h>
From: carl@montebello.ecom.unimelb.EDU.AU (Carl Brewer)
Newsgroups: comp.security.misc
Subject: Re: Setuid script - is this unsecure?
Date: 5 Nov 92 23:15:51 GMT
Organization: Dept. Engineering Computer Resources, Melbourne Uni.

In article <1d6fdiINNf5q@bnsgd245.bnr.co.uk> rickt@bnr.co.uk (Rick Tait) writes:
>I recently installed these shell scripts on my machine (on which I am root),
>and I'd like to know if I'm compromising it's security. Basically, they
>just allow the users to mount/umount/eject the floppy disk (pcfs).
>
>In: (mount script)

	[irrelevant script contents deleted]

>So do these make my system insecure? How? How the hell would a user
>turn these simple scripts over into something to compromise my IPX?

this is the oldest crack trick in the book, and is in the FAQ

Suggest you read it, the bit on creating a symbolic link 
to the script from a file called "-i" ...
you may find that informative

>
>By the way, these are the directory entries:
>
>-rwSr-xr-x  1 root     staff         368 Oct 11 11:20 in*
>-rwSr-xr-x  1 root     staff          42 Oct 23 15:05 out*
    ^
get those alarm bells ringing



-- 
 Annal  Natrach, Usthvah Spethed,         carl@ecr.mu.oz.au (IRC: Bleve)
 Dochoel Dienve                           carl@munagin.ee.mu.oz.au
					  carl@montebello.ecom.unimelb.EDU.AU
 Merlin, where are you?  Call your dragon, to weave a mist...
Newsgroups: comp.security.misc
From: jim@forgen.uucp (Jim Hood)
Subject: Re: Passwd programs!
Organization: Ontario Forest Research Institute
Date: Tue, 10 Nov 1992 15:37:14 GMT

From article <vhc.721276907@abacus.hgs.se>, by vhc@abacus.hgs.se (Mikael Larsson):
> 
> I've heard about different passwprograms like npasswd and passwd+
> but haven't been able to find them. Someone wanna help me, and
> tell me where to look? :-)

wuarchive.wustl.edu
	/mirrors4/unix-c/sysadmin/npasswd.tar.Z

dartvax.dartmouth.edu
	/pub/security/passwd+.tar.Z
Newsgroups: comp.security.misc
From: fitzgb@mml0.meche.rpi.edu (Brian Fitzgerald)
Subject: recent security patches
Organization: Rensselaer Polytechnic Institute, Troy, NY
Date: Thu, 5 Nov 1992 21:15:58 GMT

Y'know most of this stuff is fairly generic.  

This table should have a column for every unix operating system
developer and reseller.  

Good idea for a FAQ!

>  ============================================================================
>
>  patch      comments                                      what to do for 4.1.3
>  -----------------------------------------------------------------------------
>  100103     file permissions                              <get patch rev 11>
>  100513     TIOCCONS, pty living on (CA-90:12,etc)        <get rev 01>
>  100173     get root via NFS uids (CA-91:21,CA-92:15)     <get rev 09>
>  100296     rpc.mountd, netgroups (CA-91:09,CA-92:12)     <get rev 04>
>  100305     lpd deletes anything (CA-91:10a)              <get rev 10>
>  100376     SPARC integer / and * (CA-91:16,CA-92:15)     <in 4.1.3> 
>  100383     rdist lets you make setuid files (CA-91:20)   <get rev 05>
>  100424     fsirand and nfs handles (reqs 173) (CA-91:21) <patch forthcoming>
>  100448     OW 3.0 loadmodule gives you root (CA-91:22)   <get rev 01?>
>  100478     xlock screws up                               <??> 
>  100482     several NIS holes (CA-92:13)                  <get rev 03>
>  100567     icmp redirects, denial of service (CA-92:15)  <get rev 04>
>  100630,100633,100377 --
>             getting root via LD_ and env vars (CA-92:11)  <get 377-05, ...??>
>
>  I've not gone after info on the C2 Jumbo Patch, 100564, which impacts
>  rpc.yppasswdd, rpc.pwdauthd -- we're not running C2 (yet).
>
>  100513 supercedes 100188 (CA-90:12), sez Ken Pons.
>
>  100633 is for Sun Shield (so we don't care), says Steve Scampani.
From: ddv@unix.brighton.ac.uk (Domenico De Vitto)
Newsgroups: comp.security.misc
Subject: Re: Two hackers caught tapping into Boeing, federal computers
Date: 12 Nov 92 08:45:49 GMT
Organization: University of Brighton, UK

Any org. that has a _root_ password in _a_ dictionary gets all it deserves.

Dom
From: jbotz@mtholyoke.edu (Jurgen Botz)
Subject: Re: BAFFELED ??#@# !! CONFUSED !!#@@!!!!!
Organization: Mount Holyoke College
Date: Thu, 12 Nov 1992 18:34:41 GMT

In article <1992Nov12.141902.5402@ghost.dsi.unimi.it> cotrozzi@ghost.dsi.unimi.it (Massimo Cotrozzi) writes:
>Even if I installed tcp wrapper ?

tcp-wrapper won't be very helpful in the suggested scenario... unless
the victim has reason to /suspect/ a forgery why would s/he ask the
sysadmin to check the logs?  Of course if the sysadmin regularly checks
both the sendmail and wrapper logs, s/he might notice something amiss,
but it still won't help you track down the perp unless s/he happened
to be nice/foolish enough to execute the forgery on a machine that's
running authd, and from his/her own account.

--
Jurgen Botz                  |   Internet: JBotz@mtholyoke.edu
Academic Systems Consultant  |     Bitnet: JBotz@mhc.bitnet
Mount Holyoke College        |      Voice: (US) 413-538-2375 (daytime)
South Hadley, MA, USA        | Snail Mail: J. Botz, 01075-0629
Newsgroups: comp.security.misc
From: peter@ferranti.com (peter da silva)
Subject: Re: Anti-Piracy by Serial Number ?
Organization: Xenix Support, FICC
Date: Fri, 6 Nov 1992 22:21:50 GMT

In article <1992Nov4.111537.1806@rz.uni-karlsruhe.de> S_TITZ@iravcl.ira.uka.de (Olaf Titz) writes:
> This is one of the simplest, and most easily defeatable, copy
> protection schemes.

Actually, on some computers that have had this feature since the start it
works better than fancier schemes. I did this on one game I wrote for the
Amiga, and none of the fancy copy protection crackers would solve it. You
had to use a "verbatim" copy, which most people didn't try since it almost
never worked on "normal" copy protection. Plus, it was less likely that
the game would become unusable because of disk errors or users writing random
stuff (like patch files) to the disk.

You gotta do the unexpected to stay ahead in this game...

> [...] forcing the users to use dongles or keydisks is a Bad Thing.

I agree, but it was a requirement by the publisher.
-- 
% Peter da Silva % 77487-5012 % +1 713 274 5180 %
true(<<VV$@\\$'&O 9$O%'$LT$&$"V6"$&$<4$?'&$ #I&&?$=$<<@)24 24 scale 3 21 moveto
{dup 36 eq{pop not}{dup 7 and 4 sub exch 56 and 8 div 4 sub 2 index{rlineto}{
rmoveto}ifelse}ifelse}forall stroke pop showpage % Har du kramat din varg idag?
From: adam@endor.uucp (Adam Shostack)
Newsgroups: comp.security.misc
Subject: Re: Two hackers caught tapping into Boeing, federal computers
Date: 13 Nov 92 17:22:30 GMT
Article-I.D.: das.1992Nov13.172230.3045
Organization: Aiken Computation Lab, Harvard University

In article <1992Nov12.142251.9131@hubcap.clemson.edu> stehman%citron.cs.clemson.edu@hubcap.clemson.edu writes:
>From article <1992Nov12.084549.5128@unix.brighton.ac.uk>, by ddv@unix.brighton.ac.uk (Domenico De Vitto):
>> Any org. that has a _root_ password in _a_ dictionary gets all it deserves.

>Would you like to require people to read c.s.m for a couple of months before
>they're allowed to purchase a computer?

No, I'd like too see vendors ship a decent version of password, say
npasswd.

I'd also like to see a two-three page readme on securing your
workstation, and some slightly tougher defaults, like not putting that
"+" in Sun's /etc/hosts.

Closing a few simple holes probably makes an awful lot of difference.



Adam Shostack 					adam@das.harvard.edu

What a terrible thing to have lost one's .sig.  Or not to have a .sig
at all because of elections.  How true that is.
Newsgroups: comp.security.misc,alt.security,comp.unix.admin
From: uri@watson.ibm.com (Uri Blumenthal)
Subject: Re: Tripwire release
Date: Fri, 06 Nov 1992 17:30:36 GMT
Reply-To: uri@watson.ibm.com
Disclaimer: This posting represents the poster's views, not necessarily those of IBM
Organization: You're not cleared to know...

|> >If I can make that backward calculation either
|> >directly or by trial-and-error in a reasonable time, then your
|> >signature protection system is no protection.
|> 
|> I strongly agree. That's why I wrote my ATP program. A version
|> portable to BSD will be ready soon. Anyway ATP is very like tripwire
|> but is protects its database with DES/CBC. I gonna release it to
|> the net and to ftp@ghost.dsi.unimi.it:/pub/security as soon as I finish.

I'd say two things:

	a) The signature should be cryptographically strong.   It
	   means that it's infeasible for an adversary to compose
	   a message with the same signature as yours.  There are
	   several algorithms available, MD5 one of them... There
	   is no reason to be afraid of an adversary  being  able 
	   to "make backward calculation" [using decent sig, that 
	   is].

	b) The database of signatures is to be protected from [malicious] 
	   modifications [because since the algorithm is known, an enemy,
	   even if he can't modify your file  to fit the "old" signature,
	   could in this case to change the file AND the signature]. I'd
	   think, DES/CBC is quite enough of protection...
-- 
Regards,
Uri.		uri@watson.ibm.com
------------
<Disclaimer>
Xref: sparky comp.security.misc:1638 alt.security:4750 comp.unix.admin:6044
From: owens@acsu.buffalo.edu (Bill Owens)
Newsgroups: comp.security.misc,alt.security,comp.unix.admin
Subject: Re: Tripwire release
Date: 5 Nov 92 04:29:30 GMT
Organization: UB
X-Newsreader: Tin 1.1 PL5

Kevin McCurley (mccurley@cs.sandia.gov) wrote:
>> spaf@cs.purdue.EDU (Gene Spafford) writes:
>>This is to announce the first public release of "Tripwire."
>>Tripwire is an integrity-monitor for Unix systems.  It uses several
>>checksum/signature routines to detect changes to files, as well as
>
>I would like to comment that this use of the term "signature" should
>not be confused with the much stronger term of signature that is
>common in cryptology literature.
>
>You will notice that the
>Tripwire database needs to be placed in a secure location like on
>another machine with a read-only disk.  If a true digital signature
>algorithm was used (like DSS or RSA), then this would not be
>necessary.

Without adding the overhead of a digital signature for each file which
tripwire is keeping track of, could the program perhaps be set up to
check a cryptographic signature on the entire database?  If the key
used to make the signature were kept secure, presumably by encrypting
it, then I think this setup would be equally secure.

Of course, those truly worried would want to make sure that the
database, the tripwire and signature programs, and the secret key were
all on ro disks, but I suspect the signature itself would present a
sufficient hurdle. And certainly machines with floppies can be easily
set up with a physically secure filesystem, but signatures would
increase security on machines where no such facilities are available.

Comments?


Bill.
Bill Owens                                              owens@acsu.buffalo.edu
104E Computing Center                             uunet!acsu.buffalo.edu!owens
Buffalo, NY 12460                                                 716/645-3511
From: ddv@unix.brighton.ac.uk (Domenico De Vitto)
Newsgroups: comp.security.misc
Subject: Re: BAFFELED ??#@# !! CONFUSED !!#@@!!!!!
Date: 13 Nov 92 09:19:26 GMT
Organization: University of Brighton, UK

What does FTFRFC mean ??????

Semi-seasoned unix guru is puzzled ?

Dom
From: clewis@ferret.ocunix.on.ca (Chris Lewis)
Newsgroups: comp.security.misc
Subject: Re: NEED GENERAL INFORMATION ON WIRELESS LANS
Date: 10 Nov 92 15:44:53 GMT
Organization: eep.
Originator: clewis@bcarh1d7

In article <1992Nov6.085140.18307@nntp.hut.fi> jkp@cs.HUT.FI (Jyrki Kuoppala) writes:
>In article <WCS.92Nov5231548@rainier.ATT.COM>, wcs@anchor (Bill Stewart +1-908-949-0705) writes:
>>If you want a product plug, AT&T / NCR's WaveLAN product uses
>>spread-spectrum radio, which is hard to intercept and relatively
>>tolerant of noise and other LANs in the same area,
>>and offers an optional DES encryption chip (US only, I assume)

>Just a comment about semantics .. it hardly makes sense to talk about
>"US only" encryption devices, since it is the USA who has the export
>and use restrictions (via export laws, software patents and apparently
>by control of law in the future), not the rest of the world.  You
>probably mean "not to be exported from USA", assuming you are talking
>about U.S. companies.

Minor quibble.  It's not *just* the US.  Any country which is a signatory
to the COCOMM treaty (which will include most of NATO, much of Europe
and many other countries) has to respect US export regulations.  Ie:
Canadian companies had to submit applications to COCOMM (via the dept of
External Affairs) for the export of certain technologies, including DES.

>There are several DES chip and device manufacturers in Europe who are
>glad to sell and glad about increased sales due to the export
>restrictions.

Depending on which country they're in, it may be illegal for them to
export it too.  However, as long as they don't export it, they'll
not have difficulties with US Export regulations or COCOMM treaties,
and they'll reap the sales benefit of not having to compete with the US
or any other COCOMM country.
Newsgroups: comp.security.misc