HDTenEightyP/NetNews huggingface dataset:
From: valdis@vttcf.cc.vt.edu (Valdis Kletnieks)
Newsgroups: comp.security.misc,alt.security,alt.sources.d,comp.sources.testers,comp.unix.admin
Subject: Re: Beta testers needed for security tool
Date: 10 Sep 92 01:10:50 GMT
Followup-To: comp.security.misc
Organization: Virginia Tech, Blacksburg, VA

In article <mccoy.716057636@ren.cs.iastate.edu> mccoy@cs.iastate.edu (Chris McCoy) writes:
>>    Ross Ridge <ross@zooid.guild.org> writes:
>>    *shaking head*  Man, some people can get just a LITTLE too paranoid!
>Of course there's always source so you can recompile your software.
>After all, everyone can trust the compiler, right !?!  ;-)  

I assume that Chris put the smiley on there because he's read
Ken Thompson's Turing Award Lecture "On Trusting Trust".

Those who haven't read it *should*.

@ARTICLE{Trusting.Trust,
        author={Ken Thompson},
        title={Reflections on Trusting Trust},
        journal={Communications of the ACM},
        volume=27,
        number=8,
        month=Aug,
        year=1984,
        pages="761-763"
}

/Valdis
Newsgroups: comp.security.misc
From: morgan@ms.uky.edu (Wes Morgan)
Newsgroups: comp.security.misc,alt.security,alt.sources.d,comp.sources.testers,comp.unix.admin
Subject: Re: Beta testers needed for security tool
Date: 8 Sep 92 18:45:41 GMT
Organization: The Puzzle Palace, UKentucky

In article <sims.715743134@starbase> sims@drake.mitre.org (Jim Sims) writes:
>(buncha stuff about a utility to diff files as a security measure deleted)
>
> It seems to me rather useless and extremely CPU and I/O expensive to diff
>files as a security measure. 

Well, every little bit helps.  If I can run this thing once or twice per
week without melting my CPU or I/O controller, it's worth it.

>How ooften you gonna run this thing? Every 10
>minutes? What's the expected delta between logins that someone could be
>snagging passwords on your system? Seems like better control over changing
>the files is the answer rather than finding out afterwards....

In theory, you're absolutely right.  In reality, there will always be a
hole of which you are unaware.  I'd like to have something like Tripwire
"looking over my shoulder".

> If I was gonna hack some system, I'd be sure the first thing I'd do to is
>find the root's version of tripwire and change it to *always* spit out the
>"don' worry, be happy message"....

Of course, that'll be hard to do if I keep the binary(ies) encrypted (or
on a Sun floppy)......8)

--Wes

-- 
MORGAN@UKCC         |       Wes Morgan       |        ...!ukma!ukecc!morgan 
morgan@ms.uky.edu   | Engineering  Computing |   morgan@wuarchive.wustl.edu
morgan@engr.uky.edu | University of Kentucky | JWMorgan@dockmaster.ncsc.mil
  Mailing list for AT&T StarServer S/E  - starserver-request@engr.uky.edu
From: dfa@rabbit.physiol.unimelb.edu.au (David Abbott)
Newsgroups: comp.security.misc
Subject: Re: Hiding Processes from ps -ax
Date: 5 Sep 92 06:17:40 GMT
X-Newsreader: Tin 1.1 PL5

Alan J Rosenthal (flaps@dgp.toronto.edu) wrote:
: sxjcb@orca.alaska.edu (Jay C. Beavers) writes:
: >I've recently heard that you can hide a process from being displayed by a
: >ps -ax command.  Is this true, and if so what security implications does it
: >have?  How is this done,
: 
: #include <stdio.h>
: #include <string.h>
: 
: int main(argc, argv)
:     int argc;
:     char **argv;
: {
:     char *p;
: 
:     for (p = argv[0]; *p; p++)
: 	*p = 0;
:     strcpy(argv[0], "rn");
: 
:     (void)getchar();  /* to allow you to see that ps reports "rn" */
:     return(0);
: }


