HDTenEightyP/NetNews huggingface dataset:
From: sethb@fid.morgan.com (Seth Breidbart)
Subject: Re: WAISified PostScript would constitute a security hole
Organization: my opinions only
Date: Mon, 17 Aug 1992 23:25:29 GMT

In article <1992Aug16.122446.7342@jarvis.csri.toronto.edu>
flaps@dgp.toronto.edu (Alan J Rosenthal) writes:
>sethb@fid.morgan.com (Seth Breidbart) writes:
>>>Well that's easy if you have source.. just link with libraries which send
>>>messages rather than doing the syscall...
>>
>>It's not that easy, even then.  How do you know you've found all the
>>system calls?  There are people around who can hide them in
>>floating-point numbers.
>
>They're indeed hidden in that way in the calling program, but from there it's
>no different than other library routines.  When you say "a * b", this is,
>conceptually speaking, simply converted to "__double_multiply(a, b)".  The
>compiler could inline this, but it could do that for other library routines too
>(which may include syscalls); hopefully it has a command-line switch to disable
>this "helpful" behaviour.  (Anyway, I think that mostly only ibm-pc compilers
>are so rabidly time-at-the-expense-of-space-optimizing as that.)  But anyway,
>if you read the libraries, and if you understand them, including those which
>are inlined (if any) as well as those present in external .o files, then you've
>seen all the syscalls.

No, unless you look at the binary, in which case there are a lot of
things that look like syscalls (which are, after all, just bit
patterns).  They need not even be present in the object code:  I
remember (back in 1968) a FORTRAN program for the CDC 6600 that
returned the time by "calling" a floating-point number.  (The compiler
compiled a call to a name as the appropriate type of branch; the
floating-point number just happened to have the same bit pattern as
the syscall to get the time.)  A sufficiently devious programmer could
have the program construct the syscall by doing floating-point
arithmetic at runtime; he could test the identity of the machine the
same way, at the same time.

>I guess this does open up the possibility of people doing their own syscalls
>directly in an #ifdef sun or whatever, though.  Sigh, I guess to nail this down
>tight there would have to be a compiler switch to prevent them from doing this.
>Preventing #asm (or equivalent) will do it on many machines, maybe all.

Nope, I can always hand-assemble, and figure out some way to get the
bits in (maybe by branching halfway into an instruction).

Seth		sethb@fid.morgan.com
Xref: sparky alt.security:4176 comp.security.misc:1045
From: s1000101@spectrum.cs.unsw.oz.au (Saqib Razzaq)
Newsgroups: alt.security,comp.security.misc
Subject: WANTED - Information on Security in EFT (Electronic Data Transfer) Systems
Date: 18 Aug 92 09:39:22 GMT
Reply-To: s1000101@spectrum.cs.unsw.oz.au (Saqib Razzaq)
Organization: none

Hi,

        I am looking for any information on Electronic Data Transfer System and the security
features used in such systems. Please e-mail.
	
						Thanks in advance
							Zak
Newsgroups: alt.security
From: Dag Asheim <dash>
Subject: Is SecurityCheck(tm) any good?
Reply-To: Dag Asheim <dash@ifi.uio.no>
Organization: University of Oslo, Norway
Date: Fri, 21 Aug 1992 14:26:00 GMT
Originator: dash@gyda.ifi.uio.no

I'm sitting here with a demo-version of SecurityCheck by Raxco Inc.
It tries to do much the same as COPS, but the price is $$$ (or NOKNOKNOK
in my case, NOK=NOrwegian Kroner).  They even have a comparison I feel
is kind of slanted.  The selling arguments is security by obscurity and
commercial is better than PD.   But it also seems to be a little more
polished.  Does any one else have any experience with it?

Dag Asheim
Norwegian Computing Center
From: epstein@trwacs.fp.trw.com (Jeremy Epstein)
Newsgroups: alt.security
Subject: Re: HPUX with B1 security
Keywords: B1 Orange Book Security
Date: 17 Aug 92 19:02:14 GMT
Followup-To: alt.security
Organization: TRW Systems Division, Fairfax VA

In article <1992Aug17.083636.8173@ghost.dsi.unimi.it>, vince@ghost.dsi.unimi.it (David Vincenzetti) writes:
> I have examined the kernel sources for hpux 8.0. I've noticed that there are,
> somewhere, defines like the following:
> 
> 	[...]
> 	#if defined(SecureWare) && defined(B1)
> 	[...]
> 
> ...so I suppose that you can recompile the kernel and all the commands
> and the libraries to make hpux run at the B1 security level. Now it is
> at the C2 level, according to the Orange Book.

I strongly suspect this is to build HP-UX/BLS, which is HP's B1 targeted
version of HP-UX.  I doubt that even if you turned on both flags (i.e.,
SecureWare and B1) you'd have everything...there are probably additional
source modules which aren't delivered except if you buy the BLS version.

Just for the record, HP-UX has not completed *any* evaluation against
the Orange Book.  I believe it is in the DAP phase for their B1-targeted
version.  So calling it a B1 or C2 system isn't correct; it's a B1
(or C2) *targeted* system.

-- 
Jeremy Epstein			Internet: epstein@trwacs.fp.trw.com
Trusted X Research Group	Voice: +1 703/803-4947
TRW Systems Division
Fairfax Virginia
Newsgroups: alt.security
From: flaps@dgp.toronto.edu (Alan J Rosenthal)
Subject: Re: WAISified PostScript would constitute a security hole
Date: 15 Aug 92 18:09:17 GMT

nagle@netcom.com (John Nagle) writes:
>      You want the ability to start up a subprocess with limited privileges
>without having to have super-user authority to do it.

I think you need more than that.  You want the ability to start up a subprocess
whose privileges are a strict subset of your own.  For example, setuid-nobody
means that now you can chown files owned by nobody, whereas you couldn't
before.  chroot with a copied-in /bin/login means you can spoof /etc/passwd.
And so on.  You want to close certain things without opening any others.
Newsgroups: alt.security
From: styri@hal.nta.no (Haakon Styri)
Subject: Re: Encrypted email illegal?
Reply-To: styri@nta.no
Organization: Norwegian Telecom Research
Date: Mon, 3 Aug 92 19:14:31 GMT

In article <1992Aug3.181802.6496@newshost.lanl.gov>, John C. Fowler writes:
>
>It's not illegal to send encrypted mail, but if you send it from the U.S.
>to another country, it's illegal to tell them how to decrypt it.  :-)

