December 2003 - cypherpunks-legacy

New Netscape bug (in version 1.12)
by Ray Cromwell 17 Dec '03

17 Dec '03

C'punks, I just got back from a vacation in Raleigh, and downloaded the new "fixed" Netscape 1.12. It took me about an hour, but I've discovered another bug and potential security hole. This one relates to mailto:. The bug is as follows. Create a HTML file with a hyperlink containing the following URL foo This bug doesn't seem to crash Netscape, instead, it crashes my XServer as soon as the mail window pops op. I'm too tired right now to try to analyze it, but it might be another stack bug, this time, in the X libraries because Netscape isn't doing any sanity checking. I need help testing this bug on other platforms. I have created a test page. Go to http://www.gl.umbc.edu/~rcromw1/crash.html to test. I have also found 2 other bugs that cause stack trashing in v1.1 however, they are random and I haven't been able to isolate them completely yet. (I have created a page on my system, such that if you visit it, after you visit about 3 more pages, it crashes) What's my point in pursuing this? Netscape's browser is a piece of software that runs on millions of computers and in effect, allows outside agents to input arbitrary data into that software. As such, it is unlike most applications made. Sure, Microsoft Word may have bugs, but how many people are downloading hundreds of MS Word documents everyday and viewing them? Users of Web browsers are exposing themselves like this everyday, and so I think, that web browsers must have higher standards of robustness. I think Netscape represents an enormous risk to computer security, and while I think they are heading in the right direction, there are some very basic implementation issues they need to clear up which are orthogonal to SSL and credit card transactions. All the cryptography in the world won't help you if someone can subvert your cryptobox. Netscape needs to do some serious quality assurance work. I've never been a QA person in my life, but within a few minutes, I have been able to find serious bugs in the software. And while I'm sure Netscape's coders are fine people, proof reading your own code, code that you look at everyday, becomes rather hard because you tend to "see through it". (just like proof reading essays, or messages) I think Netscape should hire some outside firm/group to review their code under non-disclosure for potential implementation holes. -Ray Cromwell <rjc(a)clark.net> P.S. I am running Netscape v1.12 under BSDI2.0 and the XAccel/2.0 server

6 7

Re: Certificate proposal
by Bill Stewart 17 Dec '03

17 Dec '03

At 10:21 AM 10/3/95 EDT, Carl Ellison <cme(a)TIS.COM> wrote: >The whole issue of CRLs is on shaky ground with me. I think it's gotten >lost in debates about how to distribute them offline (or perhaps via >e-mail) and have them work. No surprise; it's a tough job. I don't expect my laptop to be continuously on-line when I'm reading mail, and even on-line use needs to be more realistic than saying "Everybody must use X.400". >CRLs are like the old credit card or check stop lists which used to be at >every supermarket checkout station. They aren't there any more. >Checkout stations are now on-line. >I see nothing wrong with having a "certificate" which says ``certificate >available online only at xxx(a)yyy.zzz''. Interesting. Aside from the excessive cost of looking up cards in paper booklets, which can be avoided by having checkstands validate on the store's backroom computer system, on-line verification lets the card company not only refuse stolen cards, but also dynamically refuse cards that have reached their credit limits, which you can't do on a slow push-based offline system. However, it's _very_ tough to spoof a credit-card verification system, because the checkout device uses phones or private networks to reach the authorization company, so the response that comes back saying yes/no/stolen can be real dumb. On the internet, the response needs to be signed, though I suppose it could say "Key sssss at xxx(a)yyy.zzz authorized key uuuuu today yyyy/mm/dd/hh:mm:ss, valid for up to $500", and you'd then have to validate the key that signed it, etc.... On the other hand, you could have the cert require multiple confirmations, e.g. both the bank and the user have to authorize this use. >>3) Neither PGP nor X.509 (as documented in the RFC1422 and PKCS#6) have any >> mechanism for additional information other than cramming it into >> the username, but supposedly X.509 Version 3 includes something? >Yup -- and it's ugly. It counts on a defined OBJECT ID to define the OBJECT IDs solve two problems - one is that you need some kind of format (yuk), but the other is that fields to have mutually agreed on values to be meaningful, and central registration is an easy way to implement it, as long as there's a simple way to register things. I hope it at least supports an OBJECTID with parameters, e.g. "CreditLimitUSDollarsBankFoo integer" rather than needing excessively many OBJECTIDs "CreditLimit3700USDollarsBankFoo"? As you say below, there's certainly no need to use ASN.1 formats instead of readable ones... > What's invalid is the assumption that >there must be a relationship (or even a person) in physical space *before* >one can have a relationship (or a person) in cyberspace. Yeah. I've decided, as an experiment, to start signing keys for pseudonyms, though I haven't settled on how to deal with unauthenticated signatures for realspace people (in the one case where I've been asked, the person didn't have any independent signatures from other people, so so far I've declined, but I may re-evaluate and just do uniqueness.) #--- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #---