This might be a simple way to do it,  if it worked!  On some systems
it will do the trick (e.g. SunOS),  but it doesn't work on IBM's
running AIX (well,  v3.1.5 at least,  'cause I tried it).  In any case,
all that changes is the program name (you could do as good as that by
changing the name of the program before you ran it!).  All the other 
info is still listed as normal,  which doesn't really satisfy the
original question.  Anyone know the real answer?

--
David Abbott                | Email: dfa@rabbit.physiol.unimelb.edu.au
School of Physics & Dept. of Physiology | Phone: +61-3-344-5465
The University of Melbourne, Australia. | Fax:    Available on request.
Newsgroups: comp.security.misc
From: john@iastate.edu (John Hascall)
Subject: Re: Locking terminals (was Re: New Princeton Policy)
Organization: Iowa State University, Ames, IA
Date: Sat, 12 Sep 1992 18:33:51 GMT

ckd@eff.org (Christopher Davis) writes:
}Simple policy fix: ``If the terminal is locked with anything other than
}the "standard" lockscreen, it may be rebooted in order to clear the
}lock.''

And how do you (or the average user walking up to it) tell the two apart?

John
-- 
John Hascall                                       ``Live with it pink-boy!''
Project Vincent                                                              
Iowa State University Computation Center                     john@iastate.edu
Ames, IA  50011                                      515/294-9551 [fax -1717]
Newsgroups: comp.security.misc,alt.security,alt.sources.d,comp.sources.testers,comp.unix.admin
From: tvv@tandem.com (Tom Van Vleck)
Subject: Re: Beta testers needed for security tool
Reply-To: VanVleck_Tom@tandem.com
Organization: Tandem Computers, Inc.
Date: Tue, 8 Sep 1992 21:28:06 GMT

In fact, Multics had a tool very like Tripwire:
 save_dir_info   wrote directory information, date modified etc for
                 a list of files into a user file;
 comp_dir_info   compared some fields of two such files and printed
                 differences.

These programs could be used by system administrators to find what
files in the system library had been modified.  They didn't do
checksums or digests though; would have been a good enhancement.
(I wrote them about 1976.)

-- 
Tom Van Vleck <vanvleck_tom@tandem.com>
From: holland@dutiws.tudelft.nl (Gerhard den Hollander)
Newsgroups: comp.security.misc
Subject: wanted crack for wp51 secured files
Date: 15 Sep 92 08:05:47 GMT
Organization: Delft University of Technology

See subject,

I know there exists a C-program which allows you to crack WP-files
with password protection,
can anybody sent me a copy of this program
I desperately neeed it
(yes I know it's stupid, but i forgot my password)

Thanks
Newsgroups: comp.security.misc,alt.security,alt.sources.d,comp.sources.testers,comp.unix.admin
From: mccoy@cs.iastate.edu (Chris McCoy)
Subject: Re: Beta testers needed for security tool
Organization: Iowa State University, Ames IA
Date: Wed, 9 Sep 1992 16:53:56 GMT

>    Ross Ridge <ross@zooid.guild.org> writes:
> 
>    >While this would be what I'd do, even this isn't 100% guaranteed if
>    >someone has broken security on the machine.  It's possible, for instance,
>    >that the mount command, shell or even kernel has been hacked to prevent
>    >tripwire from doing it's job properly.
> 
>    *shaking head*  Man, some people can get just a LITTLE too paranoid!
> 

Of course there's always source so you can recompile your software.
After all, everyone can trust the compiler, right !?!  ;-)  
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Chris McCoy, Systems Support Group  : INTERNET  mccoy@iastate.edu
Computer Science Department         : FAX       (515) 294-0258
Iowa State University               : VOICE     (515) 294-7214
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
--
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Chris McCoy                         : INTERNET  mccoy@cs.iastate.edu
Computer Science Department         : FAX	(515) 294-0258
Newsgroups: comp.security.misc
From: scs@lokkur.dexter.mi.us (Steve Simmons)
Subject: Re: Shadow password file software for BSD 4.2
Organization: Inland Sea
Date: Wed, 9 Sep 92 23:03:17 GMT

ob@obh.in-berlin.de (Oliver Brandmueller) writes:

>jfh@rpp386.lonestar.org (John F. Haugh II) writes:
>[...]
>>Actually, a better person to get ahold of is Steve Simmons.  He did a
>>significant amount of work in that area.  I don't know where he is
>>hiding these days ...

