(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 Tue, 23 Nov 1999, Mark Murray wrote:
> I have been charged with the duty of ensuring that FreeBSD gets a
> security audit that has the credibility of OpenBSD's.
Great news! I had tried to organise such an effort over a year ago with
little success, mostly because I was working for a startup.
In message <[EMAIL PROTECTED]> Dan Moschuk writes:
: I have a set up diff's that introduce OpenBSDs concept of random pids and
: source port (with a sysctl knob for you sequential weenies) that will have
: to be updated again before I commit them.
I'd like to review this before it goes in, but if
Garrett Wollman wrote:
>
> Perhaps if name[] had been declared thus:
>
> #define INTTYPE_NCHARS(t) ((sizeof(t) * 3 * CHAR_BIT + 7) / 8)
>
> char name[(sizeof "ipfw: ") + INTTYPE_NCHARS(int)];
Or alternatively (removing a bit more magic):
#include
#define INTTYPE_NCHARS(t) (how
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. Part
| 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-discus
< 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 */
> snprintf(SNPARGS(name, 0), "ipfw: %d", f ? f->fw_number : -1);
> Despite the fact that the buffer n
>
> "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
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
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
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 mi
On Tue, 23 Nov 1999, David O'Brien wrote:
> > 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 fixes - "cat now considered safe".
>
> Until the next commit to cat.
>
> A security review is never d
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() (
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 t
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]> Kris Kennaway
writes:
: Yep, this is part of the "education" component: "this is what an unsafe
: function call looks like, and this is how to fix it". There's bound to be
: enough useful documentation out there which we can collect and point to.
__warn_references(
In message <[EMAIL PROTECTED]> Kris Kennaway
writes:
:
: Maybe what we actually want is a better RCS system for FreeBSD.
:
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]> 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 lis
> 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 a
Hey guys, can we move this discussion over to security? I don't
think it's -current fodder. :)
- Jordan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
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
On Wed, 24 Nov 1999, Peter Jeremy wrote:
> A 'grep | wc' equivalent over the source tree gives:
>
> gets110
> strcat 2860
> strcpy 4717
> strncat 167
> strncpy1514
> sprintf6839
> vsprintf133
>
...
> A string search for (roughly) "scanf.*%s" also picks up 74 case
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 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 possiblit
> 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 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, c
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-dri
> 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 abou
> 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 b
> > 2) I propose that 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 appli
On Tue, 23 Nov 1999, Gerald Abshez wrote:
> 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 f
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 ch
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
> > 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
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 o
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 not
On Tue, 23 Nov 1999, David O'Brien wrote:
> > *ouch* :-)
>
> This means nothing out of context. I hope we don't go on a witch hunt.
Right, but they still need to be checked.
> Global search and replace of these can obfuscate code. Things must be
> looked for in context.
I hope no-one's sugg
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
> > 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.
> > A
> 2) I propose that 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 us.
On Wed, 24 Nov 1999, Peter Jeremy 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
On Tue, 23 Nov 1999, Gerald Abshez wrote:
> 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
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 an
> 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 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 suspe
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 ta
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
> 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 pag
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
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 ;) ).
> > I'd be delighted to work with you on getting this lot exposed.
>
> Sounds good - just let me know what you want me to do. I should have
> mentioned, BTW, that most of these aren't security-related (but are
> general functionality enhancements/bugfixes/etc), but some fraction are.
You know mo
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.
>
On Tue, 23 Nov 1999, Mark Murray wrote:
> I am prepared to provide a (semi-)automatic tool that folks can
> submit their efforts to. (Yes, this is a group effort, we all need to
> get involved and donate our Copious Free Time. All the time that is
> currently invested in flamewars would be better
> Hello FreebSD'ers!
>
[snip]
>
> 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 head us over to
> the actual work of getting it done.
[snip]
Great idea. Here
> I don't know how long it's going to take you folks to get there,
> but I'm beginning to wonder if maybe I can't hold off switching some
> machines to OpenBSD and to instead do my best to secure them under
> FreeBSD, and avoid the platform split that would otherwise result
> (and have t
At 9:05 PM +0200 1999/11/23, Mark Murray wrote:
> I have been charged with the duty of ensuring that FreeBSD gets a
> security audit that has the credibility of OpenBSD's.
You're just bound-and-determined to get me permanently drooling,
aren't you? ;-)
Seriously, I do not envy
> 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 delighted to work with you on getting this l
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 diff(1) FreeBSD with {Open|Net}BSD, and with a
> security perspective apply those bits that look relevant and that will
> work. Who nose -
On Tue, 23 Nov 1999, Mark Murray wrote:
> Hello FreebSD'ers!
> 2) I propose that 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 po
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 head
59 matches
Mail list logo
