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

  1.  
  2. Computer underground Digest    Sun  Sep 22, 1996   Volume 8 : Issue 67
  3.                            ISSN  1004-042X
  4.  
  5.        Editor: Jim Thomas (cudigest@sun.soci.niu.edu)
  6.        News Editor: Gordon Meyer (gmeyer@sun.soci.niu.edu)
  7.        Archivist: Brendan Kehoe
  8.        Shadow Master: Stanton McCandlish
  9.        Field Agent Extraordinaire:   David Smith
  10.        Shadow-Archivists: Dan Carosone / Paul Southworth
  11.                           Ralph Sims / Jyrki Kuoppala
  12.                           Ian Dickinson
  13.        Cu Digest Homepage: http://www.soci.niu.edu/~cudigest
  14.  
  15. CONTENTS, #8.67 (Sun, Sep 22, 1996)
  16.  
  17. File 1--Hackers on Net and BBC-ISP's "morality button," from FinTimes
  18. File 2--More on hackers and CIA web page
  19. File 3--official statement from Lexis-Nexis about P-Trak (fwd)
  20. File 4--Tim O'Reilly Comments in Re  DOJ's Investigation of Microsoft
  21. File 5--Condat denies the Crypt Newsletter's editor accusations
  22. File 6--CERT Advisory CA-96.20 - Sendmail Vulnerabilities (fwd)
  23. File 7--Cu Digest Header Info (unchanged since 7 Apr, 1996)
  24.  
  25. CuD ADMINISTRATIVE, EDITORIAL, AND SUBSCRIPTION INFORMATION ApPEARS IN
  26. THE CONCLUDING FILE AT THE END OF EACH ISSUE.
  27.  
  28. ---------------------------------------------------------------------
  29.  
  30. Date: Fri, 20 Sep 1996 22:36:11 -0500 (CDT)
  31. From: Declan McCullagh <declan@well.com>
  32. Subject: File 1--Hackers on Net and BBC-ISP's "morality button," from FinTimes
  33.  
  34. Financial Times
  35. Concern at attacks by hackers on Internet sites
  36.  
  37. Wednesday September 18 1996
  38.  
  39. By Louise Kehoe in San Francisco
  40.  
  41.    A rash of hacker attacks on commercial Internet sites - including one
  42.    in which the services of Panix, a New York-based Internet access
  43.    provider, were seriously disrupted - has raised new concerns about the
  44.    security and reliability of the worldwide computer network.
  45.  
  46.    In these "denial of service" attacks, hackers have flooded Internet
  47.    sites with false requests for information sent from fake addresses,
  48.    tying up the computers and preventing access by legitimate users.
  49.  
  50.    In addition to the Panix attack, at least one large information
  51.    technology company, which declined to be identified, has suffered a
  52.    similar attack.
  53.  
  54.    Attacks have been "isolated incidents", said Mr Pete Solvik,
  55.    vice-president of information systems at Cisco Systems, the leading
  56.    manufacturer of routing equipment for the Internet. The company,
  57.    however, is concerned that the problem could spread, disrupting
  58.    Internet service for millions of users and effectively closing down
  59.    large commercial sites on the Internet.
  60.  
  61.    With many banks and retailers now planning Internet services, the
  62.    potential for financial losses as a result of such attacks is rising.
  63.    Disruption of Internet service can also be a serious problem for the
  64.    tens of thousands of businesses that now rely on electronic mail and
  65.    sites on the World Wide Web to communicate with their partners and
  66.  
  67. [...]
  68.  
  69.    The Federal Bureau of Investigation's New York Computer Investigations
  70.    Threat Assessment Center is understood to be investigating the attack
  71.    on Panix. Computer Emergency Response Teams, a US organisation that
  72.    collates information about security and technical problems on the
  73.    Internet, are looking into the incident.
  74.  
  75. ###
  76.  
  77. Financial Times
  78. BBC to enter Internet market
  79.  
  80. Thursday September 19 1996
  81.  
  82. By Alan Cane and Raymond Snoddy in London
  83.  
  84.    The BBC plans to launch a service on the Internet which could promote
  85.    greater acceptance of the global computer network in the same way that
  86.    the BBC Computer popularised computing in the 1980s.
  87.  
  88.    Contracts have been signed between BBC Worldwide, the public
  89.    broadcaster's commercial arm, and the multimedia division of ICL, the
  90.    UK computer group owned by Fujitsu of Japan, to design and run the
  91.    service.
  92.  
  93.    BBC Worldwide will announce the service within the next two weeks. It
  94.    will feature news, weather and travel information as well as
  95.    educational and entertainment material. It is expected to go live in
  96.    the early part of 1997.
  97.  
  98. [...]
  99.  
  100.    The main selling points will be speed - compared with the frequent
  101.    delays experienced by users - and ease of use. There will also be a
  102.    "morality button" to reassure parents who might fear their children
  103.    could use the service to view pornography and other unsuitable
  104.    material available on the Internet.
  105.  
  106.    ICL declined to comment last night.
  107.  
  108. ------------------------------
  109.  
  110. From: Declan McCullagh <declan@well.com>
  111. To: fight-censorship@vorlon.mit.edu
  112. Subject: File 2--More on hackers and CIA web page
  113.  
  114. The web pages are at:
  115.  
  116.         http://titus.is.co.za/mikev/cia_hack/
  117.         http://www.skeeve.net/cia/
  118.  
  119. Looks like the hackers tipped off CNN, which has been running video clips.
  120. Reuters also picked this up.
  121.  
  122. -Declan
  123.  
  124. *********
  125.  
  126.                    HACKERS VANDALIZE CIA HOME PAGE
  127.  
  128.   No security breach of private files, agency says
  129.  
  130.      September 19, 1996
  131.      Web posted at: 10:00 a.m. EDT (1400 GMT)
  132.  
  133.      By Wayne B. Drash and Jim B. Morris
  134.  
  135.      ATLANTA (CNN) -- Hackers broke into the CIA's World Wide Web home
  136.      page (http://www.odci.gov/cia/) Thursday morning, altered it, added
  137.      obscenities and changed the agency's name on the page to the
  138.      "Central Stupidity Agency."
  139.  
  140.      The CIA, which took down the site shortly after 7:30 a.m. EDT, said
  141.      the hackers did not gain access to the agency's private files. "This
  142.      (the publicly available CIA Web site) is on an entirely different
  143.      circuit from everyone else at the CIA," agency spokesman Rick Oborn
  144.  
  145.      He said the CIA did not know who was responsible for the hacking or
  146.      when the page would be restored. "A team is being pulled together to
  147.      assess how many layers (of the site) were affected and how we can
  148.      get it back on line," Oborn said.
  149.  
  150.   Anonymous call
  151.  
  152.      An anonymous phone caller tipped CNN Interactive to the break-in,
  153.      saying Swedish hackers were responsible.
  154.  
  155.      The phone call was received about 5:45 a.m. EDT. When asked what the
  156.      hackers had done to the page, the man said, "I think you should just
  157.      take a look at it."
  158.  
  159.      He then hung up without further comment. He did not leave his name
  160.      or identify a specific group.
  161.  
  162. ------------------------------
  163.  
  164. Date: Wed, 18 Sep 1996 21:21:14 -0400 (EDT)
  165. From: Noah <noah@enabled.com>
  166. Subject: File 3--official statement from Lexis-Nexis about P-Trak (fwd)
  167.  
  168. From -Noah
  169.  
  170. ---------- Forwarded message ----------
  171. Date--Wed, 18 Sep 1996 21:21:14 -0400 (EDT)
  172. From--Maura Kearns <zippy@mcfeely.bsfs.org>
  173.  
  174. Here's the real info on the Lexis thing:
  175.  
  176.  
  177. This statement was issued today:
  178. --------
  179. STATEMENT FROM LEXIS-NEXIS   9/18/96
  180.  
  181. Incorrect information is being distributed on Internet newsgroups regarding
  182. the data displayed in LEXIS-NEXIS' P-TRAK file.  P-TRAK is like an
  183. electronic "white pages."  The only information displayed is the name of the
  184. individual, current address and up to two previous addresses and telephone
  185. number.  In some cases, the individual's maiden name may appear and as well
  186. as the month and year of birth.  That is the ONLY information displayed in
  187. the P-TRAK file.
  188.  
  189. Contrary to some messages that have been posted to some Internet discussion
  190. and news groups, the P-TRAK file DOES NOT contain any credit histories, bank
  191. account information, personal financial data, mother's maiden name or
  192. medical histories.  This misinformation has been posted over and over again
  193. to various news groups.
  194.  
  195. An example of a record appears below:
  196.  
  197. Name:  DOE, JOHN E
  198. Current Address:  1066 Anywhere Drive, Dayton, OH  95454
  199. Previous Address:  106 Somewhere Drive, Dayton, OH  92454
  200. Birthdate:  9/1965
  201. Telephone Number:  555-1212
  202. On File Since:  6/1/1994
  203.  
  204. The information displayed in the P-TRAK file is the type of information
  205. readily available from public information sources such as telephone
  206. directories (in print and CD-ROM format) and public records maintained by
  207. government agencies.
  208.  
  209. LEXIS-NEXIS markets the P-TRAK file to the legal community for use by
  210. general legal practitioners, litigators and public attorneys, as well as law
  211. enforcement agencies and police departments.  These professionals use the
  212. P-TRAK file to assist in locating litigants, witnesses, shareholders,
  213. debtors, heirs and beneficiaries.
  214.  
  215. LEXIS-NEXIS is aware of the sensitivities regarding the potential misuse of
  216. information.  Business competitors of LEXIS-NEXIS have for some time made
  217. Social Security numbers available to users of their services.  In addition,
  218. Social Security Numbers and other information are available on the Internet
  219. from a number of sources.  Despite this wide availability of Social Security
  220. numbers in the market place, LEXIS-NEXIS discontinued the display of Social
  221. Security numbers in the P-TRAK file as of June 11, 1996, eleven days after
  222. the product was introduced.
  223.  
  224. Through its actions, LEXIS-NEXIS is balancing the privacy concerns of the
  225. public with the legitimate needs of legal, business and government
  226. professionals for access to accurate sources of publicly available
  227. information.  By discontinuing the display of Social Security numbers in
  228. P-TRAK and only providing information that is already available to the
  229. public from other sources, LEXIS-NEXIS believes it has responsibly met the
  230. expressed concerns of the public.
  231.  
  232. Individuals interested in having their names removed from the P-TRAK file
  233. can e-mail their full name and complete address to:
  234. p-trak@prod.lexis-nexis.com or mail this information to ATTN: P-TRAK, P. O.
  235. Box 933, Dayton, OH 45401.
  236.  
  237. ------------------------------
  238.  
  239. Date: Thu, 19 Sep 1996 19:00:41 -0700
  240. From: Ellen Elias <elias@ora.com>
  241. Subject: File 4--Tim O'Reilly Comments in Re  DOJ's Investigation of Microsoft
  242.  
  243. For Immediate Release
  244. Further Information Contact
  245. Ellen Elias
  246. (707)829-0515 ext. 322
  247. elias@ora.com
  248.  
  249. STATEMENT OF TIM O'REILLY, PRESIDENT OF O'REILLY & ASSOCIATES, IN
  250. RESPONSE TO CONFIRMATION OF JUSTICE DEPARTMENT'S INVESTIGATION OF
  251. MICROSOFT
  252.  
  253. September 19, 1996, Sebastopol, CA--Tim O'Reilly, upon learning of the
  254. confirmed investigation of Microsoft by the federal Department of
  255. Justice, called for Microsoft to cease its anti-competitive behavior.
  256. Mr. O'Reilly made the following comments:
  257.  
  258. "I'm delighted to hear about the Department of Justice
  259. investigation. We don't know what they'll find, but we do know
  260. that Microsoft's recent practices have been bad for users, and
  261. they have demonstrated a pattern of anti-competitive behavior.
  262. The fact of this investigation will further alert people to
  263. Microsoft's activities. I believe in the marketplace, and think
  264. that there can be a healthy impact on the marketplace from the
  265. DOJ investigation.
  266.  
  267. "Each time O'Reilly & Associates has brought a particular fact about
  268. Microsoft into the public eye, the response from Microsoft has been
  269. deceptive and confusing.  In July, 1996, we complained publicly about
  270. their 10-connection limit on Windows NT Workstation. In response,
  271. Microsoft removed the 10-connection limit from the code, but then kept
  272. it in the user license. Further, Microsoft made extravagant claims that
  273. they were doing this for users: they claimed that NT Workstation was
  274. just not suitable as a Web server platform.  That claim inspired our
  275. Senior Editor Andrew Schulman's investigation into the actual
  276. differences between NT Workstation and NT Server. He found that,
  277. indeed, at the core, they are not very different at all.
  278.  
  279. "Microsoft doesn't need to win every battle to stifle innovation. As
  280. powerful as they are, they can determine the terms under which software
  281. development happens, and they can seriously limit important development
  282. by their anti-competitive behavior. Here's an example: when O'Reilly &
  283. Associates first developed and marketed WebSite(TM), Microsoft patted
  284. us on the back, because we were legitimizing NT as a Web server
  285. platform. But when Microsoft decided they wanted the Web server market
  286. for themselves, they used their restrictive NT 4.0 Workstation user
  287. license as a tool to frighten users against using any competitors' Web
  288. servers on that platform.  Microsoft's actions have made it difficult
  289. for us, as well as all other server vendors, to compete. So what kind
  290. of industry does that create?
  291.  
  292. "Netscape has claimed that many people have been afraid to speak in
  293. fear of retribution from Microsoft. Netscape has said that now, these
  294. people will feel free to speak publicly, and I think that should prove
  295. very enlightening. I hope the Department of Justice will vigorously
  296. pursue this investigation. I also hope the public will hold Microsoft
  297. to the same high standard of business practices to which our entire
  298. industry should adhere."
  299.  
  300. ------------------------------
  301.  
  302. Date: Wed, 18 Sep 1996 15:12:31 +0100
  303. From: Jean-Bernard Condat <jeanbc@INFORMIX.COM>
  304. Subject: File 5--Condat denies the Crypt Newsletter's editor accusations
  305.  
  306. This morning, I receive the Cu Digest #8.66 and carefully read the
  307. file 3 with a complete surprise. I never send any article related to
  308. computer viruses troubles during the US Army's Bosnian deployment
  309. plagiarizing the well-knowned Crypt Newsletter.
  310.  
  311. After my publication of the Mark A. Ludwig's book "The Little Black
  312. Book of Computer Viruses" with Addison-Wesley France ("Naissance
  313. d'un virus" for the first volume and "Mutation d'un virus" for the
  314. second one), I have had a lot of problems: night & day phone calls,
  315. injures, public critics on French TV and/or magazines, etc. I stop
  316. the crazy rumors immediately.  I don't writte any more computer
  317. virus' articles; I don't participate to any security events; I don't
  318. collaborate to any craking/phreaking/swapping actions. For example,
  319. I don't participate to the French 2600 meeting in Porte d'Italie in
  320. Paris last week.
  321.  
  322. As my understanding, this previous email under my name was send to
  323. CuD editors from and unauthorized source.  As some of you know, I
  324. have been having problems with the secret services in the past and I
  325. got into a large battle with was France Telecom -vs- Me.  It is
  326. stupid to get into an argument with that kind of corporation, and a
  327. few words and threats were thrown, they locked all my phone
  328. accounts. I wrote a letter in response of that and they proceded to
  329. harass my company that put me immediately out. Also some lamers
  330. posted some hoax letters in the French news groups and whatever.
  331. They eventually decided to charge me and whatever, and to save me
  332. time outta the Paris courts and crap like that I made an apology for
  333. the threats, seeing that they could incriminate me. France Telecom
  334. has done wrong and I probably won't be seeing alot of apologies
  335. coming my way. If they didn't have certain info about me... they
  336. could have me very well laughing at them but that is not the case.
  337.  
  338. At this time, I have some crazy guys that don't hesitate to put all
  339. the scripts of my TV shows
  340. (http://www.magic.be/InterieurNuit/SiteMars/Condat.html), or to put
  341. my picture (http://www.condat.de/condat/jean-b/). Yesterday, I lost
  342. my job of senior consultant in the Smart Card Business Unit of
  343. Informix because  Mr. Tariq Krim of the ENST in Paris don't hesitate
  344. to call all my chiefs with some kind words on my life. In France,
  345. this type of action permit to put me out the company some seconds
  346. after.
  347.  
  348. "Information wants to be free" is false. I have to many subjects to
  349. writte on that to plagiarized Crypt News will be a "sincerest form
  350. of flattery", like George Smith writte. But I prefer the unpolically
  351. correct French-style-approach, the savoir-vivre of Paris. Accept all
  352. my real excuses for all the French guy like Krim that prefer to
  353. crash my career for having the pleasure to be the best! I read Crypt
  354. News with pleasure and always respect the international copyright
  355. notices.
  356.  
  357. Apologetically,
  358.  
  359.                           \\\|///
  360.                           | ~ ~ |
  361.                          (- 0 0 -)
  362.  +--------------------.oOOo-(_)-oOOo.-------------------------+
  363.  |                  Jean-Bernard Condat                       |
  364.  |      47 rue des rosiers, 93400 Saint-Ouen France           |
  365.  | Phone: +33 1 40100357, fax: 1 46963765, Itineris: 07238628 |
  366.  |        Email: condat@atelier.fr, PGP Key Id: C8F5D50D      |
  367.  |                              Oooo.                         |
  368.  +--------------------.oooO-----(  )--------------------------+
  369.                        (  )     ) /
  370.                         \ (    (_/
  371.                          \_)
  372.  
  373. ------------------------------
  374.  
  375. Date: Wed, 18 Sep 1996 10:40:07 -0400
  376. From: Noah <noah@enabled.com>
  377. Subject: File 6--CERT Advisory CA-96.20 - Sendmail Vulnerabilities (fwd)
  378.  
  379. From -Noah
  380.  
  381. ---------- Forwarded message ----------
  382. Date--Wed, 18 Sep 1996 10:40:07 -0400
  383. From--CERT Advisory <cert-advisory@cert.org>
  384.  
  385. -----BEGIN PGP SIGNED MESSAGE-----
  386.  
  387. =============================================================================
  388. CERT(sm) Advisory CA-96.20
  389. Original issue date: September 18, 1996
  390. Last revised: --
  391.  
  392. Topic: Sendmail Vulnerabilities
  393. - -----------------------------------------------------------------------------
  394.                 *** This advisory supersedes CA-95:05 ***
  395.  
  396. The CERT Coordination Center has received reports of two security problems in
  397. sendmail that affect all versions up to and including 8.7.5. By exploiting
  398. the first of these vulnerabilities, users who have local accounts can gain
  399. access to the default user, which is often daemon. By exploiting the second
  400. vulnerability, any local user can gain root access.
  401.  
  402. The CERT/CC team recommends installing vendor patches or upgrading to the
  403. current version of sendmail (8.7.6). Until you can do so, we urge you to
  404. apply the workaround provided in Sec. III.C. In all cases, be sure to take
  405. the extra precautions listed in Sec. III.D.
  406.  
  407. For beta testers of sendmail 8.8: The vulnerabilities described in this
  408. advisory have been fixed in the beta version.
  409.  
  410. We will update this advisory as we receive additional information. Please
  411. check advisory files regularly for updates that relate to your site. In
  412. addition, you can check ftp://info.cert.org/pub/latest_sw_versions/sendmail
  413. to identify the most current version of sendmail.
  414.  
  415. - -----------------------------------------------------------------------------
  416.  
  417. I.   Description
  418.  
  419.      There are two vulnerabilities in all versions of sendmail up to and
  420.      including sendmail 8.7.5. The first vulnerability is a resource starvation
  421.      problem and the second is a buffer overflow problem.
  422.  
  423.      Resource Starvation
  424.      -------------------
  425.  
  426.      When email is forwarded to a program using a .forward file or an :include:
  427.      statement within a .forward or alias file, that program is executed as the
  428.      owner of the .forward file or the file referenced by the :include:
  429.      statement. Similarly, if email is forwarded to a file, that file is
  430.      opened as the owner of the .forward file or the file referenced by the
  431.      :include: statement. The file owner is called the "controlling user."
  432.  
  433.      If the message cannot be delivered immediately, the name of the
  434.      controlling user is written into the queue file along with the other
  435.      delivery information so that the appropriate permissions can be acquired
  436.      when the mail queue is processed.
  437.  
  438.      Only the name of the controlling user is written in the queue file. This
  439.      name is derived by calling the system routine getpwuid(3) on the user id
  440.      of the file owner. If getpwuid fails, the sendmail default user (defined
  441.      by the DefaultUser option in 8.7 and by the "u" and "g" options in older
  442.      releases) is assumed.
  443.  
  444.      In some cases, the system can be forced into resource starvation, thus
  445.      forcing getpwuid(3) to fail even though an entry exists in /etc/passwd
  446.      corresponding to that uid. Since getpwuid has no way of portably
  447.      returning an error meaning "resource failure" as distinct from "user id
  448.      not found," sendmail has no way of distinguishing between these cases; it
  449.      assumes that the uid is unknown and falls back to the default user.
  450.  
  451.      By starving sendmail of specific resources, sendmail will create files
  452.      owned by the default user. Once created, these files can be used to
  453.      access other files owned by the default user. In addition, these files
  454.      owned by the default user can be used to leverage access to other
  455.      privileged users on the system.
  456.  
  457.      Buffer Overflows
  458.      ----------------
  459.      There are several buffer overflows present in sendmail version 8.7.5 and
  460.      earlier. Some of the buffer overflows could result in local users gaining
  461.      unauthorized root access.
  462.  
  463.      Significant work has been done on sendmail version 8.8 (now in beta
  464.      test) to eliminate the problem, and the code changes originally planned
  465.      for 8.8 have been backported to 8.7.6 to address these vulnerabilities.
  466.  
  467. II.  Impact
  468.  
  469.      Resource Starvation
  470.      -------------------
  471.      Anyone with access to an account on the system can run programs or write
  472.      files as the default user. The danger of compromising the default user
  473.      depends primarily on the other files in your system owned by that user.
  474.  
  475.      For example, on many systems the line printer spool directory (e.g.,
  476.      /var/spool/lpd) is owned by daemon; because the line printer subsystem
  477.      runs setuid root, it may be possible to gain additional privileges.
  478.      However, some other systems have no files owned by user daemon on the
  479.      default system, and the only files owned by group daemon are not
  480.      writable by that group; hence, the danger is minimal.
  481.  
  482.      Buffer Overflows
  483.      ----------------
  484.      Anyone with access to an account on the system can gain root access.
  485.  
  486. III. Solution
  487.  
  488.      Install a patch from your vendor if one is available (Sec. A) or upgrade
  489.      to the current version of sendmail (Sec. B). Until you can take one of
  490.      those actions, we recommend applying the workaround described in Sec. C.
  491.      This workaround addresses the resource starvation problem but not buffer
  492.      overflows.
  493.  
  494.      In all cases, you should take the precautions listed in Sec. D.
  495.  
  496.      Note to beta testers of sendmail 8.8: The vulnerabilities described in
  497.      this advisory have been fixed in the beta version of 8.8.
  498.  
  499.      A. Install a vendor patch.
  500.  
  501.         Below is a list of the vendors who have provided information about
  502.         sendmail. Details are in Appendix A of this advisory; we will update
  503.         the appendix as we receive more information. If your vendor's name
  504.         is not on this list, please contact the vendor directly.
  505.  
  506.             Digital Equipment Corporation
  507.             Hewlett-Packard Company
  508.             IBM Corporation
  509.             Linux
  510.             Open Software Foundation
  511.             The Santa Cruz Operation
  512.             Silicon Graphics Inc.
  513.             Sun Microsystems, Inc.
  514.  
  515.      B. Upgrade to the current version of sendmail.
  516.  
  517.         Install sendmail 8.7.6. This version is a "drop in" replacement for
  518.         8.7.x. There is no patch for 8.6.x. If you are using version 8.6 or
  519.         earlier, you need to upgrade to the current version and rebuild your
  520.         sendmail.cf files. Upgrading to version 8.7.6 addresses both
  521.         vulnerabilities described in this advisory.
  522.  
  523.         Sendmail 8.7.6 is available from
  524.  
  525. ftp://ftp.sendmail.org/ucb/src/sendmail/sendmail.8.7.6.tar.gz
  526. ftp://info.cert.org/pub/tools/sendmail/sendmail.8.7.6.tar.gz
  527. ftp://ftp.cert.dfn.de/pub/tools/net/sendmail/sendmail.8.7.6.tar.gz
  528.  
  529.         MD5 (sendmail.8.7.6.tar.gz) = 4a1f2179c53c9106bc8d7738f4d55667
  530.  
  531.         Also in that directory are .Z and .sig files. The .Z file contains the
  532.         same bits as the .gz file, but is compressed using UNIX compress
  533.         instead of gzip. The .sig is Eric Allman's PGP signature for the
  534.         uncompressed tar file. The key fingerprint is
  535.  
  536.   Type bits/keyID    Date       User ID
  537.   pub  1024/BF7BA421 1995/02/23 Eric P. Allman <eric@CS.Berkeley.EDU>
  538.             Key fingerprint =  C0 28 E6 7B 13 5B 29 02  6F 7E 43 3A 48 4F 45 29
  539.                                 Eric P. Allman <eric@Reference.COM>
  540.                                 Eric P. Allman <eric@Usenix.ORG>
  541.                                 Eric P. Allman <eric@Sendmail.ORG>
  542.                                 Eric P. Allman <eric@CS.Berkeley.EDU>
  543.  
  544.         We strongly recommend that when you change to a new version of sendmail
  545.         you also change to the configuration files that are provided with that
  546.         version.
  547.  
  548.         Significant work has been done to make this task easier. It is now
  549.         possible to build a sendmail configuration file (sendmail.cf) using the
  550.         configuration files provided with the sendmail release. Consult the
  551.         cf/README file for a more complete explanation. Creating your
  552.         configuration files using this method makes it easier to incorporate
  553.         future changes to sendmail into your configuration files.
  554.  
  555.         Finally, for Sun users, a paper is available to help you convert your
  556.         sendmail configuration files from the Sun version of sendmail to one
  557.         that works with sendmail version 8.7.x. The paper is entitled
  558.         "Converting Standard Sun Config Files to Sendmail Version 8" and was
  559.         written by Rick McCarty of Texas Instruments Inc. It is included in
  560.         the distribution and is located in contrib/converting.sun.configs.
  561.  
  562.      C. Apply a workaround.
  563.  
  564.         Resource Starvation
  565.         -------------------
  566.         Eric Allman, the author of sendmail, has provided the following
  567.         workaround to the resource starvation vulnerability.
  568.  
  569.         Using smrsh as "prog" mailer limits the programs that can be run as
  570.         the default user. Smrsh does not limit the files that can be written,
  571.         but less damage can be done by writing files directly.
  572.  
  573.         The damage can be almost entirely constrained by ensuring that the
  574.         default user is an innocuous one. Sendmail defaults to 1:1 (daemon)
  575.         only because that is reasonably portable. A special "mailnull"
  576.         account that is used only for this purpose would be better. This user
  577.         should own no files and should have neither a real home directory nor
  578.         a real shell. A sample password entry might be:
  579.  
  580.            mailnull:*:32765:32765:Sendmail Default User:/no/such/dir:/dev/null
  581.  
  582.         A corresponding entry should be made in /etc/group:
  583.  
  584.            mailnull:*:32765:
  585.  
  586.         These assume that there are no other users or groups with id = 32765
  587.         on your system; if there are, pick some other unique value. After
  588.         creating this user, change the line in /etc/sendmail.cf reading
  589.  
  590.            O DefaultUser=1:1
  591.  
  592.          to read
  593.  
  594.            O DefaultUser=mailnull
  595.  
  596.         If you are running 8.6.*, you will have to change the lines reading
  597.  
  598.            Ou1
  599.            Og1
  600.  
  601.         to read
  602.  
  603.            Ou32765
  604.            Og32765
  605.  
  606.        Finally, if you are using the m4(1)-based sendmail configuration scheme
  607.        provided with sendmail 8.7.*, you should add the following line to the
  608.        m4 input file, usually named sendmail.mc:
  609.  
  610.            define(`confDEF_USER_ID', 32765:32765)
  611.  
  612.        The actual values should, of course, match those in the passwd file.
  613.  
  614.        Buffer Overflows
  615.        ----------------
  616.        There is no workaround for the buffer overflow problem. To address this
  617.        problem, you must apply your vendor's patches or upgrade to the current
  618.        version of sendmail (version 8.7.6).
  619.  
  620. D. Take additional precautions.
  621.  
  622.    Regardless of which solution you apply, you should take these extra
  623.    precautions to protect your systems.
  624.  
  625.    * Use the sendmail restricted shell program (smrsh)
  626.  
  627.      With *all* versions of sendmail, use the sendmail restricted shell
  628.      program (smrsh). You should do this whether you use vendor-supplied
  629.      sendmail or install sendmail yourself. Using smrsh gives you improved
  630.      administrative control over the programs sendmail executes on behalf of
  631.      users.
  632.  
  633.      A number of sites have reported some confusion about the need to continue
  634.      using the sendmail restricted shell program (smrsh) when they install a
  635.      vendor patch or upgrade to a new version of sendmail. You should always
  636.      use the smrsh program.
  637.  
  638.      smrsh is included in the sendmail distribution in the subdirectory
  639.      smrsh. See the RELEASE_NOTES file for a description of how to integrate
  640.      smrsh into your sendmail configuration file.
  641.  
  642.      smrsh is also distributed with some operating systems.
  643.  
  644.    * Use mail.local
  645.  
  646.      If you run /bin/mail based on BSD 4.3 UNIX, replace /bin/mail with
  647.      mail.local, which is included in the sendmail distribution. It is also
  648.      included with some other operating systems distributions, such as
  649.      FreeBSD.
  650.  
  651.      Although the current version of mail.local is not a perfect solution, it
  652.      is important to use it because it addresses vulnerabilities that are
  653.      being exploited. For more details, see CERT advisory CA-95:02.
  654.  
  655.      Note that as of Solaris 2.5 and beyond, mail.local is included with the
  656.      standard distribution. To use mail.local, replace all references to
  657.      /bin/mail with /usr/lib/mail.local. If you are using the M4(1)-based
  658.      configuration scheme provided with sendmail 8.X, add the following to
  659.      your configuration file:
  660.  
  661.         define(`LOCAL_MAILER_PATH', /usr/lib/mail.local)
  662.  
  663.    * WARNING: Check for executable copies of old versions of mail programs
  664.  
  665.      If you leave executable copies of older versions of sendmail installed
  666.      in /usr/lib (on some systems, it may be installed elsewhere), the
  667.      vulnerabilities in those versions could be exploited if an intruder
  668.      gains access to your system. This applies to sendmail.mx as well as
  669.      other sendmail programs. Either delete these versions or change the
  670.      protections on them to be non-executable.
  671.  
  672.      Similarly, if you replace /bin/mail with mail.local, remember to remove
  673.      old copies of /bin/mail or make them non-executable.
  674.  
  675.   <snip>
  676.  
  677. ------------------------------
  678.  
  679. Date: Thu, 21 Mar 1996 22:51:01 CST
  680. From: CuD Moderators <cudigest@sun.soci.niu.edu>
  681. Subject: File 7--Cu Digest Header Info (unchanged since 7 Apr, 1996)
  682.  
  683. Cu-Digest is a weekly electronic journal/newsletter. Subscriptions are
  684. available at no cost electronically.
  685.  
  686. CuD is available as a Usenet newsgroup: comp.society.cu-digest
  687.  
  688. Or, to subscribe, send post with this in the "Subject:: line:
  689.  
  690.      SUBSCRIBE CU-DIGEST
  691. Send the message to:   cu-digest-request@weber.ucsd.edu
  692.  
  693. DO NOT SEND SUBSCRIPTIONS TO THE MODERATORS.
  694.  
  695. The editors may be contacted by voice (815-753-0303), fax (815-753-6302)
  696. or U.S. mail at:  Jim Thomas, Department of Sociology, NIU, DeKalb, IL
  697. 60115, USA.
  698.  
  699. To UNSUB, send a one-line message:   UNSUB CU-DIGEST
  700. Send it to  CU-DIGEST-REQUEST@WEBER.UCSD.EDU
  701. (NOTE: The address you unsub must correspond to your From: line)
  702.  
  703. Issues of CuD can also be found in the Usenet comp.society.cu-digest
  704. news group; on CompuServe in DL0 and DL4 of the IBMBBS SIG, DL1 of
  705. LAWSIG, and DL1 of TELECOM; on GEnie in the PF*NPC RT
  706. libraries and in the VIRUS/SECURITY library; from America Online in
  707. the PC Telecom forum under "computing newsletters;"
  708. On Delphi in the General Discussion database of the Internet SIG;
  709. on RIPCO BBS (312) 528-5020 (and via Ripco on  internet);
  710. and on Rune Stone BBS (IIRGWHQ) (860)-585-9638.
  711. CuD is also available via Fidonet File Request from
  712. 1:11/70; unlisted nodes and points welcome.
  713.  
  714. EUROPE:  In BELGIUM: Virtual Access BBS:  +32-69-844-019 (ringdown)
  715.          In ITALY: ZERO! BBS: +39-11-6507540
  716.          In LUXEMBOURG: ComNet BBS:  +352-466893
  717.  
  718.   UNITED STATES: etext.archive.umich.edu (192.131.22.8) in /pub/CuD/CuD
  719.                   ftp.eff.org (192.88.144.4) in /pub/Publications/CuD/
  720.                   aql.gatech.edu (128.61.10.53) in /pub/eff/cud/
  721.                   world.std.com in /src/wuarchive/doc/EFF/Publications/CuD/
  722.                   wuarchive.wustl.edu in /doc/EFF/Publications/CuD/
  723.   EUROPE:         nic.funet.fi in pub/doc/CuD/CuD/ (Finland)
  724.                   ftp.warwick.ac.uk in pub/cud/ (United Kingdom)
  725.  
  726.  
  727. The most recent issues of CuD can be obtained from the
  728. Cu Digest WWW site at:
  729.   URL: http://www.soci.niu.edu/~cudigest/
  730.  
  731. COMPUTER UNDERGROUND DIGEST is an open forum dedicated to sharing
  732. information among computerists and to the presentation and debate of
  733. diverse views.  CuD material may  be reprinted for non-profit as long
  734. as the source is cited. Authors hold a presumptive copyright, and
  735. they should be contacted for reprint permission.  It is assumed that
  736. non-personal mail to the moderators may be reprinted unless otherwise
  737. specified.  Readers are encouraged to submit reasoned articles
  738. relating to computer culture and communication.  Articles are
  739. preferred to short responses.  Please avoid quoting previous posts
  740. unless absolutely necessary.
  741.  
  742. DISCLAIMER: The views represented herein do not necessarily represent
  743.             the views of the moderators. Digest contributors assume all
  744.             responsibility for ensuring that articles submitted do not
  745.             violate copyright protections.
  746.  
  747. ------------------------------
  748.  
  749. End of Computer Underground Digest #8.67
  750. ************************************
  751.  
  752.  
  753.