>            Steve Simmons       scs@iti.org
>            Steve Simmons       scs@lokkur.dexter.mi.us

These two are me.

>            Steve Simmons       ssimmons@convex.com
>            Steve Simmons       Steve_Simmons@a68k.denver.CO.US

And these two aren't.
-- 
 "When Dexter's on the Internet, can Hell be far behind?"
		-- Steve Simmons, scs@lokkur.dexter.mi.us
Newsgroups: comp.security.misc
From: ignatz@wam.umd.edu (Mark J. Sienkiewicz)
Subject: Re: Locking terminals (was Re: New Princeton Policy)
Organization: University of Maryland, College Park
Date: Mon, 14 Sep 1992 14:13:07 GMT

In article <rik.716283238@nella13.cc.monash.edu.au> rik.harris@fcit.monash.edu.au writes:
>>Simple policy fix: ``If the terminal is locked with anything other than
>>the "standard" lockscreen, it may be rebooted in order to clear the
>>lock.''

Nobody I know reboots terminals - I assume this means "computer" :)

>There's a similar discussion going on at Monash.  Unfortunately the same
>``solution'' came up here.  The problem with Christopher's method is
>that the person who ran the non-standard lockscreen doesn't lose
>by this (any more than a ``log out after 15 mins'' approach), but the
>people who are remotely logged in do lose.  You are punishing the
>remote users, just because of one idiot locking the screen the
>``wrong'' way.

If you have the right set of circumstances, you can just tell people how 
to defeat the lock program.  I just got some HP 9000/710 so I'll use it
as an example:

Normally, you walk up to the machine and see an X based login.  Suppose
you see xlock instead.  You type CTRL-SHIFT-BREAK and the X server dies.
After a few seconds, its back with a new login screen.  Your file
system doesn't get trashed (if you use local disks) and remote users don't
get dropped.

The last time I had a computer with X on it was back when it was R2, and
I can't remember if all the servers had a kill feature like this, but if you
have it, the whole lockscreen thing is a non-issue.  The lockscreen program
prevents unauthorized access to your account while you are away, but does
not allow denial of service.

Mark S.
Newsgroups: comp.security.misc,alt.security,alt.sources.d,comp.sources.testers,comp.unix.admin
From: barr@pop.psu.edu (David Barr)
Subject: Re: Beta testers needed for security tool
Organization: Penn State Population Research Institute
Date: Mon, 07 Sep 92 15:11:38 GMT

In article <1992Sep7.102653.18888@zooid.guild.org> ross@zooid.guild.org (Ross Ridge) writes:
>>This is one possible way to do it on floppy-equipped systems (say, an
>>SS2 or IPX or whatever).  Maybe this should go in the docs?
>
>While this would be what I'd do, even this isn't 100% guaranteed if
>someone has broken security on the machine.  It's possible, for instance,
>that the mount command, shell or even kernel has been hacked to prevent
>tripwire from doing it's job properly.

So flip the write-protect switch on the floppy.  No program is a
panacea.  This sounds like a wonderful tool, regardless.

Without knowing the full mechanism by which tripwire works, discussions
like this are of limited usefulness.  If your system regularly has been
compromised to the point that you can't trust your kernel, you
shouldn't be trusting Tripwire alone anyway.  If we're going to be
paranoid, make a miniroot disk, and put all the stuff on there.  I
kinda doubt it would all fit, however.  A floppy with tripwire, related
programs, a known good copy of the runtime C library, and the database
should be enough.

--Dave
-- 
System Administrator, Population Research Institute    barr@pop.psu.edu
  Contains: Carbonated water, high fructose corn syrup and/or sugar, caramel 
  color, phosphoric acid, caffeine, citric acid and natural flavorings.
Xref: sparky comp.security.misc:1186 alt.security:4280 alt.sources.d:1112 comp.sources.testers:9 comp.unix.admin:4920
From: holland@matt.ksu.ksu.edu (Rich Holland)
Newsgroups: comp.security.misc,alt.security,alt.sources.d,comp.sources.testers,comp.unix.admin
Subject: Re: Beta testers needed for security tool
Date: 7 Sep 1992 12:43:35 -0500
Organization: Kansas State University
NNTP-Posting-Host: matt.ksu.ksu.edu

