From owner-freebsd-audit Sun Nov 28 1:15:11 1999 Delivered-To: freebsd-audit@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 2B97D14E1A; Sun, 28 Nov 1999 01:15:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 13AB41CD44A; Sun, 28 Nov 1999 01:15:08 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Sun, 28 Nov 1999 01:15:08 -0800 (PST) From: Kris Kennaway To: Dan Moschuk Cc: freebsd-audit@freebsd.org Subject: Re: Last random PID patch before commit In-Reply-To: <19991128012420.A48334@spirit.jaded.net> 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, 28 Nov 1999, Dan Moschuk wrote: > Here's the last functionality change before I commit this. I doubt that using > random() to generate the key used to shuffle the ARC4 algorithm is the > absolute best way of doing it, but, It Works(tm). The other option I looked > at was read_random(), but I'm not 100% certain that it will have built up > sufficient entropy by the time the code is called (usually at bootup). You seed random() using the current time. This is practically a known quantity, since the system boot time is public information (you just have to guess the delta until the RNG was initialised). Using /dev/random seems much better, as you at least have some entropy (to be certain, you could measure how much is in the pool at the time the RNG is seeded). I'm not sure why you didn't just use the existing arc4random.c implementation, which a) seeds both using the time, and whatever is already in the entropy pool at that point, and b) reseeds periodically. > static int nextpid = 0; > > +static int randompid = 0; > +SYSCTL_INT(_kern, OID_AUTO, randompid, CTLFLAG_RW, &randompid, 0, ""); > + > int > fork1(p1, flags, procp) > struct proc *p1; > @@ -262,8 +265,8 @@ > * restart somewhat above 0, as the low-numbered procs > * tend to include daemons that don't exit. > */ > - if (nextpid >= PID_MAX) { > - nextpid = 100; > + if (nextpid >= PID_MAX || randompid) { > + nextpid = (randompid) ? arc4random() % PID_MAX : 100; > pidchecked = 0; > } You only seem to be randomizing the PIDs in the case when they wrap around to 0. OpenBSD have an extra conditional in there which forces this to always be the case. > Index: libkern/arc4random.c > =================================================================== > RCS file: arc4random.c > diff -N arc4random.c > --- /dev/null Sat Nov 27 21:16:45 1999 > +++ arc4random.c Sat Nov 27 22:05:05 1999 > @@ -0,0 +1,95 @@ > +/*- > + * THE BEER-WARE LICENSE > + * > + * wrote this file. As long as you retain this notice you > + * can do whatever you want with this stuff. If we meet some day, and you > + * think this stuff is worth it, you can buy me a beer in return. Why not just use the arc4random.c we already have (+ any openbsd changes) and tweak it, instead of rewriting from scratch? sys/dev/rnd.c in OpenBSD.. Kris ---- Just remember, as you celebrate Thanksgiving with your family feasts of turkey, cranberries, stuffing, gravy, mashed potatoes, squash, corn, cornbread, apples, pickles, dumplings, fish, orangutans, fruitbats, breakfast cereals, and so forth, to keep in mind the true reason for the season: The birth of Santa. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Sun Nov 28 10: 4:39 1999 Delivered-To: freebsd-audit@freebsd.org Received: from november.jaded.net (november.jaded.net [216.94.113.4]) by hub.freebsd.org (Postfix) with ESMTP id 2869F152F9; Sun, 28 Nov 1999 10:04:35 -0800 (PST) (envelope-from dan@november.jaded.net) Received: (from dan@localhost) by november.jaded.net (8.9.3/8.9.3+trinsec_nospam) id NAA33076; Sun, 28 Nov 1999 13:04:32 -0500 (EST) Date: Sun, 28 Nov 1999 13:04:32 -0500 From: Dan Moschuk To: Kris Kennaway Cc: freebsd-audit@freebsd.org Subject: Re: Last random PID patch before commit Message-ID: <19991128130432.C33028@november.jaded.net> References: <19991128012420.A48334@spirit.jaded.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: ; from Kris Kennaway on Sun, Nov 28, 1999 at 01:15:08AM -0800 Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG | You seed random() using the current time. This is practically a | known quantity, since the system boot time is public | information (you just have to guess the delta until the RNG was | initialised). Using /dev/random seems much better, as you at least have | some entropy (to be certain, you could measure how much is in the pool at | the time the RNG is seeded). I'm not sure why you didn't just use the | existing arc4random.c implementation, which a) seeds both using the time, | and whatever is already in the entropy pool at that point, and b) reseeds | periodically. Correct. That's probably not the best way of doing it, however, I'm not convinced that /dev/random is the best way either. My other idea was to leave key[256] uninitialized and just use whatever happens to be there. | > static int nextpid = 0; | > | > +static int randompid = 0; | > +SYSCTL_INT(_kern, OID_AUTO, randompid, CTLFLAG_RW, &randompid, 0, ""); | > + | > int | > fork1(p1, flags, procp) | > struct proc *p1; | > @@ -262,8 +265,8 @@ | > * restart somewhat above 0, as the low-numbered procs | > * tend to include daemons that don't exit. | > */ | > - if (nextpid >= PID_MAX) { | > - nextpid = 100; | > + if (nextpid >= PID_MAX || randompid) { | > + nextpid = (randompid) ? arc4random() % PID_MAX : 100; | > pidchecked = 0; | > } | | You only seem to be randomizing the PIDs in the case when they wrap around | to 0. OpenBSD have an extra conditional in there which forces this to | always be the case. Err. Check that again. if (nextpid >= PID_MAX *OR* randompid is not zero) nextpid = 100 if randompid is zero or arc4random() MOD PID_MAX if it is non zero | Why not just use the arc4random.c we already have (+ any openbsd changes) | and tweak it, instead of rewriting from scratch? sys/dev/rnd.c in | OpenBSD.. A few reasons. i) At the time, I planned on arc4random.c becoming arc4.c in favour of my if_vpn that I hope to get around to actually writing. However, it soon dawned on me that using a stream cipher for an unreliable transmit medium (ie Internet) is *VERY* stupid (think packet loss). ii) It's more fun writing it from scratch. :-) -- Dan Moschuk (TFreak!dan@freebsd.org) "Try not. Do, or do not. There is no try." -- Yoda To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Sun Nov 28 11: 6:37 1999 Delivered-To: freebsd-audit@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id ADE4114E79; Sun, 28 Nov 1999 11:06:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 9EC391CD741; Sun, 28 Nov 1999 11:06:35 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Sun, 28 Nov 1999 11:06:35 -0800 (PST) From: Kris Kennaway To: Dan Moschuk Cc: freebsd-audit@freebsd.org Subject: Re: Last random PID patch before commit In-Reply-To: <19991128130432.C33028@november.jaded.net> 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, 28 Nov 1999, Dan Moschuk wrote: > Correct. That's probably not the best way of doing it, however, I'm not > convinced that /dev/random is the best way either. My other idea was to Why not? I've shown it's at least better than your current implementation. If you're worried about having 0 entropy in the pool (which would degenerate it to the strength of what's in your patch now) then you should add some instrumentation to your test kernel to print the size of the pool at initialisation time. Trying to guess things isn't a good idea when you're trying to improve security. > leave key[256] uninitialized and just use whatever happens to be there. Erk - this sounds even worse. How do you know that is going to be anywhere close to random? > | > + if (nextpid >= PID_MAX || randompid) { > | > + nextpid = (randompid) ? arc4random() % PID_MAX : 100; > | > pidchecked = 0; > | > } > | > | You only seem to be randomizing the PIDs in the case when they wrap around > | to 0. OpenBSD have an extra conditional in there which forces this to > | always be the case. > > Err. Check that again. My mistake, sorry. I was on a slow link and got confused trying to compare the code on the other end. > | Why not just use the arc4random.c we already have (+ any openbsd changes) > | and tweak it, instead of rewriting from scratch? sys/dev/rnd.c in > | OpenBSD.. > > A few reasons. > > i) At the time, I planned on arc4random.c becoming arc4.c in favour of my > if_vpn that I hope to get around to actually writing. However, it soon > dawned on me that using a stream cipher for an unreliable transmit medium > (ie Internet) is *VERY* stupid (think packet loss). > > ii) It's more fun writing it from scratch. :-) NIH :-) Please just use arc4random.c..as I described in my last message, it's a better implementation, and we're reducing our long-term maintenance burden. -Kris ---- Just remember, as you celebrate Thanksgiving with your family feasts of turkey, cranberries, stuffing, gravy, mashed potatoes, squash, corn, cornbread, apples, pickles, dumplings, fish, orangutans, fruitbats, breakfast cereals, and so forth, to keep in mind the true reason for the season: The birth of Santa. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Sun Nov 28 11:11:46 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 D9E5514E79; Sun, 28 Nov 1999 11:11:41 -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 MAA29462; Sun, 28 Nov 1999 12:11:39 -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 MAA85867; Sun, 28 Nov 1999 12:11:52 -0700 (MST) Message-Id: <199911281911.MAA85867@harmony.village.org> To: Dan Moschuk Subject: Re: Last random PID patch before commit Cc: Kris Kennaway , freebsd-audit@FreeBSD.ORG In-reply-to: Your message of "Sun, 28 Nov 1999 13:04:32 EST." <19991128130432.C33028@november.jaded.net> References: <19991128130432.C33028@november.jaded.net> <19991128012420.A48334@spirit.jaded.net> Date: Sun, 28 Nov 1999 12:11:52 -0700 From: Warner Losh Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <19991128130432.C33028@november.jaded.net> Dan Moschuk writes: : Correct. That's probably not the best way of doing it, however, I'm not : convinced that /dev/random is the best way either. My other idea was to : leave key[256] uninitialized and just use whatever happens to be there. Hmmm. I think this is a bad idea. The key won't be sufficently random since you can count on a number of bits in the stack garbage being set due to kernel addresses. This weakens the resulting randomness from 2048 bits down to 1500ish bits (assumnig that my read of the code gives key a 8 bit size). What's wrong with the /dev/random random number stream? This is exactly the sort of thing that it is designed for.... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Sun Nov 28 11:24:27 1999 Delivered-To: freebsd-audit@freebsd.org Received: from november.jaded.net (november.jaded.net [216.94.113.4]) by hub.freebsd.org (Postfix) with ESMTP id 77BFC1566D; Sun, 28 Nov 1999 11:24:11 -0800 (PST) (envelope-from dan@november.jaded.net) Received: (from dan@localhost) by november.jaded.net (8.9.3/8.9.3+trinsec_nospam) id OAA33619; Sun, 28 Nov 1999 14:24:08 -0500 (EST) Date: Sun, 28 Nov 1999 14:24:07 -0500 From: Dan Moschuk To: Warner Losh Cc: Dan Moschuk , Kris Kennaway , freebsd-audit@FreeBSD.ORG Subject: Re: Last random PID patch before commit Message-ID: <19991128142407.B33514@november.jaded.net> References: <19991128130432.C33028@november.jaded.net> <19991128012420.A48334@spirit.jaded.net> <19991128130432.C33028@november.jaded.net> <199911281911.MAA85867@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <199911281911.MAA85867@harmony.village.org>; from Warner Losh on Sun, Nov 28, 1999 at 12:11:52PM -0700 Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG | Hmmm. I think this is a bad idea. The key won't be sufficently | random since you can count on a number of bits in the stack garbage | being set due to kernel addresses. This weakens the resulting | randomness from 2048 bits down to 1500ish bits (assumnig that my read | of the code gives key a 8 bit size). What's wrong with the | /dev/random random number stream? This is exactly the sort of thing | that it is designed for.... | | Warner The only problem with the /dev/random stream is that it will not have sufficient entropy built up by the time the arc4_init() is likely to be called, at bootup. Not to say that the way I initialize it is any better, but it will work until "The best" solution can be found. I like the idea of replacing our random devices with sys/dev/rnd.c from OpenBSD. -- Dan Moschuk (TFreak!dan@freebsd.org) "Try not. Do, or do not. There is no try." -- Yoda To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Sun Nov 28 11:33:15 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 2AEB714C28; Sun, 28 Nov 1999 11:33:11 -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 MAA29552; Sun, 28 Nov 1999 12:33:10 -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 MAA86069; Sun, 28 Nov 1999 12:33:23 -0700 (MST) Message-Id: <199911281933.MAA86069@harmony.village.org> To: Dan Moschuk Subject: Re: Last random PID patch before commit Cc: Kris Kennaway , freebsd-audit@FreeBSD.ORG In-reply-to: Your message of "Sun, 28 Nov 1999 14:24:07 EST." <19991128142407.B33514@november.jaded.net> References: <19991128142407.B33514@november.jaded.net> <19991128130432.C33028@november.jaded.net> <19991128012420.A48334@spirit.jaded.net> <19991128130432.C33028@november.jaded.net> <199911281911.MAA85867@harmony.village.org> Date: Sun, 28 Nov 1999 12:33:23 -0700 From: Warner Losh Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <19991128142407.B33514@november.jaded.net> Dan Moschuk writes: : The only problem with the /dev/random stream is that it will not have : sufficient entropy built up by the time the arc4_init() is likely to be called, : at bootup. Are you sure about this? Is our dev random really that bad? It should have at least 32 bits of randomness builtup within milliseconds of interrupts being enabled... : Not to say that the way I initialize it is any better, but it will work until : "The best" solution can be found. : : I like the idea of replacing our random devices with sys/dev/rnd.c from : OpenBSD. I like this idea as well. I believe that the entropy pool accumulates fast enough to use it for every process, but that might be excessive and wasteful. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Sun Nov 28 11:33:52 1999 Delivered-To: freebsd-audit@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 0F50B14C28; Sun, 28 Nov 1999 11:33:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id E90B81CD42D; Sun, 28 Nov 1999 11:33:50 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Sun, 28 Nov 1999 11:33:50 -0800 (PST) From: Kris Kennaway To: Dan Moschuk Cc: Warner Losh , freebsd-audit@FreeBSD.ORG Subject: Re: Last random PID patch before commit In-Reply-To: <19991128142407.B33514@november.jaded.net> 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, 28 Nov 1999, Dan Moschuk wrote: > The only problem with the /dev/random stream is that it will not have > sufficient entropy built up by the time the arc4_init() is likely to > be called, at bootup. Have you tested this? I repeat, even if there was zero entropy in the pool, seeding with time + /dev/random (i.e. what arc4random() does in openbsd, and probably ours too) it is as strong as your current seeding. If you even have 1 bit, it becomes better. > Not to say that the way I initialize it is any better, but it will work until > "The best" solution can be found. The existing arc4random() reseeds every 128 calls, which means that, at worst, the first 128 pids you spawn will be weakly random. Under your current system, every process spawned by the system forever is weakly random. Kris ---- Just remember, as you celebrate Thanksgiving with your family feasts of turkey, cranberries, stuffing, gravy, mashed potatoes, squash, corn, cornbread, apples, pickles, dumplings, fish, orangutans, fruitbats, breakfast cereals, and so forth, to keep in mind the true reason for the season: The birth of Santa. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Sun Nov 28 11:44:16 1999 Delivered-To: freebsd-audit@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 3E47C150DB; Sun, 28 Nov 1999 11:44:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 2CB271CD42D; Sun, 28 Nov 1999 11:44:15 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Sun, 28 Nov 1999 11:44:15 -0800 (PST) From: Kris Kennaway To: Warner Losh Cc: Dan Moschuk , freebsd-audit@FreeBSD.ORG Subject: Re: Last random PID patch before commit In-Reply-To: <199911281933.MAA86069@harmony.village.org> 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, 28 Nov 1999, Warner Losh wrote: > I believe that the entropy pool accumulates fast enough to use it for > every process, but that might be excessive and wasteful. Probably. You certainly want to reseed your random stream often, but OTOH I've found it fairly easy to drain the /dev/random pool by a couple of cooperating aggressively reading processes - in other words, there's not a whole lot there unless we keep a private pool in reserve (there was also a claim a while ago that we drastically overestimate our entropy, which I've been meaning to look into for a while). The papers by Schneier et al on www.counterpane.com on cryptographic RNGs describe the issues well. Kris > Warner ---- Just remember, as you celebrate Thanksgiving with your family feasts of turkey, cranberries, stuffing, gravy, mashed potatoes, squash, corn, cornbread, apples, pickles, dumplings, fish, orangutans, fruitbats, breakfast cereals, and so forth, to keep in mind the true reason for the season: The birth of Santa. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Sun Nov 28 23:42: 3 1999 Delivered-To: freebsd-audit@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 297C014DE8; Sun, 28 Nov 1999 23:42:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 181011CD624; Sun, 28 Nov 1999 23:42:02 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Sun, 28 Nov 1999 23:42:02 -0800 (PST) From: Kris Kennaway To: Bruce Evans Cc: Mike Smith , audit@freebsd.org, Warner Losh 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, 29 Nov 1999, Bruce Evans wrote: > It's unreasonable to ask a new committer to use /dev/random when more > important things like netinet don't use it. To use it in One must start somewhere - I hope the other candidates get addressed over the next few months (most of the patches should be simple merges from openbsd). > machine-independent code, you first have to implement it for alpha. Here > is a toy implementation: Good point. Again, OpenBSD have presumably got working code we can pull over. I'll check that tomorrow, time permitting. Hmm, given this it may be more productive to simply bring across the entire OpenBSD /dev/random as Dan suggested, Mark's plans to implement Yarrow notwithstanding. Thoughts, Mark? > This does the same thing as the i386 implementation on a bad day. The > caller must be prepared for a limited amount of entropy being available. > All callers except the ones for userland get this wrong by calling > read_random() on alphas and always ignoring the result of read_random(). Can you suggest a decent fix? Simply polling until we fill our desired buffer? Using read_random_unlimited() may well be "good enough" in many cases. I'll add the cases you mentioned to my list of things to look at - thanks! Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Mon Nov 29 0: 5:13 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 6D1721525A; Mon, 29 Nov 1999 00:05:02 -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.040 #1) id 11sLnw-0005i7-00; Mon, 29 Nov 1999 10:05:00 +0200 From: Sheldon Hearn To: Dan Moschuk Cc: freebsd-audit@FreeBSD.ORG Subject: Re: New Random PID patch using arc4 available In-reply-to: Your message of "Sat, 27 Nov 1999 03:15:47 EST." <19991127031547.A19711@november.jaded.net> Date: Mon, 29 Nov 1999 10:05:00 +0200 Message-ID: <21954.943862700@axl.noc.iafrica.com> Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 27 Nov 1999 03:15:47 EST, Dan Moschuk wrote: > I've put another patch online that moves away from random() and uses > arc4random() instead. I'm sure I'm not the only person who feels stupid following this thread. :-) Could you explain the problems involved with linear PID allocation? If it's already been explained in published notes, just a reference to those notes would be great. Thanks, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Mon Nov 29 1:21:14 1999 Delivered-To: freebsd-audit@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 25B8014ED7; Mon, 29 Nov 1999 01:21:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 106BB1CD474; Mon, 29 Nov 1999 01:21:13 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Mon, 29 Nov 1999 01:21:13 -0800 (PST) From: Kris Kennaway To: Sheldon Hearn Cc: Dan Moschuk , freebsd-audit@FreeBSD.ORG Subject: Re: New Random PID patch using arc4 available In-Reply-To: <21954.943862700@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 On Mon, 29 Nov 1999, Sheldon Hearn wrote: > Could you explain the problems involved with linear PID allocation? If > it's already been explained in published notes, just a reference to > those notes would be great. One of the things it (neatly) solves is predictable PID-based tempfile naming - a lot of code out there likes to blindly create tempfiles using foo., perhaps with a few random characters added. In many cases with a linear PID model you can exploit this by "mining" the tempdir with a few hundred symlinks, hoping the process will pick one of the names and follow it into damnation. The proper fix is to use mkstemp() with lots of X's and make sure you don't have any race conditions in your tempfile handling, but this helps a lot. Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Mon Nov 29 3:49: 5 1999 Delivered-To: freebsd-audit@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 4707714A01; Mon, 29 Nov 1999 03:48:51 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (beefcake.zeta.org.au [203.26.10.12]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id WAA24998; Mon, 29 Nov 1999 22:57:06 +1100 Date: Mon, 29 Nov 1999 22:48:41 +1100 (EST) From: Bruce Evans X-Sender: bde@alphplex.bde.org To: Kris Kennaway Cc: Mike Smith , audit@FreeBSD.org, Warner Losh 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 Sun, 28 Nov 1999, Kris Kennaway wrote: > On Mon, 29 Nov 1999, Bruce Evans wrote: > > This does the same thing as the i386 implementation on a bad day. The > > caller must be prepared for a limited amount of entropy being available. > > All callers except the ones for userland get this wrong by calling > > read_random() on alphas and always ignoring the result of read_random(). > > Can you suggest a decent fix? Simply polling until we fill our desired > buffer? Using read_random_unlimited() may well be "good enough" in many > cases. Polling would be too slow. I don't know if read_random_unlimited() is good enough. Randomness is needed soon after booting. Then it is not clear that read_random_unlimited() can provide _any_ true randomness. See the comment in init_main.c where random() is initialised. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Mon Nov 29 7:54:52 1999 Delivered-To: freebsd-audit@freebsd.org Received: from spirit.jaded.net (spirit.jaded.net [216.94.113.12]) by hub.freebsd.org (Postfix) with ESMTP id 5D37C14C35; Mon, 29 Nov 1999 07:54:49 -0800 (PST) (envelope-from dan@spirit.jaded.net) Received: (from dan@localhost) by spirit.jaded.net (8.9.3/8.9.3) id KAA01154; Mon, 29 Nov 1999 10:57:03 -0500 (EST) Date: Mon, 29 Nov 1999 10:57:03 -0500 From: Dan Moschuk To: Kris Kennaway Cc: Bruce Evans , Mike Smith , audit@FreeBSD.ORG, Warner Losh 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: <19991129105703.C277@spirit.jaded.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from kris@hub.freebsd.org on Sun, Nov 28, 1999 at 11:42:02PM -0800 Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG | Good point. Again, OpenBSD have presumably got working code we can pull | over. I'll check that tomorrow, time permitting. Hmm, given this it may be | more productive to simply bring across the entire OpenBSD /dev/random as | Dan suggested, Mark's plans to implement Yarrow notwithstanding. Thoughts, | Mark? After closer examination, it seems that we do have a part OpenBSD /dev/random implementation hiding in sys/i386/isa/random_machdep.c (although it is a few revisions out of date). As I've noted in private mail, I'm a little iffy on bringing Yarrow in as a direct replacement at this time. The algorithm is still quite virgin, and I think the matter will have to be researched more than "Bruce designed it, it must be good" before a final decision is made. | > This does the same thing as the i386 implementation on a bad day. The | > caller must be prepared for a limited amount of entropy being available. | > All callers except the ones for userland get this wrong by calling | > read_random() on alphas and always ignoring the result of read_random(). | | Can you suggest a decent fix? Simply polling until we fill our desired | buffer? Using read_random_unlimited() may well be "good enough" in many | cases. I think the code already has a decent fix around this. r = read_random(key, sizeof(key)); for (n = r; n < sizeof(key); n++) key[n] = key[n % r]; If we can't fill 256 bytes, then we repeat until we do. Of course, this code doesn't really handle r == 0 very well. -- Dan Moschuk (TFreak!dan@freebsd.org) "Cure for global warming: One giant heatsink and dual fans!" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Mon Nov 29 11:24:39 1999 Delivered-To: freebsd-audit@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 437BA1529C; Mon, 29 Nov 1999 11:24:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 310ED1CD621; Mon, 29 Nov 1999 11:24:38 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Mon, 29 Nov 1999 11:24:38 -0800 (PST) From: Kris Kennaway To: Dan Moschuk Cc: Bruce Evans , Mike Smith , audit@FreeBSD.ORG, Warner Losh 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: <19991129105703.C277@spirit.jaded.net> 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, 29 Nov 1999, Dan Moschuk wrote: > After closer examination, it seems that we do have a part OpenBSD /dev/random > implementation hiding in sys/i386/isa/random_machdep.c (although it is a > few revisions out of date). Yep - the one in the Linux kernel is 1.06 or so of the same code (we have 0.95, OpenBSD 1.00). OpenBSD have essentially welded arc4random() to the output of read_random for their /dev/arandom, whereas we just hash whatever we can get from the entropy pool (possibly nothing) with MD5 until we fill the buffer, for /dev/urandom (/dev/random is just the MD5 hash of as much entropy as is present in both cases). It's been a while since I checked, but I think in Linux they (perhaps gratuitiously) use SHA1 instead of MD5. It looks like there have been some changes in the entropy-stirring and extraction mechanism in the underlying code, though, so it's probably worthwhile updating. Whether the arandom method is better than urandom is I guess open for debate :-) > As I've noted in private mail, I'm a little iffy on bringing Yarrow in as a > direct replacement at this time. The algorithm is still quite virgin, and > I think the matter will have to be researched more than "Bruce designed it, > it must be good" before a final decision is made. I don't know what Theodore Ts'o's credentials are, but I'm still much more inclined to trust the work of someone who does this stuff for a living than a part-time cryptographer. AFAIK no professional cryptographers have taken a serious look at "our" (Linux/Open/FreeBSD) PRNG and the effects of any random twiddles people may have done to them over time. > I think the code already has a decent fix around this. > > r = read_random(key, sizeof(key)); > for (n = r; n < sizeof(key); n++) > key[n] = key[n % r]; This only has r bits of entropy, not sizeof(key). Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Mon Nov 29 11:26:21 1999 Delivered-To: freebsd-audit@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 0A4E9152F4; Mon, 29 Nov 1999 11:26:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id ECE9C1CD621; Mon, 29 Nov 1999 11:26:19 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Mon, 29 Nov 1999 11:26:19 -0800 (PST) From: Kris Kennaway To: Bruce Evans Cc: Mike Smith , audit@FreeBSD.org, Warner Losh 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, 29 Nov 1999, Bruce Evans wrote: > > On Mon, 29 Nov 1999, Bruce Evans wrote: > > > This does the same thing as the i386 implementation on a bad day. The > > > caller must be prepared for a limited amount of entropy being available. > > > All callers except the ones for userland get this wrong by calling > > > read_random() on alphas and always ignoring the result of read_random(). > > > > Can you suggest a decent fix? Simply polling until we fill our desired > > buffer? Using read_random_unlimited() may well be "good enough" in many > > cases. > > Polling would be too slow. I don't know if read_random_unlimited() is good > enough. Randomness is needed soon after booting. Then it is not clear > that read_random_unlimited() can provide _any_ true randomness. See the > comment in init_main.c where random() is initialised. Probably in the case when we first initialise the PRNG we can afford the performance hit and poll until we get as much entropy as we need, and in most other cases just use read_random_unlimited(). Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Mon Nov 29 12:26:57 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 16E8115378; Mon, 29 Nov 1999 12:26:36 -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 VAA20900; Mon, 29 Nov 1999 21:26:22 +0100 (MET) Received: (from root@localhost) by foxbert.skynet.be (8.9.1/jovi-pop-2.1) id VAA14776; Mon, 29 Nov 1999 21:26:20 +0100 (MET) Mime-Version: 1.0 X-Sender: blk@foxbert.skynet.be Message-Id: In-Reply-To: References: Date: Mon, 29 Nov 1999 21:20:13 +0100 To: Kris Kennaway , Dan Moschuk 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: Bruce Evans , Mike Smith , audit@FreeBSD.ORG, Warner Losh Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 11:24 AM -0800 1999/11/29, Kris Kennaway wrote: > I don't know what Theodore Ts'o's credentials are, but I'm still much more > inclined to trust the work of someone who does this stuff for a living > than a part-time cryptographer. As I recall, he's one of the principles at MIT working on the freely available implementation of PGP, although I don't know his specific crypto background. > AFAIK no professional cryptographers have > taken a serious look at "our" (Linux/Open/FreeBSD) PRNG and the effects > of any random twiddles people may have done to them over time. This seems like a serious problem. I think we need to fix this as soon as we can, if we're going to have any credibility in our audit and security processes (I think we also need to get the commit process changed so as to help automate what we can of the audit/re-audit process). Does anyone have any further thoughts in this area? Anyone know of any available professional cryptographers who might be available to do this kind of work? Anybody got any better contacts with Greg Rose or Carl Ellison, or perhaps other cryptographers who might know of potentially interested/available parties? -- 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 Nov 29 12:30:51 1999 Delivered-To: freebsd-audit@freebsd.org Received: from spirit.jaded.net (spirit.jaded.net [216.94.113.12]) by hub.freebsd.org (Postfix) with ESMTP id 0DDDE154F3; Mon, 29 Nov 1999 12:30:36 -0800 (PST) (envelope-from dan@spirit.jaded.net) Received: (from dan@localhost) by spirit.jaded.net (8.9.3/8.9.3) id PAA03186; Mon, 29 Nov 1999 15:32:50 -0500 (EST) Date: Mon, 29 Nov 1999 15:32:50 -0500 From: Dan Moschuk To: Kris Kennaway Cc: Dan Moschuk , Bruce Evans , Mike Smith , audit@FreeBSD.ORG, Warner Losh 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: <19991129153250.A2999@spirit.jaded.net> References: <19991129105703.C277@spirit.jaded.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from kris@hub.freebsd.org on Mon, Nov 29, 1999 at 11:24:38AM -0800 Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG | Yep - the one in the Linux kernel is 1.06 or so of the same code (we have | 0.95, OpenBSD 1.00). OpenBSD have essentially welded arc4random() to the | output of read_random for their /dev/arandom, whereas we just hash | whatever we can get from the entropy pool (possibly nothing) with MD5 | until we fill the buffer, for /dev/urandom (/dev/random is just the MD5 | hash of as much entropy as is present in both cases). Hashing is done for good reason; if we expose our internal state through random numbers, they are possible to predict. Running the data through MD5 reduces this risk. | It's been a while since I checked, but I think in Linux they (perhaps | gratuitiously) use SHA1 instead of MD5. It looks like there have been some | changes in the entropy-stirring and extraction mechanism in the underlying | code, though, so it's probably worthwhile updating. Whether the arandom | method is better than urandom is I guess open for debate :-) SHA1 generates a bigger hash than MD5, so for that reason it is probably worth switching to. However... | I don't know what Theodore Ts'o's credentials are, but I'm still much more | inclined to trust the work of someone who does this stuff for a living | than a part-time cryptographer. AFAIK no professional cryptographers have | taken a serious look at "our" (Linux/Open/FreeBSD) PRNG and the effects | of any random twiddles people may have done to them over time. ... I have to agree with you here. If we were to pit Theodore Ts'o's routine against the possibility of using Yarrow, I would choose Yarrow. Just because OpenBSD uses this, doesn't mean we have to. In fact, ideally what I would like to see is this: i) Yarrow (or possibly something else should your research yield Yarrow as ``unsafe'') routines built into the kernel. ii) Replace random() with yarrow_random() in all instances iii) Replace /dev/*random with routines from Yarrow. Indeed this is a little bit of work, but anything that allows me to further put off NFS locking is OK with me. :-) Although Yarrow is quite a virgin algorithm as far as cryptographical standards go, I do trust the work of two widely respected professional cryptographers over that of an amateur. Cheers, -- Dan Moschuk (TFreak!dan@freebsd.org) "Cure for global warming: One giant heatsink and dual fans!" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Mon Nov 29 12:34:29 1999 Delivered-To: freebsd-audit@freebsd.org Received: from spirit.jaded.net (spirit.jaded.net [216.94.113.12]) by hub.freebsd.org (Postfix) with ESMTP id 8ABDB1529A; Mon, 29 Nov 1999 12:34:26 -0800 (PST) (envelope-from dan@spirit.jaded.net) Received: (from dan@localhost) by spirit.jaded.net (8.9.3/8.9.3) id PAA03222; Mon, 29 Nov 1999 15:36:39 -0500 (EST) Date: Mon, 29 Nov 1999 15:36:39 -0500 From: Dan Moschuk To: Brad Knowles Cc: Kris Kennaway , Dan Moschuk , Bruce Evans , Mike Smith , audit@FreeBSD.ORG, Warner Losh 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: <19991129153639.B2999@spirit.jaded.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from blk@skynet.be on Mon, Nov 29, 1999 at 09:20:13PM +0100 Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG | > I don't know what Theodore Ts'o's credentials are, but I'm still much more | > inclined to trust the work of someone who does this stuff for a living | > than a part-time cryptographer. | | As I recall, he's one of the principles at MIT working on the | freely available implementation of PGP, although I don't know his | specific crypto background. PGP is based on known algorithms, implementing and designing are two vastly different things. | This seems like a serious problem. I think we need to fix this | as soon as we can, if we're going to have any credibility in our | audit and security processes (I think we also need to get the commit | process changed so as to help automate what we can of the | audit/re-audit process). | | Does anyone have any further thoughts in this area? Anyone know | of any available professional cryptographers who might be available | to do this kind of work? Anybody got any better contacts with Greg | Rose or Carl Ellison, or perhaps other cryptographers who might know | of potentially interested/available parties? One of the benefits of using an algorithm designed by a professional cryptographer is that the algorithm is bound to be studied extensively, it doesn't neccessarily have to be from our code base. -- Dan Moschuk (TFreak!dan@freebsd.org) "Cure for global warming: One giant heatsink and dual fans!" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Mon Nov 29 13:17: 2 1999 Delivered-To: freebsd-audit@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 4BCBE14A1C; Mon, 29 Nov 1999 13:17:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 3A7831CD473; Mon, 29 Nov 1999 13:17:00 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Mon, 29 Nov 1999 13:17:00 -0800 (PST) From: Kris Kennaway To: Dan Moschuk Cc: Bruce Evans , Mike Smith , audit@FreeBSD.ORG, Warner Losh 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: <19991129153250.A2999@spirit.jaded.net> 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, 29 Nov 1999, Dan Moschuk wrote: > | Yep - the one in the Linux kernel is 1.06 or so of the same code (we have > | 0.95, OpenBSD 1.00). OpenBSD have essentially welded arc4random() to the > | output of read_random for their /dev/arandom, whereas we just hash > | whatever we can get from the entropy pool (possibly nothing) with MD5 > | until we fill the buffer, for /dev/urandom (/dev/random is just the MD5 > | hash of as much entropy as is present in both cases). > > Hashing is done for good reason; if we expose our internal state through > random numbers, they are possible to predict. Running the data through > MD5 reduces this risk. Yes. > | It's been a while since I checked, but I think in Linux they (perhaps > | gratuitiously) use SHA1 instead of MD5. It looks like there have been some > | changes in the entropy-stirring and extraction mechanism in the underlying > | code, though, so it's probably worthwhile updating. Whether the arandom > | method is better than urandom is I guess open for debate :-) > > SHA1 generates a bigger hash than MD5, so for that reason it is probably > worth switching to. However... Immaterial. SHA1 is like a bucket which can be filled with up to 160 bits of entropy, so we feed it up to 160 bits at a time from the pool. MD5 is a smaller bucket, so we feed it chunks of 128 bits. The issue in the Linux case was presumably concerns about the strength of the hash function itself (I don't think they're warranted enough to replace MD5 with a much slower algorithm).. > | I don't know what Theodore Ts'o's credentials are, but I'm still much more > | inclined to trust the work of someone who does this stuff for a living > | than a part-time cryptographer. AFAIK no professional cryptographers have > | taken a serious look at "our" (Linux/Open/FreeBSD) PRNG and the effects > | of any random twiddles people may have done to them over time. > > ... I have to agree with you here. If we were to pit Theodore Ts'o's routine > against the possibility of using Yarrow, I would choose Yarrow. Just because > OpenBSD uses this, doesn't mean we have to. In fact, ideally what I would > like to see is this: wrt the OpenBSD /dev/arandom algorithm (their equivalent of our /dev/urandom), I did some thinking over lunch and came to the conclusion that it's actually worse than our current one: arc4random() (their implementation, and the one we have in libc) reseeds itself based on the contents of the entropy pool every 128 accesses. This means that if we break the state of the PRNG, we get on average 64 free "random" numbers with perfect certainty, and if furthermore we are aggressively draining the /dev/random entropy pool (which /dev/arandom reseeds itself from) then we know the state of the PRNG with probabilistic certainty into the indefinite future. Contrast our algorithm, which effectively reseeds itself every access. If we break the state, we get 0 free accesses, and probabilistically thereafter, but with a factor of 128 shorter decay time. The downside is that we use up our entropy faster (someone should really do some measurements as to how fast entropy is actually generated on a typical PC) and the algorithm is slower (MD5 vs arc4). Yarrow, (as I recall, it's been a while since I looked at it) compensates for this by keeping two entropy pools; one public, and one private, which we reseed from. The attacker can only drain the public pool, which doesn't affect the future state of the PRNG. I don't know about the overall speed of Yarrow relative to the other two. This seems to imply we shouldn't blindly use arc4random() in every case as OpenBSD have done, but neither should we always use read_random() unless we've got lots of entropy to play with and the speed doesn't matter. I hate grey areas :-) > i) Yarrow (or possibly something else should your research yield Yarrow as > ``unsafe'') routines built into the kernel. > > ii) Replace random() with yarrow_random() in all instances > > iii) Replace /dev/*random with routines from Yarrow. > > Indeed this is a little bit of work, but anything that allows me to further > put off NFS locking is OK with me. :-) This is probably a good plan of attack. On the other hand, our current /dev/random is probably quite "good enough" for now, and there are other things we can fix in the mean time with much greater benefits (like all those pesky buffer overflows :-) Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Mon Nov 29 13:27:45 1999 Delivered-To: freebsd-audit@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id BEAE814C1F; Mon, 29 Nov 1999 13:27:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id ABB3C1CD473; Mon, 29 Nov 1999 13:27:42 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Mon, 29 Nov 1999 13:27:42 -0800 (PST) From: Kris Kennaway To: Matthew Dillon Cc: Dan Moschuk , 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: <199911292104.NAA09106@apollo.backplane.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 Mon, 29 Nov 1999, Matthew Dillon wrote: > Hi Dan. Is it possible that we could adjust this feature to be enabled > with a config option? It seems to add a considerable amount of bulk to > the kernel that's deadweight for the people not using it. This raises some larger architectural issues which probably should be dealt with. Namely: * Changes which tighten security are arguably only useful if they're on by default, otherwise all the newbies will leave them off, and have (relatively speaking) insecure boxes. * Just what is the "scope" of the auditing project under which this change (and many others to come) falls? In other words, how much security do we (FreeBSD) want, and at what expense? Some of the OpenBSD changes have demonstrable security benefits, but they also carry a performance penalty. * Is adding a few bytes to the kernel size really an issue compared to the complexity of having 20 different config options to include/exclude various kernel security features? Personally, I'm quite happy with a policy of "include everything which doesn't have a large performance hit, by default, and have the rest defaulting to 'off' with a trivial way for people to turn it on", but maybe that's just me being a security weenie :-) Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Mon Nov 29 14:30:27 1999 Delivered-To: freebsd-audit@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 4757415466; Mon, 29 Nov 1999 14:30:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 345EA1CD626; Mon, 29 Nov 1999 14:30:26 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Mon, 29 Nov 1999 14:30:26 -0800 (PST) From: Kris Kennaway To: Brad Knowles Cc: Dan Moschuk , Bruce Evans , Mike Smith , audit@FreeBSD.ORG, Warner Losh 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, 29 Nov 1999, Brad Knowles wrote: > This seems like a serious problem. I think we need to fix this > as soon as we can, if we're going to have any credibility in our > audit and security processes (I think we also need to get the commit > process changed so as to help automate what we can of the > audit/re-audit process). > > Does anyone have any further thoughts in this area? Anyone know > of any available professional cryptographers who might be available > to do this kind of work? Anybody got any better contacts with Greg > Rose or Carl Ellison, or perhaps other cryptographers who might know > of potentially interested/available parties? If we were to use Yarrow, we get the review for free by virtue of it being designed & reviewed by a professional cryptographer. But, I think there are more important things we should do first to start raising our credibility wrt security (i.e. the current PRNG implementation is not bad per se, it's just perhaps suboptimal) Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Mon Nov 29 14:40:24 1999 Delivered-To: freebsd-audit@freebsd.org Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 2E0CD14F3C for ; Mon, 29 Nov 1999 14:40:20 -0800 (PST) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40337>; Tue, 30 Nov 1999 09:32:59 +1100 Content-return: prohibited Date: Tue, 30 Nov 1999 09:40:14 +1100 From: Peter Jeremy 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: To: Brad Knowles Cc: audit@FreeBSD.ORG Reply-To: peter.jeremy@alcatel.com.au Message-Id: <99Nov30.093259est.40337@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0pre3i Content-type: text/plain; charset=us-ascii References: Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 1999-Nov-30 07:20:13 +1100, Brad Knowles wrote: > Anyone know >of any available professional cryptographers who might be available >to do this kind of work? Anybody got any better contacts with Greg >Rose or Carl Ellison, I know Greg through regularly attending the same AUUG Conferences as him. Another possibility (which whom I have the same level of contact) would be Lawrie Brown, who lectures in cryptography at the Australian Defense Forces Academy. I don't know off-hand whether either would be interested in helping us. Someone could try a post to sci.crypt. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Mon Nov 29 16: 1: 3 1999 Delivered-To: freebsd-audit@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id B816415570; Mon, 29 Nov 1999 15:58:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 9B25F1CD623; Mon, 29 Nov 1999 15:58:47 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Mon, 29 Nov 1999 15:58:47 -0800 (PST) From: Kris Kennaway To: Matthew Dillon Cc: Dan Moschuk , 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: <199911292239.OAA11977@apollo.backplane.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 Mon, 29 Nov 1999, Matthew Dillon wrote: > :> to increment when I look at 'ps' and 'jobs -l' output just as a > :> double check, and I'm sure other people do to. > : > :The big thing which randomized pids gives you is protection against > :tempfile guessing (e.g. /tmp/foo). We can't fix all of those bugs > :because they exist in a lot of third party code, including code without > :source. > : > :Kris > > Not really. Example: fork/exec an suid program. You now know what > the pid is (the return valud of the fork). There is no need to guess, > and a randomized pid won't help you. In fact, you can TSTP the program > relatively easily since you are probably still the controlling terminal. > You can effectively exploit the window even without TSTPing or STOPing > the program. You misunderstand the attack. In this case I'm the attacker, trying to defeat a child of a process which isn't mine. An example of this exploit in current FreeBSD is a temp file which is created during a parallel make world (I haven't gone back and figured out what). It makes a temp file called /tmp/something without checking for prior existance of the file. As the attacker, I can exploit this by looking at the current value of maxpid, and spawning say 500 links in /tmp with the correct name, pointing to /etc/passwd. Along comes Mr. linker (or whatever), creates the temporary file and lands in the 'minefield', follows my link, and actually creates it over the top of /etc/passwd. Boom. As you noted, this only reduces to a race condition when you randomize the PID, but it's at least a lot harder to exploit. We can fix this one in FreeBSD, but third party code is still just as trivial to exploit. Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Mon Nov 29 17:48:47 1999 Delivered-To: freebsd-audit@freebsd.org Received: from 24-25-220-29.san.rr.com (24-25-220-29.san.rr.com [24.25.220.29]) by hub.freebsd.org (Postfix) with ESMTP id CD12615666; Mon, 29 Nov 1999 17:48:01 -0800 (PST) (envelope-from Doug@gorean.org) Received: from gateway.gorean.org (gateway.gorean.org [10.0.0.1]) by 24-25-220-29.san.rr.com (8.9.3/8.8.8) with ESMTP id RAA32993; Mon, 29 Nov 1999 17:48:00 -0800 (PST) (envelope-from Doug@gorean.org) Date: Mon, 29 Nov 1999 17:47:30 -0800 (PST) From: Doug Barton X-Sender: doug@24-25-220-29.san.rr.com To: Kris Kennaway Cc: Matthew Dillon , Dan Moschuk , 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, 29 Nov 1999, Kris Kennaway wrote: > On Mon, 29 Nov 1999, Matthew Dillon wrote: > > > Hi Dan. Is it possible that we could adjust this feature to be enabled > > with a config option? It seems to add a considerable amount of bulk to > > the kernel that's deadweight for the people not using it. > > This raises some larger architectural issues which probably should be > dealt with. Namely: > > * Changes which tighten security are arguably only useful if they're on by > default, otherwise all the newbies will leave them off, and have > (relatively speaking) insecure boxes. Personally I agree with this principle, and agree that options of this sort should be on by default. > * Just what is the "scope" of the auditing project under which this change > (and many others to come) falls? In other words, how much security do we > (FreeBSD) want, and at what expense? Some of the OpenBSD changes have > demonstrable security benefits, but they also carry a performance penalty. Any security feature that can cause a performance hit (and we can argue that definition another time) should be optionable, including "small ones." I have some systems where _every_ cpu cycle is non-trivial, so I want the ability to push some of my security downstream and just let the box do its job. > * Is adding a few bytes to the kernel size really an issue compared to the > complexity of having 20 different config options to include/exclude > various kernel security features? Sorry, "kernel option complexity" is a red-herring argument. If the options are well thought out, given sensible defaults and thoroughly documented that whole argument just dries up and blows away. This isn't microsoft, and we're not pushing a "one best way" on our users. My feeling is that _every_ kernel option should have a compile/link-time component (whether that is config-able, or fits into whatever new structure we come up with) AND a sysctl knob wherever possible. Just because this hasn't been done in the past doesn't mean this isn't a good time to start. As for random pids, I would turn this off with extreme prejudice. I don't think it gains us much, if anything (and yes, I understand the /tmp race arguments, I just think they are better solved elsewhere) and as Mark Murray said in relation to the forth boot password thing, bad security is worse than none. I do think that random source port numbers is a bonus, for the reasons that Warner already addressed, and because it makes spoofing packets _coming_ from your machine somewhat harder. FWIW, Doug -- "Welcome to the desert of the real." - Laurence Fishburne as Morpheus, "The Matrix" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Mon Nov 29 17:59:25 1999 Delivered-To: freebsd-audit@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id E12BB15691; Mon, 29 Nov 1999 17:58:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id CE9BE1CD623; Mon, 29 Nov 1999 17:58:59 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Mon, 29 Nov 1999 17:58:59 -0800 (PST) From: Kris Kennaway To: Doug Barton Cc: Matthew Dillon , Dan Moschuk , 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, 29 Nov 1999, Doug Barton wrote: > > * Is adding a few bytes to the kernel size really an issue compared to the > > complexity of having 20 different config options to include/exclude > > various kernel security features? > > Sorry, "kernel option complexity" is a red-herring argument. If > the options are well thought out, given sensible defaults and thoroughly > documented that whole argument just dries up and blows away. This isn't This doesn't seem to be the way other people have been pushing..I'm pretty sure there have been cases recently where it was decided against making a new feature a config option on the grounds of #ifdef HELL. For large changes I definitely agree, but not for trivial (e.g. 1-line, like this one) changes. There will probably end up being 20 or so randomized features in the kernel, most of them trivial (~1 line) patches. As long as they're sysctl'able, is it really necessary to have each of them optionable? > As for random pids, I would turn this off with extreme > prejudice. I don't think it gains us much, if anything (and yes, I > understand the /tmp race arguments, I just think they are better solved > elsewhere) and as Mark Murray said in relation to the forth boot password I'd appreciate some suggestions about how we can fix them in the case of third-party binaries (esp. statically-linked ones). > thing, bad security is worse than none. I agree, but I don't think it applies in this case. It converts a trivially exploitable hole into a quite difficult to exploit race, which is the best I can think of, and measurably improves security. Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Mon Nov 29 17:59:43 1999 Delivered-To: freebsd-audit@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id F0C0B15698; Mon, 29 Nov 1999 17:59:12 -0800 (PST) (envelope-from jkh@zippy.cdrom.com) Received: from zippy.cdrom.com (localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id RAA88178; Mon, 29 Nov 1999 17:59:10 -0800 (PST) (envelope-from jkh@zippy.cdrom.com) To: Kris Kennaway Cc: Matthew Dillon , Dan Moschuk , 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, 29 Nov 1999 13:27:42 PST." Date: Mon, 29 Nov 1999 17:59:10 -0800 Message-ID: <88174.943927150@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > * Changes which tighten security are arguably only useful if they're on by > default, otherwise all the newbies will leave them off, and have > (relatively speaking) insecure boxes. That's highly arguable. We provide secure levels, for example, but if we turned them on to any appreciable degree then people's X servers wouldn't work because we have no aperture driver. Would it be correct in the general case? Yes. Would it be correct for workstation users? No. Such is also the case in numerous other situations and it really is a question of providing mechanisms which people can use selectively, not just in providing the best "out of box" security defaults. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Mon Nov 29 18: 5:48 1999 Delivered-To: freebsd-audit@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id E17AC14A21; Mon, 29 Nov 1999 18:05:16 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id SAA13833; Mon, 29 Nov 1999 18:05:16 -0800 (PST) (envelope-from dillon) Date: Mon, 29 Nov 1999 18:05:16 -0800 (PST) From: Matthew Dillon Message-Id: <199911300205.SAA13833@apollo.backplane.com> To: Kris Kennaway Cc: Doug Barton , Dan Moschuk , 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 References: Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :There will probably end up being 20 or so randomized features in the :kernel, most of them trivial (~1 line) patches. As long as they're :sysctl'able, is it really necessary to have each of them optionable? What if we just has a general security randomization option that applied to all of them, and then a sysctl to cover each of them? That would cover my concerns. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Mon Nov 29 19:54:13 1999 Delivered-To: freebsd-audit@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id CA72B1578E; Mon, 29 Nov 1999 19:53:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id BDDB61CD736; Mon, 29 Nov 1999 19:53:09 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Mon, 29 Nov 1999 19:53:09 -0800 (PST) From: Kris Kennaway To: "Jordan K. Hubbard" Cc: Matthew Dillon , Dan Moschuk , 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: <88174.943927150@zippy.cdrom.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 Mon, 29 Nov 1999, Jordan K. Hubbard wrote: > That's highly arguable. We provide secure levels, for example, but if > we turned them on to any appreciable degree then people's X servers > wouldn't work because we have no aperture driver. Would it be correct > in the general case? Yes. Would it be correct for workstation users? > No. Such is also the case in numerous other situations and it really > is a question of providing mechanisms which people can use selectively, > not just in providing the best "out of box" security defaults. This would fall under my preferred policy, which you didn't quote, namely "turn on everything which doesn't have a negative impact, and providing an easy mechanism to enable everything else". Preventing X from running is something many (though not all :) people would consider negative :-) Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Mon Nov 29 20: 3:19 1999 Delivered-To: freebsd-audit@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 21BF715759; Mon, 29 Nov 1999 20:03:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 0ED5E1CD41E; Mon, 29 Nov 1999 20:02:59 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Mon, 29 Nov 1999 20:02:59 -0800 (PST) From: Kris Kennaway To: Matthew Dillon Cc: Doug Barton , Dan Moschuk , 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: <199911300205.SAA13833@apollo.backplane.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 Mon, 29 Nov 1999, Matthew Dillon wrote: > :There will probably end up being 20 or so randomized features in the > :kernel, most of them trivial (~1 line) patches. As long as they're > :sysctl'able, is it really necessary to have each of them optionable? > > What if we just has a general security randomization option that > applied to all of them, and then a sysctl to cover each of them? > That would cover my concerns. Hmm. I think this would be an acceptable compromise provided it's in GENERIC. Boot floppies and the anti-bloat brigade can leave it out if they want to save that extra 1k :-) The only thing is that in many cases we'd end up doing the equivalent of: #ifdef RANDOM_SECURITY i = arc4random(); #else i = random(); #endif Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Mon Nov 29 22:21:10 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 7001A14C91; Mon, 29 Nov 1999 22:21:01 -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 BAA03615; Tue, 30 Nov 1999 01:20:39 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Tue, 30 Nov 1999 01:20:39 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: scanner@jurai.net Cc: Doug Rabson , "David O'Brien" , Mark Murray , Kris Kennaway , freebsd-audit@FreeBSD.ORG Subject: Re: FreeBSD security auditing project. 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 (Damn, go away for Thanksgiving and fall behind on -CURRENT, and miss out on large interesting and fast-paced discussions! I am now subscribed to the new -audit, and probably missed some messages. I've Bcc'd this to -current, but CC'd to -audit under the assumption that that is where it belongs) On Wed, 24 Nov 1999 scanner@jurai.net wrote: > On Wed, 24 Nov 1999, Doug Rabson wrote: > > > We need to put audit tags into the source tree when a file is audited. > > That allows the diffs to be audited later which should be a smaller job > > and then the audit tag slides forward. > > Not to interrupt in the middle of this discussion but you might > want to check with robert watson before you guys get too deep here since > he is working on a FUNDED Posix.1e implementation for FreeBSD. And has > already posted some EARLY MAC code. It might be usefull to work with him > as well. Just a thought. Chris, That would be the "other" audit -- this auditing is source code auditing for bugs in the code. The POSIX.1e auditing would be event logging/etc. Sadly, they have the same name, and I'm not sure which is the more appropriate activity to have the name :-). That said, there have been past projects to audit the FreeBSD source code, but this seems to have the most steam behind it so far, and I hope it goes forwards. It's important to note that source code auditing is not the only thing that makes OpenBSD more secure -- strong crypto, careful thinking through of information leaking, etc, are also very important. There are many bugs in the security design, not just in the implementation, important as the implementation may be. Strings in C seem to be a huge source of security problems, but needless to say even if we had a better string library, there would still be security problems :-) -- poorly thought out suid programs, incorrect use of setuid to create sandboxes (man, uucp, etc, etc), bad permissions, reliance on privacy of environmental variables, poor random number seeding, misunderstandings about euids/uids/reuids/etc in the context of debugging and tracing, weak defense of /dev/kmem, etc, etc, and there are dozens and dozens of such issues. POSIX.1e extensions attempt to address some of these issues by providing least privilege capabilities, finer grained access control, as well as trusted system behavior such as mandatory access control and auditing. This all also requires serious thought. Source auditing is a great step forwards, however, as it clears up the most commonly exploited security holes that make for bad press and lots of bugtraq announcements. :-) 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 Nov 29 22:52: 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 43AD9157AE; Mon, 29 Nov 1999 22:51:38 -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 BAA08444; Tue, 30 Nov 1999 01:51:37 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Tue, 30 Nov 1999 01:51:37 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: freebsd-audit@freebsd.org, freebsd-security@freebsd.org Subject: Topics for -security vs. topics for -audit 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 (for those on -security who missed it for whatever reason (such as it only being announced on -current, and only during Thanksgiving for those US-side people who might have gone on vacation :-), a source code auditing mailing list has been set up for the discussion of reviewing FreeBSD source for security holes, and can be subscribed to by sending "subscribe freebsd-audit" to majordomo@freebsd.org) On with the email: So, I often resent those "you're off-topic" posts sent to mailing lists, but I think there's a need to distinguish the purposes of the -security and -audit mailing lists. My feeling is that -audit is likely to be a code-heavy list--that is, commentary on patches, patching techniques, and lists of files and function references. As such, it's likely to get only cursary reading by those not directly involved in the source code auditing process. On the other hand, -security is a mailing list for general security discussion, including policy issues, regular use, etc. Even in the past two days, we've seen significant discussion that should probably be taking place on -security: selecting a pseudo-random number generator does relate to source code, but it's also an issue our crypto-intense folks should be keeping an eye on, even those that are not into detailed coding. Where to use the pseudo-random number generator becomes more of an auditing issue--places where it should be used, but some approximation is currently used, or where a poor seed is used. The same goes for default conditions for using the prng in network and pid code, etc. This is discussion relevant to a wide audience. As such, I think making the distinction between the list topics is important, and making sure the broad policy issues get fully aired on -security is also important. It's my intent to read both mailing lists, but I can tell you that when my work gets heavy, it'll be diff-heavy messages on -audit that lose out, and -security policy discussions that get my attention. And I don't want to miss the wrong policy discussion that relates to my work :-). This of course raises the specter of cross-posting, but to be honest, I think that's ok on a pair of mailing lists like this, as long as people keep in mind moderation :-). Thanks, 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 Nov 29 23: 1:59 1999 Delivered-To: freebsd-audit@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id 9F9E015150; Mon, 29 Nov 1999 23:01:56 -0800 (PST) (envelope-from jkh@zippy.cdrom.com) Received: from zippy.cdrom.com (localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id XAA89019; Mon, 29 Nov 1999 23:01:53 -0800 (PST) (envelope-from jkh@zippy.cdrom.com) To: Kris Kennaway Cc: Matthew Dillon , Dan Moschuk , 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, 29 Nov 1999 19:53:09 PST." Date: Mon, 29 Nov 1999 23:01:53 -0800 Message-ID: <89015.943945313@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > This would fall under my preferred policy, which you didn't quote, namely > "turn on everything which doesn't have a negative impact, and providing Not being able to predict pids (for useful purposes) would fall under the definition of "negative impact" for a number of admins. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Tue Nov 30 2:28:52 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 A235C1584C; Tue, 30 Nov 1999 02:28:49 -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 LAA28648; Tue, 30 Nov 1999 11:28:45 +0100 (MET) Received: (from root@localhost) by foxbert.skynet.be (8.9.1/jovi-pop-2.1) id LAA21487; Tue, 30 Nov 1999 11:28:44 +0100 (MET) Mime-Version: 1.0 X-Sender: blk@foxbert.skynet.be Message-Id: In-Reply-To: <19991129153639.B2999@spirit.jaded.net> References: <19991129153639.B2999@spirit.jaded.net> Date: Tue, 30 Nov 1999 11:13:30 +0100 To: Dan Moschuk 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: Kris Kennaway , Dan Moschuk , Bruce Evans , Mike Smith , audit@FreeBSD.ORG, Warner Losh Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 3:36 PM -0500 1999/11/29, Dan Moschuk wrote: > One of the benefits of using an algorithm designed by a professional > cryptographer is that the algorithm is bound to be studied extensively, it > doesn't neccessarily have to be from our code base. That's probably true of the crypto algorithms in question, but as Schneier has repeatedly pointed out, they are only a relatively small part of the overall picture. It is entirely possible (one might even argue highly likely) that a less well-tested routine (written by programmers of unknown skill levels) based on a set of algorithms chosen by a respected cryptographer might be much, *much*, *MUCH* less secure (when viewed as a whole), than a better tested routine that has withstood attacks over a longer period of time. If you can restrict yourself to just the crypto part, then you can argue that removing older (and presumably since proven to be less secure) crypto in favour of newer (at least believed to be more secure) algorithms is a good thing. One example of this might be choosing SHA-1 over MD5, since there are certain known weaknesses in some utilizations of MD5, which might point to broader (but not yet discovered) weaknesses, wherease no one has yet been able to find any inherent weaknesses in SHA-1. However, we very rarely have the luxury of being able to replace *just* the crypto part of one routine with the crypto part of another. Instead, we need to view the whole as a collection of parts that need to be evaluated together, in which the crypto plays a critical but still relatively small part. -- 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 Tue Nov 30 2:29: 4 1999 Delivered-To: freebsd-audit@freebsd.org Received: from dozer.skynet.be (dozer.skynet.be [195.238.2.36]) by hub.freebsd.org (Postfix) with ESMTP id 65A3715833; Tue, 30 Nov 1999 02:29:00 -0800 (PST) (envelope-from root@foxbert.skynet.be) Received: from foxbert.skynet.be (foxbert.skynet.be [195.238.1.45]) by dozer.skynet.be (8.9.3/odie-relay-v1.0) with ESMTP id LAA17081; Tue, 30 Nov 1999 11:28:56 +0100 (MET) Received: (from root@localhost) by foxbert.skynet.be (8.9.1/jovi-pop-2.1) id LAA21529; Tue, 30 Nov 1999 11:28:46 +0100 (MET) Mime-Version: 1.0 X-Sender: blk@foxbert.skynet.be Message-Id: In-Reply-To: References: Date: Tue, 30 Nov 1999 11:16:29 +0100 To: Kris Kennaway 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: Dan Moschuk , Bruce Evans , Mike Smith , audit@FreeBSD.ORG, Warner Losh Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 2:30 PM -0800 1999/11/29, Kris Kennaway wrote: > If we were to use Yarrow, we get the review for free by virtue of it being > designed & reviewed by a professional cryptographer. Regardless of who the designer was, I think we need a review by an independent third party. The fact that Yarrow is a respected professional cryptographer would raise the bar and should make it less likely that there are really glaring stupid problems, and might require that we find someone of higher caliber than perhaps we might otherwise have sought out. But I don't think this eliminates the need for a review by an independent third party. -- 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 Tue Nov 30 2:29:16 1999 Delivered-To: freebsd-audit@freebsd.org Received: from dozer.skynet.be (dozer.skynet.be [195.238.2.36]) by hub.freebsd.org (Postfix) with ESMTP id C8F6515833; Tue, 30 Nov 1999 02:29:13 -0800 (PST) (envelope-from root@foxbert.skynet.be) Received: from foxbert.skynet.be (foxbert.skynet.be [195.238.1.45]) by dozer.skynet.be (8.9.3/odie-relay-v1.0) with ESMTP id LAA17063; Tue, 30 Nov 1999 11:29:03 +0100 (MET) Received: (from root@localhost) by foxbert.skynet.be (8.9.1/jovi-pop-2.1) id LAA21423; Tue, 30 Nov 1999 11:28:41 +0100 (MET) Mime-Version: 1.0 X-Sender: blk@foxbert.skynet.be Message-Id: In-Reply-To: <19991129153250.A2999@spirit.jaded.net> References: <19991129105703.C277@spirit.jaded.net> <19991129153250.A2999@spirit.jaded.net> Date: Tue, 30 Nov 1999 11:05:04 +0100 To: Dan Moschuk , Kris Kennaway 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: Dan Moschuk , Bruce Evans , Mike Smith , audit@FreeBSD.ORG, Warner Losh Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 3:32 PM -0500 1999/11/29, Dan Moschuk wrote: > Although Yarrow is quite a virgin algorithm as far as cryptographical > standards go, I do trust the work of two widely respected professional > cryptographers over that of an amateur. While T'so may not be a cryptographer by trade, it is my understanding that he has quite a bit of understanding of how crypto works (due to his involvement in PGP), and is a rather good programmer. If you read Schneier's monthly newsletter, you'll note that *many* professional cryptographers get a whole lot of crap wrong the firs time, and even the empteenth time, because they tend to ignore edge conditions or infrastructure attacks that are not aimed at the crypto per se. It's only once an algorithm has been in wide use for a long time, and many many knowledgeable and resourceful people have hammered on it as hard as they possibly could, is something typically considered to be reasonably secure. In this respect, I think T'so has a strong advantage over Yarrow, in that his stuff has been out there and tested in more installations for longer. I am not so inclined to simply yank T'so for Yarrow, not without a relatively authoritative third party who can look over the respective algorithms and code in extreme detail, etc.... -- 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 Tue Nov 30 7:44:13 1999 Delivered-To: freebsd-audit@freebsd.org Received: from jade.chc-chimes.com (jade.chc-chimes.com [216.28.46.6]) by hub.freebsd.org (Postfix) with ESMTP id B440315928; Tue, 30 Nov 1999 07:44:10 -0800 (PST) (envelope-from billf@chc-chimes.com) Received: by jade.chc-chimes.com (Postfix, from userid 1001) id 510951C5D; Tue, 30 Nov 1999 09:45:14 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by jade.chc-chimes.com (Postfix) with ESMTP id 4C686381B; Tue, 30 Nov 1999 09:45:14 -0500 (EST) Date: Tue, 30 Nov 1999 09:45:14 -0500 (EST) From: Bill Fumerola To: "Jordan K. Hubbard" Cc: Kris Kennaway , Matthew Dillon , Dan Moschuk , 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: <89015.943945313@zippy.cdrom.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 Mon, 29 Nov 1999, Jordan K. Hubbard wrote: > Not being able to predict pids (for useful purposes) would fall under > the definition of "negative impact" for a number of admins. Depending on a behavior that isn't defined anywhere and doesn't always work falls in my definition of "negative clue". -- - bill fumerola - billf@chc-chimes.com - BF1560 - computer horizons corp - - ph:(800) 252-2421 - bfumerol@computerhorizons.com - billf@FreeBSD.org - To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Tue Nov 30 7:50:36 1999 Delivered-To: freebsd-audit@freebsd.org Received: from spirit.jaded.net (spirit.jaded.net [216.94.113.12]) by hub.freebsd.org (Postfix) with ESMTP id 5515B14D85; Tue, 30 Nov 1999 07:50:31 -0800 (PST) (envelope-from dan@spirit.jaded.net) Received: (from dan@localhost) by spirit.jaded.net (8.9.3/8.9.3) id KAA02169; Tue, 30 Nov 1999 10:52:41 -0500 (EST) Date: Tue, 30 Nov 1999 10:52:41 -0500 From: Dan Moschuk To: Brad Knowles Cc: Kris Kennaway , Dan Moschuk , Bruce Evans , Mike Smith , audit@FreeBSD.ORG, Warner Losh 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: <19991130105241.A279@spirit.jaded.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from blk@skynet.be on Tue, Nov 30, 1999 at 11:16:29AM +0100 Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG | > If we were to use Yarrow, we get the review for free by virtue of it being | > designed & reviewed by a professional cryptographer. | | Regardless of who the designer was, I think we need a review by | an independent third party. | | The fact that Yarrow is a respected professional cryptographer | would raise the bar and should make it less likely that there are | really glaring stupid problems, and might require that we find | someone of higher caliber than perhaps we might otherwise have sought | out. | | But I don't think this eliminates the need for a review by an | independent third party. Right, but I think you miss the point. Yarrow WILL be reviewed by third parties whether it is in our kernel or not. -- Dan Moschuk (TFreak!dan@freebsd.org) "Cure for global warming: One giant heatsink and dual fans!" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Tue Nov 30 8: 7:27 1999 Delivered-To: freebsd-audit@freebsd.org Received: from dozer.skynet.be (dozer.skynet.be [195.238.2.36]) by hub.freebsd.org (Postfix) with ESMTP id 361C315941; Tue, 30 Nov 1999 08:06:53 -0800 (PST) (envelope-from root@foxbert.skynet.be) Received: from foxbert.skynet.be (foxbert.skynet.be [195.238.1.45]) by dozer.skynet.be (8.9.3/odie-relay-v1.0) with ESMTP id RAA14850; Tue, 30 Nov 1999 17:06:52 +0100 (MET) Received: (from root@localhost) by foxbert.skynet.be (8.9.1/jovi-pop-2.1) id RAA11680; Tue, 30 Nov 1999 17:06:46 +0100 (MET) Mime-Version: 1.0 X-Sender: blk@foxbert.skynet.be Message-Id: In-Reply-To: <19991130105241.A279@spirit.jaded.net> References: <19991130105241.A279@spirit.jaded.net> Date: Tue, 30 Nov 1999 17:05:59 +0100 To: Dan Moschuk 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: Kris Kennaway , Dan Moschuk , Bruce Evans , Mike Smith , audit@FreeBSD.ORG, Warner Losh Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 10:52 AM -0500 1999/11/30, Dan Moschuk wrote: > Right, but I think you miss the point. Yarrow WILL be reviewed by third > parties whether it is in our kernel or not. I think I understand that point. The point I was trying to make is that I feel that the FreeBSD audit project needs to have its own cryptographer/ultra-paranoid security aware programmer to review Yarrow immediately, and not only confirm that the crypto is using well-known algorithms, but also that all the other stuff is written in a sufficiently paranoid manner. I'm not sure we can afford to wait for others (presumably including Schneier) to review Yarrow and give it a stamp of "I haven't been able to break or discover serious weaknesses yet" approval, which will presumably come years on down the line. Although we need this too, we also have a more immediate need. -- 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 Tue Nov 30 9:20:26 1999 Delivered-To: freebsd-audit@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id CB39514E66; Tue, 30 Nov 1999 09:20:23 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id JAA25777; Tue, 30 Nov 1999 09:20:21 -0800 (PST) (envelope-from dillon) Date: Tue, 30 Nov 1999 09:20:21 -0800 (PST) From: Matthew Dillon Message-Id: <199911301720.JAA25777@apollo.backplane.com> To: Bill Fumerola Cc: "Jordan K. Hubbard" , Kris Kennaway , Dan Moschuk , 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 References: Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :> Not being able to predict pids (for useful purposes) would fall under :> the definition of "negative impact" for a number of admins. : :Depending on a behavior that isn't defined anywhere and doesn't :always work falls in my definition of "negative clue". : :-- :- bill fumerola - billf@chc-chimes.com - BF1560 - computer horizons corp - This is a ridiculous argument, Bill. All of us depend on (or feel comfortable with) behavior that is not defined anywhere. Such behavior exists everywhere. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Tue Nov 30 11:13:52 1999 Delivered-To: freebsd-audit@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id E5146159D8; Tue, 30 Nov 1999 11:13:49 -0800 (PST) (envelope-from jkh@zippy.cdrom.com) Received: from zippy.cdrom.com (localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id LAA91222; Tue, 30 Nov 1999 11:13:42 -0800 (PST) (envelope-from jkh@zippy.cdrom.com) To: Bill Fumerola Cc: Kris Kennaway , Matthew Dillon , Dan Moschuk , 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 "Tue, 30 Nov 1999 09:45:14 EST." Date: Tue, 30 Nov 1999 11:13:42 -0800 Message-ID: <91218.943989222@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Depending on a behavior that isn't defined anywhere and doesn't > always work falls in my definition of "negative clue". You're too newly-minted an admin to have an informed opinion about this, I hate to say. People who've been doing Unix since the 70's have different definitions of "defined" since anything you use for over 10 years becomes "defined" whether it's written down anywhere or not, and there are thousands of examples of this around. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Tue Nov 30 11:39:40 1999 Delivered-To: freebsd-audit@freebsd.org Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.133]) by hub.freebsd.org (Postfix) with ESMTP id 3223E159E8 for ; Tue, 30 Nov 1999 11:39:24 -0800 (PST) (envelope-from mark@grondar.za) Received: from grondar.za (localhost [127.0.0.1]) by gratis.grondar.za (8.9.3/8.9.3) with ESMTP id VAA17777 for ; Tue, 30 Nov 1999 21:39:22 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <199911301939.VAA17777@gratis.grondar.za> To: freebsd-audit@FreeBSD.ORG Subject: Time to redirect! (Was: Re: Topics for -security vs. topics for -audit) Date: Tue, 30 Nov 1999 21:39:21 +0200 From: Mark Murray Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG OK, we have definitely got critical mass, and we certainly have momentum. Now we need direction. The purpose of this list is not to discuss architectural issues. We are here to _audit_. If a problem crops up, and there is a code/style/security issue with it that needs to be addressed, then please take that to the most appropriate of -arch, -current or -security, and bring the answer back here. > Even in the past two days, we've seen significant discussion > that should probably be taking place on -security: selecting a > pseudo-random number generator does relate to source code, but > it's also an issue our crypto-intense folks should be keeping an > eye on, even those that are not into detailed coding. Where to > use the pseudo-random number generator becomes more of an auditing > issue--places where it should be used, but some approximation is > currently used, or where a poor seed is used. The same goes for > default conditions for using the prng in network and pid code, > etc. This is discussion relevant to a wide audience. Right! What I want to organise now is the various groups; in the beginning, I had a lot of folk volunteering for various things; I'd like you to please do this again (for the record), and in such a way that we can all find you on the appropriate mailing list archives. Please could you volunteer for each of the following classes by sending a mail to this list with your choice of subject(s) (more than one mail is OK): "Volunteer as code auditor" "Volunteer to help with web page setup" ...&c. Please write a _very_short_ resume describing why you should do this job in the body of the mail (purely for reference). Eventually you'll land up on the rogue's gallery as "one of the team". I'd like the webmasters to come out and help set up a hypertext version of the source tree (not the actual source, just the directory structure), and a method of submitting results. So far, the results (c|sh)ould be: 1) Code examined by and deemed a) abuse of i) string library functions (str* b* s*printf etc). ii) temp file races and symlink abuse iii) buffers by "inline" code iv) SUID/SGID privelige v) secret data (password buffers, environment variables, &c) vi) &c... b) clean (?) -Wall -Weverything -Werror as appropriate. (the intent is not to force the committal of these options, but to use the compiler tools (heck, even lint(1)) to automate as much of this as possible). c) to have adopted (where appropriate) such fixes/features offered by our sister BSD's. Separate s may do individual parts, but this must be tracked. So far, I lean towards the unit of audit being the file, not the function, but I suspect that with good tools, this could change in the future. There must be a mechanism for auditors to "claim" code for auditing (to avoid duplication of effort), but there must be a time limit to prevent tracts of code being "locked out" of the audit process. I request the simplest possible implementations; CGI in perl? Great! CGI in C? Wonderful! Multi-megabyte system on NT/VB? Naaah. Ideas? Cool. Volunteers? Better. Code? Aaaaah!! :-) M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Tue Nov 30 11:51:28 1999 Delivered-To: freebsd-audit@freebsd.org Received: from jade.chc-chimes.com (jade.chc-chimes.com [216.28.46.6]) by hub.freebsd.org (Postfix) with ESMTP id 76B74159FB; Tue, 30 Nov 1999 11:51:25 -0800 (PST) (envelope-from billf@chc-chimes.com) Received: by jade.chc-chimes.com (Postfix, from userid 1001) id 75EA21C66; Tue, 30 Nov 1999 13:52:28 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by jade.chc-chimes.com (Postfix) with ESMTP id 72184381B; Tue, 30 Nov 1999 13:52:28 -0500 (EST) Date: Tue, 30 Nov 1999 13:52:28 -0500 (EST) From: Bill Fumerola To: "Jordan K. Hubbard" Cc: Kris Kennaway , Matthew Dillon , Dan Moschuk , 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: <91218.943989222@zippy.cdrom.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 Tue, 30 Nov 1999, Jordan K. Hubbard wrote: > You're too newly-minted an admin to have an informed opinion about > this, I hate to say. People who've been doing Unix since the 70's > have different definitions of "defined" since anything you use for > over 10 years becomes "defined" whether it's written down anywhere or > not, and there are thousands of examples of this around. There's nothing like the "I'm older and have been doing this longer." to explain something. I still say that there are too many external factors in the old linear system to depend on getting a certain pid. -- - bill fumerola - billf@chc-chimes.com - BF1560 - computer horizons corp - - ph:(800) 252-2421 - bfumerol@computerhorizons.com - billf@FreeBSD.org - To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Tue Nov 30 12:55: 8 1999 Delivered-To: freebsd-audit@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id BF09F15A1A; Tue, 30 Nov 1999 12:54:51 -0800 (PST) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id NAA18044; Tue, 30 Nov 1999 13:54:10 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp03.primenet.com, id smtpdAAAz1aimJ; Tue Nov 30 13:54:07 1999 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id NAA05867; Tue, 30 Nov 1999 13:54:41 -0700 (MST) From: Terry Lambert Message-Id: <199911302054.NAA05867@usr09.primenet.com> Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern kern_fork.c To: billf@chc-chimes.com (Bill Fumerola) Date: Tue, 30 Nov 1999 20:54:41 +0000 (GMT) Cc: jkh@zippy.cdrom.com, kris@hub.freebsd.org, dillon@apollo.backplane.com, dan@FreeBSD.ORG, arch@FreeBSD.ORG, audit@FreeBSD.ORG In-Reply-To: from "Bill Fumerola" at Nov 30, 99 01:52:28 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > You're too newly-minted an admin to have an informed opinion about > > this, I hate to say. People who've been doing Unix since the 70's > > have different definitions of "defined" since anything you use for > > over 10 years becomes "defined" whether it's written down anywhere or > > not, and there are thousands of examples of this around. > > There's nothing like the "I'm older and have been doing this > longer." to explain something. > > I still say that there are too many external factors in the old > linear system to depend on getting a certain pid. SMP, anyone? You are supposed to use the variable containing the child process ID in your scripts, anyway. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Tue Nov 30 14:19:34 1999 Delivered-To: freebsd-audit@freebsd.org Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 5A63814C97; Tue, 30 Nov 1999 14:19:30 -0800 (PST) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40330>; Wed, 1 Dec 1999 09:12:02 +1100 Content-return: prohibited Date: Wed, 1 Dec 1999 09:19:18 +1100 From: Peter Jeremy 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: <89015.943945313@zippy.cdrom.com> To: arch@FreeBSD.ORG, audit@FreeBSD.ORG Reply-To: peter.jeremy@alcatel.com.au Message-Id: <99Dec1.091202est.40330@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0pre3i Content-type: text/plain; charset=us-ascii References: <89015.943945313@zippy.cdrom.com> Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 1999-Nov-30 18:01:53 +1100, Jordan K. Hubbard wrote: >> This would fall under my preferred policy, which you didn't quote, namely >> "turn on everything which doesn't have a negative impact, and providing > >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 find it a PITA. Sequential PID allocation makes it much easier to get a feeling for what is going on (and in what order). Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Tue Nov 30 15:14:56 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 B6ED914F31 for ; Tue, 30 Nov 1999 15:14:53 -0800 (PST) (envelope-from tstromberg@rtci.com) Received: from rtci.com (karma.afterthought.org [208.11.244.6]) by barracuda.aquarium.rtci.com (8.9.3+Sun/8.9.3) with ESMTP id SAA08985 for ; Tue, 30 Nov 1999 18:15:01 -0500 (EST) Message-ID: <38445A6A.50245AF5@rtci.com> Date: Tue, 30 Nov 1999 18:14:50 -0500 From: Thomas Stromberg Reply-To: tstromberg@rtci.com Organization: Research Triangle Commerce, Inc. X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-audit@freebsd.org Subject: Where to start? Heres a few overflows. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG About two weeks ago now I did a preliminary scan with a tool I've been developing (smashwidgets) of the FreeBSD suid applications. This was done as a precursor to 'certification' at our company of FreeBSD meeting all of our security requirements (we've got 5 FreeBSD servers in production right now, so it's in my best interest to see to the security). In any case, I found some problems in rdump/dump/systat. I reported all three to FreeBSD-security. The first two have been fixed in at least -CURRENT, not so certain about the third (minor). However, when I saw the FreeBSD Auditing project announced, I was quite elated at the chance to give smashwidgets a spin on the entire system to help out. When I started, I ran into a few speedbumps with crashes in -CURRENT, but I may have gotten these straightened out thanks to Matthew Dillon. (PV's). Please note that most of these have little significance directly. Unfortunatly, I've been so busy playing with the smashwidgets toolset that I haven't had time to follow these up for validity or exploitability. Also, the smashwidgets kit can't be released until I can get work convinced to release it under a BSD license . I've improved it during the course of the tests, for instance I just added some checks for STDIN overflows (normal, URL format, etc.).. I'll re-run when I get a chance. The results below are from the first 206 programs that breakwidgets (part of smashwidgets) was run through. I think BTW, the #'s don't mean minimum, just a # the tester happened to crash it with. A nice collection of core files are at http://www.afterthought.org/freebsd/cores/ if your bored. This roughly means that 10% of tested binaries have easily found overflows. program desc -------------------------------------------------- *dump overflow when giving it a partition to dump ex: dump -0 [A*1024] (msg?) *rdump overflow when giving it a partition to dump ex: rdump -0 [A*1024] !dig overflow in many arguments. No errors, but core. ex: dig -k [A*16000] !dnsquery overflow in any argument. ex: dnsquery [A*4000] !doscmd overflow in any argument. ex: doscmd [A*4000] !ee overflow in $NLSPATH. set NLSPATH to [A*32769] !ed overflow in any argument. ex: ed [A*40000] !red overflow in any argument. ex: ed [A*40000] !dhclient overflow in any argument. ex: dhclient [A*40000] !natd argument overflow.. ex: natd -w [A*16384] blah !startslip argument overflow.. ex: startslip -d [A*8192] -c [A*8192] !Mail overflow in $HOME, set HOME to [A*32769] !apply argument overflow.. ex: apply blah [A*16384] !mount_mfs argument overflow ex: mount_mfs [A*8192] [A*8192] !as argument overflow ex: as [A*8192] !awk arg overflow, but only a SIG6. ex: awk -f [A*8192] ?banner arg overflow. discussed in -CURRENT. ex: banner [A*8192] !captoinfo enviroment overflow, set TERMCAP to [A*32769] !colldef overflow in -I argument ex: colldef -I [A*8192] !crunchgen arg overflow ex: crunchgen [A*8192] ?systat possible race condition in systat -n (and other gui modes). Happens when program is terminated sometimes. (could be libcurses?). Test script sent to security-officer. Trace as follows: #0 0x280714c5 in wmove () from /usr/lib/libcurses.so.2 #1 0x804b916 in free () #2 0xbfbfdfdc in ?? () #3 0x2807bc4c in tgetflag () from /usr/lib/libtermcap.so.2 #4 0x2807130b in setterm () from /usr/lib/libcurses.so.2 #5 0x28071159 in setterm () from /usr/lib/libcurses.so.2 #6 0x28070759 in initscr () from /usr/lib/libcurses.so.2 #7 0x804b529 in free () #8 0x80499fd in free () * fixed in current ! not announced to my knowledge ? may be fixed, but was not when the test was done. -- ====================================================================== thomas r. stromberg smtp://tstromberg@rtci.com assistant is manager / systems guru http://thomas.stromberg.org research triangle commerce, inc. finger://thomas@stromberg.org 'om mani pedme hung' pots://1.919.380.9771:3210 ================================================================[eof]= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Tue Nov 30 15:22:14 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 8024B14E5F for ; Tue, 30 Nov 1999 15:22:10 -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 QAA10844; Tue, 30 Nov 1999 16:22:09 -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 QAA05983; Tue, 30 Nov 1999 16:22:48 -0700 (MST) Message-Id: <199911302322.QAA05983@harmony.village.org> To: tstromberg@rtci.com Subject: Re: Where to start? Heres a few overflows. Cc: freebsd-audit@FreeBSD.ORG In-reply-to: Your message of "Tue, 30 Nov 1999 18:14:50 EST." <38445A6A.50245AF5@rtci.com> References: <38445A6A.50245AF5@rtci.com> Date: Tue, 30 Nov 1999 16:22:48 -0700 From: Warner Losh Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <38445A6A.50245AF5@rtci.com> Thomas Stromberg writes: : *dump overflow when giving it a partition to dump : ex: dump -0 [A*1024] (msg?) : *rdump overflow when giving it a partition to dump : ex: rdump -0 [A*1024] These are fixed in -current. I've not backported to stable, but should. : !doscmd overflow in any argument. : ex: doscmd [A*4000] Tip of the iceburg. That's why it isn't set*id anymore. : ?banner arg overflow. discussed in -CURRENT. : ex: banner [A*8192] I have a patch in my tree for this. Just need to send commentary on it out. : ?systat possible race condition in systat -n (and other gui : modes). Happens when program is terminated sometimes. : (could be libcurses?). Test script sent to security-officer. : : Trace as follows: : : #0 0x280714c5 in wmove () from /usr/lib/libcurses.so.2 : #1 0x804b916 in free () : #2 0xbfbfdfdc in ?? () : #3 0x2807bc4c in tgetflag () from /usr/lib/libtermcap.so.2 : #4 0x2807130b in setterm () from /usr/lib/libcurses.so.2 : #5 0x28071159 in setterm () from /usr/lib/libcurses.so.2 : #6 0x28070759 in initscr () from /usr/lib/libcurses.so.2 : #7 0x804b529 in free () : #8 0x80499fd in free () If these are really to be believed, and you are recursively entering free, then I can't help you with this at all. malloc isn't reentrant. However, the traceback looks funny now that I take a closer look at it. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Tue Nov 30 18:11:38 1999 Delivered-To: freebsd-audit@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id AAC5014CD1; Tue, 30 Nov 1999 18:11:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 9819B1CD7F9; Tue, 30 Nov 1999 18:11:36 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Tue, 30 Nov 1999 18:11:36 -0800 (PST) From: Kris Kennaway To: Thomas Stromberg Cc: freebsd-audit@freebsd.org Subject: Re: Where to start? Heres a few overflows. In-Reply-To: <38445A6A.50245AF5@rtci.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 Tue, 30 Nov 1999, Thomas Stromberg wrote: > it with. A nice collection of core files are at > http://www.afterthought.org/freebsd/cores/ if your bored. This roughly > means that 10% of tested binaries have easily found overflows. > > program desc Excellent! Thanks for the work..fixing these should be easy. This kind of brute-force approach is a useful companion to more rigorous, source-based testing. Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Tue Nov 30 18:18:34 1999 Delivered-To: freebsd-audit@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id C5F0214CD1; Tue, 30 Nov 1999 18:18:31 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id SAA28858; Tue, 30 Nov 1999 18:18:29 -0800 (PST) (envelope-from dillon) Date: Tue, 30 Nov 1999 18:18:29 -0800 (PST) From: Matthew Dillon Message-Id: <199912010218.SAA28858@apollo.backplane.com> To: "Jordan K. Hubbard" Cc: Bill Fumerola , Kris Kennaway , Dan Moschuk , 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 References: <91218.943989222@zippy.cdrom.com> Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> Depending on a behavior that isn't defined anywhere and doesn't :> always work falls in my definition of "negative clue". : :You're too newly-minted an admin to have an informed opinion about :this, I hate to say. People who've been doing Unix since the 70's Mm. Unless you know the guy from grade school, you can hardly make that sort of statement. I know kids 15 years my junior who are as good programmers as I am. Well, ok, I know *one* kid. Well, ok, he *IS* a little crazy. Mmm. A lot crazy. Would you believe .... ? -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Tue Nov 30 19:44:40 1999 Delivered-To: freebsd-audit@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id B386214D6A; Tue, 30 Nov 1999 19:44:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id A3E0A1CD7F7; Tue, 30 Nov 1999 19:44:38 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Tue, 30 Nov 1999 19:44:38 -0800 (PST) From: Kris Kennaway To: "Jordan K. Hubbard" Cc: Matthew Dillon , 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: <89015.943945313@zippy.cdrom.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 Mon, 29 Nov 1999, Jordan K. Hubbard wrote: > > This would fall under my preferred policy, which you didn't quote, namely > > "turn on everything which doesn't have a negative impact, and providing > > Not being able to predict pids (for useful purposes) would fall under > the definition of "negative impact" for a number of admins. Well, I think it would be quite useful by default because of the boost it gives for badly written applications, but I'm certainly not going to go to war over it. I'm content to leave it for the viking contingent to liberate when they sail in on their longboats one cold danish morn :-) Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Tue Nov 30 21:33:44 1999 Delivered-To: freebsd-audit@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.100.7]) by hub.freebsd.org (Postfix) with ESMTP id 6EC7E14C4E; Tue, 30 Nov 1999 21:33:38 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.9.3/8.9.3) with ESMTP id AAA30992; Wed, 1 Dec 1999 00:33:21 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <91218.943989222@zippy.cdrom.com> References: <91218.943989222@zippy.cdrom.com> Date: Wed, 1 Dec 1999 00:39:02 -0500 To: "Jordan K. Hubbard" , Bill Fumerola From: Garance A Drosihn 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: Kris Kennaway , Matthew Dillon , Dan Moschuk , 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 11:13 AM -0800 11/30/99, Jordan K. Hubbard wrote: > > Depending on a behavior that isn't defined anywhere and doesn't > > always work falls in my definition of "negative clue". > >You're too newly-minted an admin to have an informed opinion about >this, I hate to say. People who've been doing Unix since the 70's >have different definitions of "defined" since anything you use for >over 10 years becomes "defined" whether it's written down anywhere >or not, and there are thousands of examples of this around. Hmm. I think you're putting the emphasis on the wrong part of his sentence. I read it as: Writing something which *depends* on this behavior is a bad idea, because this behavior does not always occur. Ie, it is *already* true that you can't "depend" on it. And since the behavior isn't written down anywhere as part of any standard, someone who depends on this can't even complain when the behavior does not happen. At the same time, I think there's a difference between finding something "useful" (as I remember the original comment), and "*depending* on that behavior". Something which is true 95% of the time can be "mighty useful" at times, even if I wouldn't want write anything which "depends" on that behavior. Just out of curiosity, is there some way we can provide the "useful" part even if the PID's are randomly assigned? Ie, what exactly *is* useful about sequential PID's? My guess is just that you want a history of which processes started in which order (including processes which may not be around any longer, or which have been reparented). Perhaps we could have some other mechanism for that? Is there any other legit benefit to having consecutive PID's? I'm just wondering, because that's the only benefit I've gotten from consecutive PID's. What I'm thinking is maybe just a wrapping buffer that keeps the last PID's which were assigned, and the PPID of the process that started each of those PID's. I imagine it'd be nice to also include process-creation timestamps, but that might chew up memory too fast. Would that provide the desired benefit, while still avoiding the security issues? [I'm sending this to both -arch and -audit, but I imagine the discussion should continue on just -arch...] --- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Tue Nov 30 21:44: 6 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 9F12014F60 for ; Tue, 30 Nov 1999 21:43:45 -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 AAA13143; Wed, 1 Dec 1999 00:43:18 -0500 (EST) Date: Wed, 1 Dec 1999 00:43:18 -0500 (EST) From: Kelly Yancey X-Sender: kbyanc@kronos.alcnet.com To: Mark Murray Cc: freebsd-audit@FreeBSD.ORG Subject: Re: Time to redirect! (Was: Re: Topics for -security vs. topics for -audit) In-Reply-To: <199911301939.VAA17777@gratis.grondar.za> 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 > Please could you volunteer for each of the following classes by sending > a mail to this list with your choice of subject(s) (more than one mail > is OK): > > "Volunteer as code auditor" I'de be glad to help where I can as code auditor. My "resume" includes 12 years of programming experience: about 10 years of which are C (the most prodigious amount of coding being in the last 6 years). Overlap that with several years of x86 assembly programming and a few years of the standard unix utility fare (perl, sh, awk, etc). Not to mention the now useless years of Pascal :) > "Volunteer to help with web page setup" For the past 5 years, this has been how I spend my days. I've been dreaming in HTML, SQL, PHP, and perl for months straight :) It's gotten so bad that when I got home I kept going and put up database-driven sites for the distributed.net Team FreeBSD and am currently working on the BSD Driver Database. This is where I think I can help the project the most. > I'd like the webmasters to come out and help set up a hypertext > version of the source tree (not the actual source, just the directory > structure), and a method of submitting results. > > So far, the results (c|sh)ould be: > 1) Code examined by and deemed > a) abuse of > i) string library functions (str* b* s*printf etc). > ii) temp file races and symlink abuse > iii) buffers by "inline" code > iv) SUID/SGID privelige > v) secret data (password buffers, environment variables, &c) > vi) &c... > b) clean (?) -Wall -Weverything -Werror as appropriate. > (the intent is not to force the committal of these > options, but to use the compiler tools (heck, even > lint(1)) to automate as much of this as possible). > c) to have adopted (where appropriate) such fixes/features > offered by our sister BSD's. > > Separate s may do individual parts, but this must be tracked. > > So far, I lean towards the unit of audit being the file, not the > function, but I suspect that with good tools, this could change > in the future. > > There must be a mechanism for auditors to "claim" code for auditing > (to avoid duplication of effort), but there must be a time limit to > prevent tracts of code being "locked out" of the audit process. > > I request the simplest possible implementations; CGI in perl? Great! > CGI in C? Wonderful! Multi-megabyte system on NT/VB? Naaah. > > Ideas? Cool. Volunteers? Better. Code? Aaaaah!! :-) I submitted some ideas I had in these regards to -current last week. See http://docs.freebsd.org/cgi/getmsg.cgi?fetch=357598+0+archive/1999/freebsd-current/19991128.freebsd-current Personally, I'm leaning toward a combination of PHP and perl. Basically, PHP to provide rapid development of the web user-interface, perl to provide back-end automated processing such as monitoring commits. I haven't played with CTM yet, but I would definately investigate using a perl script to catch the CTM-generate e-mail and flag functions (or if you prefer, files) as modified. Perhaps I've gone SQL happy, but it is my first inclination to store the project progress in a SQL database (either mySQL or postgreSQL, I use mySQL for most projects, so I'm leaning that direction). I think SQL would be an asset here in that we gain: * a standardized way to access the project data * an efficient method of retrieving and updating that data * we don't have to write our own data access interfaces so we have a faster development time Anyway, I'm looking forward to working on this, both the audit itself, and hopefully the web site. Your willing servant, 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 Tue Nov 30 21:52:52 1999 Delivered-To: freebsd-audit@freebsd.org Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.133]) by hub.freebsd.org (Postfix) with ESMTP id A0EFA14CE6 for ; Tue, 30 Nov 1999 21:52:44 -0800 (PST) (envelope-from mark@grondar.za) Received: from grondar.za (localhost [127.0.0.1]) by gratis.grondar.za (8.9.3/8.9.3) with ESMTP id HAA19929; Wed, 1 Dec 1999 07:52:35 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <199912010552.HAA19929@gratis.grondar.za> To: tstromberg@rtci.com Cc: freebsd-audit@FreeBSD.ORG Subject: Re: Where to start? Heres a few overflows. Date: Wed, 01 Dec 1999 07:52:34 +0200 From: Mark Murray Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is superb! Where can we get your code/tool? (May we use it?) > About two weeks ago now I did a preliminary scan with a tool I've been > developing (smashwidgets) of the FreeBSD suid applications. This was > done as a precursor to 'certification' at our company of FreeBSD meeting > all of our security requirements (we've got 5 FreeBSD servers in > production right now, so it's in my best interest to see to the > security). > > In any case, I found some problems in rdump/dump/systat. I reported all > three to FreeBSD-security. The first two have been fixed in at least > -CURRENT, not so certain about the third (minor). However, when I saw > the FreeBSD Auditing project announced, I was quite elated at the chance > to give smashwidgets a spin on the entire system to help out. When I > started, I ran into a few speedbumps with crashes in -CURRENT, but I may > have gotten these straightened out thanks to Matthew Dillon. (PV's). > > Please note that most of these have little significance directly. > Unfortunatly, I've been so busy playing with the smashwidgets toolset > that I haven't had time to follow these up for validity or > exploitability. Also, the smashwidgets kit can't be released until I can > get work convinced to release it under a BSD license . > > I've improved it during the course of the tests, for instance I just > added some checks for STDIN overflows (normal, URL format, etc.).. I'll > re-run when I get a chance. The results below are from the first 206 > programs that breakwidgets (part of smashwidgets) was run through. I > think > > BTW, the #'s don't mean minimum, just a # the tester happened to crash > it with. A nice collection of core files are at > http://www.afterthought.org/freebsd/cores/ if your bored. This roughly > means that 10% of tested binaries have easily found overflows. > > program desc > -------------------------------------------------- > *dump overflow when giving it a partition to dump > ex: dump -0 [A*1024] (msg?) > *rdump overflow when giving it a partition to dump > ex: rdump -0 [A*1024] > !dig overflow in many arguments. No errors, but core. > ex: dig -k [A*16000] > !dnsquery overflow in any argument. > ex: dnsquery [A*4000] > !doscmd overflow in any argument. > ex: doscmd [A*4000] > !ee overflow in $NLSPATH. set NLSPATH to [A*32769] > !ed overflow in any argument. > ex: ed [A*40000] > !red overflow in any argument. > ex: ed [A*40000] > !dhclient overflow in any argument. > ex: dhclient [A*40000] > !natd argument overflow.. > ex: natd -w [A*16384] blah > !startslip argument overflow.. > ex: startslip -d [A*8192] -c [A*8192] > !Mail overflow in $HOME, set HOME to [A*32769] > !apply argument overflow.. > ex: apply blah [A*16384] > !mount_mfs argument overflow > ex: mount_mfs [A*8192] [A*8192] > !as argument overflow > ex: as [A*8192] > !awk arg overflow, but only a SIG6. > ex: awk -f [A*8192] > ?banner arg overflow. discussed in -CURRENT. > ex: banner [A*8192] > !captoinfo enviroment overflow, set TERMCAP to [A*32769] > !colldef overflow in -I argument > ex: colldef -I [A*8192] > !crunchgen arg overflow > ex: crunchgen [A*8192] > ?systat possible race condition in systat -n (and other gui > modes). Happens when program is terminated sometimes. > (could be libcurses?). Test script sent to security-officer. > > Trace as follows: > > #0 0x280714c5 in wmove () from /usr/lib/libcurses.so.2 > #1 0x804b916 in free () > #2 0xbfbfdfdc in ?? () > #3 0x2807bc4c in tgetflag () from /usr/lib/libtermcap.so.2 > #4 0x2807130b in setterm () from /usr/lib/libcurses.so.2 > #5 0x28071159 in setterm () from /usr/lib/libcurses.so.2 > #6 0x28070759 in initscr () from /usr/lib/libcurses.so.2 > #7 0x804b529 in free () > #8 0x80499fd in free () > > > * fixed in current > ! not announced to my knowledge > ? may be fixed, but was not when the test was done. > > > > -- > ====================================================================== > thomas r. stromberg smtp://tstromberg@rtci.com > assistant is manager / systems guru http://thomas.stromberg.org > research triangle commerce, inc. finger://thomas@stromberg.org > 'om mani pedme hung' pots://1.919.380.9771:3210 > ================================================================[eof]= > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-audit" in the body of the message -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Tue Nov 30 21:59:59 1999 Delivered-To: freebsd-audit@freebsd.org Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.133]) by hub.freebsd.org (Postfix) with ESMTP id D241C14BF2 for ; Tue, 30 Nov 1999 21:59:52 -0800 (PST) (envelope-from mark@grondar.za) Received: from grondar.za (localhost [127.0.0.1]) by gratis.grondar.za (8.9.3/8.9.3) with ESMTP id HAA19975; Wed, 1 Dec 1999 07:59:43 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <199912010559.HAA19975@gratis.grondar.za> To: Kelly Yancey Cc: freebsd-audit@FreeBSD.ORG Subject: Re: Time to redirect! (Was: Re: Topics for -security vs. topics for -audit) Date: Wed, 01 Dec 1999 07:59:42 +0200 From: Mark Murray Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Personally, I'm leaning toward a combination of PHP and perl. Basically, > PHP to provide rapid development of the web user-interface, perl to > provide back-end automated processing such as monitoring commits. I > haven't played with CTM yet, but I would definately investigate using a > perl script to catch the CTM-generate e-mail and flag functions (or if you > prefer, files) as modified. You're hired! :-) > Perhaps I've gone SQL happy, but it is my first inclination to store the > project progress in a SQL database (either mySQL or postgreSQL, I use > mySQL for most projects, so I'm leaning that direction). I think SQL would > be an asset here in that we gain: > * a standardized way to access the project data > * an efficient method of retrieving and updating that data > * we don't have to write our own data access interfaces so we have > a faster development time Sounds good. > Anyway, I'm looking forward to working on this, both the audit itself, > and hopefully the web site. Bingo. Please keep me in a fairly tight loop WRT progress, and as soon as we have anything useable, we should set it up and get going. > Your willing servant, "Slave" is a better word. There ain't no pay here ;-). M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Tue Nov 30 22: 5:23 1999 Delivered-To: freebsd-audit@freebsd.org Received: from turing.csis.gvsu.edu (turing.csis.gvsu.edu [148.61.162.181]) by hub.freebsd.org (Postfix) with SMTP id 775A214C56 for ; Tue, 30 Nov 1999 22:05:20 -0800 (PST) (envelope-from matt@csis.gvsu.edu) Received: (qmail 834 invoked by uid 0); 1 Dec 1999 06:05:19 -0000 Received: from pm493-26.dialip.mich.net (HELO 198.110.188.228) (198.110.188.228) by csis.gvsu.edu with SMTP; 1 Dec 1999 06:05:19 -0000 Received: (qmail 65618 invoked by uid 500); 1 Dec 1999 06:04:56 -0000 From: matt@csis.gvsu.edu Date: Wed, 1 Dec 1999 01:04:56 -0500 To: freebsd-audit@freebsd.org Subject: [matt@: Re: Time to redirect! (Was: Re: Topics for -security vs. topics for -audit)] Message-ID: <19991201010456.A47649@badmofo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i X-my-OS-is-better-than-your-OS: FreeBSD 3.3-STABLE i386 Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Oops! Forgot to cc -audit and include a "resume". My "resume" is pretty limited, I've had about 5 years C experience and 1 year studying secure programming techniques. I suppose I don't have any specific "strengths", but I'm willing to help out in any way possible! I'll be available in roughly 2 weeks (after exams). > So far, the results (c|sh)ould be: > 1) Code examined by and deemed > [SNIP] Definately, the first targets should be S[UG]ID programs and network daemons. > c) to have adopted (where appropriate) such fixes/features > offered by our sister BSD's. I see that OpenBSD's strlcpy() and strlcat() are integrated in 3.3, but they don't seem to used at all (at least on -STABLE). Perhaps it's even worth the effort to audit some of the more popular ports? I assume the target will be -CURRENT? -- http://www.csis.gvsu.edu/matt 03 F8 23 C5 43 A2 F7 5A 24 49 F7 B0 3A F9 B1 7F Try to understand everything, but believe nothing To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Tue Nov 30 22:29:36 1999 Delivered-To: freebsd-audit@freebsd.org Received: from oskar.dev.nanoteq.co.za (oskar.dev.nanoteq.co.za [196.7.114.5]) by hub.freebsd.org (Postfix) with ESMTP id 63D3E14F2C for ; Tue, 30 Nov 1999 22:29:27 -0800 (PST) (envelope-from rbezuide@oskar.dev.nanoteq.co.za) Received: (from rbezuide@localhost) by oskar.dev.nanoteq.co.za (8.9.3/8.9.0) id IAA20217; Wed, 1 Dec 1999 08:28:09 +0200 (SAT) From: Reinier Bezuidenhout Message-Id: <199912010628.IAA20217@oskar.dev.nanoteq.co.za> Subject: Volunteer as code auditor In-Reply-To: <199911301939.VAA17777@gratis.grondar.za> from Mark Murray at "Nov 30, 99 09:39:21 pm" To: mark@grondar.za (Mark Murray) Date: Wed, 1 Dec 1999 08:28:09 +0200 (SAT) Cc: freebsd-audit@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi ... I volenteer as code auditor ... Short resume: Studied in Computer Science (networks and artificial intelligence) for 4 years. Been working for 5 years in the firewall / security environment developing a firewall system on FreeBSD. Device drivers, packetfiltering setup, client-server coding, perl coding, low level network coding etc. etc. So let's go for it :) Reinier Bezuidenhout To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Tue Nov 30 22:46:16 1999 Delivered-To: freebsd-audit@freebsd.org Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.133]) by hub.freebsd.org (Postfix) with ESMTP id C517014DDC for ; Tue, 30 Nov 1999 22:46:06 -0800 (PST) (envelope-from mark@grondar.za) Received: from grondar.za (localhost [127.0.0.1]) by gratis.grondar.za (8.9.3/8.9.3) with ESMTP id IAA20439; Wed, 1 Dec 1999 08:44:49 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <199912010644.IAA20439@gratis.grondar.za> To: matt@csis.gvsu.edu Cc: freebsd-audit@FreeBSD.ORG Subject: Re: [matt@: Re: Time to redirect! (Was: Re: Topics for -security vs. topics for -audit)] Date: Wed, 01 Dec 1999 08:44:48 +0200 From: Mark Murray Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I assume the target will be -CURRENT? Absolutely. When any bugs get fixed, they may be ported to STABLE later, but that is not the oiunt or thrust of the -audit project. That is just how FreeBSD works... M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Wed Dec 1 5:51: 6 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 CB54B14D0F for ; Wed, 1 Dec 1999 05:51:03 -0800 (PST) (envelope-from tstromberg@rtci.com) Received: from rtci.com (karma.afterthought.org [208.11.244.6]) by barracuda.aquarium.rtci.com (8.9.3+Sun/8.9.3) with ESMTP id IAA17566; Wed, 1 Dec 1999 08:51:04 -0500 (EST) Message-ID: <384527B9.3A3E3C41@rtci.com> Date: Wed, 01 Dec 1999 08:50:49 -0500 From: Thomas Stromberg Reply-To: tstromberg@rtci.com Organization: Research Triangle Commerce, Inc. X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Warner Losh , freebsd-audit@freebsd.org Subject: Re: Where to start? Heres a few overflows. References: <38445A6A.50245AF5@rtci.com> <199911302322.QAA05983@harmony.village.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > : *rdump overflow when giving it a partition to dump > : ex: rdump -0 [A*1024] > > These are fixed in -current. I've not backported to stable, but should. Seeing as it's suid, It should probably be expidited. I myself took the suid bit off of it on my -STABLE boxes (I usually do, since I make no use of dump as non-root). > : !doscmd overflow in any argument. > : ex: doscmd [A*4000] > > Tip of the iceburg. That's why it isn't set*id anymore. I figured as much. I seem to remember a while back that it was at least sgid kmem, and thought I found another good one. I was happily suprised to see the bit had been taken off however. The less set*id there is the happier I am. > : #0 0x280714c5 in wmove () from /usr/lib/libcurses.so.2 > : #1 0x804b916 in free () > : #2 0xbfbfdfdc in ?? () > : #3 0x2807bc4c in tgetflag () from /usr/lib/libtermcap.so.2 > : #4 0x2807130b in setterm () from /usr/lib/libcurses.so.2 > : #5 0x28071159 in setterm () from /usr/lib/libcurses.so.2 > : #6 0x28070759 in initscr () from /usr/lib/libcurses.so.2 > : #7 0x804b529 in free () > : #8 0x80499fd in free () > > If these are really to be believed, and you are recursively entering > free, then I can't help you with this at all. malloc isn't > reentrant. However, the traceback looks funny now that I take a > closer look at it. Did you have any luck re-creating it with the script I sent you? Interested to see if this becomes a systat or a curses thing.. -- ====================================================================== thomas r. stromberg smtp://tstromberg@rtci.com assistant is manager / systems guru http://thomas.stromberg.org research triangle commerce, inc. finger://thomas@stromberg.org 'om mani pedme hung' pots://1.919.380.9771:3210 ================================================================[eof]= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Wed Dec 1 6:20:45 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 BF3D314E9A for ; Wed, 1 Dec 1999 06:19:37 -0800 (PST) (envelope-from tstromberg@rtci.com) Received: from rtci.com (karma.afterthought.org [208.11.244.6]) by barracuda.aquarium.rtci.com (8.9.3+Sun/8.9.3) with ESMTP id JAA18360; Wed, 1 Dec 1999 09:19:38 -0500 (EST) Message-ID: <38452E6B.C820BD4A@rtci.com> Date: Wed, 01 Dec 1999 09:19:23 -0500 From: Thomas Stromberg Reply-To: tstromberg@rtci.com Organization: Research Triangle Commerce, Inc. X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Mark Murray , freebsd-audit@freebsd.org Subject: Re: Where to start? Heres a few overflows. (smashwidgets) References: <199912010552.HAA19929@gratis.grondar.za> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mark Murray wrote: > > This is superb! > > Where can we get your code/tool? (May we use it?) Can't get it yet I'm afraid. Once I can finish the base tool, I still need to get approval to release this to the public domain since it was developed through my employment. This shouldn't be a big hurdle. I should be able to post a copy up on a webpage early next week. I'll continue to post results in this list however. I think this type of tool should be in the hands of every OS vendor (with the functionality extended of course). I think it would have made our world a bit nicer of a place :0 . I would have thought Sun Microsystems would have had such a beast, but looking at the kcms_configure $NETPATH overflow released this week, it's evident that no such brute forcing or careful auditing had been done. I still have a few messes to handle: - a proper kill after timeout.. after my alarm() is triggered, some programs hang out in the background (sometimes zombies). Right now I just run killall -9 on the program. This however gets nasty when say, your testing perl. I wish system() would return a pid or something. If I was using threads, I could just kill off the thread (see bottom). This becomes a real 'trick' because some programs change their 'program name' after running in the process list. For instance, I load sendmail as "sendmail -bd -q15m", but /proc/93221/cmdline (and by nature, ps), says "sendmail: accepting connections on port 25@". I wish there was a seperate cmdline & name file :) - analyzewidgets, the program that analyzes a binary for what enviroment variables to test for, does not work so well on say the Solaris base-chain. Right now how I find what enviroment variables to test for is I took all of /usr/src, and the 150 or so ports I make use of, did some grep & regexp magic for whatever they used with *env(), and search the binary for it. I've got 567 env variables to test with, but some of these are application specific. I've got a seperate list of 326 good ones that I actually test against. Things I compile under Solaris with gcc leave the enviroment variables in plain text in the binary, but not say, /usr/openwin/bin/kcms_configure or any of the other base toolset. Whats a nice automated way to find out what enviroment variables are used by a binary? truss was no help here it seems. Maybe some gdb wizardry..? - performance sucks with programs that expect input (for instance, 'enigma'). I've got a 3 second timeout, so rather then 5000-8000 tests a minute, I gather 20 or so. The solution for this would be threading off multiple tests if it's say, under 500 tests/minute. Unfortunatly I have no experience with perl threads, and this functionality isn't a priority for me. -- ====================================================================== thomas r. stromberg smtp://tstromberg@rtci.com assistant is manager / systems guru http://thomas.stromberg.org research triangle commerce, inc. finger://thomas@stromberg.org 'om mani pedme hung' pots://1.919.380.9771:3210 ================================================================[eof]= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Wed Dec 1 6:53:20 1999 Delivered-To: freebsd-audit@freebsd.org Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.133]) by hub.freebsd.org (Postfix) with ESMTP id 4156614D70 for ; Wed, 1 Dec 1999 06:53:13 -0800 (PST) (envelope-from mark@grondar.za) Received: from grondar.za (localhost [127.0.0.1]) by gratis.grondar.za (8.9.3/8.9.3) with ESMTP id QAA21615; Wed, 1 Dec 1999 16:52:57 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <199912011452.QAA21615@gratis.grondar.za> To: tstromberg@rtci.com Cc: freebsd-audit@freebsd.org Subject: Re: Where to start? Heres a few overflows. (smashwidgets) Date: Wed, 01 Dec 1999 16:52:56 +0200 From: Mark Murray Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Where can we get your code/tool? (May we use it?) > > Can't get it yet I'm afraid. Once I can finish the base tool, I still > need to get approval to release this to the public domain since it was > developed through my employment. This shouldn't be a big hurdle. I > should be able to post a copy up on a webpage early next week. I'll > continue to post results in this list however. Wonderful! This is a long-term project, so "next week" is just fine. Heck, I reckon even next century is fine! (Yeah, yeah) :-) M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Wed Dec 1 7:47: 0 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 23D8B15BAC for ; Wed, 1 Dec 1999 07:46:05 -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 QAA21903; Wed, 1 Dec 1999 16:45:27 +0100 (MET) Received: (from root@localhost) by foxbert.skynet.be (8.9.1/jovi-pop-2.1) id QAA11809; Wed, 1 Dec 1999 16:45:22 +0100 (MET) Mime-Version: 1.0 X-Sender: blk@foxbert.skynet.be Message-Id: In-Reply-To: <199911301939.VAA17777@gratis.grondar.za> References: <199911301939.VAA17777@gratis.grondar.za> Date: Wed, 1 Dec 1999 16:44:28 +0100 To: Mark Murray , freebsd-audit@FreeBSD.ORG From: Brad Knowles Subject: Volunteer as junior code auditor (was: Re: Time to redirect! (Was: Re: Topics for -security vs. topics for -audit)) Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 9:39 PM +0200 1999/11/30, Mark Murray wrote: > Please could you volunteer for each of the following classes by sending > a mail to this list with your choice of subject(s) (more than one mail > is OK): > > "Volunteer as code auditor" > "Volunteer to help with web page setup" > ...&c. I'd like to volunteer as a junior code auditor. > Please write a _very_short_ resume describing why you should do > this job in the body of the mail (purely for reference). Eventually > you'll land up on the rogue's gallery as "one of the team". I've been doing Unix SA work for over ten years, and using Unix=20 for over fifteen. Unfortunately, I haven't done any real programming=20 since college, although I'd like to take this opportunity to get back=20 into it [-1]. I have done relatively light shell and Perl scripting,=20 however. I like to consider myself at least passingly familiar with=20 cryptography in general [0], and the semi-paranoid approach to=20 computer security [1]. For more details, if you send me private e-mail I can give you an=20 URL the previous version of my American-style r=E9sum=E9 [2], which also=20 has links to other versions of the same document, as well as the=20 expanded European-style curriculum vitae. If you can either give me automated tools to run, or procedures=20 that I can follow in order to do some of the "grunt" work, I'll be=20 glad to do it. I've got a machine here where I think I can run=20 -CURRENT [3], so that I can do some first-hand testing of the=20 procedures that would be applied. If this isn't the sort of help you folks need, that's fine. I=20 want to help in any way that I can, but if the skills I have aren't=20 useful to this phase of the project, I can deal with that. [-1] With luck, I can then take some of this experience and use it=20 to help me implement proper multi-threading in the USENET news server=20 Diablo. [0] I've been to several DC CypherPunk meetings, and have met a=20 number of the local luminaries and invited guests (such as Dave=20 Banisar and Whitfield Diffie), and I believe that I have Carl=20 Ellison's signature on one of the PGP keys I've got floating around. [1] I have had meaningful exchanges with Simson Garfinkel, and=20 Marcus Ranum should even remember my name. [2] Not yet updated to reflect the work at my current employer,=20 although it is not relevant to this project. [3] Although I may need some help getting it there. ;-) --=20 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 Wed Dec 1 8:11:21 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 30C6E14D78 for ; Wed, 1 Dec 1999 08:11:18 -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 JAA13381; Wed, 1 Dec 1999 09:09:44 -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 JAA02320; Wed, 1 Dec 1999 09:09:43 -0700 (MST) Message-Id: <199912011609.JAA02320@harmony.village.org> To: tstromberg@rtci.com Subject: Re: Where to start? Heres a few overflows. Cc: freebsd-audit@freebsd.org In-reply-to: Your message of "Wed, 01 Dec 1999 08:50:49 EST." <384527B9.3A3E3C41@rtci.com> References: <384527B9.3A3E3C41@rtci.com> <38445A6A.50245AF5@rtci.com> <199911302322.QAA05983@harmony.village.org> Date: Wed, 01 Dec 1999 09:09:43 -0700 From: Warner Losh Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <384527B9.3A3E3C41@rtci.com> Thomas Stromberg writes: : > : *rdump overflow when giving it a partition to dump : > : ex: rdump -0 [A*1024] : > : > These are fixed in -current. I've not backported to stable, but should. : : Seeing as it's suid, It should probably be expidited. I myself took the : suid bit off of it on my -STABLE boxes (I usually do, since I make no : use of dump as non-root). Yes. However, this buffer overflow appears to be benign given the memory layout. I did an extensive analysis of this which I sent to Thomas a while ago which showed that it was a bug, but not a penetration bug. A good project would be to bring in the fork write(1) rather than putting that functionality inside dump changes OpenBSD made years ago. : Did you have any luck re-creating it with the script I sent you? : Interested to see if this becomes a systat or a curses thing.. No. I tried once, but it didn't fail and I've not gotten back to it. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Wed Dec 1 8:23: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 C5E0415832 for ; Wed, 1 Dec 1999 08:23:06 -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 RAA10980; Wed, 1 Dec 1999 17:22:42 +0100 (MET) Received: (from root@localhost) by foxbert.skynet.be (8.9.1/jovi-pop-2.1) id RAA21841; Wed, 1 Dec 1999 17:22:39 +0100 (MET) Mime-Version: 1.0 X-Sender: blk@foxbert.skynet.be Message-Id: In-Reply-To: <199912011609.JAA02320@harmony.village.org> References: <384527B9.3A3E3C41@rtci.com> <38445A6A.50245AF5@rtci.com> <199911302322.QAA05983@harmony.village.org> <199912011609.JAA02320@harmony.village.org> Date: Wed, 1 Dec 1999 17:22:27 +0100 To: Warner Losh , tstromberg@rtci.com From: Brad Knowles Subject: Re: Where to start? Heres a few overflows. Cc: freebsd-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 9:09 AM -0700 1999/12/1, Warner Losh wrote: > Yes. However, this buffer overflow appears to be benign given the > memory layout. I did an extensive analysis of this which I sent to > Thomas a while ago which showed that it was a bug, but not a > penetration bug. As I recall, one of the goals that OpenBSD used in their audit process was that they fixed bugs wherever they ran across them, regardless of whether they believed they were exploitable. This has protected them against a number of exploits that have since become known, since the bug that someone is trying to exploit simply no longer exists under OpenBSD. Do we not want to employ the same kind of methodology, or have I missed something here? Also, what about the OpenBSD approach whereby security becomes inherently integrated into the entire development process, as opposed to something you try to add later? Maybe I'm missing something, but it seems to me that the entire audit project is doomed to ultimately fail if we can't ensure that bugs, once fixed, remain that way. -- 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 Wed Dec 1 8:27: 4 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 E4CF715BB1 for ; Wed, 1 Dec 1999 08:27:00 -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 JAA13433; Wed, 1 Dec 1999 09:26:26 -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 JAA02551; Wed, 1 Dec 1999 09:26:26 -0700 (MST) Message-Id: <199912011626.JAA02551@harmony.village.org> To: Brad Knowles Subject: Re: Where to start? Heres a few overflows. Cc: tstromberg@rtci.com, freebsd-audit@FreeBSD.ORG In-reply-to: Your message of "Wed, 01 Dec 1999 17:22:27 +0100." References: <384527B9.3A3E3C41@rtci.com> <38445A6A.50245AF5@rtci.com> <199911302322.QAA05983@harmony.village.org> <199912011609.JAA02320@harmony.village.org> Date: Wed, 01 Dec 1999 09:26:26 -0700 From: Warner Losh Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Brad Knowles writes: : As I recall, one of the goals that OpenBSD used in their audit : process was that they fixed bugs wherever they ran across them, : regardless of whether they believed they were exploitable. This has : protected them against a number of exploits that have since become : known, since the bug that someone is trying to exploit simply no : longer exists under OpenBSD. : : Do we not want to employ the same kind of methodology, or have I : missed something here? Yes, we do, but we don't want to put everything into stable on an expitited basis unless there is a compelling reason to expitite the change. We do want to merge these changes into stable when they have stood the test of time in -current first. That's my only point here. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Wed Dec 1 12: 2:44 1999 Delivered-To: freebsd-audit@freebsd.org Received: from pawn.primelocation.net (pawn.primelocation.net [205.161.238.235]) by hub.freebsd.org (Postfix) with ESMTP id D3ED115041 for ; Wed, 1 Dec 1999 12:02:40 -0800 (PST) (envelope-from jedgar@fxp.org) Received: from earth.fxp (oca-c1s5-34.mfi.net [209.26.94.219]) by pawn.primelocation.net (Postfix) with ESMTP id 3FB099B37; Wed, 1 Dec 1999 15:01:42 -0500 (EST) Date: Wed, 1 Dec 1999 15:01:47 -0500 (EST) From: "Chris D. Faulhaber" X-Sender: jedgar@earth.fxp To: Mark Murray Cc: freebsd-audit@FreeBSD.ORG Subject: Re: Time to redirect! (Was: Re: Topics for -security vs. topics for -audit) In-Reply-To: <199911301939.VAA17777@gratis.grondar.za> 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, 30 Nov 1999, Mark Murray wrote: > Please could you volunteer for each of the following classes by sending > a mail to this list with your choice of subject(s) (more than one mail > is OK): > You may count me in as an auditor. I have about 15 years of programming experience with C, Pascal, Perl, Fortran (ugh), Pascal, etc. Currently I am in the middle of performing code audits on inherited in-house software and am used to working with legacy code from before the 'buffer overflow' revolution. In addition, I may be able to lend a hand with some web page tasks (php in particular) and/or DBA-type work if you go the SQL route for storing information. ----- Chris D. Faulhaber | You can ISO9001 certify the process of System/Network Administrator, | shooting yourself in the foot, so long Reality Check Information, Inc. | as the process is documented and reliably | produces the proper result. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Wed Dec 1 12:55:12 1999 Delivered-To: freebsd-audit@freebsd.org Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 0943E1519D for ; Wed, 1 Dec 1999 12:55:08 -0800 (PST) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40322>; Thu, 2 Dec 1999 07:47:32 +1100 Content-return: prohibited Date: Thu, 2 Dec 1999 07:54:52 +1100 From: Peter Jeremy Subject: Re: Where to start? Heres a few overflows. (smashwidgets) In-reply-to: <38452E6B.C820BD4A@rtci.com> To: Thomas Stromberg Cc: freebsd-audit@FreeBSD.ORG Reply-To: peter.jeremy@alcatel.com.au Message-Id: <99Dec2.074732est.40322@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0pre3i Content-type: text/plain; charset=us-ascii References: <199912010552.HAA19929@gratis.grondar.za> <38452E6B.C820BD4A@rtci.com> Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 1999-Dec-02 01:19:23 +1100, Thomas Stromberg wrote: >Can't get it yet I'm afraid. Once I can finish the base tool, I still >need to get approval to release this to the public domain since it was >developed through my employment. This shouldn't be a big hurdle. I >should be able to post a copy up on a webpage early next week. I'll >continue to post results in this list however. Good. This sounds quite useful. > I wish system() would return a pid or something. Since system() blocks until the child exit()s, the pid wouldn't be much use. Why not build it yourself using fork()/exec()? >Things I compile under Solaris with gcc leave the enviroment variables >in plain text in the binary, but not say, >/usr/openwin/bin/kcms_configure or any of the other base toolset. Most X11 environment variables are actually in the shared libraries. I suspect the same is true for KDE. You'll need to use ldd to pick out the shared libraries and then run strings over them. (This isn't the best approach because there's nothing to indicate which parts of the shared library are actually used). You also have the problem that the names of environment variables may be created on the fly (eg browser proxy environment variables). > Whats >a nice automated way to find out what enviroment variables are used by a >binary? truss was no help here it seems. truss (and ktrace) won't work because the environment is in user space and doesn't generate any system calls. > Maybe some gdb wizardry..? You could put a breakpoint on getenv() and check the passed argument. The list you get in this way may not reflect all the environment variables potentially used, of course. An alternative would be to build your own libc.so with a replaced getenv() [and friends]. This still won't work for statically linked programs or for programs that grovel around in envp themselves. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Wed Dec 1 12:56:23 1999 Delivered-To: freebsd-audit@freebsd.org Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.133]) by hub.freebsd.org (Postfix) with ESMTP id 85AB4151AA for ; Wed, 1 Dec 1999 12:55:18 -0800 (PST) (envelope-from mark@grondar.za) Received: from grondar.za (localhost [127.0.0.1]) by gratis.grondar.za (8.9.3/8.9.3) with ESMTP id WAA22838; Wed, 1 Dec 1999 22:54:35 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <199912012054.WAA22838@gratis.grondar.za> To: Brad Knowles Cc: Warner Losh , tstromberg@rtci.com, freebsd-audit@FreeBSD.ORG Subject: Re: Where to start? Heres a few overflows. Date: Wed, 01 Dec 1999 22:54:34 +0200 From: Mark Murray Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > As I recall, one of the goals that OpenBSD used in their audit > process was that they fixed bugs wherever they ran across them, > regardless of whether they believed they were exploitable. This has > protected them against a number of exploits that have since become > known, since the bug that someone is trying to exploit simply no > longer exists under OpenBSD. This is very valid, and most valuable. > Do we not want to employ the same kind of methodology, or have I > missed something here? Absolutely. Any bug fises are most welcome. > Also, what about the OpenBSD approach whereby security becomes > inherently integrated into the entire development process, as opposed > to something you try to add later? As long as it is not a silly thing like adding crypto to cat(1), that is fine. > Maybe I'm missing something, but it seems to me that the entire > audit project is doomed to ultimately fail if we can't ensure that > bugs, once fixed, remain that way. If we can train the committer-base on what to do (some style(9)-type debates come to mind), then we should be able to maintain it indefinitely. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Wed Dec 1 14:56: 9 1999 Delivered-To: freebsd-audit@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 6146615057; Wed, 1 Dec 1999 14:56:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 517C11CD80E for ; Wed, 1 Dec 1999 14:56:08 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Wed, 1 Dec 1999 14:56:08 -0800 (PST) From: Kris Kennaway To: audit@freebsd.org Subject: Auditing ports 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 As Brock Tellier pointed out in Bugtraq, something else we need to focus on is auditing ports which install setuid/setgid executables. Even though these aren't part of "FreeBSD" as such, and we can't possibly audit all 2800 ports, it's not unreasonable to expect people will install a port on their FreeBSD system and we should make an effort that the obvious exploit candidates (setuid/setgid binaries) are secure. Prime candidates should be ports which we _patch_ to install set[ug]id, which may not have been written with security in mind (e.g. the angband hole Brock published). But there are probably a lot of other ports which install setuid when they don't need to be, or which are stupidly written and shouldn't be given a setuid bit at all. A first task would be to identify _which_ ports install set[ug]id executables: the easiest way to do this would probably be to install every available package on a box at once (or do them in chunks), compile a list of set[gu]id files and track them back to which port they came from. We can then prioritize this list in terms of potential severity. Anyone able to do this step? Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Wed Dec 1 15:24:37 1999 Delivered-To: freebsd-audit@freebsd.org Received: from dozer.skynet.be (dozer.skynet.be [195.238.2.36]) by hub.freebsd.org (Postfix) with ESMTP id 3A49E14E1C; Wed, 1 Dec 1999 15:24:34 -0800 (PST) (envelope-from root@foxbert.skynet.be) Received: from foxbert.skynet.be (foxbert.skynet.be [195.238.1.45]) by dozer.skynet.be (8.9.3/odie-relay-v1.0) with ESMTP id AAA26326; Thu, 2 Dec 1999 00:23:43 +0100 (MET) Received: (from root@localhost) by foxbert.skynet.be (8.9.1/jovi-pop-2.1) id AAA08725; Thu, 2 Dec 1999 00:23:43 +0100 (MET) Mime-Version: 1.0 X-Sender: blk@foxbert.skynet.be Message-Id: In-Reply-To: References: Date: Thu, 2 Dec 1999 00:19:19 +0100 To: Kris Kennaway , audit@FreeBSD.ORG From: Brad Knowles Subject: Re: Auditing ports Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 2:56 PM -0800 1999/12/1, Kris Kennaway wrote: > A first task would be to identify _which_ ports install set[ug]id > executables: the easiest way to do this would probably be to install every > available package on a box at once (or do them in chunks), compile a list > of set[gu]id files and track them back to which port they came from. We > can then prioritize this list in terms of potential severity. > > Anyone able to do this step? You want to do this under -CURRENT, as opposed to -STABLE, right? I'd be interested to know how it would be done, and as part of that exercise I'd be willing to try it under -STABLE (the version currently installed on the machine I can play with at the moment). I can't help you with doing this under -CURRENT, however. -- 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 Wed Dec 1 16:43:29 1999 Delivered-To: freebsd-audit@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 3427E14BF8; Wed, 1 Dec 1999 16:43:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 2201E1CD80D; Wed, 1 Dec 1999 16:43:25 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Wed, 1 Dec 1999 16:43:25 -0800 (PST) From: Kris Kennaway To: Brad Knowles Cc: audit@FreeBSD.ORG, asami@freebsd.org, ports@freebsd.org Subject: Re: Auditing ports 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 [crossposting discussion about auditing of ports which install setuid/setgid binaries to gather input from the ports crowd..] On Thu, 2 Dec 1999, Brad Knowles wrote: > You want to do this under -CURRENT, as opposed to -STABLE, right? It won't matter much, modulo ports which build on one but not the other (see http://bento.freebsd.org). All we'd want from this exercise is a list of ports which are setuid and which need to be investigated by source. > I'd be interested to know how it would be done, and as part of > that exercise I'd be willing to try it under -STABLE (the version > currently installed on the machine I can play with at the moment). I > can't help you with doing this under -CURRENT, however. Mount your 3.3R CDROM and pkg_add everything, then do a find /usr/local -perm -2000 -o -perm -4000 -ls Then we can take that list and match it against the PLIST files in the ports tree and figure out which port installed the file. This would be a start, then we have to do it for all the ports which have changed since 3.3-R. Actually, I just thought of a better way: we (FreeBSD) already have most of the pieces in place, in the form of Satoshi's port building cluster. All we (read: he :-) has to do is to check each port as it's built to see if it installs set[gu]id stuff, and flag it if so. The resulting list will catch all cases, and will also catch previously non-suid ports which suddenly become it (or just new suid ports). Would this be an easy thing to do, Satoshi? A second step would probably be to add a SECURITY tag to the makefile of all of these ports noting the audit status (e.g. "not reviewed", "reviewed v1.0, probably okay", etc). We could then have interactive port building/pkg_add/sysinstall emit a warning about potential danger from unaudited sources, etc. But the first thing is to get a list of what might be a major security risk. Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Wed Dec 1 18:20:30 1999 Delivered-To: freebsd-audit@freebsd.org Received: from hayseed.net (hayseed.net [207.181.249.194]) by hub.freebsd.org (Postfix) with ESMTP id D905F15007 for ; Wed, 1 Dec 1999 18:19:24 -0800 (PST) (envelope-from cnielsen@pobox.com) Received: from localhost (LOCALHOST [127.0.0.1]) by hayseed.net (8.9.3/8.9.3) with ESMTP id SAA14616; Wed, 1 Dec 1999 18:18:24 -0800 Date: Wed, 1 Dec 1999 18:18:31 -0800 (PST) From: Christopher Nielsen X-Sender: cnielsen@ender.scient.com To: Mark Murray Cc: freebsd-audit@FreeBSD.ORG Subject: Volunteer as Code Auditor (Was Re: Time to redirect! (Was: Re: Topics for -security vs. topics for -audit)) In-Reply-To: <199911301939.VAA17777@gratis.grondar.za> 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, 30 Nov 1999, Mark Murray wrote: > "Volunteer as code auditor" > "Volunteer to help with web page setup" > ...&c. I volunteer as a code auditor. > Please write a _very_short_ resume describing why you should do > this job in the body of the mail (purely for reference). Eventually > you'll land up on the rogue's gallery as "one of the team". I've been doing UNIX SA on various platforms and network engineering for 9 and 3 years respectively. I've been doing security work professionally for 7 years in everything from the networking layer through the applications layer, including firewall design and implementation, defining and writing policy, and secure programming. I've been programming for 12 years in languages including (in order of expertise) C, Java, Perl, C++, (MIPS|SPARC) assembly, Fortran (ugh!), and a few others not worth mentioning. Projects include everything from SA utilities to distributed applications with a little bit of operating systems programming thrown in. In my day job, my responsibilities include corporate security, and I am frequently called upon to perform code audits in both C and Java applications and design audits on systems and networks. I've been dabbling in cryptology over the last three years. -- Christopher Nielsen (enkhyl|cnielsen)@pobox.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Wed Dec 1 22: 1:15 1999 Delivered-To: freebsd-audit@freebsd.org Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.133]) by hub.freebsd.org (Postfix) with ESMTP id 330D214D0C; Wed, 1 Dec 1999 22:01:03 -0800 (PST) (envelope-from mark@grondar.za) Received: from grondar.za (localhost [127.0.0.1]) by gratis.grondar.za (8.9.3/8.9.3) with ESMTP id HAA24545; Thu, 2 Dec 1999 07:59:56 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <199912020559.HAA24545@gratis.grondar.za> To: Kris Kennaway , satoshi@freebsd.org Cc: audit@freebsd.org Subject: Re: Auditing ports Date: Thu, 02 Dec 1999 07:59:55 +0200 From: Mark Murray Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [ Satoshi CC'ed for comment ] Satoshi - background: The problem of auditing all 2800 ports was raised, and was reduced to the problem of auditing those which we patched to be set[gu]id. Kris continues: > A first task would be to identify _which_ ports install set[ug]id > executables: the easiest way to do this would probably be to install every > available package on a box at once (or do them in chunks), compile a list > of set[gu]id files and track them back to which port they came from. We > can then prioritize this list in terms of potential severity. Satoshi - is there any way that your ports-building engines can help us here by (say) spitting out some "ls -laR" lists automatically? We'll then grep them for s[gu]id bits and do the rest. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Thu Dec 2 2:19:26 1999 Delivered-To: freebsd-audit@freebsd.org Received: from mimer.webgiro.com (mimer.webgiro.com [212.209.29.5]) by hub.freebsd.org (Postfix) with ESMTP id E12D914E2D for ; Thu, 2 Dec 1999 02:19:24 -0800 (PST) (envelope-from abial@webgiro.com) Received: by mimer.webgiro.com (Postfix, from userid 66) id 4BCF32DC07; Thu, 2 Dec 1999 11:19:55 +0100 (CET) Received: by mx.webgiro.com (Postfix, from userid 1001) id B2D917813; Thu, 2 Dec 1999 11:15:13 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mx.webgiro.com (Postfix) with ESMTP id B0AEE10E10; Thu, 2 Dec 1999 11:15:13 +0100 (CET) Date: Thu, 2 Dec 1999 11:15:11 +0100 (CET) From: Andrzej Bialecki To: peter.jeremy@alcatel.com.au Cc: Thomas Stromberg , freebsd-audit@FreeBSD.ORG Subject: Re: Where to start? Heres a few overflows. (smashwidgets) In-Reply-To: <99Dec2.074732est.40322@border.alcanet.com.au> 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, 2 Dec 1999, Peter Jeremy wrote: > > Whats > >a nice automated way to find out what enviroment variables are used by a > >binary? truss was no help here it seems. > > truss (and ktrace) won't work because the environment is in user space > and doesn't generate any system calls. However, execve() syscall contains full environment passed to a process. You can spy on this syscall e.g. with my SPY module :-) http://www.freebsd.org/~abial/spy/README Andrzej Bialecki // WebGiro AB, Sweden (http://www.webgiro.com) // ------------------------------------------------------------------- // ------ FreeBSD: The Power to Serve. http://www.freebsd.org -------- // --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ ---- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Thu Dec 2 7:18: 6 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 315EE14CD2; Thu, 2 Dec 1999 07:18:02 -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 KAA12458; Thu, 2 Dec 1999 10:16:44 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Thu, 2 Dec 1999 10:16:44 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Mark Murray Cc: Kris Kennaway , satoshi@freebsd.org, audit@freebsd.org Subject: Re: Auditing ports In-Reply-To: <199912020559.HAA24545@gratis.grondar.za> 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, 2 Dec 1999, Mark Murray wrote: > [ Satoshi CC'ed for comment ] > > Satoshi - background: The problem of auditing all 2800 ports was > raised, and was reduced to the problem of auditing those which > we patched to be set[gu]id. > > Kris continues: > > > A first task would be to identify _which_ ports install set[ug]id > > executables: the easiest way to do this would probably be to install every > > available package on a box at once (or do them in chunks), compile a list > > of set[gu]id files and track them back to which port they came from. We > > can then prioritize this list in terms of potential severity. > > Satoshi - is there any way that your ports-building engines can help > us here by (say) spitting out some "ls -laR" lists automatically? > > We'll then grep them for s[gu]id bits and do the rest. So, while this is certainly useful (setuid binaries are prime targets), there's a lot of other code in the ports collection that will run with privilege making it also relevant. This includes daemons, inetd-spawned or otherwise, etc, etc. Everyone remembers, of course, the UWash IMAP server :-). Maybe the better approach is to have a new Makefile entry AUDIT_ME=yes for code that the porter feels might benefit from auditing. On the other hand, root can and probably will run any port installed so who cares :-). 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 Thu Dec 2 7:35:54 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 18FC914D4A; Thu, 2 Dec 1999 07:35:51 -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 KAA04463; Thu, 2 Dec 1999 10:27:05 -0500 (EST) (envelope-from gerald@manhattanprojects.com) Message-ID: <384691C6.347BE836@manhattanprojects.com> Date: Thu, 02 Dec 1999 10:35:34 -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: Auditing ports 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: > > [crossposting discussion about auditing of ports which install > setuid/setgid binaries to gather input from the ports crowd..] 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. If we already have volunteers and enough bodies for that, then lets do this. But I think that we may want to backburner this until we've done a check of the non-port stuff. 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 Thu Dec 2 8:21:44 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 8486114EEE; Thu, 2 Dec 1999 08:21:34 -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 RAA23797; Thu, 2 Dec 1999 17:21:22 +0100 (MET) Received: (from root@localhost) by foxbert.skynet.be (8.9.1/jovi-pop-2.1) id RAA28073; Thu, 2 Dec 1999 17:21:17 +0100 (MET) Mime-Version: 1.0 X-Sender: blk@foxbert.skynet.be Message-Id: In-Reply-To: <384691C6.347BE836@manhattanprojects.com> References: <384691C6.347BE836@manhattanprojects.com> Date: Thu, 2 Dec 1999 16:44:02 +0100 To: Gerald Abshez , Kris Kennaway From: Brad Knowles Subject: Re: Auditing ports Cc: 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 10:35 AM -0500 1999/12/2, 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. In so far as this goes, I agree -- we need to focus on /usr/src first (setXid stuff before non-setXid?), then we can worry about the ports. However, that said, if we've got automated tools that we can use to help us in this process, then there's no harm in firing them off at the ports in addition to the stuff under /usr/src. But first things first -- we need to define the procedures we're going to use, identify the tools that will help us implement these procedures, identify the most critical targets that should be audited before anything else, etc.... -- 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 Fri Dec 3 13:45:54 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 933C0152A6 for ; Fri, 3 Dec 1999 13:45:50 -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 QAA22747 for ; Fri, 3 Dec 1999 16:46:00 -0500 (EST) Message-ID: <84724545.944257545945.JavaMail.chenresig@karma> Date: Fri, 3 Dec 1999 16:45:45 -0500 (EST) From: tstromberg@rtci.com To: freebsd-audit@freebsd.org Subject: More binaries with overflows. (7) 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've improved the breakwidgets program a lot, so I should be getting more results now. I try now to maximize the enviroment space (ENV+argument overflows), so I should find a few of the trickier ones now. This should also improve the stdin overflow checks. I still need to add a feature that says "If I've already found X overflows with this env variable, or this program, go to the next one".. that would save me time from the 100's of cores I get right now. I've experienced a few slowdowns because of regular crashes under -CURRENT, but I'll keep on chugging. here is a few more I found: /usr/bin/error arg overflow, ex: error -I [A*16384] /usr/bin/fsplit arg overflow in -e, ex: fsplit -e [A*16384] /usr/bin/grops arg overflow, ex: grops -c blah [A*16384] /usr/bin/patch arg overflow, ex: patch -r [A*16384] /usr/bin/pr arg overflow, ex: pr -s [A*16384] /usr/bin/ypcat arg overflow in -d, ex: ypcat -d [A*16384] blah /usr/libexec/aout/as stdin overflow in -I, ex: echo "[A*16384]" | as -I I also managed to crash cc1 & cc1plus, but haven't been able to determine why. As always, a collection of core dumps is availabe at http://www.afterthought.org/freebsd/cores .. .. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Fri Dec 3 13:58: 5 1999 Delivered-To: freebsd-audit@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id C25B814BEF; Fri, 3 Dec 1999 13:58:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id B00CA1CD7A3; Fri, 3 Dec 1999 13:58:03 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Fri, 3 Dec 1999 13:58:03 -0800 (PST) From: Kris Kennaway To: tstromberg@rtci.com Cc: freebsd-audit@freebsd.org Subject: Re: More binaries with overflows. (7) In-Reply-To: <84724545.944257545945.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 Fri, 3 Dec 1999 tstromberg@rtci.com wrote: > I also managed to crash cc1 & cc1plus, but haven't been able to > determine why. As always, a collection of core dumps is availabe at > http://www.afterthought.org/freebsd/cores .. The webserver won't let me have any of these.. Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Fri Dec 3 14:54: 7 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 14C2114A16; Fri, 3 Dec 1999 14:53: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 RAA24370; Fri, 3 Dec 1999 17:53:48 -0500 (EST) Message-ID: <84718545.944261614590.JavaMail.chenresig@karma> Date: Fri, 3 Dec 1999 17:53:34 -0500 (EST) From: tstromberg@rtci.com To: Kris Kennaway , tstromberg@rtci.com Subject: Re: More binaries with overflows. (7) Cc: freebsd-audit@freebsd.org In-Reply-To: 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 -------------------------------- -> On Fri, 3 Dec 1999 tstromberg@rtci.com wrote: -> -> > I also managed to crash cc1 & cc1plus, but haven't been able to -> > determine why. As always, a collection of core dumps is availabe at -> > http://www.afterthought.org/freebsd/cores .. -> -> The webserver won't let me have any of these.. -> -> Kris -------------------------------- Oops.. forgot about the default permissions for core files. Fixed. ============================================================================ 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 Fri Dec 3 19:26:57 1999 Delivered-To: freebsd-audit@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id DD66014CB9; Fri, 3 Dec 1999 19:26:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id D00511CD7CD; Fri, 3 Dec 1999 19:26:55 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Fri, 3 Dec 1999 19:26:55 -0800 (PST) From: Kris Kennaway To: tstromberg@rtci.com Cc: freebsd-audit@freebsd.org Subject: Re: More binaries with overflows. (7) In-Reply-To: <84724545.944257545945.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 Fri, 3 Dec 1999 tstromberg@rtci.com wrote: > /usr/bin/fsplit arg overflow in -e, ex: fsplit -e [A*16384] This one is just gross. It needs to be rewritten. > /usr/bin/patch arg overflow, ex: patch -r [A*16384] OpenBSD have a bunch of tempfile fixes as well as the buffer overflow fixes which should be merged. > /usr/bin/pr arg overflow, ex: pr -s [A*16384] This one was just a simple bug :) > /usr/bin/ypcat arg overflow in -d, ex: ypcat -d [A*16384] blah This one was a buffer overflow in libc which I'm testing a patch for now. I haven't checked the others yet Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Fri Dec 3 21:34:43 1999 Delivered-To: freebsd-audit@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 8B63B15334; Fri, 3 Dec 1999 21:34:29 -0800 (PST) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id VAA82253; Fri, 3 Dec 1999 21:32:33 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <199912040532.VAA82253@gndrsh.dnsmgr.net> Subject: Re: More binaries with overflows. (7) In-Reply-To: from Kris Kennaway at "Dec 3, 1999 07:26:55 pm" To: kris@hub.freebsd.org (Kris Kennaway) Date: Fri, 3 Dec 1999 21:32:33 -0800 (PST) Cc: tstromberg@rtci.com, freebsd-audit@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Fri, 3 Dec 1999 tstromberg@rtci.com wrote: > > > /usr/bin/fsplit arg overflow in -e, ex: fsplit -e [A*16384] > > This one is just gross. It needs to be rewritten. > > > /usr/bin/patch arg overflow, ex: patch -r [A*16384] > > OpenBSD have a bunch of tempfile fixes as well as the buffer overflow > fixes which should be merged. > > > /usr/bin/pr arg overflow, ex: pr -s [A*16384] > > This one was just a simple bug :) > > > /usr/bin/ypcat arg overflow in -d, ex: ypcat -d [A*16384] blah > > This one was a buffer overflow in libc which I'm testing a patch for now. > > I haven't checked the others yet Good work Kris, but I have a point about your commits, I didn't see any ``reviewed by's: for them and you've now hidden the old flaw from one of the only automated tools we have for finding these types of flaws :-( -audit related fixes should really be very carefuly eyeballed by a few reviewers, too often in the past hasty patch work by even the best of security programmers has related to harder to find security bugs. -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Fri Dec 3 21:35:46 1999 Delivered-To: freebsd-audit@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 3064414BDB; Fri, 3 Dec 1999 21:35:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id E38151CD7C0 for ; Fri, 3 Dec 1999 21:35:44 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Fri, 3 Dec 1999 21:35:44 -0800 (PST) From: Kris Kennaway To: audit@freebsd.org Subject: Buffer overflows in libc (yp) 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 Can someone take a look over the attached patch against lib/libc/yp/yplib.c, which fixes two buffer overflows in the YP code? This is manifested in, e.g. 'ypcat -d $BIGBUF' which presently overflows and smashes the stack. Kris Index: yp/yplib.c =================================================================== RCS file: /home/ncvs//src/lib/libc/yp/yplib.c,v retrieving revision 1.31 diff -u -r1.31 yplib.c --- yplib.c 1999/08/28 00:02:58 1.31 +++ yplib.c 1999/12/04 05:23:10 @@ -29,7 +29,7 @@ */ #ifndef LINT -static char *rcsid = "$FreeBSD$"; +static char *rcsid = "$FreeBSD: src/lib/libc/yp/yplib.c,v 1.31 1999/08/28 00:02:58 peter Exp $"; #endif #include @@ -372,7 +372,7 @@ ysd->dom_client = NULL; ysd->dom_socket = -1; } - sprintf(path, "%s/%s.%d", BINDINGDIR, dom, 2); + snprintf(path, sizeof(path), "%s/%s.%d", BINDINGDIR, dom, 2); if( (fd=open(path, O_RDONLY)) == -1) { /* no binding file, YP is dead. */ /* Try to bring it back to life. */ @@ -503,7 +503,7 @@ *(u_short *)&ypbr.ypbind_resp_u.ypbind_bindinfo.ypbind_binding_port; gotit: ysd->dom_vers = YPVERS; - strcpy(ysd->dom_domain, dom); + strlcpy(ysd->dom_domain, dom, sizeof(ysd->dom_domain)-1); } /* Don't rebuild the connection to the server unless we have to. */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Fri Dec 3 21:37:56 1999 Delivered-To: freebsd-audit@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 22F4514A2A; Fri, 3 Dec 1999 21:37:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 156D11CD7EE; Fri, 3 Dec 1999 21:37:55 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Fri, 3 Dec 1999 21:37:55 -0800 (PST) From: Kris Kennaway To: "Rodney W. Grimes" Cc: tstromberg@rtci.com, freebsd-audit@FreeBSD.ORG Subject: Re: More binaries with overflows. (7) In-Reply-To: <199912040532.VAA82253@gndrsh.dnsmgr.net> 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, 3 Dec 1999, Rodney W. Grimes wrote: > > I haven't checked the others yet > > Good work Kris, but I have a point about your commits, I didn't see > any ``reviewed by's: for them and you've now hidden the old flaw from > one of the only automated tools we have for finding these types of > flaws :-( That's because the only fixes I've committed unreviewed have not been security-related, but simple bugs which crashed the program (an off-by-one error on a buffer, and some just plain wrong code). These were trivial enough that they don't require a review. > -audit related fixes should really be very carefuly eyeballed by a few > reviewers, too often in the past hasty patch work by even the best of > security programmers has related to harder to find security bugs. I agree. Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Fri Dec 3 21:55:17 1999 Delivered-To: freebsd-audit@freebsd.org Received: from gatekeeper.veriohosting.com (gatekeeper.veriohosting.com [192.41.0.2]) by hub.freebsd.org (Postfix) with ESMTP id DA8CF14A2A; Fri, 3 Dec 1999 21:55:10 -0800 (PST) (envelope-from hart@iserver.com) Received: by gatekeeper.veriohosting.com; Fri, 3 Dec 1999 22:54:32 -0700 (MST) Received: from unknown(192.168.1.109) by gatekeeper.veriohosting.com via smap (V3.1.1) id xma007635; Fri, 3 Dec 99 22:54:26 -0700 Received: (hart@localhost) by anchovy.orem.iserver.com (8.9.3) id WAA58478; Fri, 3 Dec 1999 22:51:29 -0700 (MST) Date: Fri, 3 Dec 1999 22:51:29 -0700 (MST) From: Paul Hart X-Sender: hart@anchovy.orem.iserver.com To: Kris Kennaway Cc: audit@FreeBSD.ORG Subject: Re: Buffer overflows in libc (yp) 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, 3 Dec 1999, Kris Kennaway wrote: > - strcpy(ysd->dom_domain, dom); > + strlcpy(ysd->dom_domain, dom, sizeof(ysd->dom_domain)-1); Shouldn't that be: strlcpy(ysd->dom_domain, dom, sizeof(ysd->dom_domain)); instead? I think one of the things that strlcpy(3) tries to address is the general confusion over SIZE vs. SIZE - 1 that plagues some of the other C string functions. Paul Hart -- Paul Robert Hart ><8> ><8> ><8> Verio Web Hosting, Inc. hart@iserver.com ><8> ><8> ><8> http://www.iserver.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Fri Dec 3 21:55:20 1999 Delivered-To: freebsd-audit@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 4FA941533D; Fri, 3 Dec 1999 21:55:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 432671CD7EE for ; Fri, 3 Dec 1999 21:55:13 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Fri, 3 Dec 1999 21:55:13 -0800 (PST) From: Kris Kennaway To: audit@freebsd.org Subject: Re: Buffer overflows in libc (yp) 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, 3 Dec 1999, Kris Kennaway wrote: > - strcpy(ysd->dom_domain, dom); > + strlcpy(ysd->dom_domain, dom, sizeof(ysd->dom_domain)-1); This shouldn't have the -1 at the end (this got by me, oops). Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Fri Dec 3 21:56:14 1999 Delivered-To: freebsd-audit@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 2A70114A2A; Fri, 3 Dec 1999 21:56:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 1C3901CD7EE; Fri, 3 Dec 1999 21:56:13 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Fri, 3 Dec 1999 21:56:13 -0800 (PST) From: Kris Kennaway To: Paul Hart Cc: audit@FreeBSD.ORG Subject: Re: Buffer overflows in libc (yp) 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, 3 Dec 1999, Paul Hart wrote: > Shouldn't that be: > > strlcpy(ysd->dom_domain, dom, sizeof(ysd->dom_domain)); Right, I just corrected myself then :-) Good to see someone else is awake ;) Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Sat Dec 4 19:41:13 1999 Delivered-To: freebsd-audit@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id C69381508F; Sat, 4 Dec 1999 19:41:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id BA66A1CD737 for ; Sat, 4 Dec 1999 19:41:04 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Sat, 4 Dec 1999 19:41:04 -0800 (PST) From: Kris Kennaway To: audit@freebsd.org Subject: ctm_rmail holes (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I haven't heard any responses about this one yet..can someone give it the twice-over? I'd kind of like to close this remote buffer overflow :-) Kris ---------- Forwarded message ---------- Date: Fri, 26 Nov 1999 22:56:42 -0800 (PST) From: Kris Kennaway To: audit@freebsd.org Subject: ctm_rmail holes There are a couple of buffer overflows in ctm_rmail (part of ctm which automatically decodes and applies deltas received via email) which look like they could be exploitable by sending a malformed email. OpenBSD fixed these, but for some reason Theo backed them out a few months ago during a sync with our code. Of course, a larger issue with CTM is that it looks like anyone can insert their code into your source tree just by sending a delta to you, because it does no authentication whatsoever of the contents except that it applies cleanly :-( The attached patch syncs with the OpenBSD security changes, and I've also fixed a lock file race, and some command-line buffer overflows which weren't likely to be security problems. However I can't test this, because I don't have my machine set up to use CTM. Comments, anyone? Kris Index: ctm_rmail.c =================================================================== RCS file: /home/ncvs/src/usr.sbin/ctm/ctm_rmail/ctm_rmail.c,v retrieving revision 1.14 diff -u -r1.14 ctm_rmail.c --- ctm_rmail.c 1998/07/27 22:26:25 1.14 +++ ctm_rmail.c 1999/12/05 03:34:07 @@ -10,6 +10,11 @@ * Maybe you should write some free software too. */ +#ifndef lint +static const char rcsid[] = +"$FreeBSD$"; +#endif /* not lint */ + #include #include #include @@ -35,7 +40,8 @@ void apply_complete(void); int read_piece(char *input_file); int combine_if_complete(char *delta, int pce, int npieces); -int combine(char *delta, int npieces, char *dname, char *pname, char *tname); +int combine(char *delta, int npieces, char *dname, char *pname, char *tname, + int len); int decode_line(char *line, char *out_buf); int lock_file(char *name); @@ -118,14 +124,14 @@ /* * Construct the file name of a piece of a delta. */ -#define mk_piece_name(fn,d,p,n) \ - sprintf((fn), "%s/%s+%03d-%03d", piece_dir, (d), (p), (n)) +#define mk_piece_name(fn,l,d,p,n) \ + snprintf((fn), l, "%s/%s+%03d-%03d", piece_dir, (d), (p), (n)) /* * Construct the file name of an assembled delta. */ -#define mk_delta_name(fn,d) \ - sprintf((fn), "%s/%s", delta_dir, (d)) +#define mk_delta_name(fn,l,d) \ + snprintf((fn), l, "%s/%s", delta_dir, (d)) /* * If the next required delta is now present, let ctm lunch on it and any @@ -149,22 +155,22 @@ * Grab a lock on the ctm mutex file so that we can be sure we are * working alone, not fighting another ctm_rmail! */ - strcpy(fname, delta_dir); - strcat(fname, "/.mutex_apply"); + strlcpy(fname, delta_dir, sizeof(fname)); + strlcat(fname, "/.mutex_apply", sizeof(fname)); if ((lfd = lock_file(fname)) < 0) return; /* * Find out which delta ctm needs next. */ - sprintf(fname, "%s/%s", base_dir, CTM_STATUS); + snprintf(fname, sizeof(fname), "%s/%s", base_dir, CTM_STATUS); if ((fp = fopen(fname, "r")) == NULL) { close(lfd); return; } - i = fscanf(fp, "%s %d %c", class, &dn, junk); + i = fscanf(fp, "%19s %d %c", class, &dn, junk); fclose(fp); if (i != 2) { @@ -178,7 +184,7 @@ here[0] = '\0'; if (delta_dir[0] != '/') { - getcwd(here, sizeof(here)-1); + getcwd(here, sizeof(here)-2); i = strlen(here) - 1; if (i >= 0 && here[i] != '/') { @@ -192,13 +198,13 @@ */ for (;;) { - sprintf(delta, "%s.%04d.gz", class, ++dn); - mk_delta_name(fname, delta); + snprintf(delta, sizeof(delta), "%s.%04d.gz", class, ++dn); + mk_delta_name(fname, sizeof(fname), delta); if (stat(fname, &sb) < 0) break; - sprintf(buf, "(cd %s && ctm %s%s%s%s) 2>&1", base_dir, + snprintf(buf, sizeof(buf), "(cd %s && ctm %s%s%s%s) 2>&1", base_dir, set_time ? "-u " : "", apply_verbose ? "-v " : "", here, fname); if ((ctm = popen(buf, "r")) == NULL) @@ -294,7 +300,7 @@ { char *s; - if (sscanf(line, "CTM_MAIL BEGIN %s %d %d %c", + if (sscanf(line, "CTM_MAIL BEGIN %29s %d %d %c", delta, &pce, &npieces, junk) != 3) continue; @@ -302,17 +308,17 @@ *s = '_'; got_one++; - strcpy(tname, piece_dir); - strcat(tname, "/p.XXXXXX"); - if ((ofd = mkstemp(tname)) < 0) + strlcpy(tname, piece_dir, sizeof(tname)); + strlcat(tname, "/p.XXXXXXXXXX", sizeof(tname)); + if ((ofd = mkstemp(tname)) == -1 || + (ofp = fdopen(ofd, "w")) == NULL) { - err("*mkstemp: '%s'", tname); - status++; - continue; - } - if ((ofp = fdopen(ofd, "w")) == NULL) - { - err("cannot open '%s' for writing", tname); + if (ofd != -1) { + err("cannot open '%s' for writing", tname); + close(ofd); + } + else + err("*mkstemp: '%s'", tname); status++; continue; } @@ -349,7 +355,7 @@ continue; } - mk_piece_name(pname, delta, pce, npieces); + mk_piece_name(pname, sizeof(pname), delta, pce, npieces); if (rename(tname, pname) < 0) { err("*rename: '%s' to '%s'", tname, pname); @@ -438,8 +444,8 @@ */ if (npieces == 1) { - mk_delta_name(dname, delta); - mk_piece_name(pname, delta, 1, 1); + mk_delta_name(dname, sizeof(dname), delta); + mk_piece_name(pname, sizeof(pname), delta, 1, 1); if (rename(pname, dname) == 0) { err("%s complete", delta); @@ -451,8 +457,8 @@ * Grab a lock on the reassembly mutex file so that we can be sure we are * working alone, not fighting another ctm_rmail! */ - strcpy(tname, delta_dir); - strcat(tname, "/.mutex_build"); + strlcpy(tname, delta_dir, sizeof(tname)); + strlcat(tname, "/.mutex_build", sizeof(tname)); if ((lfd = lock_file(tname)) < 0) return 0; @@ -465,7 +471,7 @@ { if (i == pce) continue; - mk_piece_name(pname, delta, i, npieces); + mk_piece_name(pname, sizeof(pname), delta, i, npieces); if (stat(pname, &sb) < 0) { close(lfd); @@ -477,7 +483,7 @@ * Stick them together. Let combine() use our file name buffers, since * we're such good buddies. :-) */ - e = combine(delta, npieces, dname, pname, tname); + e = combine(delta, npieces, dname, pname, tname, sizeof(tname)); close(lfd); return e; } @@ -490,23 +496,24 @@ * happened to by lying around in the calling routine. Waste not, want not! */ int -combine(char *delta, int npieces, char *dname, char *pname, char *tname) +combine(char *delta, int npieces, char *dname, char *pname, char *tname, int len) { FILE *dfp, *pfp; int dfd; int i, n, e; char buf[BUFSIZ]; - strcpy(tname, delta_dir); - strcat(tname, "/d.XXXXXX"); - if ((dfd = mkstemp(tname)) < 0) - { - err("*mkstemp: '%s'", tname); - return 0; - } - if ((dfp = fdopen(dfd, "w")) == NULL) - { - err("cannot open '%s' for writing", tname); + strlcpy(tname, delta_dir, len); + strlcat(tname, "/d.XXXXXXXXXX", len); + if ((dfd = mkstemp(tname)) == -1 || + (dfp = fdopen(dfd, "w")) == NULL) + { + if (dfd != -1) { + close(dfd); + err("cannot open '%s' for writing", tname); + } + else + err("*mktemp: '%s'", tname); return 0; } @@ -515,7 +522,7 @@ */ for (i = 1; i <= npieces; i++) { - mk_piece_name(pname, delta, i, npieces); + mk_piece_name(pname, len, delta, i, npieces); if ((pfp = fopen(pname, "r")) == NULL) { err("cannot open '%s' for reading", pname); @@ -545,7 +552,7 @@ return 0; } - mk_delta_name(dname, delta); + mk_delta_name(dname, len, delta); if (rename(tname, dname) < 0) { err("*rename: '%s' to '%s'", tname, dname); @@ -558,7 +565,7 @@ */ for (i = 1; i <= npieces; i++) { - mk_piece_name(pname, delta, i, npieces); + mk_piece_name(pname, len, delta, i, npieces); if (unlink(pname) < 0) err("*unlink: '%s'", pname); } @@ -648,15 +655,9 @@ { int lfd; - if ((lfd = open(name, O_WRONLY|O_CREAT, 0600)) < 0) + if ((lfd = open(name, O_WRONLY|O_CREAT|O_EXLOCK, 0600)) < 0) { err("*open: '%s'", name); - return -1; - } - if (flock(lfd, LOCK_EX) < 0) - { - close(lfd); - err("*flock: '%s'", name); return -1; } return lfd; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Sat Dec 4 23: 9:24 1999 Delivered-To: freebsd-audit@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 4383C15177; Sat, 4 Dec 1999 23:09:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 378941CD742 for ; Sat, 4 Dec 1999 23:09:22 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Sat, 4 Dec 1999 23:09:22 -0800 (PST) From: Kris Kennaway To: audit@freebsd.org Subject: arp.c patch 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 This one isn't likely exploitable, but it's still a small buffer overflow. arp looks okay apart from this. Kris Index: arp.c =================================================================== RCS file: /home/ncvs//src/usr.sbin/arp/arp.c,v retrieving revision 1.19 diff -u -r1.19 arp.c --- arp.c 1999/09/20 09:10:46 1.19 +++ arp.c 1999/12/05 07:08:16 @@ -212,8 +212,8 @@ args[4] = &arg[4][0]; retval = 0; while(fgets(line, 100, fp) != NULL) { - i = sscanf(line, "%s %s %s %s %s", arg[0], arg[1], arg[2], - arg[3], arg[4]); + i = sscanf(line, "%49s %49s %49s %49s %49s", arg[0], arg[1], + arg[2], arg[3], arg[4]) if (i < 2) { warnx("bad line: %s", line); retval = 1; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Sat Dec 4 23:12:40 1999 Delivered-To: freebsd-audit@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 479AA15177; Sat, 4 Dec 1999 23:12:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 3BFA51CD742 for ; Sat, 4 Dec 1999 23:12:39 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Sat, 4 Dec 1999 23:12:39 -0800 (PST) From: Kris Kennaway To: audit@freebsd.org Subject: Closed list policy? 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 was wondering whether it would be smarter to have a closed list policy here, to prevent just anyone (read: evil people) from subscribing and getting early notification about vulnerabilities before they're patched (which may take several days). Obviously we still should have a full disclosure policy, but it gives ourselves time to fix bugs properly. Thoughts? Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Sat Dec 4 23:43:14 1999 Delivered-To: freebsd-audit@freebsd.org Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.133]) by hub.freebsd.org (Postfix) with ESMTP id B0E9314CD4; Sat, 4 Dec 1999 23:43:06 -0800 (PST) (envelope-from mark@grondar.za) Received: from grondar.za (localhost [127.0.0.1]) by gratis.grondar.za (8.9.3/8.9.3) with ESMTP id JAA15669; Sun, 5 Dec 1999 09:42:54 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <199912050742.JAA15669@gratis.grondar.za> To: Kris Kennaway Cc: audit@FreeBSD.ORG Subject: Re: ctm_rmail holes (fwd) Date: Sun, 05 Dec 1999 09:42:54 +0200 From: Mark Murray Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I haven't heard any responses about this one yet..can someone give it the > twice-over? I'd kind of like to close this remote buffer overflow :-) I'll check it... M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Sat Dec 4 23:53: 6 1999 Delivered-To: freebsd-audit@freebsd.org Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.133]) by hub.freebsd.org (Postfix) with ESMTP id C24F214EF4; Sat, 4 Dec 1999 23:53:00 -0800 (PST) (envelope-from mark@grondar.za) Received: from grondar.za (localhost [127.0.0.1]) by gratis.grondar.za (8.9.3/8.9.3) with ESMTP id JAA15703; Sun, 5 Dec 1999 09:50:25 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <199912050750.JAA15703@gratis.grondar.za> To: Kris Kennaway Cc: audit@FreeBSD.ORG Subject: Re: Closed list policy? Date: Sun, 05 Dec 1999 09:50:25 +0200 From: Mark Murray Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I was wondering whether it would be smarter to have a closed list policy > here, to prevent just anyone (read: evil people) from subscribing and > getting early notification about vulnerabilities before they're patched > (which may take several days). Obviously we still should have a full > disclosure policy, but it gives ourselves time to fix bugs properly. We are really supposed to be taling about _how_ we do the audit, and results thereof, not the actual details. The dirty details should be on -security, -arch, -current or -security-officer, as appropriate. What should be here is "I have finished foo(1), and it is now clean of all bar/baz/qux problems that I could find.". M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message