From owner-freebsd-security Tue Sep 30 11:24:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA11653 for security-outgoing; Tue, 30 Sep 1997 11:24:57 -0700 (PDT) Received: from unix.nmarcom.com (root@host-034.nmarcom.com [207.181.124.34]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA11565; Tue, 30 Sep 1997 11:24:03 -0700 (PDT) Received: from [207.181.124.43] (host-043.nmarcom.com [207.181.124.43]) by unix.nmarcom.com (8.8.7/8.8.5) with ESMTP id OAA17528; Tue, 30 Sep 1997 14:23:44 -0400 (EDT) X-Sender: thelab@mail.nmarcom.com Message-Id: In-Reply-To: <199709301113.NAA03022@ocean.campus.luth.se> References: <28439.875567518@time.cdrom.com> from "Jordan K. Hubbard" at "Sep 29, 97 02:11:58 pm" Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 30 Sep 1997 14:23:41 -0400 To: Mikael Karpberg , jkh@time.cdrom.com (Jordan K. Hubbard), freebsd-questions@freebsd.org, freebsd-security@freebsd.org From: Will Mitayai Keeso Rowe Subject: Re: cvs commit: src/etc make.conf Cc: cvs-committers@freebsd.org, cvs-all@freebsd.org, cvs-etc@freebsd.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id LAA11567 Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [moved out of cvs-all to questions & security, which are likely more relevant to discussions.] At 07:13 -0400 1997/09/30, Mikael Karpberg wrote: >According to Jordan K. Hubbard: >> > > Document the ever decreasingly popular USA_RESIDENT variable. >> > Could this be set by sysinstall? >> Eek, no. There are too many variables there already - it needs to be >> settable, yes, but through a "ports configuration" submenu in the new >> setup(1) utility which is coming Real Soon Now, yup! ;-) > >Speaking of which... > >I hope the new utilities wont be as dump about it. When you install the >system you should be able to choose any site to get it from, and choose >any distribution, including DES, etc. When you then "commit", a check is >done to see if you have chosen DES, or such distributions, and the selected >site is not in the known free world (i.e. it's an unknown site ("other URL"), >or a US site). If that's the case, sysinstall will have to throw a requester >up and ask "Are you currently within US?" (or something), and if the answer >is "no", always try and fetch the "Dangerous parts" (DES, etc) from a list >of sites known to be "pure" (internat.freebsd.org, etc). The rest of the >dists selected should be fetched from the selected site. Possibly you have >to give the user a choise of using his "other site" for DES too, if he's >not on the net, or on a very slow line, but has a local server which has >a mirror or some ftp site. > >The anwer on the requester should probably go into make.conf automatically >too, though. That shouldn't be hard to do. > > /Mikael Ok, yet another thread on this... I'm somewhat confused about tis whole USA_RESIDENT thing. The more i reaseach, the more i seem to wonder if Canadian Residents can also use the USA_RESIDENT stuff without feeling guilty about it or having the Men in Black show up on their doorstep. Is it ok for me to generally consider USA_RESIDENT to mean US_OR_CA_RESIDENT? Or is it a package-by-package thing? The whole lifting of export restrictions between the US and Canada seems to be an odd, poorly documented thing, which is annoying since several of the US cryptology routines were developed by canadians in the first place. :( -Mit From owner-freebsd-security Tue Sep 30 13:57:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA21604 for security-outgoing; Tue, 30 Sep 1997 13:57:10 -0700 (PDT) Received: from mail.uniserve.com (dns1-van.uniserve.com [204.244.163.48]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id NAA21583; Tue, 30 Sep 1997 13:56:57 -0700 (PDT) Received: from shell.uniserve.com [204.244.210.252] by mail.uniserve.com with smtp (Exim 1.70 #1) id 0xG9Ky-0005bU-00; Tue, 30 Sep 1997 13:56:08 -0700 Date: Tue, 30 Sep 1997 13:56:05 -0700 (PDT) From: Tom To: Will Mitayai Keeso Rowe cc: Mikael Karpberg , "Jordan K. Hubbard" , freebsd-questions@freebsd.org, freebsd-security@freebsd.org Subject: Re: cvs commit: src/etc make.conf In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 30 Sep 1997, Will Mitayai Keeso Rowe wrote: > I'm somewhat confused about tis whole USA_RESIDENT thing. The more i > reaseach, the more i seem to wonder if Canadian Residents can also use the > USA_RESIDENT stuff without feeling guilty about it or having the Men in > Black show up on their doorstep. Is it ok for me to generally consider > USA_RESIDENT to mean US_OR_CA_RESIDENT? Or is it a package-by-package thing? > > The whole lifting of export restrictions between the US and Canada seems to > be an odd, poorly documented thing, which is annoying since several of the > US cryptology routines were developed by canadians in the first place. :( There are two issues: - copyrights - export restriction on cyrpto Stuff that uses RSA is (like pgp) under copyright in the US. This copyright does not seem to apply to Canada, so I always use the "international" (I find it more straightford to build) version of pgp. I peronsonally think that you'd want to set USA_RESIDENT to no, whenever possible, just because the build process is generally less complex. > -Mit Tom From owner-freebsd-security Tue Sep 30 15:44:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA27819 for security-outgoing; Tue, 30 Sep 1997 15:44:11 -0700 (PDT) Received: from pollux.or.signature.nl (root@pollux.or.signature.nl [194.229.138.194]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA27767 for ; Tue, 30 Sep 1997 15:43:57 -0700 (PDT) Received: from pc03.or.signature.nl (pc03.or.signature.nl [194.229.138.197]) by pollux.or.signature.nl (8.8.5/bs) with SMTP id AAA08226; Wed, 1 Oct 1997 00:43:20 +0200 (MET DST) Date: Wed, 1 Oct 1997 00:43:20 +0200 (MET DST) Message-Id: <1.5.4.16.19970930234321.2b37e910@pollux.or.signature.nl> X-Sender: bit@pollux.or.signature.nl X-Mailer: Windows Eudora Light Version 1.5.4 (16) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Will Mitayai Keeso Rowe From: Bart Smit Subject: Re: cvs commit: src/etc make.conf Cc: freebsd-security@freebsd.org Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 14:23 30-09-97 -0400, you wrote: >I'm somewhat confused about tis whole USA_RESIDENT thing. The more i Confused too. Frankly, I don't see how this could be of interest to non-americans (a majority). I'm getting tired of being bothered by the legislative quirks coming from the US. Can't you separate this from the global discussion, please? --Bart PS - the whole point is, of course, why produce & ship software in/from the US if it is so cumbersome... From owner-freebsd-security Tue Sep 30 16:03:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA28934 for security-outgoing; Tue, 30 Sep 1997 16:03:39 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA28929 for ; Tue, 30 Sep 1997 16:03:35 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id QAA09904; Tue, 30 Sep 1997 16:03:10 -0700 (PDT) To: Bart Smit cc: Will Mitayai Keeso Rowe , freebsd-security@FreeBSD.ORG Subject: Re: cvs commit: src/etc make.conf In-reply-to: Your message of "Wed, 01 Oct 1997 00:43:20 +0200." <1.5.4.16.19970930234321.2b37e910@pollux.or.signature.nl> Date: Tue, 30 Sep 1997 16:03:10 -0700 Message-ID: <9900.875660590@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Confused too. Frankly, I don't see how this could be of interest to > non-americans (a majority). I'm getting tired of being bothered by the > legislative quirks coming from the US. Can't you separate this from the > global discussion, please? At the very least, it does not belong in the freebsd-security mailing list. I agree that the discussion is unproductive and should be dropped. Jordan From owner-freebsd-security Thu Oct 2 15:16:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA27120 for security-outgoing; Thu, 2 Oct 1997 15:16:45 -0700 (PDT) Received: from cwsys.cwent.com (66@cschuber.net.gov.bc.ca [142.31.240.113]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA27064; Thu, 2 Oct 1997 15:15:50 -0700 (PDT) Received: (from uucp@localhost) by cwsys.cwent.com (8.8.7/8.6.10) id PAA04012; Thu, 2 Oct 1997 15:15:38 -0700 (PDT) Message-Id: <199710022215.PAA04012@cwsys.cwent.com> Received: from localhost.cwent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwent.com, id smtpd004008; Thu Oct 2 22:15:14 1997 Reply-to: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-Mailer: MH X-Sender: cschuber To: security-officer@freebsd.org cc: freebsd-security@freebsd.org Subject: Possible weakness in LPD protocol Date: Thu, 02 Oct 1997 15:15:13 -0700 Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Here's an interesting read that was sent to me via BUGTRAQ. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 UNIX Support OV/VM: BCSC02(CSCHUBER) ITSD BITNET: CSCHUBER@BCSC02.BITNET Government of BC Internet: cschuber@uumail.gov.bc.ca Cy.Schubert@gems8.gov.bc.ca "Quit spooling around, JES do it." ------- Forwarded Message Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.8.7/8.6.10) id OAA12179; Thu, 2 Oct 1997 14:57:54 -0700 (PDT) X-UIDL: 875829610.036 Resent-Message-Id: <199710022157.OAA12179@passer.osg.gov.bc.ca> Received: from localhost(127.0.0.1), claiming to be "passer.osg.gov.bc.ca" via SMTP by localhost, id smtpdaagyea; Thu Oct 2 14:57:47 1997 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.8.7/8.6.10) id OAA11672 for ; Thu, 2 Oct 1997 14:57:44 -0700 (PDT) Received: from orca.gov.bc.ca(142.32.102.25) via SMTP by passer.osg.gov.bc.ca, id smtpdaamfba; Thu Oct 2 14:57:36 1997 Received: from brimstone.netspace.org by orca.gov.bc.ca (5.4R3.10/200.1.1.4) id AA18721; Thu, 2 Oct 1997 14:57:33 -0700 Received: from unknown@netspace.org (port 27910 [128.148.157.6]) by brimstone.netspace.org with ESMTP id <79891-2107>; Thu, 2 Oct 1997 17:29:10 -0400 Received: from NETSPACE.ORG by NETSPACE.ORG (LISTSERV-TCP/IP release 1.8c) with spool id 4929228 for BUGTRAQ@NETSPACE.ORG; Thu, 2 Oct 1997 17:25:07 -0400 Received: from brimstone.netspace.org (brimstone [128.148.157.143]) by netspace.org (8.8.7/8.8.2) with ESMTP id RAA21844 for ; Thu, 2 Oct 1997 17:24:41 -0400 Received: from unknown@netspace.org (port 27910 [128.148.157.6]) by brimstone.netspace.org with ESMTP id <23487-2103>; Thu, 2 Oct 1997 17:24:17 -0400 Approved-By: aleph1@UNDERGROUND.ORG Received: from mail.redrose.net (mail.redrose.net [204.249.184.22]) by netspace.org (8.8.7/8.8.2) with SMTP id QAA18725 for ; Thu, 2 Oct 1997 16:58:36 -0400 Received: (qmail 27015 invoked from network); 2 Oct 1997 20:58:11 -0000 Received: from e1-10.redrose.net (HELO kensei.fspi.com) (205.246.85.42) by mail.redrose.net with SMTP; 2 Oct 1997 20:58:11 -0000 X-Mailer: Mozilla 3.01 (Win95; I) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <34340AEE.5395@redrose.net> Date: Thu, 2 Oct 1997 16:58:23 -0400 Reply-To: a42n8k9@**no-spam**.redrose.net Sender: Bugtraq List From: Bennett Samowich Organization: Four Seasons Produce Inc. Subject: Possible weakness in LPD protocol To: BUGTRAQ@netspace.org Resent-To: cy@passer.osg.gov.bc.ca, pblake@uumail.gov.bc.ca Resent-Date: Thu, 02 Oct 1997 14:57:46 -0700 Resent-From: Cy Schubert - ITSD Open Systems Group Greetings, This may be old news, but here it is anyway... While working of a port of "lpr/lpd" to Windows95 I noticed some weaknesses in the implementation of the LPR protocol. Mostly it appears to affect BSD based UNIX's. I found it using the source for BSD4.4, and tested it on "Linux Slackware 2.2.0". I have also tested it on AIX 4.1.5 and it seems to be OK. Unfortunately, (or Fortunately depending on how you look at it), I only have access to these two operating systems. Explaining this assumes that you are familiar with [RFC-1179 Line Pinter Daemon Protocol]. If you are not familiar or have not read it, it may be obtained via FTP from ftp://nic.ddn.mil/rfc/rfc1179.txt The possibilities are as follows: 1.) Obtaining hard (or possibly soft) copies of any file on the system. 2.) Deleting any file on the system. 3.) Creating a file on the system. 4.) Mail bombing. There are a few requirements that need to be met in order to perform these actions. 1.) Must be 'root' on the source machine. NOTE: Under Windows95 the user already has 'root' status. This means that anyone on a Win95 box can bind network sockets to the reserved ports. 2.) Must have or obtain permission to print to the target machine. Usually machines on the same network will have permission to print to each other, but that may not always be the case. 3.) Must have or obtain access to the target printer. Otherwise how will you get your printout? HOW IT WORKS... When lpd sends a file to a remote machine it creates a control file used to instruct the remote machine on how to process the incoming print job. These commands are outlined in [RFC-1179]. It is the implementation of the control commands that provide the weakness. 1.) Obtaining hard (or possibly soft) copies of any file on the system. The control command 'f' causes a file to be printed as text. The syntax is: f filename [LF] Therefore, by inserting the line: "f/etc/shadow" into the control file you will cause the Shadow password file to be printed. (Hard copy) If the print queue points to a network printer then it would be possible to capture the packets. (Soft copy) 2.) Delete any file on the system. The control command 'U' instructs the remote machine to "unlink" the file upon completion of the job. The syntax is: U filename [LF] Therefore, by inserting the line: "U/vmlinuz" into the control file you will cause the Linux kernel to be removed from the file system. 3.) Create a file on the remote system. This is a little trickier, in that BSD4.4 takes the filename that you specify and appends its view of the calling machine's hostname to it. However, BSD4.4 starts at the sixth character. The syntax is 2 size [SP] filename [LF]. Where '2' is the octet 2 not the character, size is the size of the file in bytes, filename is ... (DUH). - - From RECVJOB.C case '\2': /* read cf file */ size = 0; while (*cp >= '0' && *cp <= '9') size = size * 10 + (*cp++ - '0'); if (*cp++ != ' ') break; /* * host name has been authenticated, we use our * view of the host name since we may be passed * something different than what gethostbyaddr() * returns */ HERE -----------> strcpy(cp + 6, from); strcpy(tfname, cp); tfname[0] = 't'; if (!chksize(size)) { (void) write(1, "\2", 1); continue; } if (!readfile(tfname, size)) { rcleanup(0); continue; } if (link(tfname, cp) < 0) frecverr("%s: %m", tfname); (void) unlink(tfname); tfname[0] = '\0'; nfiles++; continue; The result is this: /rc becomes /rc /etc/passwd becomes /etc/passwd.www.yourhost.com This is accomplished by using the printer command of '2' (receive control file) Therefore by sending the printer command '2/rc' and then sending our file, we have created a file in the root directory called 'rc'. By sending '2/home/yourfriend/somefile' and the your file you will have sent somefile to yourfriend ... and even put it in their home directory. Of course it will have the name somefile.www.yourhost.com, but he got it none the less. 4.) Mail bombing. The control command 'M' instructs lpd to mail the user when the job is finished. The syntax is: M username [LF] Therefore by adding the line: "Mjoeuser@www.somewhere.com" you will cause joeuser to receive mail notification about the print job. By adding several thousand of these lines, well you get the idea. SOLUTIONS ??? These holes are due to the implementation of the lpr protocol and the fact that lpd runs as root. I am sure that there may be many solutions to this, but At first glance I think that by checking for a '/' in the filenames would cause the program to react when someone tries to print files from outside of the queue directory. As far as the mail bomb, maybe by checking the destination host with lpd's view of the caller, but that wouldn't allow for someone to print from one account and get the mail at another. IE the boss getting notices when the report is finished. Let me know if I have miss-stated something. Bennett ------- End of Forwarded Message From owner-freebsd-security Thu Oct 2 15:30:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA27978 for security-outgoing; Thu, 2 Oct 1997 15:30:25 -0700 (PDT) Received: from pericles.aipo.gov.au (pericles.aipo.gov.au [202.14.186.30]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA27900 for ; Thu, 2 Oct 1997 15:29:58 -0700 (PDT) From: Stanley.Hopcroft@aipo.gov.au Received: (from smap@localhost) by pericles.aipo.gov.au (8.8.5/8.6.12) id IAA01274 for ; Fri, 3 Oct 1997 08:27:14 +1000 (EST) X-Authentication-Warning: pericles.aipo.gov.au: smap set sender to using -f Received: from notes.aipo.gov.au(192.3.1.11) by pericles.aipo.gov.au via smap (V1.3) id sma001272; Fri Oct 3 08:27:13 1997 Received: by notes.aipo.gov.au(Lotus SMTP MTA v1.05b4 (287.3 12-16-1996)) id 4A256524.007B7024 ; Fri, 3 Oct 1997 08:28:16 +1000 X-Lotus-FromDomain: INTERNET To: security@freebsd.org Message-ID: <4A256524.007B6E1A.00@notes.aipo.gov.au> Date: Fri, 3 Oct 1997 07:43:54 +1000 Subject: recv and xmit options in ipfw, FreeBSD 2.2-RELEASE. Mime-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Dear Ladies and Gentlemen, I am writing to ask about the "recv" and "xmit" options to ipfw. These options allow a rule to match packets received from one interface and transmitted out another and would seem useful for a dual homed FreeBSD host acting as a packet filtering router. The options exist because Mr A Cobbs wrote an answer to a question about their usage to the freebsd-questions mail list. When I try to use a rule like %ipfw add 10 pass tcp from any 1023- to 192.168.11.2 21 recv ed0 xmit ed1 The response from my 2.2-RELEASE system is 4 recv ipfw: ERROR - Unknown argument Usage: ipfw [options] flush add [number] rule delete number list [number] show [number] zero [number] rule: action proto src dst extras... action: {allow|deny|reject|count|divert port} [log] proto: {ip|tcp|udp|icmp|}} src: from {any|ip[{/bits|:mask}]} [{port|port-port}, [port],... dst: to {any|ip[{/bits|:mask}]} [{port|port-port},[port],...] extras: fragment {in|out|inout} via {ifname|ip} {established|setup} tcpflags [!]{syn|fin|rst|ack|psh|urg},... ipoptions [!]{ssrr|lsrr|rr|ts},... icmptypes {type},... proto {ipproto},... See man ipfw(8) for proper usage. % The kernel is configured for ipfw (this host is a packet filter now) with options IPFIREWALL options IPFIREWALL_VERBOSE Thank you for your response and time. Yours sincerely, S Hopcroft Australian Industrial Property Organisation (AIPO) better known as Patents Office. From owner-freebsd-security Thu Oct 2 16:26:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA00995 for security-outgoing; Thu, 2 Oct 1997 16:26:33 -0700 (PDT) Received: from burka.rdy.com (burka.rdy.com [205.149.163.30]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA00964; Thu, 2 Oct 1997 16:25:48 -0700 (PDT) Received: by burka.rdy.com id QAA13494; (8.8.7/RDY) Thu, 2 Oct 1997 16:25:11 -0700 (PDT) Message-Id: <199710022325.QAA13494@burka.rdy.com> Subject: Re: Possible weakness in LPD protocol In-Reply-To: <199710022215.PAA04012@cwsys.cwent.com> from Cy Schubert - ITSD Open Systems Group at "Oct 2, 97 03:15:13 pm" To: cschuber@uumail.gov.bc.ca Date: Thu, 2 Oct 1997 16:25:10 -0700 (PDT) Cc: security-officer@FreeBSD.ORG, freebsd-security@FreeBSD.ORG X-Class: Fast Organization: HackerDome Reply-To: dima@best.net From: dima@best.net (Dima Ruban) X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Yup. And lpd is turned on by default :-/ Cy Schubert - ITSD Open Systems Group writes: > Here's an interesting read that was sent to me via BUGTRAQ. > > > Regards, Phone: (250)387-8437 > Cy Schubert Fax: (250)387-5766 > UNIX Support OV/VM: BCSC02(CSCHUBER) > ITSD BITNET: CSCHUBER@BCSC02.BITNET > Government of BC Internet: cschuber@uumail.gov.bc.ca > Cy.Schubert@gems8.gov.bc.ca > > "Quit spooling around, JES do it." > > > ------- Forwarded Message > > Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.8.7/8.6.10) id OAA12179; Thu, 2 Oct 1997 14:57:54 -0700 (PDT) > X-UIDL: 875829610.036 > Resent-Message-Id: <199710022157.OAA12179@passer.osg.gov.bc.ca> > Received: from localhost(127.0.0.1), claiming to be "passer.osg.gov.bc.ca" > via SMTP by localhost, id smtpdaagyea; Thu Oct 2 14:57:47 1997 > Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.8.7/8.6.10) id OAA11672 for ; Thu, 2 Oct 1997 14:57:44 -0700 (PDT) > Received: from orca.gov.bc.ca(142.32.102.25) > via SMTP by passer.osg.gov.bc.ca, id smtpdaamfba; Thu Oct 2 14:57:36 1997 > Received: from brimstone.netspace.org by orca.gov.bc.ca (5.4R3.10/200.1.1.4) > id AA18721; Thu, 2 Oct 1997 14:57:33 -0700 > Received: from unknown@netspace.org (port 27910 [128.148.157.6]) by brimstone.netspace.org with ESMTP id <79891-2107>; Thu, 2 Oct 1997 17:29:10 -0400 > Received: from NETSPACE.ORG by NETSPACE.ORG (LISTSERV-TCP/IP release 1.8c) with > spool id 4929228 for BUGTRAQ@NETSPACE.ORG; Thu, 2 Oct 1997 17:25:07 > -0400 > Received: from brimstone.netspace.org (brimstone [128.148.157.143]) by > netspace.org (8.8.7/8.8.2) with ESMTP id RAA21844 for > ; Thu, 2 Oct 1997 17:24:41 -0400 > Received: from unknown@netspace.org (port 27910 [128.148.157.6]) by > brimstone.netspace.org with ESMTP id <23487-2103>; Thu, 2 Oct 1997 > 17:24:17 -0400 > Approved-By: aleph1@UNDERGROUND.ORG > Received: from mail.redrose.net (mail.redrose.net [204.249.184.22]) by > netspace.org (8.8.7/8.8.2) with SMTP id QAA18725 for > ; Thu, 2 Oct 1997 16:58:36 -0400 > Received: (qmail 27015 invoked from network); 2 Oct 1997 20:58:11 -0000 > Received: from e1-10.redrose.net (HELO kensei.fspi.com) (205.246.85.42) by > mail.redrose.net with SMTP; 2 Oct 1997 20:58:11 -0000 > X-Mailer: Mozilla 3.01 (Win95; I) > Mime-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > Message-Id: <34340AEE.5395@redrose.net> > Date: Thu, 2 Oct 1997 16:58:23 -0400 > Reply-To: a42n8k9@**no-spam**.redrose.net > Sender: Bugtraq List > From: Bennett Samowich > Organization: Four Seasons Produce Inc. > Subject: Possible weakness in LPD protocol > To: BUGTRAQ@netspace.org > Resent-To: cy@passer.osg.gov.bc.ca, pblake@uumail.gov.bc.ca > Resent-Date: Thu, 02 Oct 1997 14:57:46 -0700 > Resent-From: Cy Schubert - ITSD Open Systems Group > > Greetings, > > This may be old news, but here it is anyway... > > While working of a port of "lpr/lpd" to Windows95 I noticed some > weaknesses in the implementation of the LPR protocol. Mostly it > appears to affect BSD based UNIX's. I found it using the source for > BSD4.4, and tested it on "Linux Slackware 2.2.0". I have also tested it > on AIX 4.1.5 and it seems to be OK. Unfortunately, (or Fortunately > depending on how you look at it), I only have access to these two > operating systems. > > Explaining this assumes that you are familiar with [RFC-1179 Line Pinter > Daemon Protocol]. If you are not familiar or have not read it, it may > be obtained via FTP from ftp://nic.ddn.mil/rfc/rfc1179.txt > > The possibilities are as follows: > 1.) Obtaining hard (or possibly soft) copies of any file on the system. > 2.) Deleting any file on the system. > 3.) Creating a file on the system. > 4.) Mail bombing. > > There are a few requirements that need to be met in order to perform > these actions. > 1.) Must be 'root' on the source machine. > NOTE: Under Windows95 the user already has 'root' status. This means > that anyone on a Win95 box > can bind network sockets to the reserved ports. > 2.) Must have or obtain permission to print to the target machine. > Usually machines on the same network will have permission to print to > each other, but that may not always be the case. > 3.) Must have or obtain access to the target printer. Otherwise how > will you get your printout? > > HOW IT WORKS... > > When lpd sends a file to a remote machine it creates a control file used > to instruct the remote machine on how to process the incoming print > job. These commands are outlined in [RFC-1179]. It is the > implementation of the control commands that provide the weakness. > > 1.) Obtaining hard (or possibly soft) copies of any file on the system. > The control command 'f' causes a file to be printed as text. > > The syntax is: f filename [LF] > > Therefore, by inserting the line: "f/etc/shadow" into the control file > you will cause the > Shadow password file to be printed. (Hard copy) > > If the print queue points to a network printer then it would be possible > to capture the packets. (Soft copy) > > 2.) Delete any file on the system. > The control command 'U' instructs the remote machine to "unlink" the > file upon completion of the job. > > The syntax is: U filename [LF] > > Therefore, by inserting the line: "U/vmlinuz" into the control file you > will cause the Linux kernel to be > removed from the file system. > > 3.) Create a file on the remote system. > This is a little trickier, in that BSD4.4 takes the filename that you > specify and appends its view of the calling machine's hostname to it. > However, BSD4.4 starts at the sixth character. > > The syntax is 2 size [SP] filename [LF]. Where '2' is the octet 2 not > the character, size is the size of the file in bytes, filename is ... > (DUH). > > - - From RECVJOB.C > case '\2': /* read cf file */ > size = 0; > while (*cp >= '0' && *cp <= '9') > size = size * 10 + (*cp++ - '0'); > if (*cp++ != ' ') > break; > /* > * host name has been authenticated, we use our > * view of the host name since we may be passed > * something different than what gethostbyaddr() > * returns > */ > HERE -----------> strcpy(cp + 6, from); > strcpy(tfname, cp); > tfname[0] = 't'; > if (!chksize(size)) { > (void) write(1, "\2", 1); > continue; > } > if (!readfile(tfname, size)) { > rcleanup(0); > continue; > } > if (link(tfname, cp) < 0) > frecverr("%s: %m", tfname); > (void) unlink(tfname); > tfname[0] = '\0'; > nfiles++; > continue; > > > The result is this: > > /rc becomes /rc > /etc/passwd becomes /etc/passwd.www.yourhost.com > > This is accomplished by using the printer command of '2' (receive > control file) > > Therefore by sending the printer command '2/rc' and then sending our > file, we have created a file in the root directory called 'rc'. > By sending '2/home/yourfriend/somefile' and the your file you will have > sent somefile to yourfriend ... and even put it in their home > directory. Of course it will have the name somefile.www.yourhost.com, > but he got it none the less. > > 4.) Mail bombing. > The control command 'M' instructs lpd to mail the user when the job is > finished. > > The syntax is: M username [LF] > > Therefore by adding the line: "Mjoeuser@www.somewhere.com" you will > cause joeuser to receive mail notification about the print job. By > adding several thousand of these lines, well you get the idea. > > > SOLUTIONS ??? > These holes are due to the implementation of the lpr protocol and the > fact that lpd runs as root. I am sure that there may be many solutions > to this, but At first glance I think that by checking for a '/' in the > filenames would cause the program to react when someone tries to print > files from outside of the queue directory. > > As far as the mail bomb, maybe by checking the destination host with > lpd's view of the caller, but that wouldn't allow for someone to print > from one account and get the mail at another. IE the boss getting > notices when the report is finished. > > Let me know if I have miss-stated something. > > Bennett > > > ------- End of Forwarded Message > -- dima From owner-freebsd-security Thu Oct 2 17:25:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA04229 for security-outgoing; Thu, 2 Oct 1997 17:25:30 -0700 (PDT) Received: from pericles.aipo.gov.au (pericles.aipo.gov.au [202.14.186.30]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA04212 for ; Thu, 2 Oct 1997 17:25:23 -0700 (PDT) From: Stanley.Hopcroft@aipo.gov.au Received: (from smap@localhost) by pericles.aipo.gov.au (8.8.5/8.6.12) id KAA02076 for ; Fri, 3 Oct 1997 10:22:48 +1000 (EST) X-Authentication-Warning: pericles.aipo.gov.au: smap set sender to using -f Received: from notes.aipo.gov.au(192.3.1.11) by pericles.aipo.gov.au via smap (V1.3) id smaa02070; Fri Oct 3 10:22:27 1997 Received: by notes.aipo.gov.au(Lotus SMTP MTA v1.05b4 (287.3 12-16-1996)) id 4A256525.00022478 ; Fri, 3 Oct 1997 10:23:24 +1000 X-Lotus-FromDomain: INTERNET To: security@freebsd.org Message-ID: <4A256525.00022265.00@notes.aipo.gov.au> Date: Fri, 3 Oct 1997 09:42:53 +1000 Subject: recv and xmit options in ipfw, FreeBSD 2.2-RELEASE. Mime-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Dear Ladies and Gentlemen, I am writing to apologise for wasting your time with the question about the "recv" and "xmit" options for ipfw. It seems to me that these options only apply for 3.0-CURRENT, and not 2.2-RELEASE as I was trying. Thank you. Yours sincerely. ______________________________ Forward Header _____________________________ _____ Subject: recv and xmit options in ipfw, FreeBSD 2.2-RELEASE. Author: Stanley Hopcroft at IT_Services Date: 03/10/97 7:43 AM Dear Ladies and Gentlemen, I am writing to ask about the "recv" and "xmit" options to ipfw. These options allow a rule to match packets received from one interface and transmitted out another and would seem useful for a dual homed FreeBSD host acting as a packet filtering router. From owner-freebsd-security Fri Oct 3 07:39:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA17961 for security-outgoing; Fri, 3 Oct 1997 07:39:27 -0700 (PDT) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id HAA17918; Fri, 3 Oct 1997 07:38:56 -0700 (PDT) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 0xH8sK-0000hX-00; Fri, 3 Oct 1997 08:38:40 -0600 Received: from harmony.village.org (localhost [127.0.0.1]) by harmony.village.org (8.8.7/8.8.3) with ESMTP id IAA09461; Fri, 3 Oct 1997 08:39:44 -0600 (MDT) Message-Id: <199710031439.IAA09461@harmony.village.org> To: Cy Schubert - ITSD Open Systems Group Subject: Re: Possible weakness in LPD protocol Cc: security-officer@freebsd.org, freebsd-security@freebsd.org, bugtraq@netspace.org In-reply-to: Your message of "Thu, 02 Oct 1997 15:15:13 PDT." <199710022215.PAA04012@cwsys.cwent.com> References: <199710022215.PAA04012@cwsys.cwent.com> Date: Fri, 03 Oct 1997 08:39:44 -0600 From: Warner Losh Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk : SOLUTIONS ??? : These holes are due to the implementation of the lpr protocol and the : fact that lpd runs as root. I am sure that there may be many solutions : to this, but At first glance I think that by checking for a '/' in the : filenames would cause the program to react when someone tries to print : files from outside of the queue directory. Both OpenBSD and FreeBSD disallow any files with / in them in the code that was quoted. So this isn't a problem in either of those systems. I don't have a current NetBSD source tree online at the moment, or I'd check there. The following csh code while (1) mail blah blah blah end allows effective mail bombing as well. And if you control root for the machine in question, you can use sendmail to forge the mail from any address that you want. And even if you aren't effective mail forging programs are a dime a dozen and are more general in their damage. What is the threat here? Warner From owner-freebsd-security Sat Oct 4 07:40:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA18187 for security-outgoing; Sat, 4 Oct 1997 07:40:29 -0700 (PDT) Received: from cwsys.cwent.com (66@cschuber.net.gov.bc.ca [142.31.240.113]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA18093; Sat, 4 Oct 1997 07:39:42 -0700 (PDT) Received: (from uucp@localhost) by cwsys.cwent.com (8.8.7/8.6.10) id HAA14172; Sat, 4 Oct 1997 07:39:38 -0700 (PDT) Message-Id: <199710041439.HAA14172@cwsys.cwent.com> Received: from localhost.cwent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwent.com, id smtpd014169; Sat Oct 4 14:39:25 1997 Reply-to: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-Mailer: MH X-Sender: cschuber To: freebsd-security@freebsd.org cc: security-officer@freebsd.org Subject: Changed Setuid Binary Date: Sat, 04 Oct 1997 07:39:24 -0700 Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Below is a portion of the output from the daily security check from one of my 2.2.2R (+published security patches) boxes. You'll notice that a sendmail binary's last modification date has changed. I've compared this binary with one on my other FreeBSD-2.2.2 (+published security patches) box at home. After comparing it using cmp and verifying the compare with md5, the binary did not change, only the last modification date did. I remember seeing this before on 2.1.x, though I cannot remember seeing it on 2.0.5. I also remember seeing some discussion on this list about this strange phenomenon on this list some time ago. The explanation for the problem at that time had something to do with the paging routines in FreeBSD at the time. From the output below you will notice that the date last modified stamp for sendmail has changed. At the time that this binary's modification stamp was changed I was running a CPU intensive non-nonsuid program and had just terminated a PPP connection to my place of employment. Sendmail does not run as a daemon on this machine. SMTP is handled by Obtuse Systems SMTP daemon, smtpd. Their smtpfwdd daemon periodically calls (fork/exec) sendmail to process their queue and sendmail is periodically run out of cron to process its queue. At the time the only thing that sendmail was doing was (extracted from root's crontab entry): 5/30 * * * * /usr/sbin/sendmail -q Is there any possibility that this is the same bug discussed 6 to 12 months ago on this list? Or could this be related to cron exec()ing sendmail at the time and FreeBSD modifying the mtime when sendmail was executed by cron? Even though the binary did not change, the changed mtime still has some security implications as there is no way one can know for sure whether a binary was changed by an unauthorized person or whether FreeBSD just decided to change it itself. Any thoughts or ideas? Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 UNIX Support OV/VM: BCSC02(CSCHUBER) ITSD BITNET: CSCHUBER@BCSC02.BITNET Government of BC Internet: cschuber@uumail.gov.bc.ca Cy.Schubert@gems8.gov.bc.ca "Quit spooling around, JES do it." ------- Forwarded Message Delivery-Date: Sat, 04 Oct 1997 02:05:54 -0700 Return-Path: root Received: (from root@localhost) by cwsys.cwent.com (8.8.7/8.6.10) id CAA08384 for root; Sat, 4 Oct 1997 02:00:02 -0700 (PDT) Date: Sat, 4 Oct 1997 02:00:02 -0700 (PDT) From: Charlie Root Message-Id: <199710040900.CAA08384@cwsys.cwent.com> Subject: cwsys security check output checking setuid files and devices: cwsys setuid diffs: 85d84 < -rws--x--x 1 root bin 139264 Apr 25 07:13:32 1997 /usr/local/bin/ssh 96,98c95,97 < -r-s--x--x 3 root bin 290816 Aug 9 00:59:19 1997 /usr/local/etc/sendmail/8.8.7/mailq < -r-s--x--x 3 root bin 290816 Aug 9 00:59:19 1997 /usr/local/etc/sendmail/8.8.7/newaliases < -r-s--x--x 3 root bin 290816 Aug 9 00:59:19 1997 /usr/local/etc/sendmail/8.8.7/sendmail - --- > -r-s--x--x 3 root bin 290816 Oct 2 17:05:03 1997 /usr/local/etc/sendmail/8.8.7/mailq > -r-s--x--x 3 root bin 290816 Oct 2 17:05:03 1997 /usr/local/etc/sendmail/8.8.7/newaliases > -r-s--x--x 3 root bin 290816 Oct 2 17:05:03 1997 /usr/local/etc/sendmail/8.8.7/sendmail checking for uids of 0: root 0 toor 0 cwsys kernel log messages: > ia. All rights reserved. > > FreeBSD 2.2.2-RELEASE #0: Sun Sep 7 08:55:21 PDT 1997 > root@cwsys:/opt/usr_src/sys/compile/CWSYS > CPU: Pentium (119.75-MHz 586-class CPU) > Origin = "GenuineIntel" Id = 0x52c Stepping=12 > Features=0x1bf > real memory = 33554432 (32768K bytes) > avail memory = 30597120 (29880K bytes) > Probing for devices on PCI bus 0: > chip0 rev 2 on pci0:0 > chip1 rev 1 on pci0:7:0 > chip2 rev 0 on pci0:7:1 > vga0 rev 84 int a irq 9 on pci0:20 > Probing for devices on the ISA bus: > sc0 at 0x60-0x6f irq 1 on motherboard > sc0: VGA color <16 virtual consoles, flags=0x0> > ed0 at 0x280-0x29f irq 5 maddr 0xd8000 msize 16384 on isa > ed0: address 00:00:c0:eb:b1:4a, type WD8013EPC (16 bit) > sio0 at 0x3f8-0x3ff irq 4 on isa > sio0: type 16550A > sio1 at 0x2f8-0x2ff irq 3 on isa > sio1: type 16550A > lpt0 at 0x378-0x37f irq 7 on isa > lpt0: Interrupt-driven port > lp0: TCP/IP capable interface > fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa > fdc0: NEC 72065B > fd0: 1.44MB 3.5in > fd1: 1.2MB 5.25in > wdc0 at 0x1f0-0x1f7 irq 14 on isa > wdc0: unit 0 (wd0): > wd0: 2014MB (4124736 sectors), 4092 cyls, 16 heads, 63 S/T, 512 B/S > wdc1 at 0x170-0x177 irq 15 on isa > wdc1: unit 0 (wd2): > wd2: 2441MB (4999680 sectors), 4960 cyls, 16 heads, 63 S/T, 512 B/S > aha0 at 0x330-0x333 irq 11 drq 5 on isa > aha0 waiting for scsi devices to settle > (aha0:0:0): "QUANTUM LIGHTNING 730S 241E" type 0 fixed SCSI 2 > sd0(aha0:0:0): Direct-Access 699MB (1431760 512 byte sectors) > (aha0:2:0): "PLEXTOR CD-ROM PX-4XCH 1.22" type 5 removable SCSI 2 > cd0(aha0:2:0): CD-ROM can't get the size > (aha0:4:0): "ARCHIVE Python 28388-XXX 5.45" type 1 removable SCSI 2 > st0(aha0:4:0): Sequential-Access density code 0x13, drive empty > (aha0:6:0): "IOMEGA ZIP 100 D.09" type 0 removable SCSI 2 > sd1(aha0:6:0): Direct-Access > sd1(aha0:6:0): ILLEGAL REQUEST asc:24,0 Invalid field in CDB > sd1 could not mode sense (4). Using ficticious geometry > > sd1(aha0:6:0): NOT READY asc:3a,0 Medium not present > sd1: could not get size > 0MB (0 512 byte sectors) > 1 3C5x9 board(s) on ISA found at 0x300 > ep0 at 0x300-0x30f irq 10 on isa > ep0: aui/utp/bnc[*BNC*] address 00:60:97:d3:32:3e > npx0 on motherboard > npx0: INT 16 interface ------- End of Forwarded Message