- cypherpunks-legacy - lists.cpunks.org

hacker search
by an158409＠anon.penet.fi 17 Dec '03

17 Dec '03

US Marshals On Trail Of Hacker WASHINGTON, D.C., U.S.A., 1995 JAN 26 (NB) -- The US Marshals Service is on the trail of a computer hacker who disappeared after being convicted of one electronic crime and charged with another. Authorities say they are trying to locate Kevin David Mitnick, 31, originally from Sepulveda, California. Deputy US Marshal Kathleen Cunningham told Newsbytes the Marshals Service has had a probation violation warrant for Mitnick since November 1992, and almost caught up with him in Seattle last October. Cunningham said Mitnick is a ham radio enthusiast and is believed to use a scanner to keep track of police in the area where he is hiding. "(Local police) didn't use radio security so as soon as his address was mentioned he was out of there. He just left everything." Cunningham said authorities were able to get quite a bit of information about Mitnick from the things he abandoned when he fled the Seattle location. Mitnick is considered an expert at gaining control of computers to monitor or use communications systems and knows how to manufacture false identities using computers. While still a teenager Mitnick was charged with "cracking" the North American Air Defense Command computer and of using a modem to control telephone switching centers in New York and California. A story last summer in The New York Times reported Mitnick listened in on phone calls and reprogrammed the home telephone of one individual so that each time the phone was picked up a recording asked the phone user to deposit 25 cents. Mitnick was charged with electronically stealing $1 million in secure software from Digital Equipment Corp. causing the company to spend $160,000 to close up the gaps in its computer security. Upon conviction in that case Mitnick was placed on supervisory probation in 1992. He disappeared later that year after he was charged with illegally cracking into Pacific Bell's computers. He is also reportedly a suspect in an incident in which someone illegally accessed the computer at Britain's Loughborough University. An information sheet about Mitnick says that, although he is not considered a dangerous criminal, his activities are costing millions of dollars in the public and private sectors. "Sensitive information illegally accessed by Mitnick would cause continued financial hardship to these various corporations if the information is ever disseminated to others." The document warns authorities who might come in contact with Mitnick to be very cautious and letting him get his hands on any personal information about officers. "He possesses an amazing ability to disrupt one's personal life through his computer knowledge, i.e., TRW's (credit ratings), phone service, etc." warns the US Marshal's Service. When contacted by Newsbytes, spokesperson Dave Fletcher at the Federal Bureau of Investigation Press Office in Washington DC said the FBI does not hold a warrant for Mitnick's arrest. The fugitive warrant held by the US Marshal's Service describes Mitnick as being a Caucasian, 5 feet 11 inches tall with a fair complexion, blue eyes, brown hair, and wearing glasses. (Jim Mallory/19950126/Press contact: US Marshal's Service, 202-307-9000) ------------------------------------------------------------------------- To find out more about the anon service, send mail to help(a)anon.penet.fi. Due to the double-blind, any mail replies to this message will be anonymized, and an anonymous id will be allocated automatically. You have been warned. Please report any problems, inappropriate use etc. to admin(a)anon.penet.fi.

2 1

RE: Get ready to start breaking rocks for Herr Klinton
by John Douceur 17 Dec '03

17 Dec '03

>From: Sandy Sandfort <sandfort(a)crl.com> .... >With his arms control policy background and current familiarity >with crypto as non-exportable munition, Phil Zimmermann is a >shoo-in for a seat on the president's Arms Proliferaton Board. >Hell, he ought to be the Chairperson! This may have been intended tongue-in-cheek, but I think this is an excellent idea. Think Phil would be interested in the position? How could we get this going? JD

1 0

