Re: FreeBSD security auditing project.
(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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD security auditing project.
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 -- "I've always been mad, I know I've been mad, like most of us have. And you have to explain why you were mad, even if you're not mad." -PF DsoTM ===| Open Systems FreeBSD Consulting. FreeBSD 3.3 is available now! | Yahoo Messenger ID: opsys_98 ---| 1402 N. Washington, Wellington, KS 67152 FreeBSD: The power to serve!| E-Mail: [EMAIL PROTECTED] http://www.freebsd.org | Consulting, Network Engineering, Security ===| http://open-systems.net To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD security auditing project.
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 will be ;-) MM I'll get a mailing list going if this is deemed necessary. audit-*@FreeBSD.org ? Or create general list [EMAIL PROTECTED] ? -- /* Alexey Zelkin[EMAIL PROTECTED]*/ /* Tavric National University [EMAIL PROTECTED] */ /* http://www.ccssu.crimea.ua/~phantom [EMAIL PROTECTED] */ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD security auditing project.
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 future. I'd suggest erring on the side of paranoia in this case. -- These are my opinions -- not to be taken as official Skynet policy |o| Brad Knowles, [EMAIL PROTECTED]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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD security auditing project.
"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 of, with respect to Net/2 code with any party other than UCB. That's half true. No letter ever received asked us to `cease all use of Net/2'. However, as has been publically stated *numerous* times, there does exist an agreement between NetBSD and USL stating that, after certain Net/2 files were removed and certain others were updated to their 4.4-Lite versions, USL would not bother us again. That agreement is different than the agreement I have before me. These agreements basically say that the parties would stop all use of Net/2 based code and replace it with BSD4.4 Lite, [...] That's false. If the FreeBSD agreement is *anything* like the NetBSD one, it covers only specific files, not the entire source tree. You can't make the claim that this is false, you have not seen the document, and you can't. I will assert my statement is true. I can't say anymore about it than that as the agreement itself says that it's contents are not to be disclosed. The agreement evedently does not look like the one that NetBSD signed. One could make claim that Novell/USL seriously failed to do ``due dilegence'', but they where not protecting a trademark, but instead a copyright and they could, if they still owned the code. come along and slap NetBSD/OpenBSD with a pretty healthy law suite. That's also false. Worse, it's FUD. Agreed, given the other statements. Technically if I where to bring a NetBSD repository over to my box and then let anyone other than myself even look at it I would be in violation of the USL/Novell agreement due to the fact that the repository contains Net/2 code. :-(. And that's false, too. You can't know that, you don't know what my agreement says. Unless I missed it some place the ,v files of the NetBSD repository where not purged of the Net/2 code, unless this was done offline in a non-public manner. That I might not know about. Though the legal agreement between NetBSD and USL/Novell may have only required NetBSD to purge certain files, my agreement is very explicit about ALL of Net/2. Please check your facts before spewing about legal matters. My facts on the legal points of this issue are probably at least an order of magnitude more correct than yours. NetBSD wouldn't have even seen something as simple as what it did get from USL had I not spent a month of my time working with Novel legal to have something palatible we (WC and myself) could agree to. -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD security auditing project.
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 */ snprintf(SNPARGS(name, 0), "ipfw: %d", f ? f-fw_number : -1); Despite the fact that the buffer name[] was made to be exactly the largest size Exactly the largest size of what? All I see here is a magic number. 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)]; ...but even then, if KNF is followed, this declaration might be so far away from the printf format that when the format is modified, the programmer might forget to modify the declaration as well. snprintf is a good thing. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same [EMAIL PROTECTED] | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD security auditing project.
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 of the tree had bugs fixed. Some bug fixes wound up on the floor. Poor central coordination and management of this project was likely a factor. It accomplished some things, but left others undone. It found nothing major that was snuck in while freefall's root had been compromised (which was the impetus behind the project in the first place). Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD security auditing project.
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 possibly borrowing code from NetBSD... NetBSD's
wscons looks interesting. Any chance FreeBSD will adopt this, or will we
stay with syscons?
- Donn
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD security auditing project.
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 may even pick up some useful featurez!
I've been slowly trying to do some of this, and got through at least some
of bin/ so far (billf has also been doing work on this, as have probably
others). Probably this is the easiest way to get progress towards this
goal - since FreeBSD is genetically very similar to OpenBSD, they've
already fixed most of our security bugs (but not all!).
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 spent here, *hint*
*hint*.) The tool will be web-based and will give a good idea of
progress, so we can even turn it into a sort of competition.
Here is a starter list of what we need to audit for:
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? :)
o unsafe buffer handling (probably better handled by str*(3)??)
o tmpfile races.
There is still a predictable tempfile name somewhere in binutils(?) which
gets invoked during a parallel make world (with -pipe?). Sorry I can't
remember more details, it was a while ago I found it. Running make world
-j2 with the tempwatch port active will find the file, though.
o unsafe use of command line or environment variables (?).
o unsafe passing/exposure of sensitive data.
o c. please contribute here
Probably a good resource would be to collect together a bunch of
papers/references describing what kinds of vulerabilities exist, how to
exploit them, and how to avoid them (e.g. old phrack/bugtraq articles,
etc). Programmer education is the key to secure programming! :-)
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.
Kris
Cthulhu for President! For when you're tired of choosing the _lesser_ of
two evils..
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD security auditing project.
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 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. Kris Cthulhu for President! For when you're tired of choosing the _lesser_ of two evils.. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD security auditing project.
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 ;) ). Let me know what I can do to help. Cool, we have a database guy! :) 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 (i.e. /some/openbsd/path/file.c mapped to /equiv/freebsd.path/file.c). I guess this is more of a CVS interface along the lines of cvsweb..what we're really doing here is doing a (manual) partial merge of two CVS repositories. But, CVS is a kind of database, right? :) 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. Hmm, again this sounds like a CVS tree, with reviews being tags. semi-joking Maybe what we actually want is a better RCS system for FreeBSD. /semi-joking I'll get a mailing list going if this is deemed necessary. freebsd-security? :) Hmm, I think most of the traffic would be fairly off-topic for there. I think a separate freebsd-audit list (for discussion of relevancy of changes, discussion of bugs, etc) would be the way to go. Kris Cthulhu for President! For when you're tired of choosing the _lesser_ of two evils.. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD security auditing project.
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 2860 strcpy 4717 strncat 167 strncpy1514 sprintf6839 vsprintf133 Note that (particularly in the case of gets()), this includes the definition(s) in libraries and declarations in various headers as well as occurrences in comments, strings and structure/union members. There are also occurrences in dead or unused code (eg gnu/usr.bin/as/config/tc-vax.c calls gets() 10 times as well as referring to it in a comment). These counts are based on tokens, not strings, so (eg) fgets doesn't get counted as gets. A string search for (roughly) "scanf.*%s" also picks up 74 cases of un-bounded string scans. And these are the easy ones... Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD security auditing project.
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 which shows all the external reviewers just how well things are going and what work remains to be done. It should be a professional-looking page which provides useful content and also has a "developer sign-on" feature which allows others to adopt sections for review and/or check things off as reviewed (at which point the visual appearance of the item changes and a datestamp is done so we know when to come back and audit things all over again). - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD security auditing project.
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 were also given a typical work around, you could apply it, right? Not everyone in the OpenBSD project came into this with a security mindset. Rather it was alot of getting people rallied around the cause and teaching them how to go about it. Before we go off 1/2 cocked, we need to get organized. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD security auditing project.
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 (i.e. /some/openbsd/path/file.c mapped to /equiv/freebsd.path/file.c). 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 code out there, and it would help if we could involve the non-programmers in the search. Comments? Gerald. -- This is your FreeBSD -- Where do YOU want to go tommorow? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD security auditing project.
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 suspect and people are compelled to review it. BDE's use of CTM to review changes is actually rather affective in this reguard. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD security auditing project.
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 could be slid forward when the new commit is reviewed. I don't know how feasible this would be from the POV of CVS mechanics, but it has the advantage of being in the main tree for everyone to see. Kris Cthulhu for President! For when you're tired of choosing the _lesser_ of two evils.. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD security auditing project.
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 us.
{Net,Open}BSD kept a lot of Net/2 [influenced] code (not sure how they
were allowed to do that), while we started fresh with 4.4BSD. Thus diffs
between us and them in userland utils and be quite different.
--
-- David([EMAIL PROTECTED])
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD security auditing project.
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 ones... Indeed :-( Global search and replace of these can obfuscate code. Things must be looked for in context. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD security auditing project.
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 what I can to help, although I have to admit that I may need a bit of help identifying what I can do. ;-) -- These are my opinions -- not to be taken as official Skynet policy |o| Brad Knowles, [EMAIL PROTECTED]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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD security auditing project.
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 don't go on a witch hunt. Agreed. I wasn't suggesting that all these occurrences are examples of unsafe use. They just give an order-of-magnitude indication of the number of places they are used. That said, I'm not sure that going through the code and checking every call to strcpy() (for example) is the right way to go about things. It _is_ possible to use strcpy() safely, at the same time, it is possible to use strlcpy() or snprintf() _unsafely_ (mainly mis- interpreting the return value when the result is larger than the destination buffer). In any case, you still miss the case where someone has implemented their own string copy function and is using it incorrectly. I believe the correct way is a line-by-line audit of all the code, checking for the various security problems. One thing that would help with this task is a list of code patterns that indicate security problems. This list will make it easier for auditors (and will expand over time). I suspect that a 'cvs diff' of the OpenBSD code tree is the best starting point. Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD security auditing project.
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 to look for, you could find them right? If you were also given a typical work around, you could apply it, right? Not everyone in the OpenBSD project came into this with a security mindset. Rather it was alot of getting people rallied around the cause and teaching them how to go about it. Before we go off 1/2 cocked, we need to get organized. -- -- David([EMAIL PROTECTED]) Maybe I'm being modest. :) Actually I've been programming for about 10 years (surely not as long as others on this list) and taught C programming for 2 of those years. So yes, I can not only read C code, but I spew it fairly often. In any event, I suspect your comments aren't entirely directed at my quip, but rather at the sentiment. Point taken. Perhaps, I'll start taking a second-look at some of the fine BSD code I've taken for granted all these years. Kelly -- Kelly Yancey - [EMAIL PROTECTED] - Richmond, VA Director of Technical Services, ALC Communications http://www.alcnet.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSDhttp://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD security auditing project.
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 code out there, and it would help if we could involve the non-programmers in the search. Comments? 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. Speaking as a beginning programmer, longtime FreeBSD user: Given the above, I would be happy to contribute eyeballs. As a network engineer, I spend a lot of time alone with my laptop. Might I suggest a set of instructions along the lines of: a) This is what an unsafe function call looks like b) This is a typical workaround for unsafe call X, Y, Z c) Pick a chunk of code. Begin looking for these calls. d) when you find one of these calls 1) Apply the workaround 2) Make sure the program still compiles 3) submit patch to [EMAIL PROTECTED] e) Repeat until intimately familiar with BSD In fact, I'll go further: If someone can point out a reliable resource on the Net for a) and b), I'll be happy to write up a first draft of "The FreeBSD Security Audit for Beginners". I'm sure that any number of programmers out there would be happy to review it for technical accuracy before putting it into circulation. After all, FreeBSD articles are covering Christmas this year. I suppose the least I can do is write something for you folks for free. ;) ==ml To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Console driver (Was: Re: FreeBSD security auditing project)
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 Serve! -=- [EMAIL PROTECTED] FreeBSD keltia.freenix.fr 4.0-CURRENT #75: Tue Nov 2 21:03:12 CET 1999 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD security auditing project.
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 char *ibuf, ...)
{
char buf[MYBUFSIZ];
...
strcpy(buf, ibuf);
...
}
In general, this call is unsafe because there's no apparent
restriction on the size of ibuf, but in the particular program, it may
be quite safe because the length of ibuf has been checked previously.
In this case, it's probably safer to change the strcpy() to a
strlcpy() or similar - the cost (and risk) of making the change is
probably less than the cost of checking all the places where foo()
is called. Now consider the case where `buf' is also passed
as an argument - now you don't immediately know the length of
either the source _or_ destination buffers.
And the unsafe code may not be a function call at all. It's quite
easy to have an off-by-one error when working with arrays.
If you want to look at standard library functions used unsafely, I
think there's a range you need to consider. At one end you have
"virtually impossible to use safely" (ie [v][f]scanf("...%s..."),
gets(), system() and popen()). At the other end, you have "fairly
easy to use without introducing buffer overflows" (ie fgets(),
[v]snprintf(), strlcpy()). The other string functions, [v]sprintf()
and [v]sscanf("...%s...") fall somewhere in the middle. Note that the
range does not extend to "can't be used unsafely" or even "difficult
to use unsafely" (at least in C).
In fact, I'll go further: If someone can point out a reliable resource
on the Net for a) and b), I'll be happy to write up a first draft of
"The FreeBSD Security Audit for Beginners". I'm sure that any number
of programmers out there would be happy to review it for technical
accuracy before putting it into circulation.
A good start would be to read the general `secure programming'
information on the web and look for things that are being done
differently. Aleph One [EMAIL PROTECTED] posted a good
summary in BUGTRAQ last December as Message-id:
[EMAIL PROTECTED]
Peter
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD security auditing project.
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 us.
{Net,Open}BSD kept a lot of Net/2 [influenced] code (not sure how they
were allowed to do that),
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 of, with respect to Net/2 code with any party other
than UCB.
Walnut Creek and FreeBSD where sent letters by USL/Novell specifically
requesting us to cease all use of Net/2. Out of this a formal and legally
binding agreement between Walnut Creek and USL/Novell was reached, further
I belive Jordan Hubbard signed a like agreement on behalf of FreeBSD.
These agreements basically say that the parties would stop all use of
Net/2 based code and replace it with BSD4.4 Lite, which is what was
done. There are more details, but those are ``not to be disclosed''.
One could make claim that Novell/USL seriously failed to do ``due dilegence'',
but they where not protecting a trademark, but instead a copyright and they
could, if they still owned the code. come along and slap NetBSD/OpenBSD
with a pretty healthy law suite.
while we started fresh with 4.4BSD. Thus diffs
between us and them in userland utils and be quite different.
Technically if I where to bring a NetBSD repository over to my box and
then let anyone other than myself even look at it I would be in violation
of the USL/Novell agreement due to the fact that the repository contains
Net/2 code. :-(.
--
Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD security auditing project.
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 body of the message
Re: FreeBSD security auditing project.
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 about it if you do. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD security auditing project.
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 web sites (I should...it's my day job ;) ). Let me know what I can do to help. Cool, we have a database guy! :) Count me in as well if needed, I'm in the same boat about database-driven web sites as my day job. And on another comment a few messages later, I'm more than willing to eyeball code if examples of what to look for are given. I haven't done any C programming (other than minor tweaks here and there) in quite some time, but it's like riding a bicycle. -Ryan Dewalt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD security auditing project.
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, comments, defines etc): contrib/binutils/gas/hash.c - only if compiled -DTEST contrib/cvs/lib/getdate.y - only if compiled -DTEST contrib/gperf/tests/test.c- part of gperf test suite contrib/libreadline/tilde.c - only if compiled -DTEST contrib/texinfo/info/tilde.c - only if compiled -DTEST gnu/lib/libregex/test/fileregex.c - part of libregex test suite gnu/lib/libregex/test/iregex.c- part of libregex test suite gnu/usr.bin/as/config/tc-m68k.c - only if compiled -DTEST1 gnu/usr.bin/as/config/tc-vax.c- only if compiled -Dtest or -DTEST gnu/usr.bin/tar/getdate.y - only if compiled -DTEST sys/boot/pc98/boot2/boot.c- asking for boot device sys/i386/boot/biosboot/boot.c - asking for boot device sys/i386/boot/cdboot/boot.c - asking for boot device sys/kern/vfs_conf.c - prompting user for root filesystem sys/pc98/boot/biosboot/boot.c - asking for boot device So the only live code that contains gets() is in the boot loader (where space is a serious problem) and when reading a user-specified root filesystem name in the kernel. In either case, it's not clear that exploiting the resultant buffer overflow would allow someone to gain additional privileges (beyond those they already have as a result of being able to type input into gets()). I would prefer to see the gets() in vfs_conf.c go away - the actual gets() definition is right below the (sole) call to gets() and could easily be changed to bounds check its input. The boot code is less obvious. Adding input bounds checking could make the difference to the code fitting or not fitting. This is probably an area where compliance to Standard C Library interfaces is less important than code size. and our implementation even gets whiney about it if you do. I like this and have previously suggested that it could probably be usefully extended to other functions. Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD security auditing project.
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: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD security auditing project.
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. There is a lot of code out there, and it would help if we could involve the non-programmers in the search. Comments? * We need to break the auditing process into managable work units. Specifically, I think Kris was right on the money in defining the resolution to be at the function, as opposed to file, level. Individual functions can be identified as unsafe, suspect, or as scutinized and believed to be safe. Individuals are welcome to analyze an entire file, but the status should be recorded per-function. This has the added benefit that commits which change only 1 function in a file, can reset just the confidence level of the function effected, rather than the entire file. That should reduce the amount of duplicated effort since functions which have been scrutinized and deemed safe don't require the same level of scrutiny again should some other function in the file change. * We need to note when a commit affects code that was believed to have previously been secure (so that it may be audited again). This is an extension of the previous point. The on-line tool (whatever form it takes) would have to track commits and reset the confidence flag for any functions that changed. It would be ideal to reset a function's confidence rating whenever it has changed, except when the change was to make it more secure. But of course, this is impractical. The compromise would probably have to be just to always reset the rating to "suspect" and let anyone who commits a security-related fix reset the rating themself. * We should indicate what parts of the code have been audited without discouraging others from double-checking if they like. Continuing the previous thought: we could allow people to attach their assessment to function records in the database. So that if one reviewer "eyeballs" the code and believes it to be safe, they can say so, and it is recorded along with the current version of the file the function is in, and the date of the assessment. This gives us 4 rewards: First, that everyone can see which functions have been reviewed. Second, that if commits make a function unsafe, it would be trivial to identify the last safe version of the file and thus the function. Third, it allows multiple people to review the same function, knowing that someone else has already reviewed it. If I eyeball a function and suspect it to be unsafe, I can attach my "suspect" assessment to the function. Someone looking for functions to investigate could query all of the functions whose most recent assessment was "suspect" (or worse, "unsafe", see last point below). Finally, it requires no effort on the part of the cvs-meisters (ie. no messing with CVS tags); all auditing information is stored outside of the CVS repo. * We would like to be able to identify and integrate security fixes already made by OpenBSD or NetBSD easily. The main obstacle I see here is the divergence in the code bases. Specifically, functions have slightly different names in many places, the file hierarchies are organized differently, and god-knows what else. The only way I can figure to begin to automate the process of integrating fixes from other *BSDs would be to build a mapping relationship for functions and files between their source trees and ours. That may well take as much effort as the audit itself :) I think the only reasonable way to get the fixes merged into our source is for hackers to do it by hand. That isn't to say that we couldn't provide a central place for security-conscious hackers to view security-related commits to other BSD's source trees, past and present. I suspect grepping for things like "overflow" in commit logs for the other BSDs would go a long way in separating the wheat from the chaffe. We can help people find out about potential bugs, but I just can't see how the hand-holding could extend any further. * We would like to flag programs as suspect/insecure when they are the subject of bugtraq reports. The big trick here is that bugtraq reports aren't always nice enough to point us to the specific file/function that is causing the bug :). Either someone has to be responsible for manually identifying the offending files and/or functions as "unsafe" or else we have to take the same policy as with merging fixes from the other BSDs and just provide the information for the more intelligent chair-to-keyboard interface to figure out. That aside, I have used 3 confidence levels thoughout this message for indentifying the audit status of files: "unsafe,"
Re: FreeBSD security auditing project.
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 `very likely to be misused'). if (fscanf(file, "%d:foo:%.*s", smurf, sizeof(something), something) /* This is safe, of course. */ Beep. You lose. "%.*s" doesn't exist in *scanf() [I thought it did, but it's not mentioned in either scanf(3) or the source]. You have to specify field widths as literals (which makes this sort of code a real PITA). #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 name[] was made to be exactly the largest size, where sprintf() _would_be_safe_, Not necessarily true. Consider a system where sizeof(int)==8 (such C compilers exist today). In this case "%d" can take 20 characters, but the code above code assumes an int can always be printed in 11 characters. Don't get caught doing this. If you find a strcat() (for example), see if it's safe. If it is, then why replace it? Confirming that it is safe (checking all the paths by which the strcat() can be reached) might take substantial effort (if the buffers and/or range checks are widely separated from the strcat() call. In addition, someone might add a new path to the strcat(), or might change a buffer size, without properly checking all the ramifications. I tend towards the approach that unless it's immediately obvious that it's safe, you are better off using strlcat() (or maybe strncat()). Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD security auditing project.
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 the `hard to use correctly' category (or maybe `very likely to be misused'). It seemed like you were pointing out that these were inherently mistakes. if (fscanf(file, "%d:foo:%.*s", smurf, sizeof(something), something) /* This is safe, of course. */ Beep. You lose. "%.*s" doesn't exist in *scanf() [I thought it did, but it's not mentioned in either scanf(3) or the source]. You have to specify field widths as literals (which makes this sort of code a real PITA). Ah, well, I've never actually tried it. I've used non-'*' lengths; the example still holds as long as you use fscanf() correctly and specify the size as a number inside the fmt (which I didn't, of course :) #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 name[] was made to be exactly the largest size, where sprintf() _would_be_safe_, Not necessarily true. Consider a system where sizeof(int)==8 (such C compilers exist today). In this case "%d" can take 20 characters, but the code above code assumes an int can always be printed in 11 characters. Our code doesn't run an a system _anything_ like that. In fact, I can't even think of compilers with 8 * NBBY ints. GCC is one of those that can be coerced into long being a software, 64-bit type. Don't get caught doing this. If you find a strcat() (for example), see if it's safe. If it is, then why replace it? Confirming that it is safe (checking all the paths by which the strcat() can be reached) might take substantial effort (if the buffers and/or range checks are widely separated from the strcat() call. In addition, someone might add a new path to the strcat(), or might change a buffer size, without properly checking all the ramifications. I tend towards the approach that unless it's immediately obvious that it's safe, you are better off using strlcat() (or maybe strncat()). You shouldn't be using static buffers in the first place, so str*cat() should never be used. Peter -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / [EMAIL PROTECTED]`--' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD security auditing project.
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 anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD security auditing project.
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 this afternoon and my link flaked out. Make sure that you look for unusual buffer overflows. This one requires that you think. Grepping for strcpy is one thing, but looking at all the memcpy, memmove, bcopy in the source tree is needed. Look for moving NULL terminated lists w/o moving the NULL. Look for opportunities to overflow things like the atexit run queue, etc. Look for buffer overflows that are caused by sloppy programming. while (*src++ = *dst); [SIC] is but one buggy example :-) Look for cases where the safer interfaces are used improperly. Eg, char foo[5]; ... snprintf(foo, 10, ...). Look for off by one errors in passing lengths to kernel routines. Make sure that you know if that routine will NUL terminate for you or not. Look for DoS things. These include infinite loops on bad data, core dumping (although not all core dumps can be turned into an attack, just some of them). Look for dangerous signal handling. Look for bugs. Don't overlook something because it has a bug that isn't security related. Fix it, or file a PR. Many of the early OpenBSD bug fixes were later turned into attacks. Look at all setuid programs to make sure the need to be setuid. Ditto setgid. Dump is a good example of a program that is setgid that doesn't need to be since it can fork write to do what it is doing internally. Look for places in the kernel that don't do range checking properly. These will turn into panics. Memory leaks can also be leveraged into a DoS, so look for them as well. Take a long hard look at the startup sequence of FreeBSD. Consider that most of the important files on the system are imutable, but make sure that all of them can be made imutable to secure the system. Right now there are many holes. OpenBSD closed the window by raising security level early. Might not be a bad idea to look into what they have done. Be paranoid. If you don't think the whole world is out to get you and a giant conspirancy, then watch more X-Files until you do :-) Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD security auditing project.
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
Re: FreeBSD security auditing project.
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 the CVSROOT directory of the openbsd tree. After a while, you get a good nose for reading them to know what is important and what isn't. Once you hit a program that has had one fix, it is most productive, I've found, to integrate all the security and bug fixes things you can find in that program, and then reaudit the hell of out of it in case you introduce something bogus. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD security auditing project.
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 that I've fixed with it over the years. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD security auditing project.
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() (for example), see if it's safe. If it is, : then why replace it? No. You missed the point. It is called fail-safe programming. Even though today's use of sprintf is safe, changes to the program can make it unsafe in the future. snprintf remains safe through most, if not all, of those changes. The changes that make sprintf unsafe can be more subtle than the skills of the committer making the change, as the project frequently has novice people making changes. These should be caught, but aren't always. snprintf increases the likelyhood that these people will be able to make safe changes to the code. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
