From owner-freebsd-security Tue Apr 18 15:21:28 1995 Return-Path: security-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id PAA21044 for security-outgoing; Tue, 18 Apr 1995 15:21:28 -0700 Received: from grendel.csc.smith.edu (grendel.csc.smith.edu [131.229.222.23]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id PAA20992 ; Tue, 18 Apr 1995 15:19:28 -0700 Received: from localhost (jfieber@localhost) by grendel.csc.smith.edu (8.6.5/8.6.5) id SAA23561; Tue, 18 Apr 1995 18:20:21 -0400 From: jfieber@cs.smith.edu (John Fieber) Message-Id: <199504182220.SAA23561@grendel.csc.smith.edu> Subject: Re: httpd - security problem? (question, not a statement) To: nc@ain.charm.net (Network Coordinator) Date: Tue, 18 Apr 1995 18:20:20 -0400 (EDT) Cc: freebsd-security@FreeBSD.org, freebsd-questions@FreeBSD.org In-Reply-To: from "Network Coordinator" at Apr 12, 95 07:18:43 pm Content-Type: text Content-Length: 701 Sender: security-owner@FreeBSD.org Precedence: bulk Network Coordinator writes: > I remember reading somewhere that there is a bug in a number of port 80 > daemons that would allow someone to gain root access remotely through it. > I know there is a bug when using httpd with Satan v1.0 (well, for as much > as a I trust CERT), but when not running Satan, is there any harm in > letting cern_httpd v3.0 run in standalone (full-time) mode [as root, no > less]. There was a bug in the NCSA http server which has since been fixed. I'm not currently aware of any problems with the CERN server. -john === jfieber@cs.smith.edu ================================================ =================================== Come up and be a kite! --K. Bush === From owner-freebsd-security Tue Apr 18 20:57:40 1995 Return-Path: security-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id UAA04515 for security-outgoing; Tue, 18 Apr 1995 20:57:40 -0700 Received: from arthur.cs.purdue.edu (root@arthur.cs.purdue.edu [128.10.2.1]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id UAA04509 ; Tue, 18 Apr 1995 20:57:39 -0700 Received: from moriarty.cs.purdue.edu (root@moriarty.cs.purdue.edu [128.10.2.69]) by arthur.cs.purdue.edu (8.6.10/PURDUE_CS-1.3) with ESMTP id ; Tue, 18 Apr 1995 22:57:33 -0500 Received: from localhost (wam@localhost [127.0.0.1]) by moriarty.cs.purdue.edu (8.6.10/PURDUE_CS-1.3) with SMTP id ; Tue, 18 Apr 1995 22:57:32 -0500 Message-Id: <199504190357.WAA09930@moriarty.cs.purdue.edu> To: jfieber@cs.smith.edu (John Fieber) cc: nc@ain.charm.net (Network Coordinator), freebsd-security@FreeBSD.org, freebsd-questions@FreeBSD.org Subject: Re: httpd - security problem? (question, not a statement) Date: Tue, 18 Apr 1995 22:57:31 -0500 From: wam@cs.purdue.edu (William McVey) Sender: security-owner@FreeBSD.org Precedence: bulk John Fieber wrote: >There was a bug in the NCSA http server which has since been >fixed. I'm not currently aware of any problems with the CERN >server. Actually, the one "hole" that an exploit script was written for (and published) was fixed. The NCSA http server still has lots of sloppy code that are indicate security problems. (ie, lots of strcpy as opposed to strncpy, sprintf's into fixed buffers with no range checking, etc.) I've appended a copy of a mail message posted to bugtraq that details just one of the other vulnerabilities. There are others, I'm sure. -- William McVey System Support Staff Computer Science Department Purdue University ----- Begin included message (copied without permission) ----- From: Paul Phillips Date: Tue, 11 Apr 1995 20:59:05 -0700 Message-Id: <199504120359.UAA03182@nic.cerf.net> Newsgroups: comp.infosystems.www.providers,comp.security.unix Subject: Still security holes in NCSA httpd 1.3R Keywords: security httpd www Cc: bugtraq@fc.net, www-security@ns1.rutgers.edu Precedence: bulk NCSA has been claiming at that their patch to httpd, which fixed the hole in strsubfirst, was sufficient to fix the stack overflow bug discovered by Thomas Lopatic. This is incorrect. There is at least one more instance of the same problem, this one in log_reason. NCSA has provided a performance reason not to #define MAX_STRING_LEN to HUGE_STRING_LEN (i.e. you will enter swap hell) and they are correct about that, but unfortunately that doesn't magically make the hole go away. >>> begin code traversal >>> When accept is handed some data, httpd.c calls process_request in http_request.c: 213: process_request(0,stdout); process_request allocates url[HUGE_STRING_LEN] for parsing out the URL. It calls getline in util.c to obtain the info from the socket: 104: if(getline(l,HUGE_STRING_LEN,in,timeout)) process_request now decides what the method is, and calls the relevant function. Take GET for example: it calls process_get in http_get.c with the url as an argument: 143: process_get(in,out,m,url,args); Let's say it's a standard document, so process_get calls send_node with the url as an argument (still possibly HUGE_STRING_LEN long) 195: send_node(url,args,in,out); Now send_node does various checks. Let's say the file does not exist: send_node wants to log it, here: 122: log_reason("file does not exist",file); where file is the passed url, still possible 8192 characters. log_reason is in http_log.c, and quite short: void log_reason(char *reason, char *file) { char t[MAX_STRING_LEN]; sprintf(t,"httpd: access to %s failed for %s, reason: %s", file,remote_name,reason); log_error(t); } The file can be 8192 characters, but it's sprintfed into a 256 character buffer. >>> end code traversal >>> This particular traversal is just an example, log_reason is called from several places with overlarge buffers. I pointed this out to the httpd people at NCSA, who promised a patch but haven't acted with much alacrity. Frankly I am very skeptical that any patch will fix all holes until I finish checking out all the code. When 1.4 is released to the public I will examine it in depth as soon as possible. Regards, -- Paul Phillips paulp@cerf.net ----- Begin included message ----- From owner-freebsd-security Wed Apr 19 13:15:58 1995 Return-Path: security-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id NAA27741 for security-outgoing; Wed, 19 Apr 1995 13:15:58 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id NAA27732 ; Wed, 19 Apr 1995 13:15:50 -0700 Received: by sequent.kiae.su id AA00787 (5.65.kiae-2 ); Wed, 19 Apr 1995 23:51:47 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Wed, 19 Apr 95 23:51:47 +0400 Received: (from ache@localhost) by astral.msk.su (8.6.8/8.6.6) id XAA01528; Wed, 19 Apr 1995 23:49:25 +0400 To: arch@FreeBSD.org, core@FreeBSD.org, security@FreeBSD.org Message-Id: Organization: Olahm Ha-Yetzirah Date: Wed, 19 Apr 1995 23:49:25 +0400 X-Mailer: Mail/@ [v2.32 FreeBSD] From: "Andrey A. Chernov, Black Mage" X-Class: Fast Subject: Call for remove setr[ug]id() and setre[ug]id() from libc Lines: 21 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1028 Sender: security-owner@FreeBSD.org Precedence: bulk Those fuctions never sets real [ug]id which strongly confuse programs which expect it to do. I.e. most autoconf scripts find them into library and suppose them to work. Moreover under some circumstanes they even return 0 instead of -1, i.e. mimics to working right. There is more backdoors: saved[ug]id = get[ug]id() is static variable which is set on first call to setre[ug]id(). It is very depends _where_ you call it for first time. All this problems give us potential security hole in case f.e. when real id == root, it is never changed to user id with this functions, but program assume it done. I vote for removing this fuctions completely from library sources, it is only one safe variant, if we can't implement them in 100%. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-security Wed Apr 19 15:03:59 1995 Return-Path: security-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id PAA00845 for security-outgoing; Wed, 19 Apr 1995 15:03:59 -0700 Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id PAA00829 ; Wed, 19 Apr 1995 15:03:49 -0700 Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id AAA07905 ; Thu, 20 Apr 1995 00:03:40 +0200 Received: from (roberto@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) id AAA29578 ; Thu, 20 Apr 1995 00:03:39 +0200 From: roberto@blaise.ibp.fr (Ollivier Robert) Message-Id: <199504192203.AAA29578@blaise.ibp.fr> Subject: Re: Call for remove setr[ug]id() and setre[ug]id() from libc To: ache@astral.msk.su (Andrey A. Chernov, Black Mage) Date: Thu, 20 Apr 1995 00:03:39 +0200 (MET DST) Cc: arch@FreeBSD.org, core@FreeBSD.org, security@FreeBSD.org In-Reply-To: from "Andrey A. Chernov, Black Mage" at Apr 19, 95 11:49:25 pm X-Operating-System: FreeBSD 2.0.950416-SNAP ctm#562 X-Mailer: ELM [version 2.4 PL23beta2] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 989 Sender: security-owner@FreeBSD.org Precedence: bulk > Those fuctions never sets real [ug]id which strongly confuse > programs which expect it to do. I.e. most autoconf scripts > find them into library and suppose them to work. > Moreover under some circumstanes they even return 0 instead > of -1, i.e. mimics to working right. There is more backdoors: > saved[ug]id = get[ug]id() is static variable which is > set on first call to setre[ug]id(). It is very depends _where_ > you call it for first time. We should implement them correctly in order to achieve POSIX saved uids compatibility and compatibility with the rest of UNIX... More, if you remove them from libc we should bump the *major* version number of libc... > I vote for removing this fuctions completely from library > sources, it is only one safe variant, if we can't implement > them in 100%. I think we can make them work. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@FreeBSD.ORG FreeBSD keltia 2.0.950416-SNAP #17: Sun Apr 16 17:12:07 MET DST 1995 From owner-freebsd-security Thu Apr 20 10:48:54 1995 Return-Path: security-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA03417 for security-outgoing; Thu, 20 Apr 1995 10:48:54 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id KAA03410 ; Thu, 20 Apr 1995 10:48:40 -0700 Received: by sequent.kiae.su id AA14178 (5.65.kiae-2 ); Thu, 20 Apr 1995 21:45:46 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Thu, 20 Apr 95 21:45:44 +0400 Received: (from ache@localhost) by astral.msk.su (8.6.8/8.6.6) id VAA02695; Thu, 20 Apr 1995 21:20:36 +0400 To: arch@FreeBSD.org, core@FreeBSD.org, security@FreeBSD.org References: In-Reply-To: ; from "Andrey A. Chernov" at Wed, 19 Apr 1995 23:49:25 +0400 Message-Id: Organization: Olahm Ha-Yetzirah Date: Thu, 20 Apr 1995 21:20:35 +0400 X-Mailer: Mail/@ [v2.32 FreeBSD] From: "Andrey A. Chernov, Black Mage" X-Class: Fast Subject: Re: Call for remove setr[ug]id() and setre[ug]id() from libc Lines: 20 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 839 Sender: security-owner@FreeBSD.org Precedence: bulk In message Andrey A. Chernov writes: >I vote for removing this fuctions completely from library >sources, it is only one safe variant, if we can't implement >them in 100%. More info: osetreuid/osetregid syscalls check arguments in the same way that lib function does, and they are only a little bit safe, because testing of s[rg]id independs of place calling. They both can't be implemented, they are violation of POSIX, so I prefer to remove them to not make security hole. If none object, I'll commit the change. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-security Fri Apr 21 00:47:08 1995 Return-Path: security-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id AAA02665 for security-outgoing; Fri, 21 Apr 1995 00:47:08 -0700 Received: from mail1.digital.com (mail1.digital.com [204.123.2.50]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id AAA02659 for ; Fri, 21 Apr 1995 00:47:06 -0700 Received: from muffit.reo.dec.com by mail1.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA04491; Fri, 21 Apr 1995 00:44:51 -0700 Received: by muffit.reo.dec.com (5.65/helenc-6Apr93); id AA22703; Fri, 21 Apr 1995 08:46:57 +0100 From: erandall@muffit.reo.dec.com (Ed Randall) Message-Id: <9504210746.AA22703@muffit.reo.dec.com> Subject: Re: Call for remove setr[ug]id() and setre[ug]id() from libc To: freebsd-security@FreeBSD.org Date: Fri, 21 Apr 95 8:46:57 WET DST In-Reply-To: ; from "Andrey A. Chernov, Black Mage" at Apr 20, 95 9:20 pm X-Mailer: ELM [version 2.3 PL11] Sender: security-owner@FreeBSD.org Precedence: bulk Andrey A. Chernov, Black Mage writes: > > In message Andrey A. Chernov writes: > > >I vote for removing this fuctions completely from library > >sources, it is only one safe variant, if we can't implement > >them in 100%. > > More info: > osetreuid/osetregid syscalls check arguments in the same > way that lib function does, and they are only a little bit safe, > because testing of s[rg]id independs of place calling. > > They both can't be implemented, they are violation of POSIX, > so I prefer to remove them to not make security hole. > If none object, I'll commit the change. Hi, Exactly which functions are you planning to remove : setruid setreuid setrgid setregid osetreuid osetregid and from where ? Please be aware that if you simply remove something, you will most likely prevent various (unknown) applications from compiling. Wouldn't it be better to FIX these functions to match the POSIX standard, and patch up the security holes ? POSIX compliance has surely to be the goal, and removing any POSIX functions altogether will miss the target as surely as if the functions are broken. Regards, Ed Randall ---- ---------------------------------------------------------------------- Ed Randall Digital Equipment Co.Ltd., Worton Grange, Reading DECnet : RDGENG::RANDALL Internet : erandall@muffit.reo.dec.com ---------------------------------------------------------------------- From owner-freebsd-security Fri Apr 21 02:35:35 1995 Return-Path: security-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id CAA04720 for security-outgoing; Fri, 21 Apr 1995 02:35:35 -0700 Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id CAA04714 for ; Fri, 21 Apr 1995 02:35:20 -0700 Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id LAA24790 ; Fri, 21 Apr 1995 11:34:33 +0200 Received: from (roberto@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) id LAA10116 ; Fri, 21 Apr 1995 11:34:33 +0200 From: roberto@blaise.ibp.fr (Ollivier Robert) Message-Id: <199504210934.LAA10116@blaise.ibp.fr> Subject: Re: Call for remove setr[ug]id() and setre[ug]id() from libc To: erandall@muffit.reo.dec.com (Ed Randall) Date: Fri, 21 Apr 1995 11:34:32 +0200 (MET DST) Cc: freebsd-security@FreeBSD.org In-Reply-To: <9504210746.AA22703@muffit.reo.dec.com> from "Ed Randall" at Apr 21, 95 08:46:57 am X-Operating-System: FreeBSD 2.0.950416-SNAP ctm#562 X-Mailer: ELM [version 2.4 PL23beta2] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 884 Sender: security-owner@FreeBSD.org Precedence: bulk > Please be aware that if you simply remove something, you will most likely > prevent various (unknown) applications from compiling. My precedent message doesn't seem to have gone through : if we remove something from the library, it will be an interface change and we would have to bump the *major* library version # to 3 ! Bad thing just before a release. > Wouldn't it be better to FIX these functions to match the POSIX standard, and > patch up the security holes ? POSIX compliance has surely to be the goal, and > removing any POSIX functions altogether will miss the target as surely as if > the functions are broken. Yes this is the way to go. We need working setruid and friends and proper POSIX saved uids implementation. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@FreeBSD.ORG FreeBSD keltia 2.0.950416-SNAP #17: Sun Apr 16 17:12:07 MET DST 1995 From owner-freebsd-security Fri Apr 21 07:37:19 1995 Return-Path: security-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id HAA08528 for security-outgoing; Fri, 21 Apr 1995 07:37:19 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id HAA08505 for ; Fri, 21 Apr 1995 07:36:46 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id AAA23449; Sat, 22 Apr 1995 00:31:34 +1000 Date: Sat, 22 Apr 1995 00:31:34 +1000 From: Bruce Evans Message-Id: <199504211431.AAA23449@godzilla.zeta.org.au> To: erandall@muffit.reo.dec.com, freebsd-security@FreeBSD.org Subject: Re: Call for remove setr[ug]id() and setre[ug]id() from libc Sender: security-owner@FreeBSD.org Precedence: bulk >Exactly which functions are you planning to remove : >and from where ? setruid remove (library) setreuid remove (library) setrgid remove (library) setregid remove (library) osetreuid ? (syscall) osetregid ? (syscall) seteuid keep? (syscall) setegid keep? (syscall) >Please be aware that if you simply remove something, you will most likely >prevent various (unknown) applications from compiling. This is really the point. If the applications expect 4.3BSD semantics then they may not work right with 4.4BSD semantics. They need to be checked for new security holes, and the compatibility functions can easily be replaced as part of the checking. >Wouldn't it be better to FIX these functions to match the POSIX standard, and >patch up the security holes ? POSIX compliance has surely to be the goal, and >removing any POSIX functions altogether will miss the target as surely as if >the functions are broken. All of these functions are outside the POSIX standard. Bruce From owner-freebsd-security Fri Apr 21 08:52:31 1995 Return-Path: security-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id IAA09995 for security-outgoing; Fri, 21 Apr 1995 08:52:31 -0700 Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id IAA09988 for ; Fri, 21 Apr 1995 08:52:25 -0700 Received: by halloran-eldar.lcs.mit.edu; id AA06954; Fri, 21 Apr 1995 11:49:42 -0400 Date: Fri, 21 Apr 1995 11:49:42 -0400 From: Garrett Wollman Message-Id: <9504211549.AA06954@halloran-eldar.lcs.mit.edu> To: erandall@muffit.reo.dec.com (Ed Randall) Cc: freebsd-security@FreeBSD.org Subject: Re: Call for remove setr[ug]id() and setre[ug]id() from libc In-Reply-To: <9504210746.AA22703@muffit.reo.dec.com> References: <9504210746.AA22703@muffit.reo.dec.com> Sender: security-owner@FreeBSD.org Precedence: bulk < Wouldn't it be better to FIX these functions to match the POSIX standard, and > patch up the security holes ? The POSIX standard specifies set[ug]id() AND NOTHING ELSE. Do you really want strict POSIX behavior? I didn't think so... -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-security Fri Apr 21 15:15:06 1995 Return-Path: security-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id PAA22304 for security-outgoing; Fri, 21 Apr 1995 15:15:06 -0700 Received: from localhost (localhost [127.0.0.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id PAA22291 for ; Fri, 21 Apr 1995 15:15:04 -0700 X-Authentication-Warning: freefall.cdrom.com: Host localhost didn't use HELO protocol Prev-Resent: Fri, 21 Apr 1995 15:15:03 -0700 Prev-Resent: "security " Received: from orion ([158.9.11.65]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id HAA08118 for ; Fri, 21 Apr 1995 07:21:44 -0700 Message-Id: <199504211421.HAA08118@freefall.cdrom.com> Received: by orion (1.37.109.16/16.2) id AA115984098; Fri, 21 Apr 1995 10:21:38 -0400 From: william pechter ILEX Subject: Telnet To: jkh@freefall.cdrom.com Date: Fri, 21 Apr 1995 10:21:38 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 18979 Resent-To: security@freefall.cdrom.com Resent-Date: Fri, 21 Apr 1995 15:15:04 -0700 Resent-Message-ID: <22289.798502504@freefall.cdrom.com> Resent-From: "Jordan K. Hubbard" Sender: security-owner@FreeBSD.org Precedence: bulk >From firewalls-owner@GreatCircle.COM Thu Apr 20 19:46:08 1995 >From: David Vincenzetti >Subject: STEL: Secure TELnet -- Call for Beta Testers To: firewalls@greatcircle.com Date: Tue, 18 Apr 1995 16:34:39 +0200 (METDST) X-Organization: Department of Computer Science, University of Milan, ITALY X-Name: David Vincenzetti X-Phone: +39 2 55006 391 X-Fax: +39 2 55006 394 X-Private: +39 2 7530600 X-Pgp-Key-Fingerprint: BC 78 16 B2 07 CC BF 26 8D B8 5D FA 1A A4 65 63 X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 17837 Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Jordan -- My wife forwarded this to me: I know you were looking for an encrypting telnet. Thanks again for all you're doing on FreeBSD. Even though my machine's not among the stable it IS APPRECIATED. Bill ******************************************* STEL (SECURE TELNET): CALL FOR BETA TESTERS ******************************************* 1. WHY CALLING BETA TESTERS? We, as CERT-IT, have developed STEL (Secure TELnet), a new freeware tool which is intended as a secure telnet program. We hope to present stel at the 5th USENIX Security Symposium (Salt Lake City, Utah, June 5-7 1995). Before releasing stel to the public we want to be sure that it is reasonably correct and bug free. So, we are looking for a limited number of beta testers. 2. MORE INFORMATION ABOUT STEL? Stel is a small and compact tool able to provide encryption and authentication using a variety of methods and algorithms. More details are given below (please see ``INTRODUCTION''). 3. IS STEL AVAILABLE? YES, it is available. But is it still undocumented and unsupported, so it is now available to beta testers ONLY. 4. WHERE HAS STEL BEEN PORTED TO? Stel has already been ported to the following platforms: HPUX 9.x Sunos 4.1.3x Solaris 2.4 Irix 4.0.x Linux 1.5.x We would be higly interested in seeing stel ported to other platforms as well! 4. HOW TO BECOME A STEL BETA TESTER? We are looking for a limited number of beta testers, whose skills and experience should be as follows: o good experience with Unix and TCP/IP o some expertise in C/Unix programming (having developed C/Unix network tools is considered as a BIG bonus). o experience with system and network administration o good experience with some of the most popular crypto related protocols and tools such as S/Key, Crack, Tripwire, SRA, PGP, PEM et cetera. Please let us know if you have any experience with other similar tools. o knowledge of the basic weaknesses / strenghts about DES, IDEA, RSA, DH, EKE is considered as a bonus. o experience with firewalls, IP packet filtering, strong authentication tecniques, proxies and gateways is considered as a bonus. If you think that you have the required skills please send email to: stel-beta-test@dsi.unimi.it Please be sure to send us a very brief resume (not more than 10 lines) about your skills and experiences. In particular, we are interested in knowing about your PRACTICAL experiences in security, networking, cryptography and incident handling. Being a member of the FIRST (Forum of Incident Response Security Teams) is considered as a bonus. STEL: Secure TELnet David Vincenzetti Stefano Taino Fabio Bolognesi {vince | taino | bolo}@dsi.unimi.it CERT-IT Computer Emergency Response Team ITaliano Department of Computer Science University of Milan ITALY INTRODUCTION Stel stands for Secure TELnet. We started developing Stel, at the University of Milan, when we realized that eavesdropping was a very serious problem and we did not like the freeware solutions that were available at that time. It was about three years ago. Still, as far as we know, there are no really satisfying packages able to solve the line active and passing tapping problem, and to be simple enough to use and to maintain by the average system administrator. In fact, in our honest opinion, we believe that the actual security packages available on the Internet suffer from at least one of the following drawbacks: - Not secure enough - Too large and complicated to install - Too complex to use and maintain - Unable to scale well in a distributed environment - Subject to severe export regulations, so not suitable for users outside the United States Stel is a simple package, and it is intended to act as a ``secure surrogate replacement'' for telnetd, rlogind, rcmd or rshd. [...] Stel is able to provide secure communications between the client and the server, and supports different authentications methods, in order to be as simple, flexible and convenient as possibile. Stel has several advantages in respect to other systems: - It is very simple to install, use and maintain. There are very few configuration files and two executables only - All data transmissions, any kind, are sent encrypted with a ``random'' session key - There are three encryption algorithms available: DES, Triple DES and IDEA - The method uses the Diffie Hellman algorithm to exchange session keys, and the DH modulus is reasonably sized compared with other packages (see [4]) - Since the Diffie Hellman system is vulnerable to ``Man In The Middle'' attacks, the protocol has been strenghtened in order to make such an attack unfeasible (as described in [1]) - The method is able to provide mutual authentication - The method is reasonably fast (it adds about a couple of seconds to a connection on a Sparcstation II class machine) - Upon establishing a secure channel, a variety of authentication methods are available: standard Unix passwords, S/Key and SecurID. Even standard Unix passwords, being the communication channel encrypted, provide a reasonable level of security in respect to telnet and rlogin - An optional skey daemon is included in the package. Skeyd makes it possible to centralize skey passwords in order to administer passwords in a single point - It is possible to control logins by checking IP address, authentication type, terminal name, user name, as described in [2] - Automatic killing of IP-OPTIONS is an option - A built-in skey calculator is included in the escape (^]) menu. As a feature, skey can make use of a keypad file to make dictionary attacks unfeasible, an idea described in [3] - The software is freeware, and sources are freely available PRACTICAL EXAMPLES Stel is client / server based. The client is named ``stel'', and it is intended to be directly run by users; the server is named ``steld'' and can be run as a standalone daemon by the superuser or be invoked by inetd. The purpose of stel is to provide the user a remote terminal session, very similar to a telnet or rlogin remote terminal session. The difference is, of course, that all the traffic between client and server is encrypted and that the resulting authentication is much stronger in respect to telnet or rlogin. In the following example the user connects with stel to idea.sec.dsi.unimi.it as root. The authentication is performed using SecurID smart card, being root a registered SecurID user on idea. $ stel idea.sec.dsi.unimi.it -l root Connected to idea.sec.dsi.unimi.it. This session is using DES encryption for all data transmissions. Escape character is '^]'. SECURID authentication required Enter PASSCODE for root: Passcode accepted. ****************** Welcome to idea! ****************** idea# hostname idea idea# date Fri Feb 10 17:33:27 MET 1995 idea# exit Connection with idea.sec.dsi.unimi.it closed. $ $ So, the user has stel-connected to idea.sec.dsi.unimi.it and he/she has authenticated his/herself using SecurID. All data transmission are DES (optionally 3DES or IDEA) encrypted with a session key that is generated with the DH algorithm. When the user is authenticated he/she is provided with a very comprehensive set of environment variables that are inherited from the client, and all the terminal settings are inherited from the client as well. For instance, since the DISPLAY, LINES and COLUMNS environment variables are inherited in the remote session, it is possible to remotely execute commands like these: $ stel bar xterm -fn 10x20 -bg black -fg white $ stel foo -l root vi /etc/rc $ stel somesite -l joe "ps aux > /tmp/xx; vi /tmp/xx" In the following example the user ``verbosely'' connects to ghost as vince and specifies /bin/csh as the command to be executed. The authentication is performed using S/Key. $ $ stel ghost -l vince -v /bin/csh Connected to ghost on port 10004. Diffie-Hellman modulo is 512 bits, secret exponent is 510 bits Exchanging keys with DH scheme (can be a lengthy process)... Shared encryption key: CAA90477A9CEA71D This session is using DES encryption for all data transmissions. Escape character is '^]'. S/KEY authentication required [s/key 93 cr520201] Response: drub barb nod ret coco outs SunOS Release 4.1.3_U1 (GENERIC) #1: Wed Oct 13 17:48:35 PDT 1993 1 @ghost ~ > hostname ghost 2 @ghost ~ > exit Connection with ghost closed. $ $ $ In the last example, the user connects to idea again, and makes use of some features in the escape menu. In particular, he/she takes advantage of the built-int skey calculator to locally (and thus safely) generate the required skey response. $ stel idea Connected to idea. This session is using DES encryption for all data transmissions. Escape character is '^]'. S/KEY authentication required [s/key 92 cr520201] Response: stel> ? Commands may be abbreviated. Commands are: close close current connection skey generate skey response status display operating parameters escape set escape character ! shell escape z suspend telnet ? print help information stel> stat Connected to idea. Connection time: Fri Feb 10 19:07:42 1995 Elapsed time: 0 hours, 0 minutes, 47 seconds User keystrokes: 1 Session output is 62 bytes Escape character is '^]' DES data encryption is on stel> skey Reminder - Do not use this while logged in via telnet or dial-in. Enter seed: cr520201 enter sequence number: 92 enter secret password: use mjr DES mode [n] ? y CORD AD FLY FEAR NAY ARAB stel> CORD AD FLY FEAR NAY ARAB ****************** Welcome to idea! ****************** idea% date Fri Feb 10 19:11:16 MET 1995 idea% hostname idea idea% idea% exit Connection with idea closed. $ THE PROTOCOL The protocol can be divided in different modules: 1. Key exchange Stel uses the Diffie Hellman exponential based method to determine a common DES (or 3DES, IDEA) key. This completely eliminates the need of keyservers to store and manage user keys, and it greatly simplifies the overall system design. The principles of the method are shown in figure 1. Initially, client and server, whom we call X and Y being the system symmetric, share a large prime number, P, and a generator, that is 3. Then both parties choose a secret value, making the choice at random among the set of values in modulo P arithmetic. The length of the modulo can be 512 or 1024 bits. Moduli whose length is 192 bits (see [4]), or, in general, smaller than 512 bits, are not secure. In the next stage, X and Y form the exponentials 3**x and 3**y respectively, and they exchange the exponentials. A malicious hacker could intercept 3**x and 3**y by reading the network but, due the difficulty of computing logarithms in finite fields (see [1], [4]), he/she can not calculate the x, y values. In the final stage, X and Y compute a further exponential. In the case of X the received value 3**y is raised to the power x. In the case of Y, the received value 3**x is raised to the power y. As a consequence, both partecipants now share the same secret, thus a session key is generated by digesting the shared value through MD5. |-----------|-------------|---------------|--------------| | | Known to X | Public | Known to Y | | | | | | |-----------|-------------|---------------|--------------| | Initially | x | 3, P | y | | | | | | |-----------|-------------|---------------|--------------| | Exchange | 3**x ------->------->------> 3**x | | | | | | | | 3**y <------<-------<------- 3**y | | | | | | | | | 3**x, 3**y | | |-----------|-------------|---------------|--------------| | Calculate | (3**y)**x | | (3**x)**y | |-----------|-------------|---------------|--------------| Figure 1. 2. Mutual authentication The basic DH method is very clever, but it provides no authentication between the two parties. A malicious hacker Z using an active line tap could intercept and change all messages, impersonating X to Y and Y to X. X and Y would not realize that; for example, all messages sent by X to Y would be received by Z, the Man In The Middle, decrypted by Z using X's session key, encrypted again using Y's session key and sent to Y. X and Y would share different session keys, yet not realizing that because they have exchanged no information before key exchange. This is why we added a further step to the protocol in order to make this attack ineffective. If the user wishing to login on the remote system owns a file named ``.stelsecret'' in his/her remote home directory then the information K contained in the file is exploited to perform mutual authentication between the parties. This is an idea by Shamir and Rivest (see [1]). X and Y construct authenticators AX and AY respectively. Let AX be equal to E_K(X's session key) that is, X's session key DES encrypted using K as encryption key. Let AY be equal to E_K(E_K(Y's session key)), that is, Y's session key encrypted twice using K as encryption key. In case Z is actively tapping the communication line, the sessions keys used by the parties are different. What is more, Z does not know K. The goal of this authentication step is, in fact, to verify that the sessions keys are the same at both sides. AX and AY are divided in two halves. Let AX be equal to AX1 followed by AX2 and AY be equal to AY1 followed by AY2. The exchange is by alternating messages: X sends its first half AX1, Y replies with AY1, then X sends AX2 and Y sends AY2. It is not possible for Z to translate AX1, knowing only half of the cipher block, yet Y will not reply until he/she receives something, so Z is forced to concoct a value AX in order to receive AY. Y's reply cannot be traslated by Z and passed on at the correct time to X, since Z only receives one half of AY at a time. After the exchange is complete X and Y can decrypt the authenticators AY and AX respectively and find out if they are really sharing the same session key. If not, they are being impersonated by Z. 3. Encryption All data transmitted from the client to the server and vice versa is encrypted using the specified encryption algorithm. The default algorithm is single DES, since it is faster, but triple DES and IDEA are available as well. DES is used in CBC mode when transmitting environment variables or exchanging ``large numbers'' in the DH scheme. CFB mode is used when making terminal I/O between client and server. A ``random'' Initialization Variable is used, and the source of randomness is, optionally, a garbage random string which the user is required to type in. 4. Environment settings A pseudo terminal is usually allocated by the server and attached to the remote process; it is possible, however, to specify that no pseudo terminal should be used in the remote session, a la rshd. Terminal settings are transmitted encrypted from the client to the server, so it is not usually needed to ``stty'' parameters at all. [...] 5. User authentication It has been said already that there are three authentication methods available. These methods can be listed according to their security, in decreasing order: 1. SecurID 2. S/Key 3. Unix passwords [...] An optional skey daemon has been introduced, to administer all skey passwords on a single host. We consider the unability to centralize skey passwords as a major need in the skey system. Skeyd severely simplifies skey passwords management, since passwords are stored in a single file and thus the passwords synchronization problem is solved. Data transmission between skey clients and the skey server is DES-CBC encrypted. The encryption key is stored in /etc/skeydconf, for all the clients and the server (this is an approach common to other security systems, i.e., Kerberos's kdb5_stash). [...] The three methods are checked in order. If the user is SecurID registered, then SecurID authentication is required. Else, if the user is S/Key registered he/she is prompted with an S/Key challenge. If the user is not S/Key registered, Unix passwords are used but, before that, username is checked against a set of rules as defined in /etc/skey.access. It is possible, in fact, to permit / deny Unix passwords using a wide range of criteria, as described in [2]. Finally, when the user is authenticated, his/her username is checked against /etc/login.access to control login using similar criteria. Stel verbosely reports errors and login failures via syslog. REFERENCES [1] ``Security for Computer Networks'', D.W. Davies and L. Price [2] The logdaemon package, by Wietse Venema , available as ftp://ftp.win.tue.nl/security/logdaemon-4.6.tar.gz [3] A modification of the S/key client program by Marcus J. Ranum to make dictionary attacks infeasible. Available as ftp://ftp.tis.com/pub/firewalls/toolkit/patches/skey.tar.Z [4] ``Computation of Discrete Logarithms in Prime Fields'', Brian A. La Macchia and Adrew M. Odlyzko, available as ftp://ftp.dsi.unimi.it/pub/security/crypt/docs/field.ps -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQBVAgUBL5PK1Sw4rhUX5imVAQEGIwIAwbd1FAJK5gYqpiqYKCrOGkzY2c5Ww2Ez CTpyULHAzL3p6+/wCZlg6QyhVrrtauLA4wO7hCRF1b+WEWxdbRKrwQ== =53th -----END PGP SIGNATURE----- Carolyn Pechter (908)530-7766 x415 cpechter@sesd.ilex.com Ilex Systems, Inc (908) 532-1886/2130 pechterc@sun.sed.monmouth.army.mil __________________________________________________________________________ identity crisis? what identity crisis? I'm the "other" Carolyn, and the "other" Pechter From owner-freebsd-security Sat Apr 22 11:19:18 1995 Return-Path: security-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id LAA28706 for security-outgoing; Sat, 22 Apr 1995 11:19:18 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id LAA28697 for ; Sat, 22 Apr 1995 11:19:16 -0700 Received: by sequent.kiae.su id AA21290 (5.65.kiae-2 ); Sat, 22 Apr 1995 22:06:28 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Sat, 22 Apr 95 22:06:27 +0400 Received: (from ache@localhost) by astral.msk.su (8.6.8/8.6.6) id WAA06578; Sat, 22 Apr 1995 22:03:20 +0400 To: Bruce Evans , erandall@muffit.reo.dec.com, freebsd-security@FreeBSD.org References: <199504211431.AAA23449@godzilla.zeta.org.au> In-Reply-To: <199504211431.AAA23449@godzilla.zeta.org.au>; from Bruce Evans at Sat, 22 Apr 1995 00:31:34 +1000 Message-Id: Organization: Olahm Ha-Yetzirah Date: Sat, 22 Apr 1995 22:03:19 +0400 X-Mailer: Mail/@ [v2.32 FreeBSD] From: "Andrey A. Chernov, Black Mage" X-Class: Fast Subject: Re: Call for remove setr[ug]id() and setre[ug]id() from libc Lines: 22 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 782 Sender: security-owner@FreeBSD.org Precedence: bulk In message <199504211431.AAA23449@godzilla.zeta.org.au> Bruce Evans writes: >>Exactly which functions are you planning to remove : >>and from where ? I plan to rewrite this stuff instead of removing: setruid keep (library) setreuid remove (library) setrgid keep (library) setregid remove (library) osetreuid == setreuid (syscall) \ As 1.x does osetregid == setregid (syscall) / osetreuid/gid syscalls needs to be fixed to really set ruid/rgid. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-security Sat Apr 22 11:55:57 1995 Return-Path: security-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id LAA29730 for security-outgoing; Sat, 22 Apr 1995 11:55:57 -0700 Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id LAA29724 for ; Sat, 22 Apr 1995 11:55:56 -0700 Received: from localhost (localhost [127.0.0.1]) by precipice.shockwave.com (8.6.11/8.6.9) with SMTP id LAA10750 for ; Sat, 22 Apr 1995 11:55:24 -0700 Message-Id: <199504221855.LAA10750@precipice.shockwave.com> To: security@FreeBSD.org Subject: US regulations on 'hooks' for encryption Date: Sat, 22 Apr 1995 11:55:23 -0700 From: Paul Traina Sender: security-owner@FreeBSD.org Precedence: bulk In the old days, I seem to recall that we had regulations prohibiting the export of code that had 'hooks' showing where encryption would be used, if it was available. I thought this changed back in '92, and now we can export everything except the encryption technology itself. Does anyone KNOW FOR A FACT if this is true? It would be nice to get rid of user programs in the secure distribution and merge that stuff back into the mainline code. Paul From owner-freebsd-security Sat Apr 22 12:23:17 1995 Return-Path: security-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA29964 for security-outgoing; Sat, 22 Apr 1995 12:23:17 -0700 Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id MAA29958 for ; Sat, 22 Apr 1995 12:23:16 -0700 Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.3.6) id AA08584; Sat, 22 Apr 1995 15:23:03 -0400 Date: Sat, 22 Apr 1995 15:23:03 -0400 From: Garrett Wollman Message-Id: <9504221923.AA08584@halloran-eldar.lcs.mit.edu> To: Paul Traina Cc: security@FreeBSD.org Subject: US regulations on 'hooks' for encryption In-Reply-To: <199504221855.LAA10750@precipice.shockwave.com> References: <199504221855.LAA10750@precipice.shockwave.com> Sender: security-owner@FreeBSD.org Precedence: bulk < said: > In the old days, I seem to recall that we had regulations prohibiting > the export of code that had 'hooks' showing where encryption would be > used, if it was available. > I thought this changed back in '92, and now we can export everything except > the encryption technology itself. Hmmm. This would seem to contradict what Jim Bound was yelling at the Danvers open plenary... Although I'm not sure I entire believed what he was saying, anyway. The only way to get a definitive answer is to ask the Department of State, and my understanding is that they will not give a blanket answer, but only a yes-or-no for an individual piece of code (which has to be renewed every time the code is changed). -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant