home *** CD-ROM | disk | FTP | other *** search
/ Compu-Fix / Compu-Fix.iso / pubnews / cud300.txt < prev    next >
Text File  |  1993-03-01  |  43KB  |  882 lines

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