Ross Ridge <ross@zooid.guild.org> writes:

>While this would be what I'd do, even this isn't 100% guaranteed if
>someone has broken security on the machine.  It's possible, for instance,
>that the mount command, shell or even kernel has been hacked to prevent
>tripwire from doing it's job properly.

*shaking head*  Man, some people can get just a LITTLE too paranoid!

Why don't you just restore the OS from tape every morning?  No, wait -- 
someone could break in, mount the tapes in the night, and backup their
hacked kernel.  Bad Idea.  Maybe Sun would be willing to mail you new
tapes every day?  No, someone could intercept them from your Post Office
and tamper with them...

...some people need a better sense of reality! 

-- 
Rich Holland              | INTERNET: holland@matt.ksu.ksu.edu
100 Jardine Terr, Apt A7  | BITNET  : holland@ksuvm
Manhattan, KS  66502-3357 | UUCP    : ...!rutgers!matt.ksu.ksu.edu!holland
char*p="char*p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
Newsgroups: comp.security.misc
From: rik@nella13.cc.monash.edu.au (Rik Harris)
Subject: Re: Locking terminals (was Re: New Princeton Policy)
Reply-To: rik.harris@fcit.monash.edu.au
Organization: Monash University, Melb., Australia.
Date: Sat, 12 Sep 1992 07:33:58 GMT

ckd@eff.org (Christopher Davis) writes:

>Danny> == Danny McGurl <dsm@prism.gatech.EDU> 

> Danny> Heck, we hav trouble keeping people from bringing in cokes into
> Danny> some of our clusters (even though we have huge signs).  Somehow
> Danny> I think people would laugh at a reguirement to use the system
> Danny> lockscreen :)

>Simple policy fix: ``If the terminal is locked with anything other than
>the "standard" lockscreen, it may be rebooted in order to clear the
>lock.''

There's a similar discussion going on at Monash.  Unfortunately the same
``solution'' came up here.  The problem with Christopher's method is
that the person who ran the non-standard lockscreen doesn't lose
by this (any more than a ``log out after 15 mins'' approach), but the
people who are remotely logged in do lose.  You are punishing the
remote users, just because of one idiot locking the screen the
``wrong'' way.

rik.
-- 
Rik Harris - rik.harris@fcit.monash.edu.au
+61 3 571-2895 (AH & ans.mach) +61 3 573-2679 (BH)
Faculty of Computing and Information Technology,
Caulfield Campus, Monash University, Australia
From: dsm@prism.gatech.EDU (Danny McGurl)
Newsgroups: comp.security.misc
Subject: Re: Locking terminals (was Re: New Princeton Policy)
Date: 11 Sep 92 15:17:05 GMT
Organization: Revelstone High Command

In article <1992Sep10.161835.20380@rz.uni-karlsruhe.de> S_TITZ@iravcl.ira.uka.de (Olaf Titz) writes:

[Logging out users who have their screen locked]

>What about the following?

>A locking program that 
>- displays the time it is running,
>- after N minutes provides a button which will log the user out (with
>N preferrably to be specified in a configuration file),
>- perhaps communicates with other workstations in the cluster, to
>enable the logout only when no other workstation is idle.

This leaves out one very important problem.  Since the person who is using
the machine has ownership of the console, he/she can simply crank up his
own version of lock that doesn't have the logout feature.  Are you just going
to tell them that they can't run it?

Heck, we hav trouble  keeping people from bringing in cokes into some of our
clusters (even though we have huge signs).  Somehow I think people would 
laugh at a reguirement to use the system lockscreen :)
-- 
Danny McGurl                        "No, no Pixel!  Beer is not for baby cats."
Office of Information Technology        --Richard Ames,
dsm@prism.gatech.edu 		        __The Cat Who Walks Through Walls__
Newsgroups: comp.security.misc,alt.security,alt.sources.d,comp.sources.testers,comp.unix.admin
From: erc@unislc.uucp (Ed Carp)
Subject: Re: Beta testers needed for security tool
X-Newsreader: Tin 1.1 PL5
Organization: Unisys Corporation SLC
Date: Fri, 11 Sep 1992 18:05:15 GMT

