From owner-freebsd-audit Sun Dec 5 0:14:53 1999 Delivered-To: freebsd-audit@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id DC269150F2; Sun, 5 Dec 1999 00:14:49 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id BAA32418; Sun, 5 Dec 1999 01:14:46 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id BAA27059; Sun, 5 Dec 1999 01:14:46 -0700 (MST) Message-Id: <199912050814.BAA27059@harmony.village.org> To: Mark Murray Subject: Re: Closed list policy? Cc: Kris Kennaway , audit@FreeBSD.ORG In-reply-to: Your message of "Sun, 05 Dec 1999 09:50:25 +0200." <199912050750.JAA15703@gratis.grondar.za> References: <199912050750.JAA15703@gratis.grondar.za> Date: Sun, 05 Dec 1999 01:14:46 -0700 From: Warner Losh Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199912050750.JAA15703@gratis.grondar.za> Mark Murray writes: : The dirty details should be on -security, -arch, -current or -security-officer, : as appropriate. New root holes shouldn't be posted in an open forum. They should be fixed if you are a committer. Security officer will review changes if you'd like, or if you have any doubts. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Sun Dec 5 11:53:55 1999 Delivered-To: freebsd-audit@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 31F0B154C8 for ; Sun, 5 Dec 1999 11:53:48 -0800 (PST) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (root@d60-025.leach.ucdavis.edu [169.237.60.25]) by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id LAA27082; Sun, 5 Dec 1999 11:53:48 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id LAA69128; Sun, 5 Dec 1999 11:53:48 -0800 (PST) (envelope-from obrien) Date: Sun, 5 Dec 1999 11:53:47 -0800 From: "David O'Brien" To: Gerald Abshez Cc: audit@FreeBSD.ORG Subject: Re: Auditing ports Message-ID: <19991205115347.A69102@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <384691C6.347BE836@manhattanprojects.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <384691C6.347BE836@manhattanprojects.com>; from gerald@manhattanprojects.com on Thu, Dec 02, 1999 at 10:35:34AM -0500 X-Operating-System: FreeBSD 4.0-CURRENT Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Dec 02, 1999 at 10:35:34AM -0500, Gerald Abshez wrote: > While I'm all in favour of making _everything_ secure, I feel we > have to concentrate on the core functionality. Let's not put the > cart before the horse - The base system should be fully eyeballed > before we get all of the ports done. Not necessarily. The *ONLY* time any of my FreeBSD boxes have been broken into was thru the Qpopper buffer overflow. There are key ports that are network listening daemons that should take as high a priority as any of the base network listening daemons. -- -- David (obrien@NUXI.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Sun Dec 5 12:16:48 1999 Delivered-To: freebsd-audit@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 980AD15445; Sun, 5 Dec 1999 12:16:45 -0800 (PST) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (root@d60-025.leach.ucdavis.edu [169.237.60.25]) by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id MAA27177; Sun, 5 Dec 1999 12:16:44 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id MAA69201; Sun, 5 Dec 1999 12:16:44 -0800 (PST) (envelope-from obrien) Date: Sun, 5 Dec 1999 12:16:43 -0800 From: "David O'Brien" To: arch@FreeBSD.ORG, audit@FreeBSD.ORG Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern kern_fork.c src/sys/libkern arc4random.c src/sys/sys libkern.h Message-ID: <19991205121643.A69177@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <89015.943945313@zippy.cdrom.com> <99Dec1.091202est.40330@border.alcanet.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <99Dec1.091202est.40330@border.alcanet.com.au>; from jeremyp@gsmx07.alcatel.com.au on Wed, Dec 01, 1999 at 09:19:18AM +1100 X-Operating-System: FreeBSD 4.0-CURRENT Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Dec 01, 1999 at 09:19:18AM +1100, Peter Jeremy wrote: > >Not being able to predict pids (for useful purposes) would fall under > >the definition of "negative impact" for a number of admins. > > I agree. Digital UNIX uses something like random PID generation and I Well there you go, we now have an example that you can't depend on the linear behavior in Unix. So we have a strong case for making random PIDs the default. -- -- David (obrien@NUXI.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Sun Dec 5 14: 6:18 1999 Delivered-To: freebsd-audit@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 6F22714D02; Sun, 5 Dec 1999 14:06:13 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id RAA06885; Sun, 5 Dec 1999 17:06:09 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Sun, 5 Dec 1999 17:06:09 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: "David O'Brien" Cc: Gerald Abshez , audit@FreeBSD.ORG Subject: Re: Auditing ports In-Reply-To: <19991205115347.A69102@dragon.nuxi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 5 Dec 1999, David O'Brien wrote: > On Thu, Dec 02, 1999 at 10:35:34AM -0500, Gerald Abshez wrote: > > While I'm all in favour of making _everything_ secure, I feel we > > have to concentrate on the core functionality. Let's not put the > > cart before the horse - The base system should be fully eyeballed > > before we get all of the ports done. > > Not necessarily. The *ONLY* time any of my FreeBSD boxes have been broken > into was thru the Qpopper buffer overflow. There are key ports that are > network listening daemons that should take as high a priority as any of > the base network listening daemons. A day or two ago I sent an email to bugtraq making some assertions about responsibility for ports security and requirements, and while not everyone will (or even should :-) agree with me, it might be worth reading through it to see what my thoughts on the issue were. I'll forward the post here as fodder--not as a definitive solution to the problem :-). Interestingly, the only flames I got were from people who either a) didn't want to be subscribed to bugtraq anymore, and b) who didn't like long posts and appreciated my comment at the beginning. Go figure. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Sun Dec 5 14: 7: 1 1999 Delivered-To: freebsd-audit@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 7E76614D02 for ; Sun, 5 Dec 1999 14:06:53 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id RAA06891 for ; Sun, 5 Dec 1999 17:06:58 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Sun, 5 Dec 1999 17:06:58 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: freebsd-audit@freebsd.org Subject: Re: [Re: Several FreeBSD-3.3 vulnerabilities] (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Here's the bugtraq post I referred to in my previous post. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services ---------- Forwarded message ---------- Date: Thu, 2 Dec 1999 17:01:46 -0500 From: Robert Watson Reply-To: Robert Watson To: BUGTRAQ@SECURITYFOCUS.COM Subject: Re: [Re: Several FreeBSD-3.3 vulnerabilities] WARNING: this is a long email talking about auditing responsibility, risk evaluation, and communicating about risk and vulnerabilities in the context of a free operating system environment where third party code is redistributed. If you get bored, skip to the next section or the conclusion. On Wed, 1 Dec 1999, Brock Tellier wrote: > >This one is a hole in the vendor-provided software, which wants to >install > >it setuid uucp by default. With ~2800 third-party apps shipped with > >FreeBSD, we can't be held responsible for the security of all of them :-) > > This is the statement I have a bit of a problem with. Sure there are 2800 > ports, but how many of these are suid/sgid? I'm thinking *maybe* 50 that I > saw when I did a full install of 3.3-RELEASE. Fifty apps, most of which are > small like xmindpath, isn't a ridiculous number to audit. At LEAST auditing > them for command-line overflows and setting up a /tmp watcher. > You may not be legally responsible, or be able to take responsibility for the > quality of the code, but when you allow a third-party to put a *suid* program > into your distribution you imply some sort of trust with the end-user > regarding it's security integrity. At least to the point that we can assume > that someone has taken the time to xmindpath -arg $BUF. Note that this isn't > specifically directed at FreeBSD or free OS's. > No, I contacted security-officer@freebsd.org who responded that HE had > contacted the maintainers. That was the last I ever heard of it. So there has, of course, been a lot of traffic on freebsd-security, freebsd-audit, and elsewhere about the impact of your recent advisories, and the implications for our security process. I think it's important to address a number of issues that you and others have raised, and point out that the process is probably not fixed yet, and feedback on how the FreeBSD Project (and numerous others in the same situation) should be handling this kind of thing. Issue 1: Third Party Applications One objection commonly passed around is that you are identifying these bugs as "FreeBSD vulnerabilities", and indeed, they are vulnerabilities that can arise from installing FreeBSD in the documented manner, and then adding packages bundled with the FreeBSD distribution. However, the source base of these applications is neither written nor maintained by the FreeBSD Project. There are two classes of security issues here: first, the application itself (as designed by the developers) may have security problems, be it buffer overflows, poor design, etc. The second is that during the porting process, we may introduce security problems that did not exist in the original un-FreeBSD'd version of the application. The second type, we clearly must take full responsibility for--if it's our code, it's our problem. The problem of code in the base third party application is serious also, and harder to address. As has been pointed out, the source base underlying the ports collection is enourmous--there are almost 3000 third party applications in the ports collection currently, and all of them will have "security considerations". Clearly we *cannot* audit all of the code. It is simply not feasible for a project of our size--we can skim some of the code, and encourage the original application developers to do proper auditing themselves. We can also reject applications as "unsafe" or tag them as "unsafe", which is a strategy that we have not yet employed, but probably should. You point out that there are a particular class of applications that need to be paid close attention to: setuid and setgid applications, that is, applications that rely on elevated privileges to perform their function. You also observe that they are relatively small in number. I think it's worth pointing out that in fact, almost all code in the ports collection increases risk and exposure: chances are, they interact with the network or third parties in many cases (browsers, mail servers (imap anyway? :-), etc). Almost any third party application introduces some risk. We can concentrate on subsets of these that are particularly unfortunte (setuid/setgid, daemons) but we're bumping into the risk factor. Ideally the application developers do some of this for us, right? 2: Identifying Risk and Informing the User When a user chooses to install an operating system, they are placing a certain amount of trust in the vendor, be it Microsoft, Sun, or FreeBSD. This means they've accepted the level of auditing/security that the vendors consider acceptable, and assume that unless otherwise informed, all software provided by the vendor should be considered in that equivilence class of trust. In the FreeBSD model, porst do not fall into that same class, and as such should be identified to the user. I would like to see a clear disclaimer pop up before entering the packages install component of sysinstall: The packages collection is made up of applications provided by third parties, and adapted for use under FreeBSD. Because these applications are not part of the FreeBSD source base, they may not have been reviewed and found to meet the same rigorous auditing and review process, and as such may suffer from limitations beyond the control of the FreeBSD Project, including security limitations. By installing these packages, you accept the associated risk. Clearly the wording needs work, but you get the idea: if we're going to accept risk because of the integration of third party applications in our install process, we need to let the user know so they can choose *not* to accept the risk. Similarly, we need to identify applications that have increased exposure to the "unsafe world", that is, setuid/setgid applications that interact with general users or the network, and applications that run without elevated privileges, but with exposure to third parties (i.e., netscape connecting to servers, irc, popd, etc). We could also be a bit more discerning about how we select ports and make them available. Yes, it is acceptable to pop up yet another dialog for the user that says: This application sucks. Yes, it honestly does. It was written by the *WORST* coder in the world, and as such it is full of security holes. It's swiss cheese. It makes a pile of tofu look like a well-audited piece of code. We don't think you should install it, but because there is demand, we're making it available so that you can evaluate the program, your use of the program, and your environment and see if it is appropriate. Go ahead at your own risk, and feel free to contact the developer to tell them we told you this. And the default state of the ports collection should be to have this happen for every port, and we turn it off when we feel comfortable with it. 3. Improved and Formal Communications Model So I've painted a picture of different code components with varying degrees of trust (base code, ports, etc). Now we need to think about what to do when a vulnerability is found. In the best case, we are notified in advance so that we can prepare fixes for release at the same time as the announcement of the vulnerability--this provides end users with a good combination of open disclosure, as well as vendor-provided patches. As such, we provide the security-officer@freebsd.org address as a uniform submission location for such vulnerability notifications. Somewhere, we slipped, because the fixes weren't out there. In the case of a bug in the base source tree, there may be a delay due to communicating with developers of that section of the tree, but all parties are clearly identified and the task is fairly easy. With a third party development model, there are more people involved in the process. The process you discovered goes something like this: Bug Reporter --> Security Officer --> Port Maintainer Optionally, there's a fourth party involved: --> Application Developer, and the application developer may want to be "in" on the process. Each step along the way involves a delay -- we wait for each party to check their email, live their lives (your choice: you're 9 months pregnant and water just broke: you can go to the delivery room, or you can fix a bug.. :-), and so there are timeouts. If the bug is being actively exploited, there may be shortcut approaches available, but because of the large scale of some of the software, it's important to get the designer involved in fixes, as there may be implications to any changes made by a party not understanding the code as well (such as introducing new security problems: a correct fix is better than no fix, and an incorrect fix can actually make things worse). The part that presumably got broken was the "timeout on ping to next stage, take action to limit the effects of the bug". Presumably the choices go something like this: Advisory and one of: withdraw the port patch the port update the port for application developer fixes When communications break down, we should start moving up the list until something works with sufficient rapidity. I'd say, give two days to the ports developer, and two days to the application developer. If after four days, a fix isn't found, go for the lowest on the list that is feasible, with a worst case of withdrawing the port (disabling it, and giving an advisory). There are perfectly legitimate reasons for poor communications: poor media for communication, poor availability of opportunity, etc. What there are not legitimate reasons for is being unable to decide what to do when communication fails: it's like disconnected operation on a notebook: you can't do nothing, so it's best to fail as best you can :-). The communications and action model needs to reflect the development model. And to conclude before too many people have given up: this should not look like an unfamiliar problem to anyone out there. All the free operating systems I know of have to deal with it, as well as most of the commercial vendors. When a hardware vendor irritatingly bundless AOL Instant Messenger with you Win98 machine, they've made a decision about trusted code bases, etc. Probably not consciously and with the necessary degree of thought, but they have. The same goes for Microsoft bundling parts of BSAFE for browser security, etc. Both these organizations (providers and facilitators of third party code distribution) and users need to understand the risks, and work out appropriate responses. And also the application developers: you make everyone look bad :-). Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Mon Dec 6 2:53:52 1999 Delivered-To: freebsd-audit@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 8FCDE15140; Mon, 6 Dec 1999 02:53:43 -0800 (PST) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.11 #1) id 11uvm2-0006zQ-00; Mon, 06 Dec 1999 12:53:42 +0200 From: Sheldon Hearn To: obrien@FreeBSD.ORG Cc: arch@FreeBSD.ORG, audit@FreeBSD.ORG Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern kern_fork.c src/sys/libkern arc4random.c src/sys/sys libkern.h In-reply-to: Your message of "Sun, 05 Dec 1999 12:16:43 PST." <19991205121643.A69177@dragon.nuxi.com> Date: Mon, 06 Dec 1999 12:53:42 +0200 Message-ID: <26871.944477622@axl.noc.iafrica.com> Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 05 Dec 1999 12:16:43 PST, "David O'Brien" wrote: > Well there you go, we now have an example that you can't depend on the > linear behavior in Unix. So we have a strong case for making random PIDs > the default. Nah, just leave the historical linear assignment as the default mode of operation for the sake of POLA and document the knob for random assignment in rc.conf.5 and wherever else might be appropriate. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Mon Dec 6 3:29: 8 1999 Delivered-To: freebsd-audit@freebsd.org Received: from tank.skynet.be (tank.skynet.be [195.238.2.35]) by hub.freebsd.org (Postfix) with ESMTP id 268AF150FF; Mon, 6 Dec 1999 03:29:03 -0800 (PST) (envelope-from root@foxbert.skynet.be) Received: from foxbert.skynet.be (foxbert.skynet.be [195.238.1.45]) by tank.skynet.be (8.9.3/odie-relay-v1.0) with ESMTP id MAA15484; Mon, 6 Dec 1999 12:28:59 +0100 (MET) Received: (from root@localhost) by foxbert.skynet.be (8.9.1/jovi-pop-2.1) id MAA25586; Mon, 6 Dec 1999 12:28:57 +0100 (MET) Mime-Version: 1.0 X-Sender: blk@foxbert.skynet.be Message-Id: In-Reply-To: <26871.944477622@axl.noc.iafrica.com> References: <26871.944477622@axl.noc.iafrica.com> Date: Mon, 6 Dec 1999 12:28:15 +0100 To: Sheldon Hearn , obrien@FreeBSD.ORG From: Brad Knowles Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern kern_fork.c src/sys/libkern arc4random.c src/sys/sys libkern.h Cc: arch@FreeBSD.ORG, audit@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 12:53 PM +0200 1999/12/6, Sheldon Hearn wrote: > Nah, just leave the historical linear assignment as the default mode > of operation for the sake of POLA and document the knob for random > assignment in rc.conf.5 and wherever else might be appropriate. I don't suppose that this is a democracy, and that we can each vote for the default we want to have, can we? I can't speak for the "convenience" of having linear PID assignment (I just can't imagine a way that anyone could take advantage of this in a "good" way). However, I can say that there are a boatload of dain-bramaged scripts out there that I think would have their security measurably increased (even if by a small amount), if this option were turned on. Hell, I think just about every script I've ever written would fall in this category. ;-) My understanding was that we're trying to increase the default security level of the OS, and unless there were really big problems in changing the defaults for something that would help us towards this goal, we would go ahead and make the change (properly documented and instrumented, of course). I mean, we *are* talking about -CURRENT here, right? It's my understanding that anyone running -CURRENT has to expect that the thing won't be usable (heck, may not even compile) at any one particular point in time, and if they want to actually try to use -CURRENT, it's their responsibility to track the mailing list, CVS commit log, etc... and then do their own work to make the system usable -- and then provide those changes back to the community, so that others can benefit. Unless I'm missing something fundamental here, I don't see why we can't make changes of this scale. Much larger changes have been made to -CURRENT in the past, and I'm sure that much larger changes will be made to -CURRENT in the future. It seems to me that the sort of stuff we're talking about would fit into that same mold, and could even be more important than some of the really huge changes that have been made previously -- those were just functionality, whereas now we're talking about security. If we don't make the leap now to try to raise the default security level of the OS, then when are we? -- These are my opinions -- not to be taken as official Skynet policy ____________________________________________________________________ |o| Brad Knowles, Belgacom Skynet NV/SA |o| |o| Systems Architect, News & FTP Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.11.11/12.49 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Mon Dec 6 3:35:18 1999 Delivered-To: freebsd-audit@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id F2CDF14CC3; Mon, 6 Dec 1999 03:35:08 -0800 (PST) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.11 #1) id 11uwPu-0007Jz-00; Mon, 06 Dec 1999 13:34:54 +0200 From: Sheldon Hearn To: Brad Knowles Cc: obrien@FreeBSD.ORG, arch@FreeBSD.ORG, audit@FreeBSD.ORG Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern kern_fork.c src/sys/libkern arc4random.c src/sys/sys libkern.h In-reply-to: Your message of "Mon, 06 Dec 1999 12:28:15 +0100." Date: Mon, 06 Dec 1999 13:34:54 +0200 Message-ID: <28146.944480094@axl.noc.iafrica.com> Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 06 Dec 1999 12:28:15 +0100, Brad Knowles wrote: > I mean, we *are* talking about -CURRENT here, right? It's my > understanding that anyone running -CURRENT has to expect that the > thing won't be usable One thing you're missing here is that CURRENT often _becomes_ STABLE later. :-) However, I think I agree with you. Perhaps a small POLA sacrifice for the sake of a large security gain is cool. I don't see a massive gain for day-to-day stuff myself, but folks are talking like it's a large gain. Some of them are sensible folks. ;-) Ciao, Sheldon. PS: Damnit, I didn't realize that the message I replied to originally was a cross-post. Sorry. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Mon Dec 6 4: 7:15 1999 Delivered-To: freebsd-audit@freebsd.org Received: from tank.skynet.be (tank.skynet.be [195.238.2.35]) by hub.freebsd.org (Postfix) with ESMTP id 7340914FCE; Mon, 6 Dec 1999 04:07:08 -0800 (PST) (envelope-from root@foxbert.skynet.be) Received: from foxbert.skynet.be (foxbert.skynet.be [195.238.1.45]) by tank.skynet.be (8.9.3/odie-relay-v1.0) with ESMTP id NAA24794; Mon, 6 Dec 1999 13:07:01 +0100 (MET) Received: (from root@localhost) by foxbert.skynet.be (8.9.1/jovi-pop-2.1) id NAA23530; Mon, 6 Dec 1999 13:06:58 +0100 (MET) Mime-Version: 1.0 X-Sender: blk@foxbert.skynet.be Message-Id: In-Reply-To: <28146.944480094@axl.noc.iafrica.com> References: <28146.944480094@axl.noc.iafrica.com> Date: Mon, 6 Dec 1999 13:05:24 +0100 To: Sheldon Hearn From: Brad Knowles Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern kern_fork.c src/sys/libkern arc4random.c src/sys/sys libkern.h Cc: obrien@FreeBSD.ORG, audit@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 1:34 PM +0200 1999/12/6, Sheldon Hearn wrote: > One thing you're missing here is that CURRENT often _becomes_ STABLE > later. :-) Understood. However, so long as it's -CURRENT, we can still make large changes, right? ;-) Speaking of which, if 4.0 is going to hit feature freeze pretty soon, does this mean that -CURRENT will become version 5.0? Will that happen automatically when 4.0 hits feature freeze, or are these two separate events? > However, I think I agree with you. Perhaps a small POLA sacrifice for > the sake of a large security gain is cool. I don't see a massive gain > for day-to-day stuff myself, but folks are talking like it's a large > gain. Some of them are sensible folks. ;-) Well, perhaps this particular thing isn't that big. This is one reason why I was so surprised to see people advocating that we don't change the default. However, if you collect all these "little" changes together, I think you arrive at something that is *huge*. What I'm trying to do is advocate a policy that allows us to more quickly get closer to where we want to be. > PS: Damnit, I didn't realize that the message I replied to originally > was a cross-post. Sorry. Damn. Caught me, too. I've removed the cross-post to -arch on this reply, and will let you have the last word on this subject on that list. ;-) -- These are my opinions -- not to be taken as official Skynet policy ____________________________________________________________________ |o| Brad Knowles, Belgacom Skynet NV/SA |o| |o| Systems Architect, News & FTP Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.11.11/12.49 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Mon Dec 6 7:57:41 1999 Delivered-To: freebsd-audit@freebsd.org Received: from smtp.manhattanprojects.com (smtp.manhattanprojects.com [207.181.119.22]) by hub.freebsd.org (Postfix) with ESMTP id 5D48315319; Mon, 6 Dec 1999 07:57:38 -0800 (PST) (envelope-from gerald@manhattanprojects.com) Received: from manhattanprojects.com (xs.lab.glc.com [10.0.0.14]) by smtp.manhattanprojects.com (8.9.1/8.8.7) with ESMTP id KAA27333; Mon, 6 Dec 1999 10:49:16 -0500 (EST) (envelope-from gerald@manhattanprojects.com) Message-ID: <384BDCF0.7CA47AA8@manhattanprojects.com> Date: Mon, 06 Dec 1999 10:57:36 -0500 From: Gerald Abshez X-Mailer: Mozilla 4.05 [en] (X11; I; FreeBSD 2.2.5-RELEASE i386) MIME-Version: 1.0 To: Kris Kennaway Cc: audit@FreeBSD.ORG Subject: Re: arp.c patch References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Kris Kennaway wrote: > > This one isn't likely exploitable, but it's still a small buffer overflow. > arp looks okay apart from this. Hmmm. A while back, a friend and I were discussing Firewalling and arp. It seems that arp accepted packets from anywhere. This was a problem, as my friend had a firewall, and someone had (improperly) hooked up a machine with an IP on the public side of the internet that corresponded with a machine on the private net. The firewall would simply move the address back and forth between the various interfaces. The traffic wouldn't go out, since it was blocked by the firewall, but I did think that this was an issue. (It's a DOS attack) I'm not sure that this has been addressed, and I thought I'd mention it since your patch reminded me of it. Gerald. -- This is your FreeBSD -- Where do YOU want to go tommorow? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Mon Dec 6 8: 1:12 1999 Delivered-To: freebsd-audit@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 2B2E814E30; Mon, 6 Dec 1999 08:01:07 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id LAA10811; Mon, 6 Dec 1999 11:00:59 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Mon, 6 Dec 1999 11:00:59 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Brad Knowles Cc: Sheldon Hearn , obrien@FreeBSD.ORG, arch@FreeBSD.ORG, audit@FreeBSD.ORG Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern kern_fork.c src/sys/libkern arc4random.c src/sys/sys libkern.h In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 6 Dec 1999, Brad Knowles wrote: > At 12:53 PM +0200 1999/12/6, Sheldon Hearn wrote: > > > Nah, just leave the historical linear assignment as the default mode > > of operation for the sake of POLA and document the knob for random > > assignment in rc.conf.5 and wherever else might be appropriate. > > I don't suppose that this is a democracy, and that we can each > vote for the default we want to have, can we? > > > I can't speak for the "convenience" of having linear PID > assignment (I just can't imagine a way that anyone could take > advantage of this in a "good" way). > > However, I can say that there are a boatload of dain-bramaged > scripts out there that I think would have their security measurably > increased (even if by a small amount), if this option were turned on. > Hell, I think just about every script I've ever written would fall in > this category. ;-) An interesting, although perhaps not useful, observation is that an attacker can easily coerce linear PID allocation to non-linear allocation, even without an account on the machine. Most daemons are quite happy to fork children with little provocation (i.e., a connection) and this chews through the PID space. Similarly, given an account, they can run #include while (1) if (fork()) exit(0); So it's clear that nothing should *rely* on linear allocation if it's going to resist disruption as the result of an attack. On the other hand, it has usefully been observed that poorly written scripts (over which we have no control, so can't fix) have been vulnerable as a result of predictable PID allocation--and while we can force non-linear PID allocation, there is no way for us to force linear allocation :-). I vote yes on this change (not that it's a democracy). On any busy system, especially an SMP machine, linear allocation of PIDs is an unsafe assumption, even during the boot process where, for example, named will spawn off an indefinite number of named-xfers based on third party changes to zone files, or where sendmail (and even route add default) are willing to block based on network conditions (name lookup availability), screwing around with ordering of events. For most debugging purposes, /var/run/whatever.pid, the PPID entry, and accounting (if desired) are quite adequate replacements. And there's always killall :-). Robert To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Tue Dec 7 7: 5:35 1999 Delivered-To: freebsd-audit@freebsd.org Received: from barracuda.aquarium.rtci.com (barracuda.aquarium.rtci.com [208.11.247.5]) by hub.freebsd.org (Postfix) with ESMTP id 0D2C014BF1 for ; Tue, 7 Dec 1999 07:05:33 -0800 (PST) (envelope-from tstromberg@rtci.com) Received: from karma (karma.afterthought.org [208.11.244.6]) by barracuda.aquarium.rtci.com (8.9.3+Sun/8.9.3) with SMTP id KAA03755 for ; Tue, 7 Dec 1999 10:05:32 -0500 (EST) Message-ID: <84728396.944579128399.JavaMail.chenresig@karma> Date: Tue, 7 Dec 1999 10:05:28 -0500 (EST) From: tstromberg@rtci.com To: freebsd-audit@freebsd.org Subject: FreeBSD-audit project & zombies galore. Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: ICEMail (rel 2.8.2) Organization: Research Triangle Commerce, Inc. Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG For the FreeBSD-auditing project I had previously been running the brute-force audit on just 4.0-CURRENT, but unfortunatly, 4.0-CURRENT was unstable enough that I started running it on a -STABLE box as well. Seeing as 3.4-RELEASE will be coming out in a few weeks, I also thought it'd be beneficial to see if we can't test & fix a bunch of the minor problems we've found.. I didn't expect "Night of the Living Dead" with 4000 zombie processes on my box. What the brute force tester does is try all sorts of combinations of enviroment, input, and argument overflows, and execs them all with the combinations. Some programs get ~3000 tests, but for instance, /usr/sbin/fixmount got 24771 different tests applied to it because of it's enviroment variables and it's linkage to libc & librpcsvc .. A lot of these programs timeout, and since I have better things to do I have a 2 second timeout to abort the system() that calls them. This created some zombies for me. Over 4000 of them to be exact. (sh) and (pax) were all over the process table. I tried to kill -9 them (hey, it worked in -CURRENT for the dozen or so I got), but the zombies were never reaped. I had to reboot to gain any control of the system again because I couldn't fork() anything to be useful after I had managed to login via console. Right now in perl I've just got an alarm(2) going before a system(@args).. after that I also do a killall on the program just in case it's hanging out in the background (will find a friendlier solution shortly). There must be a better way to do this, I just wonder if I will run into this if I add forking and kill my perl forks.. I already attempt to try to kill off the program after I abort it with a timeout (of course however, if say "blah" times out, but has spawned an sh shell, and I kill blah afterwards, the sh shell remains). I'm going to add some more knobs to the tester to say "abort tests when there are >X processes total running". This should be good for zombies because they dissappear when the perl script is completed. I'll probably also add some resource restrictions in login.conf for my testing account, but this doesn't help me so much when I have to do the Solaris tests. The basic questions I have are I guess: - What can I do to avoid having zombied processes? - What should I do to handle zombies processes correctly when they occur? - Why didn't this happen to me under -CURRENT? Right now some zombie favorites include: sh, pax, fpr, rcp.. I'm just going to monitor for now how many zombies happen, and skip tests on the executables that zombie out on me till I find a better way. BTW: I got permission to release the scripts, once I remove some of the more awful bugs & hacks, I'll go ahead and release it. This should happen over the weekend. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Tue Dec 7 9: 6: 3 1999 Delivered-To: freebsd-audit@freebsd.org Received: from barracuda.aquarium.rtci.com (barracuda.aquarium.rtci.com [208.11.247.5]) by hub.freebsd.org (Postfix) with ESMTP id 0D2DD14D1B for ; Tue, 7 Dec 1999 09:05:58 -0800 (PST) (envelope-from tstromberg@rtci.com) Received: from karma (karma.afterthought.org [208.11.244.6]) by barracuda.aquarium.rtci.com (8.9.3+Sun/8.9.3) with SMTP id MAA09291 for ; Tue, 7 Dec 1999 12:05:58 -0500 (EST) Message-ID: <84723845.944586353513.JavaMail.chenresig@karma> Date: Tue, 7 Dec 1999 12:05:53 -0500 (EST) From: tstromberg@rtci.com To: freebsd-audit@freebsd.org Subject: 10 more overflows (minor) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: ICEMail (rel 2.8.2) Organization: Research Triangle Commerce, Inc. Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I found another 10 minor overflows today. I'm about to put up a webpage with a nice table as far as what's been discovered/fixed/etc, hope to have it up by tommorow. If you have fixed an exploit I have found, please tell me so I can do a retest on it and mark it off as fixed. Many of these programs are bound to have multiple overflows, so I'll have to retest them later. I'm reposting all of them for some people new to the list. 38 overflows now. If that doesn't make you want to move forward with the FreeBSD-audit project, I don't know what will! Binaries Tested: 405 Binaries Total: 763 Binaries Left: 358 * = setuid/sgid, + = fixed 07DEC99 /usr/sbin/fsinfo fsinfo -D [3000] 07DEC99 /usr/bin/tconv set $TERMCAP to [2000], tconv -D blah 07DEC99 /usr/libexec/f771 stdin overflow, echo [2000] | f771 -G 07DEC99 /usr/bin/rs stdin overflow, echo [1000] | rs (handled) 07DEC99 /usr/libexec/getty stdin overflow, echo [2000] | getty -x 07DEC99 /usr/libexec/elf/as as [65000] 07DEC99 /usr/libexec/aout/as as [65000] 07DEC99 /usr/bin/rpcgen rpcgen -Y [8192] 07DEC99 /usr/bin/jot jot -w [8192] (all args) 07DEC99 /usr/bin/indent set $HOME to [8192] Older Ones: ----------- 03DEC99 /usr/bin/error error -I [16384] 03DEC99 /usr/bin/fsplit fsplit -e [16384] 03DEC99 /usr/bin/grops grops -c blah [16384] 03DEC99 /usr/bin/patch patch -r [16384] 03DEC99 /usr/bin/pr+ pr -s [16384] 03DEC99 /usr/bin/ypcat+ ypcat -d [16384] blah 03DEC99 /usr/libexec/aout/as stdin overflow, echo [16384] | as -I 30NOV99 /usr/bin/awk awk -f [8192] 30NOV99 /usr/bin/ee set $NLSPATH to [32769] 30NOV99 /usr/bin/doscmd doscmd [4000] 30NOV99 /usr/bin/dnsquery dnsquery [4000] 30NOV99 /usr/bin/dig dig -k [16000] 30NOV99 /usr/bin/crunchgen crunchgen [8192] 30NOV99 /usr/bin/colldef colldef -I [8192] 30NOV99 /usr/bin/captoinfo set $TERMCAP to [32769] 30NOV99 /usr/bin/banner+ banner [8192] 30NOV99 /usr/bin/as as [8192] 30NOV99 /usr/bin/apply startslip -d [8192] -c [8192] 30NOV99 /usr/bin/Mail set $HOME to [32769] 30NOV99 /sbin/startslip startslip -d [8192] -c [8192] 30NOV99 /sbin/natd natd -w [16384] blah 30NOV99 /sbin/mount_mfs mount_mfs [8192] [8192] 30NOV99 /sbin/dhclient dhclient [40000] 30NOV99 /bin/red red [40000] 30NOV99 /bin/ed ed [40000] 15NOV99 /usr/bin/systat* race condition with bad exit 10NOV99 /sbin/rdump*+ dump -0 [1024] 10NOV99 /sbin/dump*+ dump -0 [1024] PS. Sorry for the bad pasting ============================================================================ Thomas R. Stromberg Asst. IS Manager / Systems Guru FreeBSD Contrib, BeOS Dev, Security Geek Research Triangle Commerce, Inc. http://www.afterthought.org/ http://www.rtci.com/ thomas@stromberg.org tstromberg@rtci.com ======================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Tue Dec 7 10:58:13 1999 Delivered-To: freebsd-audit@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 20DD514D42 for ; Tue, 7 Dec 1999 10:58:06 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id NAA17811; Tue, 7 Dec 1999 13:58:00 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Tue, 7 Dec 1999 13:57:59 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: tstromberg@rtci.com Cc: freebsd-audit@freebsd.org Subject: Re: 10 more overflows (minor) In-Reply-To: <84723845.944586353513.JavaMail.chenresig@karma> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Those ones in dump/etc are nasty. :-) So, right now you grab environment information from the binaries, but you could also instrument libc (and others) to report on their use of getenv/etc to some logging mechanism, and then attempt to exploit the ones used. This would help you in situations (that might exist) where the program uses variable string pointers to call getenv. Also, with the fts_ stuff a while, back, that raises the issue of long filenames as a potential source of suffering. Not sure how easy that would be to test, but really suggests a libc test harness (or syscall test harness) that causes unpleasentness for processes running in it. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Tue Dec 7 13:18:53 1999 Delivered-To: freebsd-audit@freebsd.org Received: from barracuda.aquarium.rtci.com (barracuda.aquarium.rtci.com [208.11.247.5]) by hub.freebsd.org (Postfix) with ESMTP id 20EBD14E8B for ; Tue, 7 Dec 1999 13:18:44 -0800 (PST) (envelope-from tstromberg@rtci.com) Received: from karma (karma.afterthought.org [208.11.244.6]) by barracuda.aquarium.rtci.com (8.9.3+Sun/8.9.3) with SMTP id QAA17319 for ; Tue, 7 Dec 1999 16:18:43 -0500 (EST) Received: from cvs.openbsd.org (cvs.openbsd.org [199.185.137.3]) by barracuda.aquarium.rtci.com (8.9.3+Sun/8.9.3) with ESMTP id OAA14286 for ; Tue, 7 Dec 1999 14:46:41 -0500 (EST) Received: from cvs.openbsd.org (IDENT:deraadt@localhost [127.0.0.1]) by cvs.openbsd.org (8.9.3/8.9.1) with ESMTP id MAA18862; Tue, 7 Dec 1999 12:46:18 -0700 (MST) Message-ID: <84714733.944601517508.JavaMail.chenresig@karma> Date: Tue, 07 Dec 1999 12:46:18 -0700 From: tstromberg@rtci.com To: freebsd-audit@freebsd.org Subject: FW: Buffer overflows Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Scanned-By: AntiMail $Revision: 1.57 $ by Thomas Stromberg [RTCI] X-Mailer: ICEMail (rel 2.8.2) Organization: Research Triangle Commerce, Inc. Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This was sent to me by Theo DeRaadt (everyone on this list should be familiar with him). I thought you guys might be interested since we seem to be helping each other quite a bit. We may want to integrate several of their programs as we see here, or at least apply similar fixes if need be. On a side note, I managed to accidentally trash all of my testing data by removing the wrong directory, but at least it's forced me to rewrite some large portions of the testing code. I've added (and fixed) several more tests, and found an interim solutions to all of the lovely zombies I've been getting. Hopefully the zombie fixes will mean less reboots for me in -CURRENT. I guess this means I get to re-run through all of the binaries, this time however I'll have simultaneous testing with -CURRENT, two -STABLE machines, Solaris 7. Right now I've got one of our admins installing an OpenBSD 2.6 system for tests as well. Hi Thomas. Referencing: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=41804+0+current/freebsd-audit -------------------- 07DEC99 /usr/sbin/fsinfo fsinfo -D [3000] 07DEC99 /usr/bin/tconv set $TERMCAP to [2000], tconv -D blah These are not in openbsd. 07DEC99 /usr/libexec/f771 stdin overflow, echo [2000] | f771 -G OpenBSD f77 does not show this bug; we use the brand new gcc 2.95.1 codebase. 07DEC99 /usr/bin/rs stdin overflow, echo [1000] | rs (handled) revision 1.2 date: 1996/05/21 21:37:11; author: deraadt; state: Exp; lines: +46 -45 avoid divide-by-zero trap when specifying small widths do not overrun entry array when printing output tables cleanup storage allocation for entries use err/warn etc. 07DEC99 /usr/libexec/getty stdin overflow, echo [2000] | getty -x Just fixed. revision 1.13 date: 1999/12/07 19:24:27; author: deraadt; state: Exp; lines: +7 -5 do not crash if stdin is not a tty 07DEC99 /usr/libexec/elf/as as [65000] 07DEC99 /usr/libexec/aout/as as [65000] Cannot reproduce. 07DEC99 /usr/bin/rpcgen rpcgen -Y [8192] revision 1.4 date: 1999/12/04 21:58:31; author: deraadt; state: Exp; lines: +6 -5 oflow Note the date very carefully. That's what I call 'proactive' 07DEC99 /usr/bin/jot jot -w [8192] (all args) revision 1.4 date: 1999/12/04 21:28:34; author: deraadt; state: Exp; lines: +8 -4 more oflows Again, note the date. 07DEC99 /usr/bin/indent set $HOME to [8192] revision 1.3 date: 1996/10/28 00:36:23; author: millert; state: Exp; lines: +7 -2 Safe $HOME usage. 03DEC99 /usr/bin/error error -I [16384] revision 1.5 date: 1999/12/04 00:16:52; author: deraadt; state: Exp; lines: +11 -9 avoid overflows 03DEC99 /usr/bin/fsplit fsplit -e [16384] We have not fixed the 10 problems in fsplit yet. We may just remove it, since noone uses it. 03DEC99 /usr/bin/grops grops -c blah [16384] Not fixed yet. 03DEC99 /usr/bin/patch patch -r [16384] patch.c: ---------------------------- revision 1.13 date: 1999/12/04 01:01:06; author: provos; state: Exp; lines: +9 -5 avoid overflows util.c revision 1.9 date: 1999/12/04 21:00:03; author: provos; state: Exp; lines: +19 -40 a few more overflows gone ---------------------------- revision 1.8 date: 1999/12/04 01:04:14; author: provos; state: Exp; lines: +3 -3 revert strlcpy to strcpy for one case. ---------------------------- revision 1.7 date: 1999/12/04 01:01:07; author: provos; state: Exp; lines: +12 -9 avoid overflows pch.c revision 1.10 date: 1999/12/04 01:01:07; author: provos; state: Exp; lines: +7 -7 avoid overflows ---------------------------- 03DEC99 /usr/bin/pr+ pr -s [16384] date: 1999/12/03 23:43:02; author: deraadt; state: Exp; lines: +8 -7 the -s option was broken; spotted by tstromberg@rtci.com on freebsd-audit, but i have not seen them fix any of the bugs That one includes a little bit of realistic commentary. 03DEC99 /usr/bin/ypcat+ ypcat -d [16384] blah This bug was fixed almost 4 years ago. 03DEC99 /usr/libexec/aout/as stdin overflow, echo [16384] | as -I This bug still exists. 30NOV99 /usr/bin/awk awk -f [8192] We use a different awk; the true Kernighan version. That said, we found other bugs and fixed them: revision 1.8 date: 1999/12/04 00:12:25; author: millert; state: Exp; lines: +6 -2 Fix 2 core dumps: 1) give an error if the user specifies > 20 -f options instead of oflowing 2) use snprintf in the ERROR macro to avoid an oflow 30NOV99 /usr/bin/ee set $NLSPATH to [32769] 30NOV99 /usr/bin/doscmd doscmd [4000] Not in OpenBSD. 30NOV99 /usr/bin/dnsquery dnsquery [4000] revision 1.4 date: 1999/12/04 00:22:34; author: deraadt; state: Exp; lines: +15 -4 avoid overflow 30NOV99 /usr/bin/dig dig -k [16000] This is a disaster. We've not fixed it yet. 30NOV99 /usr/bin/crunchgen crunchgen [8192] revision 1.15 date: 1999/12/06 01:47:58; author: deraadt; state: Exp; lines: +46 -16 oflow fixes; provos 30NOV99 /usr/bin/colldef colldef -I [8192] Not in OpenBSD. 30NOV99 /usr/bin/captoinfo set $TERMCAP to [32769] Not reproduceable. We use brand new ncurses. 30NOV99 /usr/bin/banner+ banner [8192] Must have been a bug introduced by FreeBSD. 30NOV99 /usr/bin/as as [8192] Not reproduceable. 30NOV99 /usr/bin/apply startslip -d [8192] -c [8192] revision 1.6 date: 1999/12/03 23:55:18; author: deraadt; state: Exp; lines: +3 -3 off by one for string length calculation Note that FreeBSD has the same fix, but this patch went out a few hours before it was fixed in FreeBSD.... 30NOV99 /usr/bin/Mail set $HOME to [32769] revision 1.4 date: 1996/10/28 00:42:21; author: millert; state: Exp; lines: +3 -3 Ignore $HOME if > MAXPATHLEN 30NOV99 /sbin/startslip startslip -d [8192] -c [8192] 30NOV99 /sbin/natd natd -w [16384] blah Not in OpenBSD. 30NOV99 /sbin/mount_mfs mount_mfs [8192] [8192] Bug not in OpenBSD. 30NOV99 /sbin/dhclient dhclient [40000] revision 1.7 date: 1999/12/04 00:15:09; author: angelos; state: Exp; lines: +2 -2 Careful with long, command-line provided interface names. 30NOV99 /bin/red red [40000] 30NOV99 /bin/ed ed [40000] revision 1.14 date: 1998/05/18 20:36:14; author: deraadt; state: Exp; lines: +27 -13 buf oflows 15NOV99 /usr/bin/systat* race condition with bad exit I have never seen that bug. I do know of another two bugs in systat, not security related, but have not managed to reproduce them. 10NOV99 /sbin/rdump*+ dump -0 [1024] 10NOV99 /sbin/dump*+ dump -0 [1024] Numerous fixes over the years for buffer overflows, including: revision 1.25 date: 1998/11/24 01:25:47; author: deraadt; state: Exp; lines: +2 -2 Wall, and do not let tapesize overflow -------------------- revision 1.21 date: 1998/08/07 17:29:25; author: millert; state: Exp; lines: +23 -23 Use strlcpy() instead of strncpy(). Change the order of name -> raw device conversions 1) statfs the name and use that info iff the name is the mount point 2) look up name in fstab 3) treat as a device The reason for this is that the mounted filesystems may not agree with what fstab says. Anyone who has ever moved disks around and accidentally dumped and empty filesystem will know what I mean. -------------------- revision 1.9 date: 1996/09/14 03:26:02; author: millert; state: Exp; lines: +1 -2 Now uses "wall -g" so no need to be setgid tty. This makes $RSH work. Also fix buf oflow. ---- revision 1.5 date: 1996/08/02 10:26:48; author: deraadt; state: Exp; lines: +3 -3 mostly harmless buffer overflow I grant you permission to re-post this to the freebsd mailing lists. I don't post there, but you may repost this, if it helps your cause. If there is any doubt as to what the freebsd-audit project is, and how freebsd deals with code quality concerns, this should be it. But moreso, it says who OpenBSD is. OpenBSD people -- we've got a few more bugs to squish. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Tue Dec 7 13:36:22 1999 Delivered-To: freebsd-audit@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 40CBC154D5; Tue, 7 Dec 1999 13:36:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 2FE0A1CD41E; Tue, 7 Dec 1999 13:36:19 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Tue, 7 Dec 1999 13:36:19 -0800 (PST) From: Kris Kennaway To: tstromberg@rtci.com Cc: freebsd-audit@freebsd.org Subject: Re: FW: Buffer overflows In-Reply-To: <84714733.944601517508.JavaMail.chenresig@karma> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 7 Dec 1999 tstromberg@rtci.com wrote: > This was sent to me by Theo DeRaadt (everyone on this list should be > familiar with him). I thought you guys might be interested since we > seem to be helping each other quite a bit. We may want to integrate > several of their programs as we see here, or at least apply similar > fixes if need be. I'm going through and merging across all of the fixes from OpenBSD (/bin is almost done so far). However, at least a few of the OpenBSD ones were unfortunately bogus (using the sizeof() of your source, not destination string, etc) or otherwise not quite right (corrected an off-by-one error with another more benign off-by-one error, etc), so it's not completely trivial. Plus, there's no guarantee they've found all of the problems (e.g. the recent flurry of commits since your posts here :), and our codebases are slightly divergent, so we still have further work to do. I probably won't have much time to work on this further until January, as I'm trying to get OpenSSL cleaned up for committing, have exams to study for, and I'm going home over christmas :-) Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Thu Dec 9 12: 7:16 1999 Delivered-To: freebsd-audit@freebsd.org Received: from ints.ru (ints.ru [194.67.173.1]) by hub.freebsd.org (Postfix) with ESMTP id 1D239156B0; Thu, 9 Dec 1999 12:07:11 -0800 (PST) (envelope-from ilmar@ints.ru) Received: (from uucp@localhost) by ints.ru (8.9.2/8.9.2) id XAA28693; Thu, 9 Dec 1999 23:07:04 +0300 (MSK) Received: from ws-ilmar.ints.ru(194.67.173.16) via SMTP by ints.ru, id smtpdV28691; Thu Dec 9 23:07:03 1999 Received: from localhost (localhost [127.0.0.1]) by ws-ilmar.ints.ru (8.9.3/8.9.3) with ESMTP id XAA00600; Thu, 9 Dec 1999 23:07:02 +0300 (MSK) Date: Thu, 9 Dec 1999 23:07:02 +0300 (MSK) From: "Ilmar S. Habibulin" To: freebsd-audit@FreeBSD.ORG Cc: freebsd-security@FreeBSD.ORG Subject: question to auditors In-Reply-To: <84714733.944601517508.JavaMail.chenresig@karma> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm wondering what do you guys search in the sources. I know that there are some functions like gets(), which don't check bounds of arrays, and possible problems with setuid/setgid bits. So i have some questions like: - what is the full list of risky functions - what else could be a treat to security, integrety or functionality of some application - or where can i find full answers to my maybe stupid questions Thanx. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Thu Dec 9 13:13:19 1999 Delivered-To: freebsd-audit@freebsd.org Received: from kronos.alcnet.com (kronos.alcnet.com [63.69.28.22]) by hub.freebsd.org (Postfix) with ESMTP id 7752215682; Thu, 9 Dec 1999 13:13:08 -0800 (PST) (envelope-from kbyanc@posi.net) X-Provider: ALC Communications, Inc. http://www.alcnet.com/ Received: from localhost (kbyanc@localhost) by kronos.alcnet.com (8.9.3/8.9.3/antispam) with ESMTP id QAA23898; Thu, 9 Dec 1999 16:13:03 -0500 (EST) Date: Thu, 9 Dec 1999 16:13:03 -0500 (EST) From: Kelly Yancey X-Sender: kbyanc@kronos.alcnet.com To: "Ilmar S. Habibulin" Cc: freebsd-audit@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: question to auditors In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 9 Dec 1999, Ilmar S. Habibulin wrote: > > I'm wondering what do you guys search in the sources. I know that there > are some functions like gets(), which don't check bounds of arrays, and > possible problems with setuid/setgid bits. So i have some questions like: > > - what is the full list of risky functions > - what else could be a treat to security, integrety or functionality of > some application > - or where can i find full answers to my maybe stupid questions > Well, I'm working on a web site where such information will be located (along with the audit progress itself). Unfortunately, the holidays are slowing development :( Kelly -- Kelly Yancey - kbyanc@posi.net - Richmond, VA Director of Technical Services, ALC Communications http://www.alcnet.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSD http://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Thu Dec 9 13:51:34 1999 Delivered-To: freebsd-audit@freebsd.org Received: from mail001.mediacity.com (mail001.mediacity.com [205.216.172.9]) by hub.freebsd.org (Postfix) with SMTP id 0C518152DD for ; Thu, 9 Dec 1999 13:51:31 -0800 (PST) (envelope-from spock@techfour.net) Received: (qmail 6627 invoked from network); 9 Dec 1999 21:51:29 -0000 Received: from cm-208-138-198-17.fredericksburg.mg.ispchannel.com (HELO enterprise.muriel.penguinpowered.com) (208.138.198.17) by mail001.mediacity.com with SMTP; 9 Dec 1999 21:51:29 -0000 Content-Length: 794 Message-ID: X-Mailer: XFMail 1.3.1 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: X-SENDERNAME: `Mike Heffner` Date: Thu, 09 Dec 1999 16:51:53 -0500 (EST) From: Mike Heffner To: "Ilmar S. Habibulin" Subject: RE: question to auditors Cc: freebsd-security@FreeBSD.ORG, freebsd-audit@FreeBSD.ORG Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 09-Dec-99 Ilmar S. Habibulin said: | | I'm wondering what do you guys search in the sources. I know that there | are some functions like gets(), which don't check bounds of arrays, and | possible problems with setuid/setgid bits. So i have some questions like: | | - what is the full list of risky functions | - what else could be a treat to security, integrety or functionality of | some application | - or where can i find full answers to my maybe stupid questions | There's a short list of some trouble spots at: http://www.freebsd.org/security/ as well as other links to security related sites. --------------------------------- Mike Heffner Fredericksburg, VA ICQ# 882073 Date: 09-Dec-99 Time: 16:50:04 --------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Fri Dec 10 0:18:36 1999 Delivered-To: freebsd-audit@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id BBA5B152DF for ; Fri, 10 Dec 1999 00:18:27 -0800 (PST) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.11 #1) id 11wLFk-00023o-00; Fri, 10 Dec 1999 10:18:12 +0200 From: Sheldon Hearn To: "Ilmar S. Habibulin" Cc: freebsd-audit@FreeBSD.ORG Subject: Re: question to auditors In-reply-to: Your message of "Thu, 09 Dec 1999 23:07:02 +0300." Date: Fri, 10 Dec 1999 10:18:12 +0200 Message-ID: <7923.944813892@axl.noc.iafrica.com> Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 09 Dec 1999 23:07:02 +0300, "Ilmar S. Habibulin" wrote: > - what is the full list of risky functions > - what else could be a treat to security, integrety or functionality of > some application > - or where can i find full answers to my maybe stupid questions Unfortunately, most of this discussion took place on the -current mailing list. Look through the -current archives from 23 Nov 1999 for messages with the subject: Re: FreeBSD security auditing project. You'll find lots of valuable discussion in there. Ciao, Sheldon. PS: The cross-post was naughty. :-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Fri Dec 10 9:18:21 1999 Delivered-To: freebsd-audit@freebsd.org Received: from ints.ru (ints.ru [194.67.173.1]) by hub.freebsd.org (Postfix) with ESMTP id 421D3157B6 for ; Fri, 10 Dec 1999 09:18:14 -0800 (PST) (envelope-from ilmar@ints.ru) Received: (from uucp@localhost) by ints.ru (8.9.2/8.9.2) id UAA04034 for ; Fri, 10 Dec 1999 20:18:12 +0300 (MSK) Received: from ws-ilmar.ints.ru(194.67.173.16) via SMTP by ints.ru, id smtpdff4031; Fri Dec 10 20:18:02 1999 Received: from localhost (localhost [127.0.0.1]) by ws-ilmar.ints.ru (8.9.3/8.9.3) with ESMTP id UAA39394 for ; Fri, 10 Dec 1999 20:18:01 +0300 (MSK) Date: Fri, 10 Dec 1999 20:18:00 +0300 (MSK) From: "Ilmar S. Habibulin" To: freebsd-audit@FreeBSD.ORG Subject: Re: question to auditors In-Reply-To: <7923.944813892@axl.noc.iafrica.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Thanks for everybody. btw, the great url is http://www.freebsd.org/auditors.html To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Fri Dec 10 11:24: 0 1999 Delivered-To: freebsd-audit@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 4E33D1585E for ; Fri, 10 Dec 1999 11:19:55 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id OAA35614; Fri, 10 Dec 1999 14:19:51 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Fri, 10 Dec 1999 14:19:50 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: "Ilmar S. Habibulin" Cc: freebsd-audit@FreeBSD.ORG Subject: Re: question to auditors In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG My impression was that this page describes the "old" auditing project, not the "new" project. For example, I don't know whether the email addresses/etc still apply. On Fri, 10 Dec 1999, Ilmar S. Habibulin wrote: > > Thanks for everybody. btw, the great url is > http://www.freebsd.org/auditors.html > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-audit" in the body of the message > Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Fri Dec 10 11:33:39 1999 Delivered-To: freebsd-audit@freebsd.org Received: from ints.ru (ints.ru [194.67.173.1]) by hub.freebsd.org (Postfix) with ESMTP id 7844715B88 for ; Fri, 10 Dec 1999 11:28:58 -0800 (PST) (envelope-from ilmar@ints.ru) Received: (from uucp@localhost) by ints.ru (8.9.2/8.9.2) id WAA12151; Fri, 10 Dec 1999 22:28:48 +0300 (MSK) Received: from ws-ilmar.ints.ru(194.67.173.16) via SMTP by ints.ru, id smtpdC12149; Fri Dec 10 22:28:46 1999 Received: from localhost (localhost [127.0.0.1]) by ws-ilmar.ints.ru (8.9.3/8.9.3) with ESMTP id WAA43264; Fri, 10 Dec 1999 22:28:45 +0300 (MSK) Date: Fri, 10 Dec 1999 22:28:44 +0300 (MSK) From: "Ilmar S. Habibulin" To: Robert Watson Cc: freebsd-audit@FreeBSD.ORG Subject: Re: question to auditors In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 10 Dec 1999, Robert Watson wrote: > My impression was that this page describes the "old" auditing project, not > the "new" project. > For example, I don't know whether the email addresses/etc still apply. > > http://www.freebsd.org/auditors.html There is some links, that are helpful i think. So even it is old project this url contains some interesting info. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Fri Dec 10 11:52:26 1999 Delivered-To: freebsd-audit@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 83ACA1598D for ; Fri, 10 Dec 1999 11:48:42 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id MAA56420; Fri, 10 Dec 1999 12:48:35 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id MAA24297; Fri, 10 Dec 1999 12:48:35 -0700 (MST) Message-Id: <199912101948.MAA24297@harmony.village.org> To: Robert Watson Subject: Re: question to auditors Cc: "Ilmar S. Habibulin" , freebsd-audit@FreeBSD.ORG In-reply-to: Your message of "Fri, 10 Dec 1999 14:19:50 EST." References: Date: Fri, 10 Dec 1999 12:48:35 -0700 From: Warner Losh Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Robert Watson writes: : My impression was that this page describes the "old" auditing project, not : the "new" project. Likely. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message