home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / zines / cud / cud300.txt < prev    next >
Encoding:
Text File  |  2003-06-11  |  42.0 KB  |  879 lines

  1.  
  2.   ****************************************************************************
  3.                   >C O M P U T E R   U N D E R G R O U N D<
  4.                                 >D I G E S T<
  5.               ***  Volume 3, Issue #3.00 (January 6, 1991)   **
  6.   ****************************************************************************
  7.  
  8. MODERATORS:   Jim Thomas / Gordon Meyer  (TK0JUT2@NIU.bitnet)
  9. ARCHIVISTS:   Bob Krause / Alex Smith / Bob Kusumoto
  10. BYTEMASTER:  Brendan Kehoe
  11.  
  12. USENET readers can currently receive CuD as alt.society.cu-digest.
  13. Anonymous ftp sites: (1) ftp.cs.widener.edu (2) cudarch@chsun1.uchicago.edu
  14. E-mail server: archive-server@chsun1.uchicago.edu.
  15.  
  16. COMPUTER UNDERGROUND DIGEST is an open forum dedicated to sharing
  17. information among computerists and to the presentation and debate of
  18. diverse views.  CuD material may be reprinted as long as the source is
  19. cited.  Some authors, however, do copyright their material, and those
  20. authors should be contacted for reprint permission.
  21. It is assumed that non-personal mail to the moderators may be reprinted
  22. unless otherwise specified. Readers are encouraged to submit reasoned
  23. articles relating to the Computer Underground.
  24. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  25. DISCLAIMER: The views represented herein do not necessarily represent the
  26.             views of the moderators. Contributors assume all responsibility
  27.             for assuring that articles submitted do not violate copyright
  28.             protections.
  29. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  30.  
  31. CONTENTS:
  32. File 1: Moderators' Corner
  33. File 2: From the Mailbag
  34. File 3: Gender-Neutral Language
  35. File 4: Sexism and the CU
  36. File 5: Security on the Net
  37. File 6: The CU in the News
  38.  
  39. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  40.  
  41. ----------------------------------------------------------------------
  42.  
  43. ********************************************************************
  44. ***  CuD #3.00: File 1 of 6: Moderator's corner                  ***
  45. ********************************************************************
  46.  
  47. From: Moderators
  48. Subject: Moderators' Corner
  49. Date: January 6, 1991
  50.  
  51. ++++++++++
  52. In this file:
  53. 1. VOLUME 3 BEGINS WITH THIS ISSUE
  54. 2. SEXISM AND CuD
  55. ++++++++++
  56.  
  57. +++++++++++
  58. Volume 3 Starts Here
  59. +++++++++++
  60.  
  61. Volume 1, with issues #1.00 thru 1.29 and Volume 2, issues 2.00 thru 2.19,
  62. complete the first year of CuD. With the new year we start a new volume,
  63. and it will remain Volume #3 thru 1991.  We'll spare readers self-indulgent
  64. reflections on the first year, but we're amazed that what began as a
  65. temporary outlet with Pat Townson's support and help back in March seems to
  66. have become at least semi-permanent. Following Craig Neidorf's victory, we
  67. thought there would be little else to write about, but the articles,
  68. comments, and responses keep coming, so we'll keep publishing as long as
  69. they do. The ftp sites have expanded and contain a variety of papers and
  70. documents related to the CU. We *STRONGLY ENCOURAGE* researchers, attorneys
  71. and law students to send quality papers over to us for the archives. We
  72. also thank all those who send in news blurbs--keep them coming.
  73.  
  74. +++++++++++
  75. CuD and Sexism
  76. ++++++++++++
  77.  
  78. In a file below, the writer takes the moderators to task for not taking a
  79. stand on sexist language. We agree that writing should be as gender free as
  80. possible, but we don't change articles (except for formatting, spelling,
  81. and deleting long sigs).  Authors have their own style, and while we object
  82. to sexist language (or any other action that reinforces the cultural power
  83. of one group over another), we cannot edit it out. An author's style is a
  84. valid index of cultural influences, and therefore it remains an open
  85. archive to be decoded as window into the world of, in this case, the CU. We
  86. *STRONGLY* encourage articles on the isms (ageism, sexism, racism) and the
  87. CU.
  88.  
  89. ********************************************************************
  90.                            >> END OF THIS FILE <<
  91. ***************************************************************************
  92.  
  93. ------------------------------
  94.  
  95. From: Various
  96. Subject: From the Mailbag
  97. Date: January 6, 1991
  98.  
  99. ********************************************************************
  100. ***  CuD #3.00: File 2 of 6: From the Mailbag                    ***
  101. ********************************************************************
  102.  
  103. From: wayner@SVAX.CS.CORNELL.EDU(Peter Wayner)
  104. Subject: Re: Cu Digest, #2.19
  105. Date: Thu, 3 Jan 91 14:27:26 -0500
  106.  
  107. This is in reply to John Debert's note in CuDigest #2.19:
  108.  
  109. He writes:
  110. "Now, suppose that someone has used this method to encrypt files on his/her
  111. system and then suppose that Big Brother comes waltzing in with a seizure
  112. warrant, taking the system along with all the files but does not take the
  113. code keys with them. Knowing Big Brother, he will really be determined to
  114. find evidence of a crime and is not necessarily beneath (or above) fudging
  115. just a bit to get that evidence. What's to keep him from fabricating such
  116. evidence by creating code keys that produce precisely the resultsthat they
  117. want-evidence of a crime? Would it not be a relatively simple procedure to
  118. create false evidence by creating a new key using the encrypted files and a
  119. plaintext file that says what they want it to? Using that new key, they
  120. could, in court, decrypt the files and produce the desired result, however
  121. false it may be. How can one defend oneself against such a thing? By
  122. producing the original keys? Whom do you think a court would believe in
  123. such a case?
  124.  
  125. One should have little trouble seeing the risks posed by encryption."
  126.  
  127. This is really unlikely, because in practice most people only use one-time
  128. pads for communication. They are not in any way practical for on-site
  129. encryption. Imagine you have 40 megabytes of data. If you want to encrypt
  130. it with a one-time pad, you need 40 megabytes of key. If you did this,
  131. it would be very secure because there exists a perfectly plausible 40 Meg key
  132. for each possible 40 meg message.
  133.  
  134. But, if you were going to keep the 40 megs of encrypted data handy, you
  135. would need to keep the 40 megs of key just as handy. When the government
  136. came to call, they would get the key as well. That is why it is only
  137. practical to use systems like DES and easy to remember, relatively short
  138. keys to do the encryption. That way there is nothing to seize but your
  139. brain.
  140.  
  141. ---Peter Wayner
  142. Dept. of Computer Science, Cornell Univ.
  143. (wayner@cs.cornell.edu)
  144.  
  145. ++++++++++++++++++++++++++
  146.  
  147. From: CuD Dump Account <works!cud@UUNET.UU.NET>
  148. Subject:   BBSs as Business Phones?
  149. Date: Thu, 03 Jan 91 15:57:49 EDT
  150.  
  151. Ok this is just a quick question.
  152.  
  153. How can it be legal to make BBS' operators shell out extra money for a
  154. hobby, answering machines aren't something people have to pay extra for,
  155. and in some cases thats what BBS's are used for. If its a public BBS, it is
  156. receiving no true income from its users, unless they pay a standard,
  157. billable time, (ie. A commercial BBS) What gives them the right to charge
  158. us now? They don't force you to pay for special business class lines/fiber
  159. optic lines to call lond distance do they? No its by choice. Most SysOps
  160. buy the cheapest line available which is usually local only, no dial out,
  161. etc. SysOp's in the long run absorb most, if not all the costs of running a
  162. BBS, that means power, servicing, and the phone. The phone line at minimum,
  163. is going to cost at least a hundred or so per year. Then power, its absurd.
  164. In my case, I run a BBS to share information, and I allow everyone on for
  165. free.  I've seen the old FCC proposals to have people using modems pay
  166. more, but I don't rightly see why. If I am not mistaken this is bordering
  167. on their greed to make more money for the growing modem populous.
  168.  
  169. Do they have a right to charge us? are they providing any type of special
  170. service because we have a modem on the line, instead of an answering
  171. machine, FAX, phone, or other? we are private citizens, it should be up to
  172. us how we use the phones. TelCo's still a monopoly
  173.  
  174. There are a lot of rumours about this type of thing, only I've never seen
  175. it actually put into action.
  176.  
  177. +++++++++++++++++++++++++
  178.  
  179. From: Paul Cook <0003288544@MCIMAIL.COM>
  180. Suject: Response to "Hackers as a software development tool"
  181. Date: Fri, 4 Jan 91 06:44 GMT
  182.  
  183. {Andy Jacobson <IZZYAS1@UCLAMVS.BITNET> writes:}
  184. >
  185. >I received one of those packs of postcards you get with comp.  subscription
  186. >magazines (Communications Week) that had an unbelievable claim in one of
  187. >the ads. I quote from the advertisement, but I in no way promote,
  188. >recommend, or endorse this.
  189. >
  190. >"GET DEFENSIVE!
  191. >YOU CAN'S SEE THEM BUT YOU KNOW THEY'RE THERE.
  192. >Hackers pose an invisible but serious threat to your information system.
  193. >Let LeeMah DataCom protect your data with the only data security system
  194. >proven impenetrable by over 10,000 hackers in LeeMah Hacker Challenges I
  195. >and II. For more information on how to secure your dial-up networks send
  196. >this card or call, today!" (Phone number and address deleted.)
  197. >
  198. >So it seems they're claiming that 10,000 hackers (assuming there are that
  199. >many!) have hacked their system and failed. Somehow I doubt it. Maybe they
  200. >got 10,000 attempts by a team of dedicated hackers, (perhaps employees?)
  201. >but has anyone out there heard of the LeeMah Hacker Challenges I and II?
  202.  
  203. Yes, Lee Mah is for real.  They make a some nice computer security
  204. equipment to stop folks from trying to gain access to your dialup modems.
  205.  
  206. The "Hacker Challenge" is for real too.  They publicized it for a long
  207. time, and I recall reading about it in PC Week, Byte, and possibly
  208. InfoWorld.  I don't know how accurate the "10,000" hackers is (maybe it was
  209. 10,000 call attempts?) but they ran a couple of contests where they gave a
  210. phone number of one of their devices, and offered some kind of a prize to
  211. anyone who could figure out how to get in.  I have seen the Lee Mah
  212. catalog, and I don't recall how they provide security, but I think some of
  213. their gear uses dialback modems that call pre-programmed user numbers when
  214. the right code is entered.
  215.  
  216. ++++++++++++++++++++++
  217.  
  218. From: stanley@PHOENIX.COM(John Stanley)
  219. Subject: Re: a.k.a. freedom of expression
  220. Date: Fri, 04 Jan 91 23:45:31 EST
  221.  
  222. In CuD 2.19, balkan!dogface!bei@CS.UTEXAS.EDU(Bob Izenberg) writes:
  223.  
  224. > I read this in issue 2.16 of the Computer Underground Digest:
  225. >
  226. >          [ quoted text follows ]
  227. >
  228. >           ADAM E. GRANT, a/k/a The             :
  229. >           Urvile, and a/k/a Necron 99,         :
  230. >           FRANKLIN E. DARDEN, JR., a/k/a       :
  231. >           The Leftist, and                     :
  232. >           ROBERT J. RIGGS, a/k/a               :
  233. >           The Prophet                          :
  234. >           [ quoted text ends ]
  235. >
  236. > The assumption here, that an alias employed in computer communications is
  237. > the same as an alias used to avoid identification or prosecution, doesn't
  238. > reflect an awareness of the context within which such communications
  239. > exist.
  240.  
  241. The only reason "The Prophet" was used was to avoid identification.
  242. But, that doesn't really matter. The reason it was included in the
  243. Government doohicky was to identify the one legal name and alternates
  244. chosen by the defendant used by him as his sole identification at specific
  245. times.
  246.  
  247. > The very nature of some computer operating systems demands some
  248. > form of alias from their users. Management policy also affects how you
  249. > can identify yourself to a computer, and to anyone who interacts with you
  250. > through that computer.
  251.  
  252. How you identify yourself in communications is entirely up to you.  You
  253. do not need to use your computer User ID as your sole identity. Note that
  254. the From: line of your original post identified you, as does mine.  If I
  255. add a .sig that identifies me as "Draken, Lord of Trysdil", and remove the
  256. From: comment name, then you know me as Draken, and bingo, I have an a.k.a.
  257. Am I doing it to commit a crime? Probably not. It doesn't really matter.
  258.  
  259. > If we strip the implication from those three letters
  260. > that the party of the leftmost part is calling themselves the party of the
  261. > rightmost part to avoid getting nabbed with the goods, what's left?
  262.  
  263. You are left with the fact that they are also known as ..., which is
  264. just what the a.k.a stands for. It does NOT stand for Alias for Kriminal
  265. Activity, as you seem to think it does. The "implication" you speak of is
  266. an incorrect inferance on your part. Guilty conscience?
  267.  
  268. > In using a computer communications medium, particularly an informal one
  269. > like a BBS, the name you choose can set the tone for the aspect of your
  270. > personality that you're going to present (or exaggerate.)
  271.  
  272. You mean, like, the name you chose is how you will be known? Like, you
  273. will be known to some as "Bob Izenberg", but on the BBS you will be also
  274. known as "Krupkin the Gatherer"? Like a.k.a.?
  275.  
  276. > Are radio
  277. > announcers using their "air names" to avoid the law?  How about people with
  278. > CB handles?  Movie actors and crew members?  Fashion designers?  Society
  279. > contains enough instances of people who, for creative reasons, choose
  280. > another name by which they're known to the public.
  281.  
  282. And if any of them go to court, they will have a.k.a., too. There will
  283. be their legal name, followed by the a.k.a. There is no implication of
  284. criminal activity from just having an a/k/a, just the indication that the
  285. prosecution wants to make sure the defendants are identified. "Him.  That
  286. one, right there. His legal name is X, but he is also known as Y and Z. All
  287. the evidence that says that Y did something is refering to him, X, because
  288. the witness knows him by that."
  289.  
  290. > Whenever somebody uses a.k.a., correct them!
  291.  
  292. Ok, consider this a correction, at your own demand.
  293.  
  294. +++++++++++++++++++++++
  295.  
  296. From: 6600mld@UCSBUXA.BITNET
  297. Subject: Response to Encryption dangers in seizures
  298. Date: Sat, 5 Jan 91 14:19:07 PST
  299.  
  300. >Subject: Encryption dangers in Seizures
  301. >Date: Sat, 29 Dec 90 11:20 PST
  302.  
  303. [misc background on encryption and its use to thwart Big Brother deleted.]
  304.  
  305. >Now, suppose that someone has used this method to encrypt files on his/her
  306. >system and then suppose that Big Brother comes waltzing in with a seizure
  307. >warrant, taking the system along with all the files but does not take the
  308. >code keys with them. Knowing Big Brother, he will really be determined to
  309. >find evidence of a crime and is not necessarily beneath (or above) fudging
  310. >just a bit to get that evidence. What's to keep him from fabricating such
  311. >evidence by creating code keys that produce precisely the results that they
  312. >want-evidence of a crime? Would it not be a relatively simple procedure to
  313. >create false evidence by creating a new key using the encrypted files and a
  314. >plaintext file that says what they want it to? Using that new key, they
  315. >could, in court, decrypt the files and produce the desired result, however
  316. >false it may be. How can one defend oneself against such a thing? By
  317. >producing the original keys? Whom do you think a court would believe in
  318. >such a case?  > >One should have little trouble seeing the risks posed by
  319. encryption.
  320.  
  321. I think it unlikely that if the Feds wanted to frame you or fabricate
  322. evidence that they would bother to use the encrypted data found at your
  323. site.  Instead, I think, they would fabricate the whole wad -- plaintext,
  324. key, and ciphertext.  For this reason, it is not only one-time key
  325. encryption that is threatened, but iterative algorithms as well.
  326.  
  327. So, if I have data encrypted, and the feds are going to "fix" it, why is
  328. this any more dangerous than having NO DATA?  If they want to frame me,
  329. they're going to (try), regardless of whether they found encrypted data or
  330. not!  Thus, I see encryption as preventing the feds from really KNOWING
  331. what you do and do not have.  This is very valuable.  I think that even in
  332. our mostly corrupt government that it would be difficult to fabricate
  333. evidence to the tune of posession of AT&T source code.
  334.  
  335. Similar tactics can be applied JUST AS EASILY to physical crimes.  The
  336. crime lab finds a dead guy with a .44 slug in him.  The suspect owns a .44,
  337. but not the one used in the shooting.  What is to prevent the (now seized)
  338. .44 of the suspect to be fired and the slug swapped for the slug discovered
  339. in the body?  This is trivial to accomplish, assuming the poeple involved
  340. are sufficiently crooked.
  341.  
  342. Now, I'm not saying that the Feds don't fabricate evidence.  But I do not
  343. think that encrypting one's data makes one a more vulnerable target to such
  344. injustice.
  345.  
  346. >jd / onymouse@netcom.UUCP     netcom!onymouse@apple.com
  347.  
  348. ********************************************************************
  349.                            >> END OF THIS FILE <<
  350. ***************************************************************************
  351.  
  352. ------------------------------
  353.  
  354. From: "Brenda J. Allen (303) 492-0273" <ALLEN_B@CUBLDR.COLORADO.EDU>
  355. Subject: Gender-Neutral Language
  356. Date: Wed, 2 Jan 1991 14:03 MST
  357.  
  358. ********************************************************************
  359. ***  CuD #3.00: File 3 of 6: Gender-Neutral Language             ***
  360. ********************************************************************
  361.  
  362. The Dark Adept's article (CuD #2.10, File 9) on In-House Security Problems
  363. was informative and insightful.  However, I was appalled by the author's
  364. consistent and flagrant use of masculine pronouns and sex-linked nouns to
  365. refer to persons (hackers, system operators, employees) who could be either
  366. male or female.  Although hackers and system operators traditionally have
  367. been men, women also are assuming those roles.  Moreover, employees who use
  368. computers certainly comprise both genders.  Therefore, references to users
  369. as males (e.g., "employees often choose passwords such as their wife's
  370. maiden name") are particularly inappropriate and sexist.
  371.  
  372. I am not accusing the author of intentional discrimination against females.
  373. Rather, I believe that he or she may not be aware of the implications and
  374. ramifications of gender-biased language.  Language has the power to shape
  375. thought, reinforce biases, and perpetuate stereotypes.  Consequently,
  376. omitting mention of females in a discussion about computer-related
  377. activities may help to sustain the impression of male domination of that
  378. area of our lives.  Moreover, such oversights may send the covert message
  379. that some persons wish to maintain such an image, to discount contributions
  380. by women, and/or to discourage female participation.
  381.  
  382. Therefore, I encourage everyone to become more thoughtful of their choice
  383. of words and more sensitive to issues regarding gender.  This seems
  384. particularly crucial in the contemporary forum of electronic discourse.  As
  385. we pave new paths, we must assume responsibility for changing old language
  386. habits.  Also, we should strive to avoid sending implicit and explicit
  387. messages regarding females and their roles in computer science and related
  388. fields.
  389.  
  390. On a positive note, I've observed such awareness in other CuD files.  For
  391. instance, job announcements usually cite both genders, and Alan Wexelblat
  392. recently qualified a reference to philosophers as males by noting that
  393. women had been systematically excluded from that area of study.
  394.  
  395. Guidelines for avoiding the use of male-only pronouns include the
  396. following: reword sentences to eliminate unnecessary gender pronouns;
  397. alternate the use of female and male pronouns and nouns; recase sentences
  398. into plural forms (e.g., "they" or "we"); use neutral terms like "one,"
  399. "you," "an individual," etc. instead of "he" or "she."  Another way to
  400. avoid subtle sexism is to substitute asexual words and phrases for
  401. man-words (e.g., "spouse's name" instead of "wife's maiden name").
  402.  
  403. Although applying these and other guidelines may be challenging and
  404. somewhat time-consuming, it is imperative that we make the effort to
  405. acknowledge the changing shape of our society as women continue to occupy
  406. positions previously reserved for men.
  407.  
  408. ********************************************************************
  409.                            >> END OF THIS FILE <<
  410. ***************************************************************************
  411.  
  412. ------------------------------
  413.  
  414. From: Liz E. Borden
  415. Subject: Sexism and the CU
  416. Date: Mon, 31 Dec 90 12:52 PST
  417.  
  418. ********************************************************************
  419. ***  CuD #3.00: File 4 of 6: Sexism and the CU                   ***
  420. ********************************************************************
  421.  
  422. Why, you ask, do I think the CU is sexist?  Carol Gilligan wrote that women
  423. speak in "a different voice" from men, one grounded more in nurturing,
  424. dialogue, negotiation and control-fee language.  The voice of the computer
  425. world reflects a male voice and recreates the subtle patriarchy of the
  426. broader society through the so-called neutrality of "objective" science and
  427. the ways of speaking and behaving that, when translated into the
  428. two-dimensional world of electronic communications, tend to silence women.
  429.  
  430. Computer underground Digest, like the CU in general, is a male bastion.
  431. Sexist language, male metaphors, and if I'm counting correctly, not a
  432. single self-announced female contributor (although it is possible that some
  433. of the pseudonyms and anonymous writers were women).  In fairness, I judge
  434. that the editors of CuD attempt to be sensitive to the concerns of
  435. feminists, and have noticed that articles under their name do not contain
  436. sexist language and tend toward what's been called "androgenous discourse."
  437. But, they have have not used their position to translate concerns for
  438. social justice into practice by removing sexist language (or even posting a
  439. policy preference), by encouraging women, or by soliciting articles on
  440. minorities, women, and other groups that are invisible and silent.
  441.  
  442. Let's look at just a few areas where cybersexism creeps in.  First, The CU
  443. is made up mostly of males. I'm told by friends, and the facts are
  444. consistent with those given to me by one CuD moderator, that at a maximum,
  445. less that five percent of pirates are female, and probably less than one
  446. percent are phreaks or hackers. This skewed participation transports the
  447. male culture of values, language, concerns, and actions, into a new world
  448. and creates models that women must conform to or be excluded from full
  449. membership. Like the Europeans, CUites move into a new territory and stake
  450. out their cultural claim committing a form of cultural genocide against
  451. those with different cultural backgrounds.  Isn't it ironic that in a new
  452. world where "a million flowers bloom" and a variety of subcultures emerge,
  453. that they are for all practical purposes male?
  454.  
  455. Second, BBSs, especially those catering to adolescents and college
  456. students, are frightening in their mysogeny. I have commonly seen in
  457. general posts on large boards on college towns discussion of women in the
  458. basest of terms (but never comparable discussions of men), use of such
  459. terms as broads, bitches, cunts, and others as synonomous with the term
  460. "woman" in general conversation, and generalized hostile and angry
  461. responses against women as a class. These are not isolated, but even if we
  462. were to concede that they are not typical of all users on a board, such
  463. language use is rarely challenged and the issues the language implies are
  464. not addressed.
  465.  
  466. Third, sexism is rampant on the nets. The alt.sex (bondage, gifs,
  467. what-have-you) appeal to male fantasies of a type that degrades women. No,
  468. I don't believe in censorship, but I do believe we can raise the gender
  469. implications of these news groups just as we would if a controversial
  470. speaker came to a campus.  Most posts that refer to a generic category tend
  471. to use male specific pronouns that presume masculinity (the generic "he")
  472. or terms such as "policeman" or "chairman" instead of "chair" or "police
  473. officer."
  474.  
  475. At the two universities I attended, both with excellent computer science
  476. departments, women comprised about half of the undergraduate majors. This
  477. shifted dramatically in grad school, and the male professors were generally
  478. well-meaning, but most were not sensitive to the difficulties of women in a
  479. male-dominated career. Yes, of course it's possible for women to succeed
  480. and be taken seriously in the computer world, to advance, to earn high
  481. salaries. But this isn't the point. The peripheral treatment in which we
  482. are still treated like second class citizens exists.  The jokes, the
  483. language, the subtle behaviors that remind us that we are women first and
  484. professionals second, and all the other problems of sexism are carried over
  485. into the computer world.  Why don't we think about and discuss some of
  486. this, and why isn't CuD taking the lead?!
  487.  
  488. ********************************************************************
  489.                            >> END OF THIS FILE <<
  490. ***************************************************************************
  491.  
  492. ------------------------------
  493.  
  494. From: Name withheld
  495. Subject: Security on the Net
  496. Date: Sun, 23 Dec 90 17:04:49 -0500
  497.  
  498. ********************************************************************
  499. ***  CuD #3.00: File 5 of 6: Security on the Net                 ***
  500. ********************************************************************
  501.  
  502. COPS is a unix security package that runs through a checklist of sorts
  503. looking for common flaws in system security.
  504.  
  505. I polled a security mailing list and got about 40 responses to a selected
  506. number of questions dealing with security; it might be useful for inclusion
  507. on how the net (at least some of the security minded ones) view security.
  508. The answers to these questions shaped some of the philosophies of COPS and
  509. might be indicative of the type of security tools to be developed in the
  510. future.  My questions start with a number and a ")".
  511.  
  512.    1)  What kinds of problems should a software security system (SSS)
  513.    such as COPS check for? (Mention specific examples, if you can.)
  514.  
  515. Just about everyone agreed that the more things checked, the better.  Some
  516. specific wants of items I didn't mention, more or less in the order of # of
  517. requests:
  518.  
  519. Some kind of _secure_ checksum method for checking up on binary files.
  520.  
  521. Checking binaries for known security problems - sendmail, fingerd, ftpd,
  522. ect.
  523.  
  524. Checking the validity of the _format_ of key files rather than merely
  525. checking if they are writable.
  526.  
  527. Checking for potential trojan horses; files such as "ls" in a users
  528. account.
  529.  
  530. Finding things hidden under mount points.
  531.  
  532. Keeping track of accounts in a seperate file from /etc/passwd and run
  533. periodic checks to see if any accounts have been added by any unauthorized
  534. user.
  535.  
  536. Report unusual system activity, such as burning lots of CPU time.
  537.  
  538. Record unsuccessful login attempts and su's to root, when and by whom if
  539. possible.
  540.  
  541.    2)  Are there any security problems too sensitive to be checked
  542.    by a SSS?  That is, what things should *not* be built into a SSS?
  543.  
  544. Boy, this was a landslide.  Over 90% said NO, and not only no, but
  545. basically "Hell No".  The only concerns I got were against password
  546. cracking and problems that could not be easily fixed.  There was also a
  547. small amount of concern about limiting access to root, but most realized
  548. that no matter what, the benifits would outweigh any losses if the programs
  549. were put out.
  550.  
  551.    3) What should the primary goal of a SSS be -- discovering as many
  552.    security holes as possible in a given system (including bugs or
  553.    design flaws that may not be easily fixed -- especially without
  554.    source code), or merely uncovering correctable errors (due to
  555.    ignorance, carelessness, etc)?
  556.  
  557. Another landslide.  Of all the responses, only one person objected to
  558. finding all holes, although a few did say that finding the fixable holes
  559. was top priority.
  560.  
  561. One view:
  562.  
  563. My use for an SSS is as a system monitor, not as a diagnostic tool.  I
  564. suppose the diagnostic version also has its uses, but writing and
  565. distributing such a program is asking for trouble.  I don't see anything
  566. wrong with writing it and distributing only the binaries.
  567.  
  568.    4)  Do you feel that SSS are a security threat themselves?
  569.  
  570. Some dissent begins to show.... It was almost even here, with the no's
  571. beating out the yes's by a single vote.  However, 2/3 of the yes votes
  572. qualified there answer by stating something like "a tool can be misused"
  573. and whatnot.  Here are some typical responses:
  574.  
  575. Of course.  They point to way for bad guys.  Such is life.  They are a
  576. tool.  They have the potential for anything.  The security threat lies in
  577. how they are used....
  578.  
  579. No, as long as they don't breed complacency. Just by running a SSS each
  580. night should not make you thinks your systems are secure.
  581.  
  582. Fire is also dangerous but VERY useful.
  583.  
  584.  
  585.    5) Do you think that the SSS should be restricted to be used only
  586.    by system administrators (or other people in charge), or should
  587.    they be accessible to all?
  588.  
  589. Here's where the problems start :-)  Everyone wants as many features as
  590. possible, but quite a few of you don't want anyone else to have it.  Hmm...
  591. Out of 35 responses on this question:
  592.  
  593.   12 - Yes, only SA's.
  594.   10 - No.
  595.    6 - It would be nice to have it restricted, but... How?
  596.    5 - Have two versions; one restricted, one not.  Needless to say,
  597.         the dangerous stuff should go in the first.
  598.    1 - Restrict only parts that detect bugs/whatever that cannot be
  599.         repaired.
  600.    1 - Argh!  Help!
  601.  
  602.      Some quotable quotes:
  603.  
  604. I don't see how it could be restricted.
  605.  
  606. Admins, etc only. (possibly said because I'm an admin. From an intellectual
  607. standpoint, I would want to know about this stuff even if I was just a
  608. user)
  609.  
  610. I think the SSS should be restricted to system administrators with the
  611. realisation that others can probably get their hands on the code if they
  612. want to.
  613.  
  614. Definitely available to all, SA's can be as lazy as anyone and should not
  615. be allowed to hide behind a veil of secrecy if, in doing so, they expose
  616. the systems they administer.
  617.  
  618. It seems to me that only an "administrator type" will have sufficient
  619. privilege levels to make _effective_ use of such a tool.  Ordinary users
  620. may be able to garner _some_ benefit though, if run on their own files.  If
  621. possible, can there be an "administrator" mode and a (restriced/limited)
  622. "user" mode?
  623.  
  624. (and finally, my personal favorite...)
  625.  
  626. I think that a check for a hole that can't be closed shouldn't be a part of
  627. the check, if that hole is widespread.  I have no examples of any such
  628. hole, but a weak spot that can't be closed and has no workaround is one of
  629. the few candidates for the security by secrecy concept.  I have mixed
  630. feelings about this, but if I can't fix the hole, I'd rather not have it's
  631. existence be "public" knowledge.  A freely available routine to locate the
  632. hole would spread it's existence far and wide.....(?) But, if I didn't know
  633. about it beforehand then it would be good to have a tool to tell me it
  634. existed.  Gads, I hate moral conflicts!
  635.  
  636.    6) When a SSS finds a security flaw in a system, do you want it to
  637.    indicate how they flaw could be used to compromise your system, or
  638.    would you just accept the conclusion and apply a fix?
  639.  
  640. This question was ill worded and gramatically incorrect, but still managed
  641. to conjure up a lot of comments.  Some thought it was asking if the system
  642. should apply a fix.  In any case, almost 3/4 said Yes, indicate exactly how
  643. to exploit any potential hole.  As usual, there were a few with
  644. reservations about the info getting out, but....
  645.  
  646. Here are some of the more interesting comments:
  647.  
  648.                 (Think about this one!)
  649. *I* would like to know to futher my knowledge of Unix, but more importantly
  650. to make sure that the version I have was not modified by a cracker to put
  651. security holes *into* a system.  (That'd be sneaky :-)
  652.  
  653. Security by obfuscation doesn't work.
  654.  
  655. By definition, a SSS is a software system, and therefore has bugs in it.
  656. If it reported a problem which would cause quite a bit of inconvenience if
  657. fixed, or would be difficult to fix, then I would be much more apt to make
  658. the fix if I knew how the problem could be exploited.  This is important,
  659. because many, if not most, sites require only a moderate level of security,
  660. and many security holes are fiendishly difficult to exploit.
  661.  
  662. We cannot assume that end-purchasers of a system can be as aware of the
  663. internal workings of a system as the designers of the system (or SSS) are.
  664. If a security flaw is discovered, the administrators need to be informed
  665. about what changes are necessary to remove that flaw, and what
  666. repercussions they may have.
  667.  
  668. Imagine a SSS that knew sendmail(8) was a security flaw allowing a worm to
  669. enter systems.  It would report that sendmail is a security flaw, please
  670. disable it like....  If the vendor had released a patch, and the SSS didn't
  671. know how it, the administrator (in blind faith to this SSS program) might
  672. disable a *very* useful program unnecessarily.
  673.  
  674.    7)  Do you think that there is too much, not enough, or just about
  675.    the right amount of concern over computer security?  How about at
  676.    your computer site?  At other sites?
  677.  
  678. The "not enough"s won, but not by much.  I thought that given the paranoia
  679. of a security group, this would be a larger victory.  Lots of people said
  680. it depends -- on the type of facility, the size, etc. Large sites seem to
  681. have a healthier view of security (paranoia :-)) than
  682. smaller/non-governmental.  Only 4 or 5 said there was enough concern.  A
  683. couple of people mentioned _The Cuckoo's Egg_ as suggested reading (I
  684. heartily agree.)
  685.  
  686. More quotes:
  687.  
  688. (I don't know if the next answer is true, but I like it anyway!)
  689.  
  690. This is really a deep philosophical question---something to talk about over
  691. a few beers at the bar, but not here.
  692.  
  693. I think it's a site dependent problem, and all the above are true: too
  694. much, too little, and just right. Computer is not a "one size fits all"
  695. situation. Having offered that opinion, I think an assessment of my site or
  696. other sites is extraneous, and I will reserve that opinion.
  697.  
  698. ... more attention to unauthorized use of the networks.
  699.  
  700.    8)  Do you think that there should be a ruling body that governs
  701.    and enforces rules and regulations of the net -- sort of a net.police?
  702.  
  703. Some of you wondered what this had to do with software security, but just
  704. about everyone answered anyway.  This one scared me!  The "No's" only beat
  705. out the "yes's" by one vote.  Yikes!  Maybe I'm from the old school of
  706. thought, but....  Several people said that it couldn't be done anyway; a
  707. couple mentioned they a CERT-like agency to help out, but not control, and
  708. finally two said that the laws and government were already there to do
  709. this.
  710.  
  711. It's there, defacto.  The free market is working pretty well.
  712.  
  713. Absolutely. I quarrel with the "net.police" designation, per se, of course,
  714. as do many others. But perhaps something more like a recognized trade
  715. association, and providing similar services. Also, it is time that the
  716. basic duties which must be reasonably performed by a site in order for it
  717. to remain on the net should become a requirement rather than a matter of
  718. individual whim.
  719.  
  720. Yuck!  This is very distasteful to me.  It will probably be necessary
  721. though as more and more people participate in the net.  Enforcement will
  722. have to be judicious until secure networking is developed and implemented
  723. generally.
  724.  
  725. No.  Aside from the fact that it'd never work, I like Usenet as an anarchy.
  726. It has some rough edges, but for the most part it works.  What does this
  727. question have to do with SSS-type programs?
  728.  
  729. Enforcement will be tough and may hold back legitimate users.  But we have
  730. to start somewhere.  So I suppose that I agree with having net.police, as
  731. long as they don't turn things into a police.state.net.
  732.  
  733.    9)  Do you believe that breaking into other people's systems should
  734.    continue to be against the law?
  735.  
  736. Only one said "no", and s/he had a smiley following the answer.  But there
  737. were some of you who voiced concern that it wasn't really against the law
  738. to begin with.  In _The Cuckoo's Nest_, Cliff Stoll talked about a
  739. (Canadian, I think) case that the only reason the cracker was prosecuted
  740. was for stealing electricity!  Less than a watt or something.  A few of you
  741. mentioned denial of services as being a just reason, but what if they break
  742. in only at night, when no one else is on, and they really don't take
  743. anything at all?  Should that be less punishable than someone who sucks
  744. away user CPU/disk/whatever?
  745.  
  746. Breakins should be encouraged and rewarded (1/2 :-).
  747.  
  748. Yes.  Unquestionably.  However, those laws should not attempt to regulate
  749. inter-system traffic to cause these things to happen.
  750.  
  751. Yes - and as a felony in all cases, without exception.
  752.  
  753. Yes but murder, rape, robbery... are more important and laws and sentencing
  754. should reflect this. There are some around who want to treat cracking as a
  755. capital crime!
  756.  
  757. Yes, from the denial of services standpoint.  I pay $XXX,XXX.XX for a
  758. system, and joe blow slides in and sucks away at those resources, there
  759. should be a nontrivial penalty for getting caught.  Don't behead the guy,
  760. but monetary fines or community service would be just fine.
  761.  
  762. I don't know.  I'm not a philosopher.  Certainly causing damage to others
  763. is wrong, including denial of service, compromising sensitive info, or
  764. whatever.  I'm concerned though that clamping down on young kids will
  765. discourage them from becoming computer geeks.  I think we need to encourage
  766. our young people to become technically literate.  If we don't become a more
  767. expert society we can kiss it goodbye; all we'll have left is our military
  768. solutions, like some brainless jock bully...
  769.  
  770. I'm not sure that it is everywhere - but: Yes.  Should attempting to break
  771. in be against the law: No.  Is this vague: Yes.
  772.  
  773. I did not know that it was. The laws about it have not been tested and are
  774. vague and unclear. You need to be very clear about what the laws are going
  775. to do.
  776.  
  777. **HELL FUCKING YES** Those of us who started in UNIX years ago have for the
  778. most part *always* respected others!! This I can't stress strong enough.
  779.  
  780.   10)  Is your site academic, government, or commercial in nature?
  781.  
  782. Just over 1/2 of those that answered claimed university ties, with about
  783. 1/4 being commercial, 1/6 government, a few research sites, and a couple
  784. that were a mixture.  Sites included Sun, AT&T, SCO (Xenix), the DoD, and
  785. the Army, among others.
  786.  
  787. (Guess where this one came from :-)
  788.  
  789. Research.  We invented Unix.
  790.  
  791. Academic with commercial applications.
  792.  
  793. Primarily academic, but we are part of the government.
  794.  
  795. Academic, except when collecting student fees *) *)
  796.  
  797. ********************************************************************
  798.                            >> END OF THIS FILE <<
  799. ***************************************************************************
  800.  
  801. ------------------------------
  802.  
  803. From: Various
  804. Subject: The CU in the News
  805. Date: January 6, 1991
  806.  
  807. ********************************************************************
  808. ***  CuD #3.00: File 6 of 6: The CU in the News                  ***
  809. ********************************************************************
  810.  
  811. From: portal!cup.portal.com!ZEL@SUN.COM
  812. Subject: Kevin Mitnick ejected from DEC Meeting
  813. Date: Wed,  2 Jan 91 19:30:48 PST
  814.  
  815. The December 24 edition of COMMUNICATIONS WEEK has an interesting article
  816. on page 18 by Anne Knowles.  Quickly . . . DEC caught a fellow by the name
  817. of Kevin Mitnick trying to register to attend their DECUS user group
  818. meeting in Las Vegas.  According to the article he (Mitnick) is a well
  819. known hacker who is currently on probation after having been found guilty
  820. of breaking into Easynet.  Apparently someone recognized him while he was
  821. registering.  They apparently barred him from the meeting and DEC is now
  822. figuring out how to address any future attempts by "hackers" to get into
  823. their meetings.  The article said they threw someone out of a meeting a
  824. couple of years ago for hacking during the meeting.   One wonders exactly
  825. what was being hacked during a training meeting!  The article says DEC
  826. supplies networked terminals for for use by attendee's.
  827.  
  828. +++++++++++++++++++++++++++++++++
  829.  
  830. From: Rambo Pacifist
  831. Subject: Another Naperville Story
  832. Date: Sat, 5 Jan 91 05:09:22 CST
  833.  
  834.                      "Naperville man pleads innocent"
  835.              From: CHICAGO TRIBUNE, Jan. 4, 1991, sect II p. 3
  836.                             By Joseph Sjostrom
  837.  
  838. A former employee of Spiegel Inc. pleaded innocent Thursday to computer
  839. fraud and other charges in connection with the alleged theft of thousands of
  840. dollars worth of cash and credits from the company.
  841.  
  842. Michael H. Ferrell, 34, of Naperville, entered the plea before Du Page
  843. County Associate Judge Brian F. Telander, who set the next hearing for Jan.
  844. 31.
  845.  
  846. Ferrell was indicted on Dec. 10 by the Du Page County grand jury on four
  847. counts of computer fraud, three counts of theft and three counts of
  848. forgery. The computer fraud indictments charge him with using computerized
  849. cash registers in Spiegel stores on four occasions between November 1989,
  850. and September 1990, to issue $5,451.41 in credits to his Mastercard,
  851. American Express and Spiegel's charge cards.
  852.  
  853. The theft and forgery indictments charge that he took $22,673 in cash from
  854. the company. He allegedly generated vouchers and other forms, some of them
  855. at the Downers Grove and Villa Park stores, that described services
  856. performed for Spiegel by equipment renters and printers. However, those
  857. services had never actually been performed, and Ferell pocketed the money
  858. that Spiegel payed for the services, according to the indictments.
  859.  
  860. Ferrell worked for Spiegel from 1981 until he was fired last Oct.  24, said
  861. a company spokesman. Ferrell was a support services manager for the
  862. company's catalog and outlet store operations, the spokesman said.
  863.  
  864. Ferrell was the second person charged in December by the Du Page County
  865. state's attorney's office with the illegal use of a computer. The other
  866. defendant was charged with computer tampering for allegedly gaining access
  867. to computer programs in a Naperville software firm where he worked,
  868. although he was not charged with profiting financially from the alleged
  869. intrusion.
  870.  
  871.                                (end article)
  872.  
  873. ********************************************************************
  874.  
  875. ------------------------------
  876.  
  877.                            **END OF CuD #3.00**
  878. ********************************************************************
  879.