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 <kris@hub.freebsd.org>
To: Dan Moschuk <dan@freebsd.org>
Cc: freebsd-audit@freebsd.org
Subject: Re: Last random PID patch before commit
In-Reply-To: <19991128012420.A48334@spirit.jaded.net>
Message-ID: <Pine.BSF.4.21.9911280042420.89688-100000@hub.freebsd.org>
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
> + *
> + * <dan@FreeBSD.ORG> 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 <dan@freebsd.org>
To: Kris Kennaway <kris@hub.freebsd.org>
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> <Pine.BSF.4.21.9911280042420.89688-100000@hub.freebsd.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.4i
In-Reply-To: <Pine.BSF.4.21.9911280042420.89688-100000@hub.freebsd.org>; 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 <kris@hub.freebsd.org>
To: Dan Moschuk <dan@freebsd.org>
Cc: freebsd-audit@freebsd.org
Subject: Re: Last random PID patch before commit
In-Reply-To: <19991128130432.C33028@november.jaded.net>
Message-ID: <Pine.BSF.4.21.9911281055390.80171-100000@hub.freebsd.org>
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 <dan@FreeBSD.ORG>
Subject: Re: Last random PID patch before commit
Cc: Kris Kennaway <kris@hub.freebsd.org>, 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> <Pine.BSF.4.21.9911280042420.89688-100000@hub.freebsd.org>
Date: Sun, 28 Nov 1999 12:11:52 -0700
From: Warner Losh <imp@village.org>
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 <dan@FreeBSD.ORG>
To: Warner Losh <imp@village.org>
Cc: Dan Moschuk <dan@FreeBSD.ORG>,
Kris Kennaway <kris@hub.freebsd.org>, 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> <Pine.BSF.4.21.9911280042420.89688-100000@hub.freebsd.org> <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 <dan@FreeBSD.ORG>
Subject: Re: Last random PID patch before commit
Cc: Kris Kennaway <kris@hub.freebsd.org>, 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> <Pine.BSF.4.21.9911280042420.89688-100000@hub.freebsd.org> <19991128130432.C33028@november.jaded.net> <199911281911.MAA85867@harmony.village.org>
Date: Sun, 28 Nov 1999 12:33:23 -0700
From: Warner Losh <imp@village.org>
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 <kris@hub.freebsd.org>
To: Dan Moschuk <dan@FreeBSD.ORG>
Cc: Warner Losh <imp@village.org>, freebsd-audit@FreeBSD.ORG
Subject: Re: Last random PID patch before commit
In-Reply-To: <19991128142407.B33514@november.jaded.net>
Message-ID: <Pine.BSF.4.21.9911281126580.80171-100000@hub.freebsd.org>
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 <kris@hub.freebsd.org>
To: Warner Losh <imp@village.org>
Cc: Dan Moschuk <dan@FreeBSD.ORG>, freebsd-audit@FreeBSD.ORG
Subject: Re: Last random PID patch before commit
In-Reply-To: <199911281933.MAA86069@harmony.village.org>
Message-ID: <Pine.BSF.4.21.9911281137050.80171-100000@hub.freebsd.org>
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 <kris@hub.freebsd.org>
To: Bruce Evans <bde@zeta.org.au>
Cc: Mike Smith <msmith@FreeBSD.org>, audit@freebsd.org,
Warner Losh <imp@village.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: <Pine.BSF.4.10.9911291736390.11459-100000@alphplex.bde.org>
Message-ID: <Pine.BSF.4.21.9911282330220.21883-100000@hub.freebsd.org>
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 <sheldonh@uunet.co.za>
To: Dan Moschuk <dan@FreeBSD.ORG>
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 <kris@hub.freebsd.org>
To: Sheldon Hearn <sheldonh@uunet.co.za>
Cc: Dan Moschuk <dan@FreeBSD.ORG>, freebsd-audit@FreeBSD.ORG
Subject: Re: New Random PID patch using arc4 available
In-Reply-To: <21954.943862700@axl.noc.iafrica.com>
Message-ID: <Pine.BSF.4.21.9911290115240.32858-100000@hub.freebsd.org>
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.<pid>, 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 <bde@zeta.org.au>
X-Sender: bde@alphplex.bde.org
To: Kris Kennaway <kris@hub.freebsd.org>
Cc: Mike Smith <msmith@FreeBSD.org>, audit@FreeBSD.org,
Warner Losh <imp@village.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: <Pine.BSF.4.21.9911282330220.21883-100000@hub.freebsd.org>
Message-ID: <Pine.BSF.4.10.9911292245180.12106-100000@alphplex.bde.org>
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 <dan@FreeBSD.ORG>
To: Kris Kennaway <kris@hub.freebsd.org>
Cc: Bruce Evans <bde@zeta.org.au>, Mike Smith <msmith@FreeBSD.ORG>,
audit@FreeBSD.ORG, Warner Losh <imp@village.org>
Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern kern_fork.c src/sys/libkern arc4random.c src/sys/sys libkern.h
Message-ID: <19991129105703.C277@spirit.jaded.net>
References: <Pine.BSF.4.10.9911291736390.11459-100000@alphplex.bde.org> <Pine.BSF.4.21.9911282330220.21883-100000@hub.freebsd.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <Pine.BSF.4.21.9911282330220.21883-100000@hub.freebsd.org>; 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 <kris@hub.freebsd.org>
To: Dan Moschuk <dan@FreeBSD.ORG>
Cc: Bruce Evans <bde@zeta.org.au>, Mike Smith <msmith@FreeBSD.ORG>,
audit@FreeBSD.ORG, Warner Losh <imp@village.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: <19991129105703.C277@spirit.jaded.net>
Message-ID: <Pine.BSF.4.21.9911291103500.51314-100000@hub.freebsd.org>
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 <kris@hub.freebsd.org>
To: Bruce Evans <bde@zeta.org.au>
Cc: Mike Smith <msmith@FreeBSD.org>, audit@FreeBSD.org,
Warner Losh <imp@village.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: <Pine.BSF.4.10.9911292245180.12106-100000@alphplex.bde.org>
Message-ID: <Pine.BSF.4.21.9911291125140.51314-100000@hub.freebsd.org>
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: <v0420551bb4688f87fb80@[195.238.21.204]>
In-Reply-To: <Pine.BSF.4.21.9911291103500.51314-100000@hub.freebsd.org>
References: <Pine.BSF.4.21.9911291103500.51314-100000@hub.freebsd.org>
Date: Mon, 29 Nov 1999 21:20:13 +0100
To: Kris Kennaway <kris@hub.freebsd.org>,
Dan Moschuk <dan@FreeBSD.ORG>
From: Brad Knowles <blk@skynet.be>
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 <bde@zeta.org.au>, Mike Smith <msmith@FreeBSD.ORG>,
audit@FreeBSD.ORG, Warner Losh <imp@village.org>
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, <blk@skynet.be> 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 <dan@FreeBSD.ORG>
To: Kris Kennaway <kris@hub.freebsd.org>
Cc: Dan Moschuk <dan@FreeBSD.ORG>, Bruce Evans <bde@zeta.org.au>,
Mike Smith <msmith@FreeBSD.ORG>, audit@FreeBSD.ORG,
Warner Losh <imp@village.org>
Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern kern_fork.c src/sys/libkern arc4random.c src/sys/sys libkern.h
Message-ID: <19991129153250.A2999@spirit.jaded.net>
References: <19991129105703.C277@spirit.jaded.net> <Pine.BSF.4.21.9911291103500.51314-100000@hub.freebsd.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <Pine.BSF.4.21.9911291103500.51314-100000@hub.freebsd.org>; 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 <dan@FreeBSD.ORG>
To: Brad Knowles <blk@skynet.be>
Cc: Kris Kennaway <kris@hub.freebsd.org>,
Dan Moschuk <dan@FreeBSD.ORG>, Bruce Evans <bde@zeta.org.au>,
Mike Smith <msmith@FreeBSD.ORG>, audit@FreeBSD.ORG,
Warner Losh <imp@village.org>
Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern kern_fork.c src/sys/libkern arc4random.c src/sys/sys libkern.h
Message-ID: <19991129153639.B2999@spirit.jaded.net>
References: <Pine.BSF.4.21.9911291103500.51314-100000@hub.freebsd.org> <v0420551bb4688f87fb80@[195.238.21.204]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <v0420551bb4688f87fb80@[195.238.21.204]>; 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 <kris@hub.freebsd.org>
To: Dan Moschuk <dan@FreeBSD.ORG>
Cc: Bruce Evans <bde@zeta.org.au>, Mike Smith <msmith@FreeBSD.ORG>,
audit@FreeBSD.ORG, Warner Losh <imp@village.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: <19991129153250.A2999@spirit.jaded.net>
Message-ID: <Pine.BSF.4.21.9911291304160.51314-100000@hub.freebsd.org>
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 <kris@hub.freebsd.org>
To: Matthew Dillon <dillon@apollo.backplane.com>
Cc: Dan Moschuk <dan@FreeBSD.org>, arch@freebsd.org,
audit@freebsd.org
Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern kern_fork.c
src/sys/libkern arc4random.c src/sys/sys libkern.h
In-Reply-To: <199911292104.NAA09106@apollo.backplane.com>
Message-ID: <Pine.BSF.4.21.9911291319580.51314-100000@hub.freebsd.org>
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 <kris@hub.freebsd.org>
To: Brad Knowles <blk@skynet.be>
Cc: Dan Moschuk <dan@FreeBSD.ORG>, Bruce Evans <bde@zeta.org.au>,
Mike Smith <msmith@FreeBSD.ORG>, audit@FreeBSD.ORG,
Warner Losh <imp@village.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: <v0420551bb4688f87fb80@[195.238.21.204]>
Message-ID: <Pine.BSF.4.21.9911291427180.19254-100000@hub.freebsd.org>
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 <audit@FreeBSD.ORG>; 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 <jeremyp@gsmx07.alcatel.com.au>
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: <v0420551bb4688f87fb80@[195.238.21.204]>
To: Brad Knowles <blk@skynet.be>
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: <Pine.BSF.4.21.9911291103500.51314-100000@hub.freebsd.org>
<v0420551bb4688f87fb80@[195.238.21.204]>
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 <kris@hub.freebsd.org>
To: Matthew Dillon <dillon@apollo.backplane.com>
Cc: Dan Moschuk <dan@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: <199911292239.OAA11977@apollo.backplane.com>
Message-ID: <Pine.BSF.4.21.9911291550311.19254-100000@hub.freebsd.org>
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<pid>). 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<pid> 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 <Doug@gorean.org>
X-Sender: doug@24-25-220-29.san.rr.com
To: Kris Kennaway <kris@hub.freebsd.org>
Cc: Matthew Dillon <dillon@apollo.backplane.com>,
Dan Moschuk <dan@FreeBSD.ORG>, arch@FreeBSD.ORG, audit@FreeBSD.ORG
Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern kern_fork.c
src/sys/libkern arc4random.c src/sys/sys libkern.h
In-Reply-To: <Pine.BSF.4.21.9911291319580.51314-100000@hub.freebsd.org>
Message-ID: <Pine.BSF.4.21.9911291737310.32747-100000@24-25-220-29.san.rr.com>
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 <kris@hub.freebsd.org>
To: Doug Barton <Doug@gorean.org>
Cc: Matthew Dillon <dillon@apollo.backplane.com>,
Dan Moschuk <dan@FreeBSD.ORG>, arch@FreeBSD.ORG, audit@FreeBSD.ORG
Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern kern_fork.c
src/sys/libkern arc4random.c src/sys/sys libkern.h
In-Reply-To: <Pine.BSF.4.21.9911291737310.32747-100000@24-25-220-29.san.rr.com>
Message-ID: <Pine.BSF.4.21.9911291751510.65191-100000@hub.freebsd.org>
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 <kris@hub.freebsd.org>
Cc: Matthew Dillon <dillon@apollo.backplane.com>,
Dan Moschuk <dan@FreeBSD.ORG>, arch@FreeBSD.ORG, audit@FreeBSD.ORG
Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern kern_fork.c src/sys/libkern arc4random.c src/sys/sys libkern.h
In-reply-to: Your message of "Mon, 29 Nov 1999 13:27:42 PST."
<Pine.BSF.4.21.9911291319580.51314-100000@hub.freebsd.org>
Date: Mon, 29 Nov 1999 17:59:10 -0800
Message-ID: <88174.943927150@zippy.cdrom.com>
From: "Jordan K. Hubbard" <jkh@zippy.cdrom.com>
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 <dillon@apollo.backplane.com>
Message-Id: <199911300205.SAA13833@apollo.backplane.com>
To: Kris Kennaway <kris@hub.freebsd.org>
Cc: Doug Barton <Doug@gorean.org>, Dan Moschuk <dan@FreeBSD.ORG>,
arch@FreeBSD.ORG, audit@FreeBSD.ORG
Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern kern_fork.c
src/sys/libkern arc4random.c src/sys/sys libkern.h
References: <Pine.BSF.4.21.9911291751510.65191-100000@hub.freebsd.org>
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 <kris@hub.freebsd.org>
To: "Jordan K. Hubbard" <jkh@zippy.cdrom.com>
Cc: Matthew Dillon <dillon@apollo.backplane.com>,
Dan Moschuk <dan@FreeBSD.ORG>, arch@FreeBSD.ORG, audit@FreeBSD.ORG
Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern kern_fork.c
src/sys/libkern arc4random.c src/sys/sys libkern.h
In-Reply-To: <88174.943927150@zippy.cdrom.com>
Message-ID: <Pine.BSF.4.21.9911291950390.65191-100000@hub.freebsd.org>
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 <kris@hub.freebsd.org>
To: Matthew Dillon <dillon@apollo.backplane.com>
Cc: Doug Barton <Doug@gorean.org>, Dan Moschuk <dan@FreeBSD.ORG>,
arch@FreeBSD.ORG, audit@FreeBSD.ORG
Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern kern_fork.c
src/sys/libkern arc4random.c src/sys/sys libkern.h
In-Reply-To: <199911300205.SAA13833@apollo.backplane.com>
Message-ID: <Pine.BSF.4.21.9911291953130.65191-100000@hub.freebsd.org>
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 <robert@cyrus.watson.org>
X-Sender: robert@fledge.watson.org
Reply-To: Robert Watson <robert+freebsd@cyrus.watson.org>
To: scanner@jurai.net
Cc: Doug Rabson <dfr@nlsystems.com>,
"David O'Brien" <obrien@FreeBSD.ORG>, Mark Murray <mark@grondar.za>,
Kris Kennaway <kris@hub.freebsd.org>, freebsd-audit@FreeBSD.ORG
Subject: Re: FreeBSD security auditing project.
In-Reply-To: <Pine.BSF.4.20.9911240408270.28165-100000@sasami.jurai.net>
Message-ID: <Pine.BSF.3.96.991130011005.3225A-100000@fledge.watson.org>
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 <robert@cyrus.watson.org>
X-Sender: robert@fledge.watson.org
Reply-To: Robert Watson <robert+freebsd@cyrus.watson.org>
To: freebsd-audit@freebsd.org, freebsd-security@freebsd.org
Subject: Topics for -security vs. topics for -audit
Message-ID: <Pine.BSF.3.96.991130014731.3225B-100000@fledge.watson.org>
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 <kris@hub.freebsd.org>
Cc: Matthew Dillon <dillon@apollo.backplane.com>,
Dan Moschuk <dan@FreeBSD.ORG>, arch@FreeBSD.ORG, audit@FreeBSD.ORG
Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern kern_fork.c src/sys/libkern arc4random.c src/sys/sys libkern.h
In-reply-to: Your message of "Mon, 29 Nov 1999 19:53:09 PST."
<Pine.BSF.4.21.9911291950390.65191-100000@hub.freebsd.org>
Date: Mon, 29 Nov 1999 23:01:53 -0800
Message-ID: <89015.943945313@zippy.cdrom.com>
From: "Jordan K. Hubbard" <jkh@zippy.cdrom.com>
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: <v04205503b469524d12f0@[195.238.21.204]>
In-Reply-To: <19991129153639.B2999@spirit.jaded.net>
References: <Pine.BSF.4.21.9911291103500.51314-100000@hub.freebsd.org>
<v0420551bb4688f87fb80@[195.238.21.204]>
<19991129153639.B2999@spirit.jaded.net>
Date: Tue, 30 Nov 1999 11:13:30 +0100
To: Dan Moschuk <dan@FreeBSD.ORG>
From: Brad Knowles <blk@skynet.be>
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 <kris@hub.freebsd.org>,
Dan Moschuk <dan@FreeBSD.ORG>, Bruce Evans <bde@zeta.org.au>,
Mike Smith <msmith@FreeBSD.ORG>, audit@FreeBSD.ORG,
Warner Losh <imp@village.org>
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, <blk@skynet.be> 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: <v04205504b46953e472c1@[195.238.21.204]>
In-Reply-To: <Pine.BSF.4.21.9911291427180.19254-100000@hub.freebsd.org>
References: <Pine.BSF.4.21.9911291427180.19254-100000@hub.freebsd.org>
Date: Tue, 30 Nov 1999 11:16:29 +0100
To: Kris Kennaway <kris@hub.freebsd.org>
From: Brad Knowles <blk@skynet.be>
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 <dan@FreeBSD.ORG>, Bruce Evans <bde@zeta.org.au>,
Mike Smith <msmith@FreeBSD.ORG>, audit@FreeBSD.ORG,
Warner Losh <imp@village.org>
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, <blk@skynet.be> 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: <v04205502b46950a9b055@[195.238.21.204]>
In-Reply-To: <19991129153250.A2999@spirit.jaded.net>
References: <19991129105703.C277@spirit.jaded.net>
<Pine.BSF.4.21.9911291103500.51314-100000@hub.freebsd.org>
<19991129153250.A2999@spirit.jaded.net>
Date: Tue, 30 Nov 1999 11:05:04 +0100
To: Dan Moschuk <dan@FreeBSD.ORG>,
Kris Kennaway <kris@hub.freebsd.org>
From: Brad Knowles <blk@skynet.be>
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 <dan@FreeBSD.ORG>, Bruce Evans <bde@zeta.org.au>,
Mike Smith <msmith@FreeBSD.ORG>, audit@FreeBSD.ORG,
Warner Losh <imp@village.org>
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, <blk@skynet.be> 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 <billf@chc-chimes.com>
To: "Jordan K. Hubbard" <jkh@zippy.cdrom.com>
Cc: Kris Kennaway <kris@hub.freebsd.org>,
Matthew Dillon <dillon@apollo.backplane.com>,
Dan Moschuk <dan@FreeBSD.ORG>, arch@FreeBSD.ORG, audit@FreeBSD.ORG
Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern kern_fork.c
src/sys/libkern arc4random.c src/sys/sys libkern.h
In-Reply-To: <89015.943945313@zippy.cdrom.com>
Message-ID: <Pine.BSF.4.10.9911300944240.59489-100000@jade.chc-chimes.com>
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 <dan@FreeBSD.ORG>
To: Brad Knowles <blk@skynet.be>
Cc: Kris Kennaway <kris@hub.freebsd.org>,
Dan Moschuk <dan@FreeBSD.ORG>, Bruce Evans <bde@zeta.org.au>,
Mike Smith <msmith@FreeBSD.ORG>, audit@FreeBSD.ORG,
Warner Losh <imp@village.org>
Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern kern_fork.c src/sys/libkern arc4random.c src/sys/sys libkern.h
Message-ID: <19991130105241.A279@spirit.jaded.net>
References: <Pine.BSF.4.21.9911291427180.19254-100000@hub.freebsd.org> <v04205504b46953e472c1@[195.238.21.204]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <v04205504b46953e472c1@[195.238.21.204]>; 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: <v04205508b469a5aaabae@[195.238.21.204]>
In-Reply-To: <19991130105241.A279@spirit.jaded.net>
References: <Pine.BSF.4.21.9911291427180.19254-100000@hub.freebsd.org>
<v04205504b46953e472c1@[195.238.21.204]>
<19991130105241.A279@spirit.jaded.net>
Date: Tue, 30 Nov 1999 17:05:59 +0100
To: Dan Moschuk <dan@FreeBSD.ORG>
From: Brad Knowles <blk@skynet.be>
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 <kris@hub.freebsd.org>,
Dan Moschuk <dan@FreeBSD.ORG>, Bruce Evans <bde@zeta.org.au>,
Mike Smith <msmith@FreeBSD.ORG>, audit@FreeBSD.ORG,
Warner Losh <imp@village.org>
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, <blk@skynet.be> 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 <dillon@apollo.backplane.com>
Message-Id: <199911301720.JAA25777@apollo.backplane.com>
To: Bill Fumerola <billf@chc-chimes.com>
Cc: "Jordan K. Hubbard" <jkh@zippy.cdrom.com>,
Kris Kennaway <kris@hub.freebsd.org>, Dan Moschuk <dan@FreeBSD.ORG>,
arch@FreeBSD.ORG, audit@FreeBSD.ORG
Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern kern_fork.c
src/sys/libkern arc4random.c src/sys/sys libkern.h
References: <Pine.BSF.4.10.9911300944240.59489-100000@jade.chc-chimes.com>
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
<dillon@backplane.com>
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 <billf@chc-chimes.com>
Cc: Kris Kennaway <kris@hub.freebsd.org>,
Matthew Dillon <dillon@apollo.backplane.com>,
Dan Moschuk <dan@FreeBSD.ORG>, arch@FreeBSD.ORG, audit@FreeBSD.ORG
Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern kern_fork.c src/sys/libkern arc4random.c src/sys/sys libkern.h
In-reply-to: Your message of "Tue, 30 Nov 1999 09:45:14 EST."
<Pine.BSF.4.10.9911300944240.59489-100000@jade.chc-chimes.com>
Date: Tue, 30 Nov 1999 11:13:42 -0800
Message-ID: <91218.943989222@zippy.cdrom.com>
From: "Jordan K. Hubbard" <jkh@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
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 <freebsd-audit@FreeBSD.ORG>; 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 <freebsd-audit@FreeBSD.ORG>; 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 <mark@grondar.za>
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 <auditor> 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 <auditor>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 <billf@chc-chimes.com>
To: "Jordan K. Hubbard" <jkh@zippy.cdrom.com>
Cc: Kris Kennaway <kris@hub.freebsd.org>,
Matthew Dillon <dillon@apollo.backplane.com>,
Dan Moschuk <dan@FreeBSD.ORG>, arch@FreeBSD.ORG, audit@FreeBSD.ORG
Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern kern_fork.c
src/sys/libkern arc4random.c src/sys/sys libkern.h
In-Reply-To: <91218.943989222@zippy.cdrom.com>
Message-ID: <Pine.BSF.4.10.9911301351090.59489-100000@jade.chc-chimes.com>
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 <tlambert@primenet.com>
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: <Pine.BSF.4.10.9911301351090.59489-100000@jade.chc-chimes.com> 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 <jeremyp@gsmx07.alcatel.com.au>
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: <Pine.BSF.4.21.9911291950390.65191-100000@hub.freebsd.org>
<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 <freebsd-audit@freebsd.org>; 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 <freebsd-audit@freebsd.org>; 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 <tstromberg@rtci.com>
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 <sigh>.
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 <freebsd-audit@FreeBSD.ORG>; 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 <imp@village.org>
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 <kris@hub.freebsd.org>
To: Thomas Stromberg <tstromberg@rtci.com>
Cc: freebsd-audit@freebsd.org
Subject: Re: Where to start? Heres a few overflows.
In-Reply-To: <38445A6A.50245AF5@rtci.com>
Message-ID: <Pine.BSF.4.21.9911301809080.31430-100000@hub.freebsd.org>
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 <dillon@apollo.backplane.com>
Message-Id: <199912010218.SAA28858@apollo.backplane.com>
To: "Jordan K. Hubbard" <jkh@zippy.cdrom.com>
Cc: Bill Fumerola <billf@chc-chimes.com>,
Kris Kennaway <kris@hub.freebsd.org>, Dan Moschuk <dan@FreeBSD.ORG>,
arch@FreeBSD.ORG, audit@FreeBSD.ORG
Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern kern_fork.c src/sys/libkern arc4random.c src/sys/sys libkern.h
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 <kris@hub.freebsd.org>
To: "Jordan K. Hubbard" <jkh@zippy.cdrom.com>
Cc: Matthew Dillon <dillon@apollo.backplane.com>, 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: <Pine.BSF.4.21.9911301939290.44002-100000@hub.freebsd.org>
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: <v04210100b46a5eebcf42@[128.113.24.47]>
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" <jkh@zippy.cdrom.com>,
Bill Fumerola <billf@chc-chimes.com>
From: Garance A Drosihn <drosih@rpi.edu>
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 <kris@hub.freebsd.org>,
Matthew Dillon <dillon@apollo.backplane.com>,
Dan Moschuk <dan@FreeBSD.ORG>, 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 <x> 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 <freebsd-audit@FreeBSD.ORG>; 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 <kbyanc@posi.net>
X-Sender: kbyanc@kronos.alcnet.com
To: Mark Murray <mark@grondar.za>
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: <Pine.BSF.4.05.9912010012110.12753-100000@kronos.alcnet.com>
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 <auditor> 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 <auditor>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 <freebsd-audit@FreeBSD.ORG>; 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 <mark@grondar.za>
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 <sigh>.
>
> 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 <freebsd-audit@FreeBSD.ORG>; 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 <kbyanc@posi.net>
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 <mark@grondar.za>
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 <freebsd-audit@freebsd.org>; 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 <auditor> 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 <freebsd-audit@FreeBSD.ORG>; 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 <rbezuide@oskar.dev.nanoteq.co.za>
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 <freebsd-audit@FreeBSD.ORG>; 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 <mark@grondar.za>
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 <freebsd-audit@freebsd.org>; 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 <tstromberg@rtci.com>
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 <imp@village.org>, 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 <freebsd-audit@freebsd.org>; 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 <tstromberg@rtci.com>
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 <mark@grondar.za>, 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 <or at least, the overflows tougher
to find.. depends on your outlook>. 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 <freebsd-audit@freebsd.org>; 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 <mark@grondar.za>
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 <freebsd-audit@FreeBSD.ORG>; 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: <v0420550fb46aed7db5f4@[195.238.21.204]>
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 <mark@grondar.za>, freebsd-audit@FreeBSD.ORG
From: Brad Knowles <blk@skynet.be>
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, <blk@skynet.be> 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 <freebsd-audit@freebsd.org>; 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 <imp@village.org>
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 <freebsd-audit@FreeBSD.ORG>; 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: <v04205513b46afa98c429@[195.238.21.204]>
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 <imp@village.org>, tstromberg@rtci.com
From: Brad Knowles <blk@skynet.be>
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, <blk@skynet.be> 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 <freebsd-audit@FreeBSD.ORG>; 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 <blk@skynet.be>
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."
<v04205513b46afa98c429@[195.238.21.204]>
References: <v04205513b46afa98c429@[195.238.21.204]> <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 <imp@village.org>
Sender: owner-freebsd-audit@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
In message <v04205513b46afa98c429@[195.238.21.204]> 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 <freebsd-audit@FreeBSD.ORG>; 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" <jedgar@fxp.org>
X-Sender: jedgar@earth.fxp
To: Mark Murray <mark@grondar.za>
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: <Pine.BSF.4.21.9912011406250.45254-100000@earth.fxp>
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
<jedgar@fxp.org> | 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 <freebsd-audit@FreeBSD.ORG>; 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 <jeremyp@gsmx07.alcatel.com.au>
Subject: Re: Where to start? Heres a few overflows. (smashwidgets)
In-reply-to: <38452E6B.C820BD4A@rtci.com>
To: Thomas Stromberg <tstromberg@rtci.com>
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 <freebsd-audit@FreeBSD.ORG>; 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 <blk@skynet.be>
Cc: Warner Losh <imp@village.org>, 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 <mark@grondar.za>
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 <audit@freebsd.org>; 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 <kris@hub.freebsd.org>
To: audit@freebsd.org
Subject: Auditing ports
Message-ID: <Pine.BSF.4.21.9912011449180.87299-100000@hub.freebsd.org>
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: <v04205507b46b5d29b40a@[195.238.21.204]>
In-Reply-To: <Pine.BSF.4.21.9912011449180.87299-100000@hub.freebsd.org>
References: <Pine.BSF.4.21.9912011449180.87299-100000@hub.freebsd.org>
Date: Thu, 2 Dec 1999 00:19:19 +0100
To: Kris Kennaway <kris@hub.freebsd.org>, audit@FreeBSD.ORG
From: Brad Knowles <blk@skynet.be>
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, <blk@skynet.be> 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 <kris@hub.freebsd.org>
To: Brad Knowles <blk@skynet.be>
Cc: audit@FreeBSD.ORG, asami@freebsd.org, ports@freebsd.org
Subject: Re: Auditing ports
In-Reply-To: <v04205507b46b5d29b40a@[195.238.21.204]>
Message-ID: <Pine.BSF.4.21.9912011631060.10470-100000@hub.freebsd.org>
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 <freebsd-audit@FreeBSD.ORG>; 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 <cnielsen@pobox.com>
X-Sender: cnielsen@ender.scient.com
To: Mark Murray <mark@grondar.za>
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: <Pine.BSF.4.10.9912011749040.1443-100000@ender.scient.com>
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 <kris@hub.freebsd.org>, satoshi@freebsd.org
Cc: audit@freebsd.org
Subject: Re: Auditing ports
Date: Thu, 02 Dec 1999 07:59:55 +0200
From: Mark Murray <mark@grondar.za>
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 <freebsd-audit@FreeBSD.ORG>; 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 <abial@webgiro.com>
To: peter.jeremy@alcatel.com.au
Cc: Thomas Stromberg <tstromberg@rtci.com>, 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: <Pine.BSF.4.20.9912021113150.15679-100000@mx.webgiro.com>
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
// <abial@webgiro.com> 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 <robert@cyrus.watson.org>
X-Sender: robert@fledge.watson.org
Reply-To: Robert Watson <robert+freebsd@cyrus.watson.org>
To: Mark Murray <mark@grondar.za>
Cc: Kris Kennaway <kris@hub.freebsd.org>, satoshi@freebsd.org,
audit@freebsd.org
Subject: Re: Auditing ports
In-Reply-To: <199912020559.HAA24545@gratis.grondar.za>
Message-ID: <Pine.BSF.3.96.991202101402.12358A-100000@fledge.watson.org>
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 <gerald@manhattanprojects.com>
X-Mailer: Mozilla 4.05 [en] (X11; I; FreeBSD 2.2.5-RELEASE i386)
MIME-Version: 1.0
To: Kris Kennaway <kris@hub.freebsd.org>
Cc: audit@FreeBSD.ORG
Subject: Re: Auditing ports
References: <Pine.BSF.4.21.9912011631060.10470-100000@hub.freebsd.org>
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: <v04205506b46c438506dd@[195.238.21.204]>
In-Reply-To: <384691C6.347BE836@manhattanprojects.com>
References: <Pine.BSF.4.21.9912011631060.10470-100000@hub.freebsd.org>
<384691C6.347BE836@manhattanprojects.com>
Date: Thu, 2 Dec 1999 16:44:02 +0100
To: Gerald Abshez <gerald@manhattanprojects.com>,
Kris Kennaway <kris@hub.freebsd.org>
From: Brad Knowles <blk@skynet.be>
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, <blk@skynet.be> 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 <freebsd-audit@freebsd.org>; 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 <freebsd-audit@freebsd.org>; 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) <http://www.ice.com/icemail/>
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 <kris@hub.freebsd.org>
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: <Pine.BSF.4.21.9912031357070.57168-100000@hub.freebsd.org>
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 <kris@hub.freebsd.org>, tstromberg@rtci.com
Subject: Re: More binaries with overflows. (7)
Cc: freebsd-audit@freebsd.org
In-Reply-To: <Pine.BSF.4.21.9912031357070.57168-100000@hub.freebsd.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: ICEMail (rel 2.8.2) <http://www.ice.com/icemail/>
Organization: Research Triangle Commerce, Inc.
Sender: owner-freebsd-audit@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
-<reply>-------------------------------
-> 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
-<reply>-------------------------------
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
=======================================================================<eof>
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 <kris@hub.freebsd.org>
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: <Pine.BSF.4.21.9912031922230.4215-100000@hub.freebsd.org>
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" <freebsd@gndrsh.dnsmgr.net>
Message-Id: <199912040532.VAA82253@gndrsh.dnsmgr.net>
Subject: Re: More binaries with overflows. (7)
In-Reply-To: <Pine.BSF.4.21.9912031922230.4215-100000@hub.freebsd.org> 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 <audit@freebsd.org>; 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 <kris@hub.freebsd.org>
To: audit@freebsd.org
Subject: Buffer overflows in libc (yp)
Message-ID: <Pine.BSF.4.21.9912032127370.19005-100000@hub.freebsd.org>
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 <sys/param.h>
@@ -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 <kris@hub.freebsd.org>
To: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net>
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: <Pine.BSF.4.21.9912032136050.21530-100000@hub.freebsd.org>
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 <hart@iserver.com>
X-Sender: hart@anchovy.orem.iserver.com
To: Kris Kennaway <kris@hub.freebsd.org>
Cc: audit@FreeBSD.ORG
Subject: Re: Buffer overflows in libc (yp)
In-Reply-To: <Pine.BSF.4.21.9912032127370.19005-100000@hub.freebsd.org>
Message-ID: <Pine.BSF.4.21.9912032247210.58329-100000@anchovy.orem.iserver.com>
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 <audit@freebsd.org>; 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 <kris@hub.freebsd.org>
To: audit@freebsd.org
Subject: Re: Buffer overflows in libc (yp)
In-Reply-To: <Pine.BSF.4.21.9912032127370.19005-100000@hub.freebsd.org>
Message-ID: <Pine.BSF.4.21.9912032154170.23092-100000@hub.freebsd.org>
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 <kris@hub.freebsd.org>
To: Paul Hart <hart@iserver.com>
Cc: audit@FreeBSD.ORG
Subject: Re: Buffer overflows in libc (yp)
In-Reply-To: <Pine.BSF.4.21.9912032247210.58329-100000@anchovy.orem.iserver.com>
Message-ID: <Pine.BSF.4.21.9912032155500.23335-100000@hub.freebsd.org>
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 <audit@freebsd.org>; 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 <kris@hub.freebsd.org>
To: audit@freebsd.org
Subject: ctm_rmail holes (fwd)
Message-ID: <Pine.BSF.4.21.9912041930430.3023-100000@hub.freebsd.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <Pine.BSF.4.21.9912041930432.3023@hub.freebsd.org>
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 <kris@hub.freebsd.org>
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 <stdio.h>
#include <stdlib.h>
#include <strings.h>
@@ -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 <audit@freebsd.org>; 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 <kris@hub.freebsd.org>
To: audit@freebsd.org
Subject: arp.c patch
Message-ID: <Pine.BSF.4.21.9912042308350.34489-100000@hub.freebsd.org>
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 <audit@freebsd.org>; 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 <kris@hub.freebsd.org>
To: audit@freebsd.org
Subject: Closed list policy?
Message-ID: <Pine.BSF.4.21.9912042309240.34489-100000@hub.freebsd.org>
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 <kris@hub.freebsd.org>
Cc: audit@FreeBSD.ORG
Subject: Re: ctm_rmail holes (fwd)
Date: Sun, 05 Dec 1999 09:42:54 +0200
From: Mark Murray <mark@grondar.za>
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 <kris@hub.freebsd.org>
Cc: audit@FreeBSD.ORG
Subject: Re: Closed list policy?
Date: Sun, 05 Dec 1999 09:50:25 +0200
From: Mark Murray <mark@grondar.za>
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