(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
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
hi,
MM I have been charged with the duty of ensuring that FreeBSD gets a
MM security audit that has the credibility of OpenBSD's.
What's going on with FreeBSD Auditing Project
(http://www.FreeBSD.org/auditors.html) ? Is it still alive ?
I think this task is task of this project members. Or
At 1:41 AM -0500 1999/11/24, Brian Fundakowski Feldman wrote:
Our code doesn't run an a system _anything_ like that.
That may well be true today, however as FreeBSD gets more widely
ported to other platforms, and as the "native" platforms it runs on
progress, this might change in the
"Rodney W. Grimes" [EMAIL PROTECTED] writes:
It's not so much that they where ``allowed'' to do it, it is more the
matter that they where never directly served with legal papers from USL/Novell
to cease all use of Net/2. Nor did they ever enter into any agreement,
that I am aware
On Tue, 23 Nov 1999 23:33:14 -0500 (EST), Brian Fundakowski Feldman
[EMAIL PROTECTED] said:
#define SNPARGS(buf, len) buf + len, sizeof(buf) len ? sizeof(buf) - len : 0
char action2[32], proto[47], name[18], fragment[17];
/* Print command name */
In message [EMAIL PROTECTED] Alexey Zelkin writes:
: What's going on with FreeBSD Auditing Project
: (http://www.FreeBSD.org/auditors.html) ? Is it still alive ?
: I think this task is task of this project members. Or will be ;-)
Went gangbusters for a short while. Everybody was jazzed. Parts
Hello FreebSD'ers!
[ Apologies to committers, I have Bcc'ed you to ensure you got
this; you may get two copies. ]
I have been charged with the duty of ensuring that FreeBSD gets a
security audit that has the credibility of OpenBSD's.
Consider this to be a request-for-discussion that will
On Tue, 23 Nov 1999, Mark Murray wrote:
Hello FreebSD'ers!
2) I propose that WE diff(1) FreeBSD with {Open|Net}BSD, and with a
security perspective apply those bits that look relevant and that will
work. Who nose - we may even pick up some useful featurez!
While we're on the subject of
On Tue, 23 Nov 1999, Mark Murray wrote:
1) We need to eyeball _all_ of the code for potential security holes,
and fix those ASAP.
2) I propose that WE diff(1) FreeBSD with {Open|Net}BSD, and with a
security perspective apply those bits that look relevant and that will
work. Who nose - we
On Tue, 23 Nov 1999, Mark Murray wrote:
I have some 500+ commit messages in my openbsd folder which are things I
need to investigate further for relevancy. Some way of sharing these with
the group, adding/removing/vetting changes which should be looked at would
be very useful.
I'd be
On Tue, 23 Nov 1999, Kelly Yancey wrote:
Need volunteers, eh? I can be suckered in to helping in regards to
building the web-based database for keeping track of the effor's progress.
I may be no security expert, but I can build database-driven web sites (I
should...it's my day job ;) ).
On 1999-Nov-24 06:35:16 +1100, Kris Kennaway wrote:
o unsafe use of the str*(3) functions; strcat/strcpy/sprintf c.
I wonder how many instances of the potentially unsafe functions there are
in the source tree? :)
A 'grep | wc' equivalent over the source tree gives:
gets110
strcat
Also useful would be a review status of the freebsd tree. So (approved)
people can "sign off" on a particular file or directory as having been
reviewed as of a certain date, and we can work in a coordinated fashion.
Well, IMHO what you guys most significantly need is a "tinderbox"
style page
On Tue, Nov 23, 1999 at 03:23:23PM -0500, Kelly Yancey wrote:
I may be no security expert,
So??? You can read C code, right? What needs to happen is a leader to
take charge and give people direction. If someone gave you a few
sequences of code to look for, you could find them right? If you
Kris Kennaway wrote:
Let me throw in some ideas..
I think it would be very useful to have a database which can track
submitted open/netbsd CVS commits (with the code diff included),
preferably mapped to the relevant file in the freebsd tree if possible
according to a path mapping table
So when Joe Blow clicks on (say) src-bin-cat he'll find that
(say) markm eyballed the code and kris diffed it with OpenBSD
and merged in blah fixes - "cat now considered safe".
Until the next commit to cat.
A security review is never done. We need to be in a mode where every
commit is
On Tue, 23 Nov 1999, David O'Brien wrote:
A security review is never done. We need to be in a mode where every
commit is suspect and people are compelled to review it. BDE's use of
CTM to review changes is actually rather affective in this reguard.
A CVS tag would also accomplish this and
2) I propose that WE diff(1) FreeBSD with {Open|Net}BSD,
This is not the easiest thing to do (I've tried). Rather one should look
at what changes OpenBSD has done to a piece of code since they imported
it from NetBSD and compare with FreeBSD code to see if the OpenBSD change
is applicable to
A 'grep | wc' equivalent over the source tree gives:
gets110
strcat 2860
strcpy 4717
strncat 167
strncpy1514
sprintf6839
vsprintf133
*ouch* :-)
This means nothing out of context. I hope we don't go on a witch hunt.
And these are the easy
At 12:05 PM -0800 1999/11/23, Jordan K. Hubbard wrote:
Part of what will make this go a lot faster is people like yourself
committing to sticking around and helping us find and fix any security
problems we might have, so I certainly hope you can do this!
I'm certainly willing to do
On 1999-Nov-24 09:26:26 +1100, David O'Brien wrote:
A 'grep | wc' equivalent over the source tree gives:
gets110
strcat 2860
strcpy 4717
strncat 167
strncpy1514
sprintf6839
vsprintf133
*ouch* :-)
This means nothing out of context. I hope we
On Tue, 23 Nov 1999, David O'Brien wrote:
On Tue, Nov 23, 1999 at 03:23:23PM -0500, Kelly Yancey wrote:
I may be no security expert,
So??? You can read C code, right? What needs to happen is a leader to
take charge and give people direction. If someone gave you a few
sequences of code
Here is my 0.02:
I think it would be useful to identify "unsafe" functions, so that
anyone can participate in the "eyeball" portion of the game. This means
that we need eyeballed, identified as a (potential) problem and fixed,
as well as some other possiblities. There is a lot of
According to Donn Miller:
While we're on the subject of possibly borrowing code from NetBSD...
NetBSD's wscons looks interesting. Any chance FreeBSD will adopt this, or
will we stay with syscons?
What features does it have compared to syscons ?
--
Ollivier ROBERT -=- FreeBSD: The Power to
On 1999-Nov-24 10:21:17 +1100, [EMAIL PROTECTED] wrote:
a) This is what an unsafe function call looks like
Without checking a lot of the call context, it is very difficult
to categorically state that a particular function call is safe or
not. As an example, consider the following:
foo(const
2) I propose that WE diff(1) FreeBSD with {Open|Net}BSD,
This is not the easiest thing to do (I've tried). Rather one should look
at what changes OpenBSD has done to a piece of code since they imported
it from NetBSD and compare with FreeBSD code to see if the OpenBSD change
is
I'm certainly willing to do what I can to help, although I have
to admit that I may need a bit of help identifying what I can do. ;-)
That's Mark's job - he's the security leader. :)
- Jordan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the
This means nothing out of context. I hope we don't go on a witch hunt.
No, but there is some merit to simply replacing these so that they
don't show up on our radar later. I don't see any reason, for
example, why anyone should still be using gets() and our
implementation even gets whiney
On Tue, 23 Nov 1999, Kris Kennaway wrote:
On Tue, 23 Nov 1999, Kelly Yancey wrote:
Need volunteers, eh? I can be suckered in to helping in regards to
building the web-based database for keeping track of the effor's progress.
I may be no security expert, but I can build database-driven
On 1999-Nov-24 12:02:59 +1100, Jordan K. Hubbard wrote:
I don't see any reason, for
example, why anyone should still be using gets()
To take gets() as an example, of the 110 occurrences that gid found in
-current, the following files contain actual calls to gets() (rather
than declarations,
I don't see any reason, for example, why anyone should still be using
gets() and our implementation even gets whiney about it if you do.
That one is definitely up for a global search and replace as its only use
is to read external data.
--
-- David([EMAIL PROTECTED])
To Unsubscribe:
On Tue, 23 Nov 1999, Kelly Yancey wrote:
I think it would be useful to identify "unsafe" functions, so that
anyone can participate in the "eyeball" portion of the game. This means
that we need eyeballed, identified as a (potential) problem and fixed,
as well as some other possiblities.
On 1999-Nov-24 15:33:14 +1100, Brian Fundakowski Feldman wrote:
I'd like to note something. Strcat isn't necessarily unsafe, and strncat()
isn't necessarily safe.
I wasn't implying that. In fact, I believe the semantics of strncat()
put it into the `hard to use correctly' category (or maybe
On Wed, 24 Nov 1999, Peter Jeremy wrote:
On 1999-Nov-24 15:33:14 +1100, Brian Fundakowski Feldman wrote:
I'd like to note something. Strcat isn't necessarily unsafe, and strncat()
isn't necessarily safe.
I wasn't implying that. In fact, I believe the semantics of strncat()
put it into
Hey guys, can we move this discussion over to security? I don't
think it's -current fodder. :)
Actually, I'd like to start a whole new list - freebsd-audit - if
that is OK with you. I have a conference to attend, but if this is OK
I'll set it up in about 9 hours.
M
--
Mark Murray
Join the
In message [EMAIL PROTECTED] Mark Murray writes:
: o unsafe use of the str*(3) functions; strcat/strcpy/sprintf c.
Keep a keen eye out for unsafe uses of strncpy and strncat and know
the man page by heart before thinking you are correct :-)
: o c. please contribute here
I had a long list
In message [EMAIL PROTECTED] Kris Kennaway
writes:
: semi-joking
: Maybe what we actually want is a better RCS system for FreeBSD.
: /semi-joking
http://www.perforce.com/
:-)
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
In message [EMAIL PROTECTED] Peter Jeremy writes:
: I suspect that a 'cvs diff' of the OpenBSD code tree is the best
: starting point.
As a veteran of that war, I think you underestimate that task be about
a few orders of magnitude. A better starting point I've found to be
the ChangeLog files
In message [EMAIL PROTECTED] Peter Jeremy writes:
: I wasn't implying that. In fact, I believe the semantics of strncat()
: put it into the `hard to use correctly' category (or maybe `very likely
: to be misused').
I'd put strncat in the definitely unsafe category based on the number
of bugs
In message [EMAIL PROTECTED] Brian
Fundakowski Feldman writes:
: Despite the fact that the buffer name[] was made to be exactly the
: largest size, where sprintf() _would_be_safe_, some people insist
: on using snprintf() "for stability". Don't get caught doing this.
: If you find a strcat()
41 matches
Mail list logo