John F. Haugh II (jfh@rpp386.lonestar.org) wrote:

: I run something like this nightly.  It checks UID, GID, mode bits, sizes,
: creation and update times, and the checksum.  It has yet to find an
: intruder, but then the system hasn't been broken into in 3 or 4 years now.

...not since khijol moved out of Austin... :) :) :)

You could always set up a one-way UUCP path to an XT or something, then
UUCP the stuff from tripwire (or whatever) to the secured system.  It's
on the other end of a one-way UUCP link, so I'd think it'd be pretty secure.
:) :)
-- 
Ed Carp, N7EKG     erc@apple.com                801/538-0177
"This is the final task I will ever give you, and it  goes  on  forever.   Act
happy, feel happy, be happy, without a reason in the world. Then you can love,
and do what you will."           -- Dan Millman, "Way Of The Peaceful Warrior"
Newsgroups: comp.security.misc,alt.security
From: styri@hal.nta.no (Haakon Styri)
Subject: Re: Info requested on "computer crime"
Reply-To: styri@nta.no
Organization: Norwegian Telecom Research
Date: Wed, 9 Sep 92 07:05:23 GMT


Here are two references:

Ulrich Sieber:
"The International Handbook on Computer Crime"
John Wiley, 1986.
ISBN 0-471-91224-7

Chantico Publishing Company, Inc.:
"Combating Computer Crime"
McGraw-Hill, 1992.
ISBN 0-8306-7664-3


Enjoy,

---
Haakon Styri
Norwegian Telecom Research
Newsgroups: comp.security.misc,alt.security
From: who@gandalf.UMCS.Maine.EDU (William H. Owen)
Subject: Re: Info requested on "computer crime"
Organization: University of Maine Department of Computer Science
Date: Wed, 9 Sep 1992 13:49:58 GMT

	Well, at ftp.eff.org in the /pub/cud you should find a wealth
of information on computer crimes. Anonymous ftp of course.
Newsgroups: comp.security.misc
From: fitzgb@mml0.meche.rpi.edu (Brian Fitzgerald)
Subject: Re: Hiding Processes from ps -ax
Organization: Rensselaer Polytechnic Institute, Troy, NY
Date: Sun, 6 Sep 1992 03:32:29 GMT