Nah, it's legal to tell - just don't use any known programming languages
if you use electronic media. (Of course, if you use a classified algorithm
it's different.) At least I believe this is true, I can still buy US books
on encryption here in europe...

---
Haakon Styri
Norwegian Telecom Research
Newsgroups: alt.security
From: memco@cns.nyu.edu (Matthew Merkelson)
Subject: Help Find PGPv2
Reply-To: memco@cns.nyu.edu
Organization: New York University
Date: Tue, 18 Aug 1992 19:28:10 GMT


The latest issue of Boardwatch magazine says that version
2 of PGP has been released and is at kauri.vuw.ac.nz.
I can't find the IP # of this site to get it.
If anyone knows it or another site with the latest version,
please e-mail me.

Thanks.

---
memco@wotan.cns.nyu.edu               There was a guy named Joel,
                                      Not too different from you or me
From: pgut1@cs.aukuni.ac.nz (Peter Gutmann)
Newsgroups: alt.security
Subject: Re: Help Find PGPv2
Date: 19 Aug 92 07:46:25 GMT
Organization: PGP Conspiracy Secret Laboratory

In <1992Aug18.192810.4541@cmcl2.nyu.edu> memco@cns.nyu.edu (Matthew Merkelson) writes:

>The latest issue of Boardwatch magazine says that version
>2 of PGP has been released and is at kauri.vuw.ac.nz.
>I can't find the IP # of this site to get it.
>If anyone knows it or another site with the latest version,
>please e-mail me.

Just in case lots of people start rushing to kauri to get a copy - it hasn't
been released yet.  RSN.....

--
    pgut1@cs.aukuni.ac.nz || peterg@kcbbs.gen.nz || peter@nacjack.gen.nz
			  (In order of preference)
Newsgroups: alt.security
From: flaps@dgp.toronto.edu (Alan J Rosenthal)
Subject: Re: Secure setuid programs: A model
Distribution: alt
Date: 20 Aug 92 13:30:29 GMT

buzz@toxicavenger.bear.com (Buzz Moschetti) writes:
>The binary should be stripped and chmod-ed to 4711 to prevent strings(1)
>from being run on it.

I presume that y'all realize that this is security through obscurity.  Not
fatal, but don't assume it buys you anything.  Sure, chmod it non-readable, why
not, but pretend you didn't.

Except that you might not want to tell them who is allowed to run it when you
say that they're not allowed to.
Newsgroups: alt.security
From: casper@fwi.uva.nl (Casper H.S. Dik)
Subject: Re: Secure setuid programs: A model + NFS
Organization: FWI, University of Amsterdam
Distribution: alt
Date: Thu, 20 Aug 1992 18:49:37 GMT

wls@cray.csd.uwm.edu (Bill Stapleton) writes:

>Something I've noticed in at least two vendors' NFS (perhaps it's standard) is
>that even with client superuser access mapped, root on a client can *READ*
>a file with world execute (like 711) on the server, no matter who owns the
>file.  Is this really in the NFS "design" or is it a common implementation
>bug?

>It may be obscurity, but we prefer people not be able to read/copy some system
>software, especially where licenses or "secure" programs are involved.

If you want to execute code on a client, it must be transmitted over
the net.  Therefor, execute permission always implies read permission.

Casper
-- 
						|	Casper H.S. Dik
						|	casper@fwi.uva.nl
Newsgroups: alt.security,comp.security.misc
From: sethb@fid.morgan.com (Seth Breidbart)
Subject: Re: WAISified PostScript would constitute a security hole
Organization: my opinions only
Date: Sat, 15 Aug 1992 23:27:05 GMT

In article <1992Aug15.172943.4449@jarvis.csri.toronto.edu>
flaps@dgp.toronto.edu (Alan J Rosenthal) writes:
>sethb@fid.morgan.com (Seth Breidbart) writes:
>>What I need is the ability to run a subprocess as a slave; whenever it
>>tries to do any kind of system call, the call is handed to me (the
>>master process) instead.  That way, I can allow only "safe" actions; I
>>can also pretend to have done "unsafe" actions so the subprocess will
>>run without causing trouble.
>
>Well that's easy if you have source.. just link with libraries which send
>messages rather than doing the syscall...
>
>(when I say easy, I mean, theoretically speaking.. it *would* be a lot of work
>to create these libraries, but they would only have to be done once.)

It's not that easy, even then.  How do you know you've found all the
system calls?  There are people around who can hide them in
floating-point numbers.

Seth		sethb@fid.morgan.com
Newsgroups: alt.security
From: frank@D012S436.sniap.mchp.sni.de ()
Subject: Re: Secure setuid programs
Organization: Siemens-Nixdorf AG
Distribution: alt
Date: Fri, 21 Aug 92 12:49:26 GMT

buzz@toxicavenger.bear.com (Buzz Moschetti) writes:
: We wish to make mount and umount available to two or three non-root accounts.
: The plan is create a C code fork/exec wrapper that does the following:
: 
: 	1.  Verifies that the euid is root.

The above seems superfluous...it's an suid root program isn't it?
Why would the euid become other than root?

: 	2.  Verifies that the uid is one of the "privileged" users.
: 	3.  Forces argv[0] to be /usr/etc/(u)mount.
: 	4.  Does an execv(3) -- NOT execvp(3) -- to run the argv.

You should check that the program doesn't itself use execvp(3), or
system(?).  

Better yet, use execve(3) to set up an environment with a restricted
PATH.

: 
: The program itself is setuid root, mode 4711, so that the binary image
: cannot be copied and compromised:
: 	-rws--x--x  1 root        24576 Aug 17 11:51 mmount
: 
: I believe this to be secure.  Can someone claim otherwise?

Ummm, probably...
--
Frank O'Dwyer		       			Disclaimer: 
Siemens-Nixdorf AG 	                        I will deny everything
Tel.  : +49 (89) 636-40639                      Fax.  : +49 (89) 636-45860
e-mail: Frank.ODwyer@sniap.mchp.sni.de
Xref: sparky alt.security:4167 comp.security.misc:1025
Newsgroups: alt.security,comp.security.misc
From: flaps@dgp.toronto.edu (Alan J Rosenthal)
Subject: Re: WAISified PostScript would constitute a security hole
Date: 16 Aug 92 16:24:46 GMT

sethb@fid.morgan.com (Seth Breidbart) writes:
>>Well that's easy if you have source.. just link with libraries which send
>>messages rather than doing the syscall...
>
>It's not that easy, even then.  How do you know you've found all the
>system calls?  There are people around who can hide them in
>floating-point numbers.

They're indeed hidden in that way in the calling program, but from there it's
no different than other library routines.  When you say "a * b", this is,
conceptually speaking, simply converted to "__double_multiply(a, b)".  The
compiler could inline this, but it could do that for other library routines too
(which may include syscalls); hopefully it has a command-line switch to disable
this "helpful" behaviour.  (Anyway, I think that mostly only ibm-pc compilers
are so rabidly time-at-the-expense-of-space-optimizing as that.)  But anyway,
if you read the libraries, and if you understand them, including those which
are inlined (if any) as well as those present in external .o files, then you've
seen all the syscalls.

I guess this does open up the possibility of people doing their own syscalls
directly in an #ifdef sun or whatever, though.  Sigh, I guess to nail this down
tight there would have to be a compiler switch to prevent them from doing this.
Preventing #asm (or equivalent) will do it on many machines, maybe all.

(By compiler switch, please!  Hey, did you hear the one about the OS whose C
compiler restricted the use of #asm to root?  It meant that all programmers
needed the root password or they wouldn't be able to compile a particular
little bit of our big application program.  And it didn't increase security,
because average people could still run the assembler; we could have done it not
as root with sed or by hand (it wasn't unix).)
Newsgroups: alt.security
Organization: large
Date: 19 Aug 1992 17:18:15 EDT
Expires: 1 Apr 93 12:34
Subject: suid on dump
From: hobbit@babyoil.ftp.com (*Hobbit*)

What you really should worry about is the companion setuid bit on "restore".
I can take a dump of a filesystem containing one setuid program, restore it
to just about anywhere, and if the restore is running as root it will restore
the owner and modes of my setuid-root file, hyeugh hyeugh...

Many people have beaten Sun [and DEC, and probably several others] about the
head and shoulders about this and they KEEP SHIPPING IT THAT WAY.

_H*
Newsgroups: alt.security
From: casper@fwi.uva.nl (Casper H.S. Dik)
Subject: Re: suid on dump
Organization: FWI, University of Amsterdam
Date: Thu, 20 Aug 1992 07:36:36 GMT

rob@wzv.win.tue.nl (Rob J. Nauta) writes:

>ufe@dlva.dl.ac.uk writes:

>>Attempts to dump from an HP 9000/750 to a remote tape on a SUN revealed
>>the fact that SUN ship dump as suid, while HP,DEC,SGI do not.
>>Remote dump will only work if it is set on the host machine.
>>Does anyone know of any security implications in using suid on dump ?
>>Cheers,
>>	Mark

>Hm, you used to be able to dump (parts of) a filesystem to a file, then
>with 'restore -i' restore selected files, even those that were unreadable
>before, since dump is setuid to be able to read the device. I guess
>it's been fixed a long time ago, but maybe it's still in 4.0.3.
>I think you can remove the 's' bit, since dump is run by the root
>crontab anyway.

Dump is not set-uid to be able to read the device. In the standard
SunOS setup, the devices are readable by owner and group. The defaulkt
group for disks is ``operator''. This way everyone in group
operator can perform a dump.

SunOS dump is set-uid because of it is also rdump. Rdump uses
``rcmd(3)'' to open a connection with the remote host. For that
library call you need to have superuser privileges. I suppose
that also the reason why restore is set-uid on Sun's. (though we
switched that off, we restore only as root). This is why Mark finds
that remote dump only works with the set-uid bit set.

As for dump being run as root, that's often not the case. Most larger
sites run dump as some non human user. This has the benefit of not
having to put all the hosts with disks in dumphost:/.rhosts, but only in
dumphost:~dumpuser/.rhosts.

As for security implication, trace shows that dump almost directly 
reverts to the original uid, atleast before opening the device.

Casper
-- 
						|	Casper H.S. Dik
						|	casper@fwi.uva.nl
Newsgroups: alt.security
From: casper@fwi.uva.nl (Casper H.S. Dik)
Subject: Re: Secure setuid programs
Organization: FWI, University of Amsterdam
Distribution: alt
Date: Wed, 19 Aug 1992 14:21:39 GMT

buzz@toxicavenger.bear.com (Buzz Moschetti) writes:

>We wish to make mount and umount available to two or three non-root accounts.
>The plan is create a C code fork/exec wrapper that does the following:

>	1.  Verifies that the euid is root.
>	2.  Verifies that the uid is one of the "privileged" users.
>	3.  Forces argv[0] to be /usr/etc/(u)mount.
>	4.  Does an execv(3) -- NOT execvp(3) -- to run the argv.

>The program itself is setuid root, mode 4711, so that the binary image
>cannot be copied and compromised:
>	-rws--x--x  1 root        24576 Aug 17 11:51 mmount

Have you thought about the environment? Better set $PATH to include
only system directories. Why? On some systems (e.g., Suns) mount
execvp's programs called ``mount_<fstype>''. E.g., mount_hsfs, mount_pcfs,
mount_tfs, mount_lo, mount_rfs and mount_tmp.

add to your program:

char * env[]  = { "PATH=/usr/etc:/usr/bin:/usr/ucb", 0 };

and call execve instead of execv, with env as the environment pointer.

Casper
-- 
						|	Casper H.S. Dik
						|	casper@fwi.uva.nl
Xref: sparky alt.security:4157 comp.infosystems.wais:367 comp.lang.postscript:4291
From: jimc@tau-ceti.isc-br.com (Jim Cathey)
Newsgroups: alt.security,comp.infosystems.wais,comp.lang.postscript
Subject: Re: WAISified PostScript would constitute a security hole
Date: 14 Aug 92 00:02:10 GMT
Organization: ISC - Bunker Ramo, Spokane, WA

In article <9208131507.AA14641@wendy-fate.UU.NET> kyle@WENDY-FATE.UU.NET (Kyle Jones) writes:
> > Oh, I don't know about that. "chroot" seems pretty comprehensive. An
> > advantage of putting everything in the file system. If you're REALLY
> > paranoid you can setuid to a user-id with no files of its own.
>
>setgid() also. (And setgroups() on BSD systems.)  You also have
>to make sure this user can't tunnel out of the chroot'd
>environment via the network.

Because Berklix sockets aren't in the filesystem.  (Other systems 
[like ours] have their network access points in the filesystems, and
are immune to this.)

-- 
+----------------+
! II      CCCCCC !  Jim Cathey
! II  SSSSCC     !  ISC-Bunker Ramo
! II      CC     !  TAF-C8;  Spokane, WA  99220
! IISSSS  CC     !  UUCP: uunet!isc-br!jimc (jimc@isc-br.isc-br.com)
! II      CCCCCC !  (509) 927-5757
+----------------+
			"PC's --- the junk bonds of the computer industry"
From: ufe@dlva.dl.ac.uk
Newsgroups: alt.security
Subject: suid on dump
Date: 19 Aug 92 16:03:41 GMT
Reply-To: ufe@dlva.dl.ac.uk ()
Organization: SERC Daresbury

Attempts to dump from an HP 9000/750 to a remote tape on a SUN revealed
the fact that SUN ship dump as suid, while HP,DEC,SGI do not.
Remote dump will only work if it is set on the host machine.
Does anyone know of any security implications in using suid on dump ?
Cheers,
	Mark
========================================================================
Mark Enderby			   JANET - ENDERBY@UK.AC.DARESBURY
Systems Manager		  	   EARN/Bitnet - ENDERBY@DARESBURY.AC.UK
SERC Daresbury Laboratory
Keckwick Lane						
Daresbury
Warrington	tel:   0925-603353
WA4 4AD		Int:+44-925-603353
UK		fax:   0925-603174
Newsgroups: alt.security,comp.infosystems.wais,comp.lang.postscript
From: peter@taronga.com (Peter da Silva)
Subject: Re: WAISified PostScript would constitute a security hole
Organization: Taronga Park BBS
Date: Sat, 15 Aug 1992 02:01:00 GMT

In article <9208131507.AA14641@wendy-fate.UU.NET> kyle@WENDY-FATE.UU.NET (Kyle Jones) writes:
>Peter da Silva writes:
> > In article <cx4mcgb.nagle@netcom.com> nagle@netcom.com (John Nagle) writes:
> > >      What's needed is the ability to start up a process with limited
> > >privileges.  UNIX doesn't have this.

> > Oh, I don't know about that. "chroot" seems pretty comprehensive. An
> > advantage of putting everything in the file system. If you're REALLY
> > paranoid you can setuid to a user-id with no files of its own.

>setgid() also. (And setgroups() on BSD systems.)  You also have
>to make sure this user can't tunnel out of the chroot'd
>environment via the network.

Oh yes, I forgot that Berkeley networking is a by-our-lady disaster for
any hope of making UNIX security at all complete, reliable, convenient,
or robust. And I'm not just talking about network security. A UNIX system
should allow no access to data sets, streams, or related file system
objects without going through the file system. Period.

Not that System V is much better, with all those horrible sem* and shm*
routines.

Oh, I DO wish they'd hurry up with Plan 9.
-- 
                                                                `-_-'
                         Have you hugged your wolf today?        'U`

Peter da Silva, Taronga Park BBS, Houston, TX  +1 713 568 0480/1032
From: rob@wzv.win.tue.nl (Rob J. Nauta)
Newsgroups: alt.security
Subject: Re: suid on dump
Date: 19 Aug 92 21:05:48 GMT
Organization: Sex, UNIX & Rock 'n Roll

ufe@dlva.dl.ac.uk writes:

>Attempts to dump from an HP 9000/750 to a remote tape on a SUN revealed
>the fact that SUN ship dump as suid, while HP,DEC,SGI do not.
>Remote dump will only work if it is set on the host machine.
>Does anyone know of any security implications in using suid on dump ?
>Cheers,
>	Mark

Hm, you used to be able to dump (parts of) a filesystem to a file, then
with 'restore -i' restore selected files, even those that were unreadable
before, since dump is setuid to be able to read the device. I guess
it's been fixed a long time ago, but maybe it's still in 4.0.3.
I think you can remove the 's' bit, since dump is run by the root
crontab anyway.

Rob
-- 
/-----------------------------------------------\	Never		   ,==.
| Rob J. Nauta, UNIX computer security expert.	| 	 Apologize,	  /@  |
| rob@wzv.win.tue.nl, Phone: +31-40-837549	| 	  Never		 /_  <
| Feel free to email me for free advice		|	   Explain.	=" `g'
Newsgroups: alt.security
Subject: Unix Security Administration
From: John.Jarvie@p0.f140.n772.z3.fido.nacjack.gen.nz (John Jarvie)
Date: 20 Aug 92 13:54:08 GMT
Organization: Infoboard BBS - Auckland - (09) 833-8788 - 

As a Unix wcomer, can anyone one tell mhow unix sites typically 
implement user account and password controls in advance of unix's base
password change?
For example, single terminal sign on, password retry disconnection, etc.
Are there any third-party or shareware/user group programs available?
Any info please.....
From: kyle@wendy-fate.uu.net (Kyle Jones)
Newsgroups: alt.security.index
Newsgroups-Indexed: alt.security
Subject: alt.security index for the week ending 22 August 1992
Date: Sat, 22 Aug 1992 22:00:43 EDT
Summary: This is an index of alt.security postings that describe or fix a
         security hole in a computer system.  Each line contains the
         message-ID of an article and a terse summary of the article's
         contents.  See the article itself for details.

<BUZZ.92Aug19161905@toxicavenger.bear.com> "model for setuid programs"
Xref: sparky alt.security:4180 comp.security.misc:1051