Secure (!?) Remailer Net
by Nathan Zook 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Maybe I'm way behind the curve on this, but... The traffic analysis that we've seen so far mainly just documents tcmay's "everybody a remailer" concept. If you look, you will notice that these analyses all assume that Alice and Bob are _not_ remailers themselves, and for a good reason. If Alice and Bob _are_ remailers, analysis of the type used here is worthless, especially if Alice and Bob have a policy of not sending any mail unless they first receive garbage, and of sending out garbage whenever they get a letter. HOWEVER, the analysis makes another assumption--that messages are indistinguishable. This assumption does not correlate, as I understand it, with the current remailer net. There are, as I see it, a couple of modifications that (I think) would not impose to great a burden on our longsuffering coders, and, as a side benefit, might allow more flexibility in other matters as well. Standard packet sizes, as I see it, are not very difficult to implement, with a couple of assumptions. (I now assume that all traffic is intra-remailer-net) First, the message is signed with the sender's key. (More on that later.) Suppose a signed message to be forwarded is smaller than the standard packet size. The sending remailer adds a Cutmarks: header. At the end of the message, the cutmark is added, followed by sufficient garbage to fill out the standard packet size. The message is then pgp'ed to the recipent _with COMPRESS = OFF_. Upon receipt, the message is decrypted, and its origination can then be triply verified (at least). From: line, packet size, and PGP signature. Since the message claims to be from a packeting remailer, the packet size should be the standard one. The recipient now has the message that was sent to it. This message is probably itself encrypted, so it can be handled (almost) as if this message were just received. This includes stripping the garbage and (probably) decrypting the message to get the forwarding information. Note that this system would allow the extropian remailer to be compatible with Matt Ghio's alias system. (Right now, the remailer doesn't like separate pgp packets, or packets it can't read, or something.) Under the current system, the precausion is entirely warranted. To make life even more fun, there is no good reason that non-remailers cannot be in on the action! Alice, sending to Bob through Chaum, pretends to be a remailer. That is, she prepares her message to Bob, (encrypted), and adds the Request-Remailing-To: Bob(a)nowhere.org, and signs it. She then observes that the message is too small, so she adds the Cutmarks: header, etc. When Chaum receives the packet, he opens it, removes the cutmarks, and sees a signature he does not know. Chaum then sends a request to pgp-key-server(a)omniscient.gov for the key, and holds the message until he gets it. He then compares the address and name on the key recieved to the message. The signature is good, so he is ready to send the packet to Bob. But Bob can be in on the game as well, since there is no reason that he cannot handle the Cutmarks:, the signature, and the nested encryption. In fact, Alice could include a copy of Bob's key in the message for Chaum to use, after a Recipient-Key: header. Bob can also verify that the message was actually routed through Chaum. If Chaum is concerned that, at some future time, Eve might supeona his key ring in order to demonstrate that Alice and Bob are using Chaum, Chaum can alternately request keys that he does not need from the servers, and delete (older) keys in the ring. In other words, if all the remailers can handle nested pgp packets and cutmarks, we are close to moving all small messages to a standard size. What if the file is too big? If the file is too big, break it in pieces. We need a header, Multipart Message: n of m. Note that since this is assumed to be _inside_ a pgp wrapper, it is secure. The recipient could hold and merge the files as needed. If the message to be forwarded is too big, split and continue. Since the messages are ascii armored, the split/combine protocal is to concatenate. Message parts could be made equal size to minimize the chance of a message barely bumping over the limit as it moves. Of course, Alice could break her message to Bob directly, but we cannot assume that all would do this for us. This also means that if Alice sends a message to Bob in the clear through Chaum, and David, that the message will be encrypted from Chaum to David. Thus, if Eve wants to know which message from Chaum to David is the one from Alice to Bob, (perhaps to know that it is _not_ the message from Frank she is interested in) she knows only that it was one of the messages from Chaum to David after Chaum got the message from Alice, and before David sent it to Bob. While Chaum and David can both read the message, it still provides mixing capabilites inside the remailer net itself, and thus, some protection to Frank. (Who apparently needs the help.) A word on remailer keys: Since pgp uses square-and-multiply for exponentiation, we see that the amount of work needed to sign a message is d(m) * (d(e) + o(e)) where d(m) is the digits of the modulous, d(e) digits of the exponent, and o(e) is the number of ones in e. (I don't remember the technical term.) Since the public key is small, each of the parts of the private key will be large, BUT, there is no reason to assume that we cannot get lucky, and find an m such that d(e) + o(e) is much smaller than expected, (d(m) * 3/2, roughly) thus greatly reducing the system demand of the remailer. In fact, it might be possible to move to 768-bit keys for those that have kept their sizes down in the past. If pgp handles each prime separately, we look for a double-lucky modulous. (And a source of random numbers that does not involve striking keys!) Cypherpunks come up with really neato ideas for somebody ELSE to code... (Sorry guys, but I've not figured out how to get Unix/TCP/etc working on my Amiga...yet...) By the way, the following key id's are showing on the list, but are not on the servers: 27D5B76D 231C7021 34ED427F E37385DD. The first is the auto-signer at bb.hks.net. Also, my modem isn't too thrilled with my connection these days, If the signature fails, look for obvious errors in the text. Sorry. "PGP?" "ITAR!" "Oh, RKBA!" |--------------------------------------------------+ ----------------- 14712B4D 1994/12/26 Nathan H. Zook <nzook(a)bga.com> ) |44B3D866 3D551E2E --------------------------------------------------- |F89222A6 338CDE24/ | ----------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBLym3unmgMs8UcStNAQEAZggAlIsw7HDs4V2GU3DQo7Fx5TiRO6+6mW2B 7Qjn6I+CY1URQQbA3bhPvYoJUt2o3DJ0BCLRej03L/7mdRJmqS3f/1m+juflqPm7 oKlonwpOpFNg2kFSzjE4IpAgIcgi7tHgaLKsIfQ4+QO3s4pJdwAf8VMBHGLyWd2Z h9mNaKgUeKHjhHys2zATm6FNMipcAQgU8sFOl4/YIGyso+cfj4iSXAK4NM4tolDZ uca7l6bQdW5vwRjCJhNmKo+GuSHCY/QczbZZ9R5SkE58LrOVj1MY2x3qcg6gD04X Veddx83tLLsvnh02psRkWH+n0tv7GP8s8cle1ziJcgT96DrQIW6qMw== =t9x5 -----END PGP SIGNATURE-----

1 0

alt.religion.your.operating.system.sucks
by Joe Turner 17 Dec '03

17 Dec '03

I mean no disrespect, but the attrocities commited by the aged masters who wrote most of the operating systems are well documented. I have run into this line of thinking in many occasions (my <insert compiler or operating system> is better than yours...), although it it seems to be more of a sore spot to those who love thier compiler/ interpreter. Most of these observations are made out of ignorance. I get paid for programming under NT, windows, MS-DOS, VMS, RSX, and UNIX, not insulting the designers or users. Additionally, I deal with other people in other companies who love thier AS/400s and IBM mainframes. Hell there is even several programmers here who go misty-eyed everytime the word Amiga is mentioned. I bet there is even someone out there who believes that he/she could write a GUI operating system in COBOL (if someone has accomplished this I would love to see the punch cards...). UNIX is a programmers environment. It is very flexible, and you can do just about anything you want to, provided you have the ability. Spawning processes and child processes are trivial, and much more efficent compared to windows-NT and VMS. Additionally, I don't know of too many operating systems where the source code is floating around. I mean so what if it doesn't come with a pretty shrink wrapped package and a thick getting-started, if you have a question just go find the source code. Geez. And as far as a GUI, most of my work revolves around plain old ASCII. X windows may be "standard" now, but it didn't stop SUN, DEC, etc., from making their own proprietary (errr.. I mean "optimized") versions. I don't know why there is so much whining about: - My GUI interface sucks - Your GUI interface sucks - Your mother's interface sucks. I see no reason to puke up this garbage other people. VMS is more secure (interlock intrusion detection, etc.), but any operating system is only as strong as its users/administrators. The one thing I do not like about VMS is the way the system libraries are structured, but such is life. I was not consulted when DEC was designing the operating system. Thier Xwindows system needs some work, but it does work. NT is cool (if you are running on a 300MHz Sable). I think it is something special when you can run UNIX, Windows, and OpenVMS applications simultaniously on the same box. Can your operating system do that? Hell, for $3500 you can by a 166MHz alpha that will do this. System 7 is great. I just didn't like it. I didn't like the way I was isolated from the hardware, forced to take what the designers thought I needed. Just my preference. Besides, Apple equipment was, and still is overpriced (I should know I used to own several). Windows isn't a true multitasking operating system, and besides its like the old joke, Q: "how do you turn a 486/66 into a 286?" A: "run windows!". But like it or not, it is here to stay. I do like programming under windows over dos, simply because it is a pre-emptive operating system and forces the programmers to write structured code (for the most part) to intercept the messages. But the serial driver code sucks. PDP-11/RSX. Ewwwwww.. MS-DOS. If you want to write fast graphics, assembly is the way to go. Windows just can't keep up. Sure Micro$oft released win-G, but what's the point. Your operating system is so much better than mine are, as is your keyboard, your mouse, etc., My point is that every operating system, programming language, or whatever has benefits and detracting points. If you want to continue this discussion, I will be more than happy to create a list for it,.. then you can rant until you fingers are bloody. -- Joe N. Turner Telecheck International turner(a)telecheck.com 5251 Westheimer, PO BOX 4659, Houston, TX 77210-4659 compu$erv: 73301,1654 (800) 888-4922 * (713) 439-6597 Finger for PGP KEY.

6 7

CIAC Bulletin F-09
by John Young 17 Dec '03

17 Dec '03

[Note: Document reformated for mailing by jya(a)pipeline.com. If in doubt contact CIAC for original: ciac.llnl.gov:/pub/ciac/bulletin/f-fy95/f-09.ciac.(doc).] ________________________________________________________ The U.S. Department of Energy Computer Incident Advisory Capability ___ __ __ _ ___ / | /_\ / \___ __|__ / \ \___ _________________________________________________________ INFORMATION BULLETIN Unix /bin/mail Vulnerabilities January 27, 1995 1030 PST Number F-09 _________________________________________________________ PROBLEM: The Unix /bin/mail utility contains security vulnerabilities. PLATFORMS: DEC OSF/1 1.2, 1.3, and 2.0 DEC Ultrix 4.3, 4.3A, and 4.4 SCO Unix System V/386 Release 3.2 OS Version 4.2 SCO Open Desktop Lite Release 3.0 SCO Open Desktop Release 3.0 SCO Open Server Enterprise System Release 3.0 SCO Open Server Network System Release 3.0 Solbourne OS4.1x SunOS 4.x DAMAGE: Local users may gain privileged (root) access. SOLUTION: Apply appropriate vendor patch as described below. _________________________________________________________ VULNERABILITY ASSESSMENT The vulnerabilities in the /bin/mail program have been openly discussed in several Internet forums, and automated scripts exploiting the vulnerabilities have been widely distributed. These tools have been used in many recent attacks. CIAC recommends sites install these patches as soon as possible. _________________________________________________________ Critical Information about Unix /bin/mail Vulnerabilities The /bin/mail utility on several Unix versions based on BSD 4.3 Unix contain a security vulnerability. The vulnerability is the result of race conditions that exist during the delivery of messages to local users. These race conditions will allow intruders to create or modify files on the system, resulting in privileged access to the system. Below is a summary of systems known to be either vulnerable or not vulnerable. If your vendor's name is not listed, please contact the vendor or CIAC for more information. Vendor or Source Status ---------------- ------------ Apple Computer, Inc. Not vulnerable Berkeley SW Design, Inc. (BSDI) Not vulnerable Cray Research, Inc. Not vulnerable Data General Corp. Not vulnerable Digital Equipment Corp. Vulnerable FreeBSD Not vulnerable Harris Not vulnerable IBM Not vulnerable NetBSD Not vulnerable NeXT, Inc. Not vulnerable Pyramid Not vulnerable The Santa Cruz Operation (SCO) Vulnerable Solbourne (Grumman) Vulnerable Sun Microsystems, Inc. SunOS 4.x vulnerable Solaris 2.x not vulnerable Patch Information ----------------- DEC The /bin/mail patch is a part of a comprehensive Security Enhanced Kit that addresses other security problems as well. This kit was released on May 17, 1994 and was described in DEC Security Advisory #0505 and CIAC Notes 94-03. OSF/1 users should upgrade to a minimum of version 2.0 and install Security Enhanced Kit CSCPAT_4061 v1.0. Ultrix users should upgrade to at least version 4.4 and install Security Enhanced Kit CSCPAT_4060 v1.0. Both kits are available from your Digital support channel or electronically by request via DSNlink. SCO Vulnerabilities in SCO's /bin/mail utility are removed by applying SCO's Support Level Supplement (SLS) uod392a. It is available via anonymous FTP from ftp.sco.com in the /SLS directory: Description Filename MD5 Checksum ----------- ------------ -------------------------------- Disk image uod392a.Z 2c26669d89f61174f751774115f367a5 Cover letter uod392a.ltr.Z 52db39424d5d23576e065af2b80aee49 Solbourne Grumman System Support Corporation now performs all Solbourne software and hardware support. Please contact them for further information: E-mail: support(a)nts.gssc.com Phone: 1-800-447-2861 FTP: ftp.nts.gssc.com Sun Sun has made patches available to remove vulnerabilities in /bin/mail. These patches address all vulnerabilities CIAC has seen exploited to date, and CIAC recommends they be installed. However, the patches will be updated again in the near future to remove additional vulnerabilities that have recently come to light. CIAC will announce the availability of the new patches when they are released. The patches may be obtained from your local Sun Answer Center or through anonymous FTP from sunsolve1.sun.com in the /pub/patches directory: SunOS Filename MD5 Checksum ------- --------------- -------------------------------- 4.1.x 100224-13.tar.Z 90a507017a1a40c4622b3f1f00ce5d2d 4.1.3U1 101436-08.tar.Z 0e64560edc61eb4b3da81a932e8b11e1 Alternative Solution -------------------- For those sites unable to obtain a vendor patch From owner-cypherpunks Fri Jan 27 13:19:28 1995 Return-Path: <owner-cypherpunks> Received: by toad.com id AA15273; Fri, 27 Jan 95 13:19:28 PST Received: from gateway.informix.com by toad.com id AA15259; Fri, 27 Jan 95 13:19:22 PST Received: from informix.com (infmx.informix.com) by gateway.informix.com (4.1/SMI-4.1) id AA10439; Fri, 27 Jan 95 13:19:16 PST Received: from carbon.informix.com by informix.com (4.1/SMI-4.1) id AA02110; Fri, 27 Jan 95 13:19:08 PST Received: by carbon.informix.com (5.0/SMI-SVR4) id AA00461; Fri, 27 Jan 1995 13:19:01 +0800 Date: Fri, 27 Jan 1995 13:19:01 +0800 From: jamesd(a)com.informix.com Message-Id: <9501272119.AA00461(a)carbon.informix.com> Subject: Oops, Correction: one big error in "Even more unix holy war." Apparently-To: perry(a)imsi.com Apparently-To: sdw(a)lig.net Apparently-To: wmo(a)digibd.com Apparently-To: cypherpunks(a)toad.com Content-Length: 2646 Sender: owner-cypherpunks(a)toad.com Precedence: bulk I wrote: > The great strength is of course symbolic debugging -- you can > single step your compiled code, and see it displayed symbolicly, > with the symbols and statements of your source code, > and with the contents memory displayed in terms of your > source code variables. On this I was of course totally wrong: Unix has symbolic debugging equal to DOS/Windows. I was under the false impression that it only had C code interpretation. This is an error -- what I said was true for C++, but then in Windows we too are forced to primarily use interpretation to debug C++. C++ symbolic debuggers are not up to acceptable capabilities in either system. Sorry. But my statement concerning internationalization and resource files was correct. Unix has no equivalent of App Studio, etc. I have made a little tour of people in my company who work on both unix and Windows. I (fortunately) work primarily on Windows, as you may have guessed. The company I presently work for is making a tool they call Window Painter. This is in some respects similar to App Studio. It works with their unix database language. But it is no App Studio, as the unix folk who are working on it freely admit, those few of them that have used App Studio. Most of my correspondents had replies along the lines of "Huh -- internationalization -- what source code tools could possibly help you with internationalization." Others listed irregular bands of random unix tools which are essentially irrelevant to the problem of internationalization. Most international unix programs have string files that the compiled program refers to a string by a number, and a font size by a number, and the position of the button on screen by a number -- site customizable information, Xdefaults, *.cfg This is functionally equivalent to the Windows Resource file, in that in principle one can keep translatable elements separate from source code. But is certainly not equivalent in ease of use. One can do the job, but in essense one does it by hand. Resource files, and dialog box editing tools such as App Studio, provide a clean separation between visual user interface elements that typically require translation, and functiona code that does not. --------------------------------------------------------------------- | We have the right to defend ourselves | http://www.catalog.com/jamesd/ and our property, because of the kind | of animals that we are. True law | James A. Donald derives from this right, not from the | arbitrary power of the omnipotent state. | jamesd(a)netcom.com

1 0

CIAC Bulletin F-09: Unix /bin/mail Vulnerability (fwd)
by Mike Acklin 17 Dec '03

17 Dec '03

Just got this in the mail and thought I would share it with all of you... ---------- Forwarded message ---------- Date: Fri, 27 Jan 1995 11:16:55 -0800 From: Steve Weeber <weeber(a)eek.llnl.gov> To: hroller(a)metronet.com Subject: CIAC Bulletin F-09: Unix /bin/mail Vulnerability _____________________________________________________ The U.S. Department of Energy Computer Incident Advisory Capability ___ __ __ _ ___ / | /_\ / \___ __|__ / \ \___ _____________________________________________________ INFORMATION BULLETIN Unix /bin/mail Vulnerabilities January 27, 1995 1030 PST Number F-09 _____________________________________________________________________________ PROBLEM: The Unix /bin/mail utility contains security vulnerabilities. PLATFORMS: DEC OSF/1 1.2, 1.3, and 2.0 DEC Ultrix 4.3, 4.3A, and 4.4 SCO Unix System V/386 Release 3.2 OS Version 4.2 SCO Open Desktop Lite Release 3.0 SCO Open Desktop Release 3.0 SCO Open Server Enterprise System Release 3.0 SCO Open Server Network System Release 3.0 Solbourne OS4.1x SunOS 4.x DAMAGE: Local users may gain privileged (root) access. SOLUTION: Apply appropriate vendor patch as described below. _____________________________________________________________________________ VULNERABILITY The vulnerabilities in the /bin/mail program have been openly ASSESSMENT: discussed in several Internet forums, and automated scripts exploiting the vulnerabilities have been widely distributed. These tools have been used in many recent attacks. CIAC recommends sites install these patches as soon as possible. _____________________________________________________________________________ Critical Information about Unix /bin/mail Vulnerabilities The /bin/mail utility on several Unix versions based on BSD 4.3 Unix contain a security vulnerability. The vulnerability is the result of race conditions that exist during the delivery of messages to local users. These race conditions will allow intruders to create or modify files on the system, resulting in privileged access to the system. Below is a summary of systems known to be either vulnerable or not vulnerable. If your vendor's name is not listed, please contact the vendor or CIAC for more information. Vendor or Source Status ---------------- ------------ Apple Computer, Inc. Not vulnerable Berkeley SW Design, Inc. (BSDI) Not vulnerable Cray Research, Inc. Not vulnerable Data General Corp. Not vulnerable Digital Equipment Corp. Vulnerable FreeBSD Not vulnerable Harris Not vulnerable IBM Not vulnerable NetBSD Not vulnerable NeXT, Inc. Not vulnerable Pyramid Not vulnerable The Santa Cruz Operation (SCO) Vulnerable Solbourne (Grumman) Vulnerable Sun Microsystems, Inc. SunOS 4.x vulnerable Solaris 2.x not vulnerable Patch Information ----------------- DEC The /bin/mail patch is a part of a comprehensive Security Enhanced Kit that addresses other security problems as well. This kit was released on May 17, 1994 and was described in DEC Security Advisory #0505 and CIAC Notes 94-03. OSF/1 users should upgrade to a minimum of version 2.0 and install Security Enhanced Kit CSCPAT_4061 v1.0. Ultrix users should upgrade to at least version 4.4 and install Security Enhanced Kit CSCPAT_4060 v1.0. Both kits are available from your Digital support channel or electronically by request via DSNlink. SCO Vulnerabilities in SCO's /bin/mail utility are removed by applying SCO's Support Level Supplement (SLS) uod392a. It is available via anonymous FTP from ftp.sco.com in the /SLS directory: Description Filename MD5 Checksum ------------ ------------- -------------------------------- Disk image uod392a.Z 2c26669d89f61174f751774115f367a5 Cover letter uod392a.ltr.Z 52db39424d5d23576e065af2b80aee49 Solbourne Grumman System Support Corporation now performs all Solbourne software and hardware support. Please contact them for further information: E-mail: support(a)nts.gssc.com Phone: 1-800-447-2861 FTP: ftp.nts.gssc.com Sun Sun has made patches available to remove vulnerabilities in /bin/mail. These patches address all vulnerabilities CIAC has seen exploited to date, and CIAC recommends they be installed. However, the patches will be updated again in the near future to remove additional vulnerabilities that have recently come to light. CIAC will announce the availability of the new patches when they are released. The patches may be obtained from your local Sun Answer Center or through anonymous FTP from sunsolve1.sun.com in the /pub/patches directory: SunOS Filename MD5 Checksum ------- --------------- -------------------------------- 4.1.x 100224-13.tar.Z 90a507017a1a40c4622b3f1f00ce5d2d 4.1.3U1 101436-08.tar.Z 0e64560edc61eb4b3da81a932e8b11e1 Alternative Solution -------------------- For those sites unable to obtain a vendor patch for a vulnerable version of /bin/mail, a replacement package called mail.local has been developed and made freely available on the Internet. The /bin/mail program is relatively complex software, serving both as a mail delivery agent and a user interface, allowing users to send and read E-mail messages. Complex system software, like /bin/mail, is more likely to exhibit security vulnerabilities. The mail.local package was written to perform only one task: the delivery of mail to local users. It is comparatively small, and the code has been examined carefully by experts in the security community. While it has not been formally evaluated, it is probable that mail.local addresses all vulnerabilities currently being exploited in /bin/mail. For more information, see the file README in the directory ftp://coast.cs.purdue.edu/pub/tools/unix/mail.local/. _____________________________________________________________________________ CIAC wishes to acknowledge the contributions of the CERT Coordination Center in the construction of this bulletin. _____________________________________________________________________________ For emergencies and off-hour assistance, DOE and DOE contractor sites can contact CIAC 24-hours a day via an integrated voicemail and SKYPAGE number. To use this service, dial 1-510-422-8193 or 1-800-759-7243 (SKYPAGE). The primary SKYPAGE PIN number, 8550070 is for the CIAC duty person. A second PIN, 8550074 is for the CIAC Project Leader. CIAC's FAX number is 510-423-8002, and the STU-III number is 510-423-2604. Send E-mail to ciac(a)llnl.gov. Previous CIAC notices, anti-virus software, and other information are available on the Internet via anonymous FTP from ciac.llnl.gov (IP address 128.115.19.53). CIAC has several self-subscribing mailing lists for electronic publications: 1. CIAC-BULLETIN for Advisories, highest priority - time critical information, and Bulletins, important computer security information; 2. CIAC-NOTES for Notes, a collection of computer security articles; 3. SPI-ANNOUNCE for official news about Security Profile Inspector (SPI) software updates, new features, distribution and availability; 4. SPI-NOTES, for discussion of problems and solutions regarding the use of SPI products. Our mailing lists are managed by a public domain software package called ListProcessor, which ignores E-mail header subject lines. To subscribe (add yourself) to one of our mailing lists, send requests of the following form: subscribe list-name LastName, FirstName PhoneNumber as the E-mail message body, substituting CIAC-BULLETIN, CIAC-NOTES, SPI-ANNOUNCE or SPI-NOTES for "list-name" and valid information for "LastName" "FirstName" and "PhoneNumber." Send to: ciac-listproc(a)llnl.gov not to: ciac(a)llnl.gov e.g., subscribe ciac-notes O'Hara, Scarlett 404-555-1212 x36 subscribe ciac-bulletin O'Hara, Scarlett 404-555-1212 x36 You will receive an acknowledgment containing address and initial PIN, and information on how to change either of them, cancel your subscription, or get help. _____________________________________________________________________________ PLEASE NOTE: Many users outside of the DOE and ESnet computing communities receive CIAC bulletins. If you are not part of these communities, please contact your agency's response team to report incidents. Your agency's team will coordinate with CIAC. The Forum of Incident Response and Security Teams (FIRST) is a world-wide organization. A list of FIRST member organizations and their constituencies can be obtained by sending E-mail to first-request(a)first.org with an empty subject line and a message body containing the line: send first-contacts. This document was prepared as an account of work sponsored by an agency of the United States Government. Neither the United States Government nor the University of California nor any of their employees, makes any warranty, expressed or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial products, process, or service by trade name, trademark manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favoring by the United States Government or the University of California. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government nor the University of California, and shall not be used for advertising or product endorsement purposes.

1 0

Oops, Correction: one big error in "Even more unix holy war."
by m5＠vail.tivoli.com 17 Dec '03

17 Dec '03

jamesd(a)com.informix.com writes: > This is an error -- what I said was true for C++, but > then in Windows we too are forced to primarily use > interpretation to debug C++. C++ symbolic debuggers > are not up to acceptable capabilities in either system. I hate to contribute to this silliness, but I can't let blatant errors like this pass. I debug reams of C++ daily on a wide variety of UNIX platforms. With real symbols. With real C++ expression evaluation an overload resolution. (I also get to use compilers that actually come close to supporting the language as defined by the ARM.) | GOOD TIME FOR MOVIE - GOING ||| Mike McNally <m5(a)tivoli.com> | | TAKE TWA TO CAIRO. ||| Tivoli Systems, Austin, TX: | | (actual fortune cookie) ||| "Like A Little Bit of Semi-Heaven" |

1 0

anonymous mailing
by craig＠passport.ca 17 Dec '03

17 Dec '03

Since you invite comment: You seem to think that anoynimity can be separated from privacy itself. Anoynimity was an accidental feature of the telephone system that was only recently eliminated. Now, it seems, that those who seek control over others have realized that it could be eliminated in other media as well (why not routinely fingerprint everyone, and dust all postal mail for fingerprints? More practically, why not earmark every transaction on the Reuters feed? Or credit every article in the Economist?). But even these fundamental disruptions to basic institutions are dwarfed by the threat to individual confidence to speak out and not fear retribution, in a world with so many laws that everyone is breaking one or another... Consider this: Given the speed and efficiency with which data can be gathered over the networks, including levels of traffic between entitites (often the most useful data for purposes of spying on them), it could be a matter of a short time before a complete dossier of our motions and associations is in the hands of every lawful authority, every service provider, and every brother in law of either, and for sale to the highest bidder - note that most complaints against "hackers" that dig up private data concern attacks against large data banks (e.g. bank records). We might question the buildup of these data banks that make us so vulnerable to invasions of privacy, rather than those who invade. I am pondering whether to put a standing offer out in this feared "hacker" community for your tax records. If I received no takers for the challenge, I am confident that it would not be due to lack of ability, but because they respect your rights more than your respect theirs. That is, ours. That is, yours. There is no need to protect my name in this case, but only because it seems clear to me that a majority of those who understand this issue, stand on my side. If we ever become a minority I may feel less confident, and then anoynimity may make the difference between speaking out alone or not at all. Extinguish the "lone anonymous voice" from electronic media, which is the mainstream in which commerce is done and thoughts develop, and you might as well have extinguished the pamphleteer from the American Revolution. In fact, you *will* have extinguished him. I hope you have something to replace him with: Universal tolerance ? Spiritual nirvana? How do you propose to protect the lone citizen with an unpopular view who is not yet numerous enough to command a seat in Congress. Craig Hubley Business that runs on knowledge Craig Hubley & Associates needs software that runs on the net craig(a)passport.ca 416-778-6136 416-778-1965 FAX

2 1

Shut up already - James Donald does not even exist...
by craig＠passport.ca 17 Dec '03

17 Dec '03

James Donald does not exist. We can stop the flame war now. Trying to be a good net.citizen, I sent "him" e-mail to correct one of "his" line- noise-quality opinions quietly (so he might shut up) - has no one else tried this? It bounced, failing to resolve host which does not usually happen here if the site is real. So I submit the following as evidence that "he" does not exist: - com.informix.com does not seem real. - no living human being could hold such opinions and simultaneously operate his vital organs (i.e. the level of intelligence implied by his "opinions" is even lower than that necessary to support breathing and digestion) - posting pseudonymously to cypherpunks and engaging them in spurious flame argument might seem like fun to someone hostile to the anoynimity agenda and a way of generating a case that "see, anonymous/pseudonymous use of the internet angers even cypherpunks" James, if you *do* exist, I suggest you shut up now before someone you may want to work for reads your idiot posts. As for me, I am enforcing my own opinion that you do not exist by entering your "address" in my filter file. Goodbye. Those of you who care about flame wars can read the following bounced msg: > Date: Fri, 27 Jan 95 18:50 EST > From: <MAILER-DAEMON(a)passport.ca> > To: craig > Subject: mail failed, returning to sender > Reference: <m0rY0Qb-0002HEC(a)forged.passport.ca> > Content-Type: text > Content-Length: 1980 > > |------------------------- Failed addresses follow: ---------------------| > jamesd(a)com.informix.com ... unknown host > |------------------------- Message text follows: ------------------------| > Received: by forged.passport.ca (Smail3.1.29.1 #5) > id m0rY0Qb-0002HEC; Fri, 27 Jan 95 18:50 EST > Message-Id: <m0rY0Qb-0002HEC(a)forged.passport.ca> > From: craig (Craig Hubley) > Subject: Re: Oops, Correction: one big error in "Even more unix holy war." > To: jamesd(a)com.informix.com > Date: Fri, 27 Jan 1995 18:50:09 -0500 (EST) > In-Reply-To: <9501272119.AA00461(a)carbon.informix.com> from "jamesd(a)com.informix.com" at Jan 27, 95 01:19:01 pm > X-Mailer: ELM [version 2.4 PL23] > MIME-Version: 1.0 > Content-Type: text/plain; charset=US-ASCII > Content-Transfer-Encoding: 7bit > Content-Length: 1203 > > > Unix has no equivalent of App Studio, etc. I have made > > Nonsense. What about UIM/X, InterViews screen painter, > and the many cross-platform toolkits (C++Views, Visix > Galaxy, Neuron Data Client/Server Elements, Zinc, Zapp, > and now Taligent... for that matter what about NextStep? > And the increasing number of Smalltalk tools ?) > > > a little tour of people in my company who work on both > > unix and Windows. I (fortunately) work primarily on > > Windows, as you may have guessed. > > I *did* guess, but never mind how. :-) > > > Most of my correspondents had replies along the lines > > of "Huh -- internationalization -- what source code > > tools could possibly help you with internationalization." > > Zinc runs off a special purpose OODB. Translating a GUI > from one language to another is a matter of setting a flag > at runtime... everything switches from English into Spanish > or whatever. > > > James A. Donald > > Sorry James, your opinions on this matter are line noise. Posts > with this subject and your name on them will be ignored. Please > consult the various FAQs on Unix programming and crossplatform > toolkits before wasting bandwidth with this pure nonsense again. > > So much for your free education. > > Craig > >

2 1

Why encrypt intra-remailernet.
by Nathan Zook 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Suppose Alice sends Bob a message e(M) through Chaum. Eve, a stong opponent, wants to trace the message. She keeps track of all outgoing mail from Alice, an MD5 hash of all incoming messages to Bob, and outgoing from Bob. Eve then sends Chaum e(M), and waits for a matching MD5 to Bob that doesn't correlate to an outgoing MD5 from Bob. (Eve knows that Bob is a remailer.) (Thanks to whoever came up with Eve. I'm embarassed that I didn't think of that trick.) Clearly, this generalizes. Gentlemen, I believe that I have just stumbled upon a strong proof of the necessity of remailer auto-encryption of all messages. Since the session key is PRG, MD5 will change (a lot;). Furthermore, remailer auto- encryption allows the mailers to number their messages to each other. A low number means a re-transmit from the remailer, which is not possible, unless some sort of ACK system is in place, and even then, would still flag. Of course, if the remailers _sign_ their messages (on the way out) as well, you could compare the timestamps of the signatures with the message itself. - --- I also believe that the spammed remailer attack reveals another important weakness: if 50% of all mail leaving Alice during one tick goes to Bob, then Eve can gain probablistic information about the messages that Alice recieved, when attempting to trace a message through the net. This "attack" suggests a rational use of garbage: 1) A remailer always sends at least as many messages as it recieves, _including junk_. This means that you don't have a system "mysteriously" recieving 200 messages, and sending eight. 2) A remailer always sends at least n messages per tick. (n may vary between remailers.) If a remailer has very low traffic, that traffic is still protected. 3) On a given tick, a remailer always sends the same number of messages to each other remailer. This eliminates the effectiveness of a spam hit on a remailer of an old message. 4) Designated users of the net receive the same number of messages from each remailer each tick. (Such users probably _send_ the same number of messages each tick, as well. Note also that if some remailer is untrusted, that will be reflected by its always being sent garbage.) This puts the users "inside" the net. No, these axioms do not blow up the amount of garbage. New messages to the net displace garbage, unless they raise the maximum for the number going to a particular remailer. This system also has the advantage of _immediately_ fully integrating any new remailers. New remailers don't have to build up their users in order to be secure. - --- By combining these two, I believe we can turn the remailer net into a black box, including designated users. A communication should be safe if either end is in the black box. I believe that "PGP only" is the only way that remailers will be able to fulfill their potential. It should also increase the base of PGP users. - --- I nominate the phrases "Execute plan X.", "I have the soveineers.", "Your fried chicken is ready.", and "The NSA is a bunch of idiots." for garbage. If they ever attempt to prosecute, the have to reveal that they broke IDEA or RSA to X digits. ___ Note that the maintainence of an MD5 log of all messages by recipient by the remailers can be used to kill primitive spam/bombs. "PGP?" "ITAR!" "Oh, RKBA!" |--------------------------------------------------+ ----------------- 14712B4D 1994/12/26 Nathan H. Zook <nzook(a)bga.com> ) |44B3D866 3D551E2E --------------------------------------------------- |F89222A6 338CDE24/ | ----------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBLyrUVnmgMs8UcStNAQH18wf/a4SSoew9TJeaLsGWg+rL6wqm2RStrdFI XOULDD7e1yaYLBaovSz8BeNgHgW1UUAiKWWsl4rmVQ+QI1u2Oprgzo/mGy5qa1Bv i2GK9yjRleypn06fOf9kS7lr8ACO71m+1L/HPz+NBlPCgg6hCaWSJfoJkSQ1cHYi 5SHCvn/s/zLypgxcbDNqDF3eBMgpYokhFFyoTeD8LfNEtqQB/EGOwMlsik9YaKGg 5djDfDBucRsWy1a7H9G/BPejacA7PsIBKIIjbsQbxqCIczjzPR75j69ypM1IAtow kCwq6KH4d9dyKPaB5Q564LsDiEkrift+84/rADro6L5ppi4GG4PFmQ== =NgpM -----END PGP SIGNATURE-----

2 1