Thanks for the clarification.  :-)
Sorry for adding confusion. :-(

Brian
Newsgroups: comp.security.misc
From: flaps@dgp.toronto.edu (Alan J Rosenthal)
Subject: Re: Hiding Processes from ps -ax
Date: 5 Sep 92 20:24:09 GMT

fitzgb@mml0.meche.rpi.edu (Brian Fitzgerald) writes:
>If p is char*, then p++ steps p through the characters in argv[0],
>which is not wanted here.

It's what I meant, and I think it is wanted here.  I found that if I just did
strcpy(argv[0], "rn") then ps displayed "rn ut", that is if my binary was named
a.out.  It seems it knows from some other means the length of the argv string
area, and it goes through it just printing spaces for zeroes.

Setting argv[...] to null does nothing, since ps looks at the string area, not
the place where all the pointers are put.  Questions about this can be taken to
comp.lang.c or to e-mail.

To respond to other points:
* This works fine on AIX, at least version 3.1 on the RS6000, which is where I
just tested it.
* Things like "ps -c" will show you the command name, but this can usually be
changed for real via symlinks or copying; they won't show you the arguments.
* It's true that this doesn't prevent it from showing up on ps at all.  But it
can make it awfully innocuous looking.

So here's a program which wipes all arguments, not just the program name.  I
found that on suns (I didn't test this widely), if you set arguments to null
strings, ps tends to get pissed off, so I just set them to spaces.  Ps on the
sun even seems to remove the trailing spaces!  And btw, I had (apparently
mistakenly) assumed that presenting the idea was sufficient and that I didn't
have to present a fully functional program.  But here is a closer to fully
functional program since the first example didn't seem to be sufficient.

#include <stdio.h>
#include <string.h>

int main(argc, argv)
    int argc;
    char **argv;
{
    int i;
    char *p;

    for (i = 0; i < argc; i++)
	for (p = argv[i]; *p; p++)
	    *p = ' ';
    strcpy(argv[0], "rn");

    (void)getchar();
    return(0);
}
Newsgroups: comp.security.misc
From: ob@obh.in-berlin.de (Oliver Brandmueller)
Subject: Re: Shadow password file software for BSD 4.2
Organization: obh - private bbs in Berlin/Germany
Date: Wed, 9 Sep 92 11:51:44 GMT

Hi,

jfh@rpp386.lonestar.org (John F. Haugh II) writes:
[...]
>Actually, a better person to get ahold of is Steve Simmons.  He did a
>significant amount of work in that area.  I don't know where he is
>hiding these days ...

            Steve Simmons       scs@iti.org
            Steve Simmons       scs@lokkur.dexter.mi.us
            Steve Simmons       ssimmons@convex.com
            Steve Simmons       Steve_Simmons@a68k.denver.CO.US

Don't know, which one you mean, or if he's in that list. These are all
People with "Steve Simmons" in their realname field writing in the news
I get these days.

Hope that helps.

Bye, Olli

-- 
| Oliver Brandmueller | Detmolder Str. 64 | 1000 Berlin 31 | Germany - (FRG) |
| ob@obh.in-berlin.de | V +49 30 853 6980 | Cityruf 315 30 68 30 (numerisch) |
| "Ich werde Millionaer, heirate Jodie Foster und nehme mir eine Nymphomanin |
|          als Putzfrau. Dann habe ich alles erreicht." - ob@school          |
Newsgroups: comp.security.misc
From: cp78067@csie.nctu.edu.tw (82/6/31)
Subject: EtherNet
Organization: Computer Science & Information Engin., Chiao-Tung U, Taiwan, ROC
X-Newsreader: Tin 1.1 PL5
Date: Mon, 7 Sep 1992 11:04:26 GMT

Hi , 

     Since a packet on ethernet can be received by all the nodes , how could I 
solve security problem ( if some one write a program to 'listen' my packets ) ?
Could someone's screen display the same data of my screen EXACTLY ( plus the 
password ! ) ? 
     Thanx in advance.

     Jason
From: rjq@phys.ksu.edu (Rob Quinn)
Newsgroups: comp.security.misc
Subject: World writable syslog.pid file
Date: 14 Sep 1992 21:18:54 GMT
Organization: Kansas State University
NNTP-Posting-Host: bohr.phys.ksu.edu

 On most of the Suns I just checked, /etc/syslog.pid is world writable.
If they are running the standard crontab for root, then they probably
have an entry like this:
 5 4 * * 6      /usr/lib/newsyslog >/dev/null 2>&1

 And the last line of /usr/lib/newsyslog is:
kill -HUP `cat /etc/syslog.pid`


 So, any creative uses for this? 

--
|                                                                Rob Quinn |
|                                                         rjq@phys.ksu.edu |
|                                                    QuinnBob@KSUVM.BITNET |
From: gay@moebius.loria.fr (Gay Stephane)
Newsgroups: comp.security.misc
Subject: Re: Hiding Processes from ps -ax
Date: 10 Sep 92 12:12:55 GMT
	<3078@ariel.its.unimelb.EDU.AU>
Organization: INRIA-Lorraine / CRIN - Nancy - France
In-reply-to: dfa@rabbit.physiol.unimelb.edu.au's message of 5 Sep 92 06:17:40 GMT

>Alan J Rosenthal (flaps@dgp.toronto.edu) wrote:
>: sxjcb@orca.alaska.edu (Jay C. Beavers) writes:
>: >I've recently heard that you can hide a process from being displayed by a
>: >ps -ax command.  Is this true, and if so what security implications does it
>: >have?  How is this done,

>This might be a simple way to do it,  if it worked!  On some systems
>it will do the trick (e.g. SunOS),  but it doesn't work on IBM's
                            ^^^^^

ok, name is changed. but you can have the real name using ps -axc.
still waiting for *the* solution. i've been told that you've to go
into /dev/kmem ...
--
---------------------------------------------------------------------------
 Stephane GAY, Metz, FRANCE.        please e.mail to : bigorno@ese-metz.fr
---------------------------------------------------------------------------