2 1

Oct 14 DC-area physical meeting
by pfarrell＠netcom.com 17 Dec '03

17 Dec '03

Sorry to send this to 800+ folks, this is the only announcement I'll send this month. The October DC-area cypherpunks meeting will be on Saturday, Oct. 14 at 3:00 PM at the Digital Express offices in Laurel. For more information (directions, agenda, etc.), please see url: http://www.isse.gmu.edu/~pfarrell/dccp/index.html Additional agenda topics solicited! Thanks Pat Pat Farrell grad student http://www.isse.gmu.edu/students/pfarrell Infor. Systems and Software Engineering, George Mason University, Fairfax, VA PGP key available via finger or request #include standard.disclaimer

1 0

(fwd) ETO TENDER
by rah＠shipwright.com 17 Dec '03

17 Dec '03

--- begin forwarded text Date: Tue, 3 Oct 95 09:14:04 -0400 From: "GORD JENKINS" <jenkins(a)fox.nstn.ca> X-Minuet-Version: Minuet1.0_Beta_14.1 Reply-To: <JENKINS(a)fox.nstn.ca> X-Popmail-Charset: English To: www-buyinfo(a)allegra.att.com, untpdc(a)urgento.gse.rmit.EDU.AU Subject: ETO TENDER For List: Ref UN Trade Point ------------------ Attached is an alternative to the use of electronic brokers who charge per transaction. This sevice is free and very well organized. Check out the UNCTAD Trade Point Web site at: http://www.unicc.org/untpcd Gordon Jenkins Emailjenkins(a)fox.nstn.ca URL : http://www.infop.com/karoma ----- Forwarded message begins here ----- From: UNTPDC <untpdc(a)urgento.gse.rmit.EDU.AU> Thu, 28 Sep 1995 11:47:45 +1000 (EST) To: ETO gateway <etotrade(a)wtm.com> Subject: ETO TENDER TO : ETO ASSOCIATES - TRADE POINTS FROM : Carlos Moreira Head United Nations Trade Point Development Centre UNCTAD Subject : ETO Tenders Dear ETO users, we are introducing a new service to the ETO systems which relates to international tenders. The service ETO Tender is also free and we will disseminate the information via email. The tender data is always free text so we will not codify the information. Please send us your national tenders so we can increase the number of tenders on-line. With my best regards Carlos Moreira ETO TENDER Japan FOREIGN GOVERNMENT TENDER Description: S16 CONSTRUCTION Comments: PRODUCT DATA A. INDUSTRY SECTOR CODE: B. DETAILED PRODUCT DESCRIPTION: CONSTRUCTION TITLE: PRELIMINARY DESIGN OF THE KOYA JUNCTION BRIDGES; SUMMARY: PRELIMINARY DESIGN OF BRIDGES FOR GENERAL AND EXCLUSIVE USE AT THE KOYA JUNCTION (TENTATIVE NAME); DELIVERY DATE: MARCH 25, 1996. C. PRODUCT SPECIFICATIONS/TECHNICAL DATA: N/A (NOT AVAILABLE) D. QUANTITY: N/A E. U.S. DOLLAR VALUE: N/A F. OTHER INFORMATION: N/A RESPONSE DATA A. RESPONSE LANGUAGE: JAPANESE. B. BEST WAY TO RESPOND: LETTER. C. FROM MANUFACTURERS ONLY: N/A D. INFORMATION DESIRED FROM U.S. FIRM: N/A E. PRIMARY BUYING FACTOR: N/A F. OTHER INFORMATION: INTERESTED FIRMS MUST SUBMIT THEIR EXPRESSION OF INTEREST IN THIS DESIGN COMPETITION BY 17:00 PM, SEP. 29. THE PROSPECTUS MUST BE OBTAINED DIRECTLY FROM THE PROCURING AGENCY, NOT FROM U.S. EMBASSY. TENDER LEAD DATA A. ISSUING AGENCY: METROPOLITAN NATIONAL HIGHWAY WORK OFFICE, KANTO REGIONAL CONSTRUCTION BUREAU B. FINANCING AGENCY: SAME AS ABOVE. C. PRICE OF PROSPECTUS: N/A D. OBTAIN PROSPECTUS BY: OCT. 23, 1995. E. TENDER NUMBER REQUIRED IN ALL COMMUNICATIONS: N/A F. PERFORMANCE BONDS REQUIRED: N/A G. CLOSED PROCUREMENT PROCEDURE: NO. H. BIDDING PROCEDURES: SELECTIVE TENDER. I. PROPOSAL DEADLINE: 17:00 PM, OCT. 24, 1995. J. OTHER INFORMATION: "KENSETSU KOGYO SHIMBUN": 9/19/95. CRITERIA FOR QUALIFICATION, SELECTION, AND SCREENING: 1) QUALIFICATION CRITERIA FOR PARTICIPANTS: FIRMS PRE- QUALIFIED FOR OPEN COMPETITIVE OR SELECTIVE BIDDING ON CIVIL ENGINEERING CONSULTING WORK BY THE KANTO REGIONAL CONSTRUCTION BUREAU; 2) SELECTION CRITERIA FOR PARTICIPANTS: A) RECORDS OF SAME TYPE OR SIMILAR WORK; B) CONDITIONS OF REGISTERED BUSINESS; C) AVAILABILITY OF SPECIALIZED ENGINEERS; D) QUALIFICATION, BACKGROUNDS, AND WORK INVOLVED OF ASSIGNED ENGINEERS; E) PLAN FOR SUBCONTRACTING; AND F) RELATIONS WITH CONTRACTORS; AND 3) SCREENING CRITERIA FOR DESIGN PROPOSALS: A) HISTORY OF COMPANY'S BUSINESS: RECORDS OF SAME TYPE OR SIMILAR WORK; AVAILABILITY OF SPECIALIZED ENGINEERS; B) EXPERIENCE AND ABILITY OF ENGINEERS: QUALIFICATION, EXPERIENCE, WORK INVOLVED, AND WORK RECORDS OF ASSIGNED ENGINEERS; AND C) PLAN OF ACTION AND ITS METHOD: LEVEL OF UNDERSTANDING OF PROSPECTUS; APPROPRIATENESS OF PLAN OF ACTION; ADEQUACY, ORIGINALITY, AND FEASIBILITY OF PROPOSAL; AND APPROPRIATENESS OF PROCESS AND MANPOWER PLAN. POST REMARKS: POST CONTACT/PREPARED BY: HAOMORI APPROVED BY: GTAEVS CONTACT: FIRST PLANNING AND DESIGN DIVISION, METROPOLITAN NATIONAL HIGHWAY WORK OFFICE, KANTO REGIONAL CONSTRUCTION BUREAU, MINISTRY OF CONSTRUCTION, 86 TAKEGAHANA, MATSUDO-SHI, CHIBA-KEN 271, JAPAN PHONE: 81/473/62-4115 FAX: N/A Please send a copy of your response to: COMMERCIAL OFFICER (FCS TOP) AMERICAN EMBASSY TOKYO UNIT 45004 APO AP 96337 Refer to TC606 ------ Forwarded message ends here ------ -- GORD JENKINS e maik JENKINS(a)fox.nstn.ca tel 613 794 6735 fax 613 723 8938 --- end forwarded text ----------------- Robert Hettinga (rah(a)shipwright.com) Shipwright Development Corporation, 44 Farquhar Street, Boston, MA 02131 USA (617) 323-7923 "Reality is not optional." --Thomas Sowell >>>>Phree Phil: Email: zldf(a)clark.net http://www.netresponse.com/zldf <<<<<

1 0

Monkeywrenching Certificate Schemes
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 7:15 PM 10/3/95, Carl Ellison wrote: >Yup. Verisign is probably going to fight hard to keep their certificate >model. On top of them, there's the US Postal Service and a few others, >fighting over the chance to set up a certificate hierarchy. Almost needless to say, there is nothing particularly wrong with certificate-granting agencies. A big caveat: Providing the process is fully voluntary. (I'm not addressing issues of implementation, of the "X.509" messinesses, etc.) The big danger I see in all this talk of "certificate authorities" is that it won't be a voluntary process. (The same themes as with key escrow.) I'm not suggesting we waste our time arguing against such certificate authorities. Rather, we might better spend our time finding ways to monkeywrench the proposals. I don't want either the "Postal Service" or "Verisign" given the authority to approve or disapprove my identity or any identity I may choose to adopt. Isn't it about time for SAIC to acquire Verisign? --Tim May (Identity Subject to Approval) ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 | black markets, collapse of governments. "National borders are just speed bumps on the information superhighway."

1 0

HUL_loo
by John Young 17 Dec '03

17 Dec '03

The Economist of September 30-October 6 has a long survey of global telecommunications, excellently researched and written: The death of distance as a determinant of the cost of communications will probably be the single most important economic force shaping society in the first half of the next century. It will alter, in ways that are only dimly imaginable, decisions about where people live and work; concepts of national borders; patterns of international trade. Its effects will be as pervasive as those of the discovery of electricity. Buy it, see it at http://www.economist.com, or, in a pinch: HUL_loo (92 kb in 6 parts)

2 1

Oct 20th SF C'punks meeting: at the ITAR Constitutional trial court
by John Gilmore 17 Dec '03

17 Dec '03

We're having a "Cypherpunks Dress-Up Day" on Friday, October 20th. Meet at the Federal Building in San Francisco, 450 Golden Gate Avenue, at 10:15AM. Hey, I've seen Tim May in a suit once, why not again? The first "oral arguments" in the Bernstein crypto export case will happen there, starting at 10:30, in Judge Patel's courtroom upstairs. We've been fedexing legalese back and forth for months; now we get to explain the case in person. You can meet our intrepid lawyers, who are slaving away without pay, in durance vile, to protect our rights! Shake hands with an NSA lawyer specially flown in for the occasion! Meet some local journalists! And watch the wheels of justice grindin' as the judge first explores our case. We will follow the hearing with a group lunch at Max's Opera Plaza, a block away, and break up at 12:30 or 1PM. In this case, Dan Bernstein, ex-grad-student from UC Berkeley, is suing the State Department, NSA, and other agencies, with help from the EFF. Our main argument is that the export controls on crypto software are a "prior restraint on publication" which is unconstitutional under the First Amendment unless handled very delicately by a court (not just by an agency acting on its own). These agencies restrained Dan's ability to publish a paper, as well as source code, for the crypto algorithm that he invented. There are additional arguments along the lines that the State Department and NSA take a lot more liberties during the export process than their own regulations and laws really permit. Full background and details on the case are in the EFF Web/FTP archives at: http://www.eff.org/pub/Privacy/ITAR_export/Bernstein_case. Like Phil Karn's case, this lawsuit really has the potential to outlaw the whole NSA crypto export scam. We could make your right to publish and export crypto software as well-protected by the courts as your right to publish and export books. Of course, the government would appeal any such decision, and it will take years and probably an eventual Supreme Court decision to make it stick. But you can be there at the very beginning! Please make a positive impression on the judge. Show her -- by showing up -- that this case matters to more people than just the plaintiff and defendant. That how it gets decided will make a difference to society. That the public and the press are watching, and really do care that it gets handled well. We'll have to be quiet and orderly while we're in the courthouse. There will be no questions from the audience (that's us), but the session will be tape-recorded, and you can take notes if you like. The judge is Marilyn Hall Patel, who used to be on the board of directors of the ACLU. I haven't met her, but I hear that she's not afraid to tell the government where to stuff it, when they deserve it. Our lawyers met with her once before, but this will be your first chance to meet the judge in person. The particular issue in front of the judge on the 20th is whether the case should be thrown out. The government is arguing that it should. It's a mess of legal details about whether the Judicial Branch has the right to decide questions like this, and over whether we have really properly claimed a Constitutional rights violation. It will teach most c'punks something about how the courts work, and how the NSA and State Dept use bureaucratic tricks to avoid facing the real issues. We have managed to drag in some of these issues, like whether there is sufficient "expression" in software that the First Amendment should protect publishers of software. It's possible, but unlikely, that the judge will decide then-and-there. We will get some clues to how she is leaning, based on her questions and comments. Her written decision will come out some days or weeks later. Don't bring any interesting devices unless you're willing to check them with the lobby guards for the duration. They seem to want to hold onto guns, "munitions", and even small pocketknives, before they'll let you go upstairs to the courtrooms. So, here's your excuse to put on a nice costume, take an early lunch, and pay a call on the inner sanctum of our civil rights. See you there! John Gilmore

1 0

meeting on 20th
by anonymous＠wmono.remailer 17 Dec '03

17 Dec '03

could someone that goes make a transcript of the hearing??? like to hear it but too far away!! 10x.

1 0

Re: NetScape's dependence upon RSA down for the count!
by jbass＠dmsd.com 17 Dec '03

17 Dec '03

> The point to attacking SSL is to be able to decode a message from any > browser, without having to do anything extraordinary to the victim's host. > No cryptosystem is proof against an attacker who can see and > control everything you do on the client side (i.e. has root in UNIX > parlance). > > So, while your idea #1 might be interesting or fun to do as far as computer > security goes, it's not an attack on SSL. Agreed, within limits. Security as "Marketed" by NetScape goes far past just claiming SSL to be secure, including the use of NetScape client and servers as secure. With this expanded model, attacking NetScapes claim of security includes attacking the process and enviornment that they provide to endusers and info mall businesses. In this case electronicaly distributing clients in a hostile environment is a gross disregard for endusers security needs, traded off for ease of distribution. I probably should not have included virus attacks, and just focused upon the main problem ... unsecured network transmission of clients. As it stands, a third party with minimal trouble can compromise a very large number of NetScape clients and capture the dredit card data for those users who would otherwise expect their transactions to be secure. To take the ground that their product is secure in a secure environment is meaningless ... the product value they seem to offer is security in a non-secure environment - which I don't think is true, and I gather you might agree? > That points out the flaw in Netscape's authentication model that > others have already pointed out on this list. Admittedly, like Don > Stephenson just posted, there's not really a good way to distribute > and authenticate certificates until there's a ubiquitous global > CA chain. Again, we agree that this reflect negatively on NetScapes claims of security in an unsecure environment? As an aside, readers in private have suggested that a signature by Verilog as the CA my not be required, quoting that until receintly, NetScape signed their own certificates. This seems that the MITM can choose his own CA, possibly of his own design to sign false certificates. > Assume that the attacker Mallet is in the middle and has control of the http > stream. Alice clicks on 'open Widget order form' to order a Widget > and Mallet sends her browser a redirect pointing to his evil web server. > Alice doesn't notice that the hostname in the url has changed, or > if she does, she figures that the catalog people have arranged to > have Mallet's server host their 'secure' transactions (not an unreasonable > assumption). Mallet takes the order and pockets the money. > The hostname in the certificate (Mallet's) matches the hostname > in the URL (also Mallet's). Or Mallet places the order in Alice's name defering the chances of detection until enough cards numbers are aquired to make a run on the bank. There is tremendous value in forstalling the point of detection and the location of the MITM becoming known. If Alice get's her goods promptly she is much less likely to question the transaction. > Of course this isn't really an attack on SSL per se. It's an attack on > the certificate-granting policy- the CA gave a certificate to > an unscrupulous person (Mallet). But it is a clear attack on NetScape's advertised "security" for end users. Almost all sucessfull crooks/thieves have a front business to launder their money thru. In this case you can steal customers just by redirecting your competitor's DNS records to your server ... With a similar home page and ordering/catalog screens they might never notice the switch, certainly not first time customers. Gee nobody would probably own up to the occasional named failures that could also cause this. Somehow I don't think this is what endusers of info mall owners consider security. > > > Well of course, if the secret key of the server (or worse yet, certificate > > > authority) is compromised, all bets are off. That's true of just about any > > > protocol you can dream up. > > > > I'm not referring to the secret key of _the_ server; I'm referring to the > > secret key of _ANY_ server. In the limiting case, such a key can be > > obtained by buying one from the CA. > > Right. That's what I pointed out in an earlier message, although I > didn't elaborate on it. The security of Netscape browsers depends > on Verisign's policy in handing out server certificates. and on the physical security of the site plus it's network connections, the trustworthyness of it's internal staff and contractors, and it's ability to deliver service in the face of failures and disasters, both man made and natural. Security includes more than just crypto correctness, in this case it include denial of service attacks as well has physical site attacks. In this case I strongly suspect that bombing Verilog would shutdown net commerce for a while. Certainly it's employees are in a position to earn high six figures for the key algorithm or a copy of the key database. As for the policy, it has to include mom & pops and young business owners setting out to make their honest fortune on the net ... unfortunately this profile includes the evil side as well. I don't think restricting info mall business to the fortune 500 is that we have in mind here. As such, I don't think screening by the CA takes us very far at all. > Backing up for a minute, the same problem holds for those neeto > credit-card readers that Visa and MasterCharge give out to merchants. > The merchant can be a crook setting up a 'store-front' operation to charge > to bogus/stolen card numbers, or the employees can steal using the numbers > they get in the corse of doing business, etc. There are already > procedures in place for dealing with this sort of crime. I'm not > sure that tricking Verisign into giving out a certificate to a group > of crackers is really any different than tricking Visa into giving > a card reader to a group of theives. Volume greatly affect the risk factor. Giving a merchant number to a business means that only the number of people that can walk-in or phone in to that merchants store are at risk. Stolen cards are handled differently than stolen numbers. Stolen numbers are cross correlated by past purchase locations by store, and if possible by register location and employee. There is a strong pointer to the person(s) involved. Skimming card numbers off the net has the potential to cross vendors, geographic areas, and other determinates that would aid in locating the source of the tap. The number of card numbers exposed has the potential to be several orders of magnitude higher, and remain undetected for quite some time. The net offers the ability to place a large number of orders in a short period of time for very high valued merchandice for delivery to what would appear proper customers ... and using the UPS/FedX example picking off the proceeds in a centralized low security location. With another computer store front on the net, you turn the same hijacked goods into full value shipments in a few days ... and maybe coordinate the bogus orders and hijackings to meet your customers demands. Or for an economic terrorist create $100 million in bogus orders and deliveries to drive the system into failure. Gone are the days when sheer man-power limited your exposure. Gone are the days when a sturdy building, good doors and locks, and a security system backed by Well Fargo staff would protect your business. Security in our network context includes not only the protection of the individual consumer, but the info mall vendors and the future of the medium as a viable way to do business. NetScape I believe is working toward all three of these goals, I strongly disagree with the short cuts and risks they are taking to get there. John Bass

8 8

NYT: WWW Usage Monitoring for Marketing
by futplex＠pseudonym.com 17 Dec '03

17 Dec '03

New York Times, National Edition, 95/10/03: A positive sign in the marketing/privacy war on the net: In his regular Advertising column, Stuart Elliott discusses the presentation of a report on the problem of "assuring accurate and comprehensive measurement of consumer exposure to advertisements that appear in interactive media like World Wide Web sites and on-line services." The report was issued by "Casie", the Coalition for Advertising Supported Information and Entertainment, a creation of two main advertising trade groups: the American Assn. of Advertising Agencies, and the Assn. of Nat'l. Advertisers. Elliott's article identifies three main issues covered in the report. One of these is privacy: "Every effort should be made to maintain consumers' privacy," the report urges, adding that identities of computer users "must not be revealed by audience measurement providers." -Futplex <futplex(a)pseudonym.com> If you haven't seen the film "Twelve Angry Men", it's about time you did.

1 0