Re: sbc and pcm
On Tue, 23 Nov 1999, Peter Wemm wrote: "Matthew N. Dodd" wrote: On Mon, 22 Nov 1999, Nick Hibma wrote: My compliments on the sbc bridge drivers. This is what newbus is supposed to look like. Anyone wanting to know what a bridge driver is, have a look at sys/dev/sound/isa/sbc.c Beautiful in its simplicity: probe attach (create a few children: pcm, midi, etc.) helper functions (alloc/free resource). Actually, I've a few issues with it but I'm sure Peter will cover anything I have to say. Mostly, sbc.c is handling PnP ID matching in a totally bogus manner. Yes, it's quite bogus and is incompatible with motherboard devices. There should be no vendor ID references in there at all, that's for card ID, not device id. I thought the problem with that (which was present in the non-bridged sb driver too) is that for sound cards, we need to use both logical and vendor IDs to detect things accuratly (a surprisingly large number of cards are just labeled CSC0001 or similar). -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make -j13 world broken
John Hay wrote: A normal "make world" on current is ok, but a "make -j13 world" is broken. I have looked at it a little bit, but I can't figure out what is going wrong. It dies with: cd /usr/src/usr.bin/lex;make beforeinstall install -C -o root -g wheel -m 644 /usr/src/usr.bin/lex/FlexLexer.h /usr/obj/usr/src/tmp/usr/include/g++ -- Building elf libraries -- cd /usr/src; PATH=/usr/obj/usr/src/tmp/sbin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/bin:/usr/obj/usr/src/tmp/usr/bin BISON_SIMPLE=/usr/obj/usr/src/tmp/usr/share/misc/bison.simple COMPILER_PATH=/usr/obj/usr/src/tmp/usr/libexec:/usr/obj/usr/src/tmp/usr/bin GCC_EXEC_PREFIX=/usr/obj/usr/src/tmp/usr/lib:/usr/obj/usr/src/tmp/usr/lib/ LD_LIBRARY_PATH=/usr/obj/usr/src/tmp/usr/lib LIBRARY_PATH=/usr/obj/usr/src/tmp/usr/lib:/usr/obj/usr/src/tmp/usr/lib PERL5LIB=/usr/libdata/perl/5.00503 OBJFORMAT_PATH=/usr/obj/usr/src/tmp/usr/libexec CFLAGS="-nostdinc -O -pipe" make DESTDIR=/usr/obj/usr/src/tmp -DNOINFO -DNOMAN -f Makefile.inc1 libraries make: not found *** Error code 127 I assume make(1) has been built, because that's the first constructive thing that happens. Can you check that it has been installed? -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
VB
Title: VideBula-991118 VideBula "No importa o que tiraram de voc, o que importa o que voc vai fazer com o que sobrou." "Voc no pode estar s se gostar da pessoa com quem fica quando esta sozinho." RECEBER NORECEBER PUBLICAR CRTICAS, DVIDAS SUGESTES
Re: Unbreak XFree86
This patch might be a bit heavy handed, but it seems to fix the problem... The KerberosIV bits can go; I have some cleanups that nuke that completely in favour of PAM. Now all I need to do is make PAM work for xdm... 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: Netscape and -current
On Tue, 23 Nov 1999, Peter Wemm wrote:
I'm pretty sure it's this commit to i386/machdep.c:
===
revision 1.377
date: 1999/11/21 14:46:43; author: pho; state: Exp; lines: +5 -5
Moved useracc() to top of sigreturn as to avoid panic
caused by invalid arguments to rutine.
Reviewed by:marcel, phk
===
Hmm. My netscape works, but I didn't use merge that commit. I had already
inadvertly fixed the bug in another way while cleaning up.
Indeed, the proplem is checking the new context before checking that the
context is actually new.
Here is my version.
int
sigreturn(p, uap)
struct proc *p;
struct sigreturn_args /* {
ucontext_t *ucp;
} */ *uap;
{
struct trapframe *regs;
ucontext_t *ucp;
int cs, eflags;
#if defined(COMPAT_43) || defined(COMPAT_SUNOS)
if (((struct osigcontext *)uap-sigcntxp)-sc_trapno == 0x01d516)
return (osigreturn(p, (struct osigreturn_args *)uap));
#endif
ucp = uap- /* ucp */ sigcntxp;
if (!useracc((caddr_t)ucp, sizeof(*ucp), VM_PROT_READ))
return (EFAULT);
eflags = ucp-uc_mcontext.mc_eflags;
regs = p-p_md.md_regs;
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Install Glitch
Works like a charm. Two more I've encountered: lynx: libncurses.so.3 libmytinfo.so.2 Thanks! I've added them to my list. I'm going to populate compat3x from 3.4-RELEASE. So we aren't too far off. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ps on 4.0-current
Why does ps not show the full path on 4.0 as in 3.3? (for non-root users) ie: 4.0 ps -ax 134 v2 Is+0:00.00 (getty) 135 v3 Is+0:00.00 (getty) 136 v4 Is+0:00.00 (getty) 137 v5 Is+0:00.00 (getty) 3.3 ps -ax 312 v0 Is+0:00.01 /usr/libexec/getty Pc ttyv0 313 v1 Is+0:00.01 /usr/libexec/getty Pc ttyv1 314 v2 Is+0:00.01 /usr/libexec/getty Pc ttyv2 ?? _F To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ps on 4.0-current
On Tuesday, 23 November 1999 at 13:15:58 -0500, Forrest Aldrich wrote: Why does ps not show the full path on 4.0 as in 3.3? (for non-root users) ie: 4.0 ps -ax 134 v2 Is+0:00.00 (getty) 135 v3 Is+0:00.00 (getty) 136 v4 Is+0:00.00 (getty) 137 v5 Is+0:00.00 (getty) Have you rebuilt world? It looks fine here with a kernel supped this morning and built 20 minutes ago. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ps on 4.0-current
In the last episode (Nov 23), Forrest Aldrich said: Why does ps not show the full path on 4.0 as in 3.3? (for non-root users) 4.0 ps -ax 134 v2 Is+0:00.00 (getty) 135 v3 Is+0:00.00 (getty) 136 v4 Is+0:00.00 (getty) 137 v5 Is+0:00.00 (getty) 3.3 ps -ax 312 v0 Is+0:00.01 /usr/libexec/getty Pc ttyv0 313 v1 Is+0:00.01 /usr/libexec/getty Pc ttyv1 314 v2 Is+0:00.01 /usr/libexec/getty Pc ttyv2 That just means that on your 4.0 box, the gettys have been swapped out. ps will not swap the process back in just to get the processname unless you give it the -f flag (and are root). -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
FreeBSD security auditing project.
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 us over to
the actual work of getting it done.
My proposals are pretty simple;
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 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.
o unsafe buffer handling (probably better handled by str*(3)??)
o tmpfile races.
o password buffers not being zeroed fast enough
o unsafe use of command line or environment variables (?).
o unsafe passing/exposure of sensitive data.
o c. please contribute here
Let the discussion begin! All contributions welcome. Volunteers for the
effort (there were lots of you at FreeBSDCon) please fight your way to
the front now!
You'll need to be a $#|t-hot programmer, paranoid, and experienced in
code auditing to do the actual code review, but any other skills that
may be of use (*anything* - volunteers are most welcome!!) please come
forward with a miniresume and a proposal.
I'll get a mailing list going if this is deemed necessary.
Thanks!
M
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: ps on 4.0-current
In the last episode (Nov 23), Forrest Aldrich said: Why does ps not show the full path on 4.0 as in 3.3? (for non-root users) 4.0 ps -ax 134 v2 Is+0:00.00 (getty) 135 v3 Is+0:00.00 (getty) 136 v4 Is+0:00.00 (getty) 137 v5 Is+0:00.00 (getty) 3.3 ps -ax 312 v0 Is+0:00.01 /usr/libexec/getty Pc ttyv0 313 v1 Is+0:00.01 /usr/libexec/getty Pc ttyv1 314 v2 Is+0:00.01 /usr/libexec/getty Pc ttyv2 That just means that on your 4.0 box, the gettys have been swapped out. ps will not swap the process back in just to get the processname unless you give it the -f flag (and are root). $ ps jtva USER PID PPID PGID SESS JOBC STAT TT TIME COMMAND root 222 1 222 9dac400 Is+ va0:00.01 (getty) $ ps fjtva USER PID PPID PGID SESS JOBC STAT TT TIME COMMAND root 222 1 222 9dac400 Is+ va0:00.01 (getty) $ sudo ps jtva USER PID PPID PGID SESS JOBC STAT TT TIME COMMAND root 222 1 222 9dac400 Is+ va0:00.01 /usr/libexec/getty Pc tt $ sudo ps fjtva USER PID PPID PGID SESS JOBC STAT TT TIME COMMAND root 222 1 222 9dac400 Is+ va0:00.01 /usr/libexec/getty Pc tt $ head -1 /etc/motd FreeBSD 4.0-CURRENT (HAK) #9: Mon Nov 22 01:09:55 GMT 1999 This looks a bit wrong -- Dan Nelson [EMAIL PROTECTED] -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.Awfulhak.org [EMAIL PROTECTED] Don't _EVER_ lose your sense of humour ! [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 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: ftpd is not listed in pam.conf
On Mon, 22 Nov 1999, Mark Murray wrote: May this is not the best way for ftpd to use pam (many other lines for login, may ftpd should be so). But I think ftpd should be listed in /etc/pam.conf. Any plan to fix it in /usr/src/etc/pam.conf ? On my list! :-) rsh too, while you're at it, please. (Only using it for internal use) Leif 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: bind vulnerabilities
At 03:57 PM 11/23/99 , Vlad Skvortsov wrote: Sorry for probably a bit stupid question (I've been out of lists for a while). Are patches for named already in -current or -stable ? No they have not to either. Use it out of the ports. Be sure to adjust named-xfer "/usr/local/libexec/named-xfer"; // _PATH_XFER accordingly in your named.conf file. This raises a question, why has the new BIND not been committed to current at least ? I am not complaining, just curious as to the rationale ? ---Mike ** Mike Tancsa, Network Admin* [EMAIL PROTECTED] Sentex Communications Corp, * http://www.sentex.net/mike Cambridge, Ontario* 519 651 3400 Canada* To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ps on 4.0-current
In the last episode (Nov 23), Brian Somers said: $ ps jtva USER PID PPID PGID SESS JOBC STAT TT TIME COMMAND root 222 1 222 9dac400 Is+ va0:00.01 (getty) $ sudo ps jtva USER PID PPID PGID SESS JOBC STAT TT TIME COMMAND root 222 1 222 9dac400 Is+ va0:00.01 /usr/libexec/getty Pc tt $ head -1 /etc/motd FreeBSD 4.0-CURRENT (HAK) #9: Mon Nov 22 01:09:55 GMT 1999 This looks a bit wrong Now that does look weird. After a bit more investigation, it looks like you can only get the full commandline of your own processes. Root can see all commandlines. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
make -DWANT_AOUT world fails
Hi,
"make -DWANT_AOUT world" on my current box fails because of the
recent changes to src/Makefile.inc1.
log starts here
--
Building legacy libraries
--
cd /usr/src;
PATH=/usr/obj/usr/src/tmp/sbin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/bin:/usr/obj/usr/src/tmp/usr/bin
BISON_SIMPLE=/usr/obj/usr/src/tmp/usr/share/misc/bison.simple
COMPILER_PATH=/usr/obj/usr/src/tmp/usr/libexec:/usr/obj/usr/src/tmp/usr/bin
GCC_EXEC_PREFIX=/usr/obj/aout/usr/src/tmp/usr/lib/aout:/usr/obj/aout/usr/src/tmp/usr/lib/
LD_LIBRARY_PATH=/usr/obj/usr/src/tmp/usr/lib/aout
LIBRARY_PATH=/usr/obj/aout/usr/src/tmp/usr/lib/aout:/usr/obj/aout/usr/src/tmp/usr/lib
PERL5LIB=/usr/libdata/perl/5.00503 OBJFORMAT_PATH=/usr/obj/usr/src/tmp/usr/libexec
CFLAGS="-nostdinc -O2 -m486 -pipe" /usr/obj/usr/src/tmp/usr/bin/make
DESTDIR=/usr/obj/aout/usr/src/tmp -DNOINFO -DNOMAN -f Makefile.inc1 bootstrap-libraries
make: don't know how to make bootstrap-libraries. Stop
*** Error code 2
= log ends here =
I think we must delete following 2 lines in Makefile.inc1.
--- Makefile.inc1.old Wed Nov 24 01:39:15 1999
+++ Makefile.inc1 Wed Nov 24 08:10:25 1999
@@ -808,8 +808,6 @@
@echo " Building legacy libraries"
@echo "--"
cd ${.CURDIR}; \
- ${XMAKE} -DNOINFO -DNOMAN -f Makefile.inc1 bootstrap-libraries
- cd ${.CURDIR}; \
${XMAKE} -DNOINFO -DNOMAN -f Makefile.inc1 libraries
@echo
@echo "--"
--
Motoyuki Konno [EMAIL PROTECTED] (Univ)
[EMAIL PROTECTED] (Home)
[EMAIL PROTECTED] (FreeBSD Project)
Yamanashi Medical Universityhttp://www.freebsd.org/~motoyuki/ (WWW)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Netscape and -current
On Wed, 24 Nov 1999, Bruce Evans wrote:
Hmm. My netscape works, but I didn't use merge that commit. I had already
inadvertly fixed the bug in another way while cleaning up.
Indeed, the proplem is checking the new context before checking that the
context is actually new.
Here is my version.
Hmm...
int
sigreturn(p, uap)
struct proc *p;
struct sigreturn_args /* {
ucontext_t *ucp;
} */ *uap;
{
struct trapframe *regs;
ucontext_t *ucp;
int cs, eflags;
#if defined(COMPAT_43) || defined(COMPAT_SUNOS)
if (((struct osigcontext *)uap-sigcntxp)-sc_trapno == 0x01d516)
return (osigreturn(p, (struct osigreturn_args *)uap));
#endif
I don't see how this fixes things, other than hiding it. Since the i386
memory model we use maps kernel and user memory all at the same time,
this code is reading directly from user space memory, right? If this is
the case, wouldn't a copyin() be the proper thing to do? At least doing
the useracc() would be better than doing nothing, wouldn't it?
ucp = uap- /* ucp */ sigcntxp;
if (!useracc((caddr_t)ucp, sizeof(*ucp), VM_PROT_READ))
return (EFAULT);
eflags = ucp-uc_mcontext.mc_eflags;
regs = p-p_md.md_regs;
Bruce
--
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.
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
Re: Netscape and -current
On Tue, 23 Nov 1999, Peter Wemm wrote: Brian Fundakowski Feldman wrote: Forget anything I said about KAME being the strong possibility :) As soon as peter noted what commit it could have to do with, I figured it out and fixed it; after testing, I committed it. Be happy :) Your fix suffers from exactly the same problem.. Suppose down the track that ucontext_t becomes smaller than 'struct sigocontext' ? You're then failing what would have worked. The check against sizeof osigcontext should not be fatal. That will not happen, though. Your proposal suffers from a very similar problem. Okay, let's assume that ucontext_t is _smaller_ than a struct osigcontext. If it fails the "osigcontext size test", it won't go to osigreturn, fine. BUT, it continues on, and is taken as a valid ucontext_t instead of an EINVAL osigcontext. Do you see where the problem is with this approach? Since the revision I committed went under an assumption that's alway going to be true, and even if it weren't, it would be updated to match the world anyway, I don't see the problem. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] -- 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: ps on 4.0-current
In the last episode (Nov 23), Brian Somers said: $ ps jtva USER PID PPID PGID SESS JOBC STAT TT TIME COMMAND root 222 1 222 9dac400 Is+ va0:00.01 (getty) $ sudo ps jtva USER PID PPID PGID SESS JOBC STAT TT TIME COMMAND root 222 1 222 9dac400 Is+ va0:00.01 /usr/libexec/getty Pc tt $ head -1 /etc/motd FreeBSD 4.0-CURRENT (HAK) #9: Mon Nov 22 01:09:55 GMT 1999 This looks a bit wrong Now that does look weird. After a bit more investigation, it looks like you can only get the full commandline of your own processes. Root can see all commandlines. Any comments Poul ? Is this anything to do with the recent command line buffering ? -- Dan Nelson [EMAIL PROTECTED] -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.Awfulhak.org [EMAIL PROTECTED] Don't _EVER_ lose your sense of humour ! [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ps on 4.0-current
On Tue, Nov 23, 1999 at 05:11:37PM -0600, Dan Nelson wrote: Now that does look weird. After a bit more investigation, it looks like you can only get the full commandline of your own processes. Root can see all commandlines. Yes, I can confirm it too on recently rebuilded -current. Looks like access to this info becomes too restrictive. Something bad in the kernel, not in kvm library. -- Andrey A. Chernov http://nagual.pp.ru/~ache/ MTH/SH/HE S-- W-- N+ PEC+ D A a++ C G+ QH+(++) 666+++ Y 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: Threads and my new job.
Jason, you are my savior. Go forth and do much to create Truly Kick Ass Threading. Give me my tools to smite these Linux database servers once and for all! :-) Why do we need to smite the Linux database servers? With threads in their current state they already outperform Linux's native threads by ~50x for things like sending mail. I would assume that the differences in database performance is similar. -Kip To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ps on 4.0-current
In the last episode (Nov 23), Lyndon Nerenberg said: After you verify that this change isn't going to break things that assume they can see the *argv list via ps(1). I.e. lightning bolts that do 'kill -MUMBLE `ps -ax|grep foo`'. Which may not be elegant style, but sometimes is the only workable solution. That won't be affected, because anyone that has kill rights to the process will also see the full processname. Now that I think about it, I can't come up with a case where this is really bad. If you're doing ps'es with intent to kill arbitrary processes (in the name of debugging or whatever), you're probably already root. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
buildworld across signal changes not quite right
Thanks to Marcel's latest Makefile.inc1 changes (1.92), a -current buildworld running on an older -current system now progresses much further - in fact it now completes :-). There are, however still a few problems - as far as I can tell, these are all related to the wrong version of perl being called whilst perl is being built in the " Building everything.." section. I'm not sure how to fix this problem. Unlike our other build tools, perl is not designed to be able to be cross-built: It builds bits of itself and assumes they can be safely executed to build other bits. Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Lint broken in -current.
Lint no longer works in -current as cpp seems to have lost the -undef option. The option is still shown in the usage message and the man page, but the code seems to have gone walk about! David. 0:30:gonzo 92% uname -a FreeBSD gonzo.home 4.0-CURRENT FreeBSD 4.0-CURRENT #17: Sat Nov 20 13:35:22 GMT 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/GONZO i386 0:30:gonzo 93% cpp --help | fgrep undef -Wundef Warn if an undefined macro is used by #if -Wno-undefDo not warn about testing undefined macros -gInclude #define and #undef directives in the output -u or -undef Do not predefine any macros 0:30:gonzo 94% cpp -undef cpp: Invalid option `-undef' 0:30:gonzo 95% cpp -u cpp: Invalid option `-u' 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
Make buildworld blowing up
I'm trying to build a CURRENT system from the 4.0 CURRENT snapshot cdroms on 7-5-1999. I did a cvsup to cvsup4.freebsd.org, and attempted to build world. It keeps on blowing up as illustrated below. I nuked the /usr/src directory and then checked the source tree from our local mirror of the master CVS repository, but it too dies. Even after a ``make clean''. Anyone have any ideas whats going on here? === cc_tools gperf -p -j1 -i 1 -g -o -t -G -N is_reserved_word -k1,3,$ /usr/src/gnu/usr.bin/ cc/cc_tools/../../../../contrib/gcc/c-parse.gperf c-gperf.h /* starting time is 13:42:44 */ /* ending time is 13:42:44 */ gperf -p -j1 -g -o -t -N is_reserved_word '-k1,4,7,$' /usr/src/gnu/usr.bin/cc/c c_tools/../../../../contrib/gcc/cp/gxx.gperf gxx-hash.h /* starting time is 13:42:44 */ /* ending time is 13:42:44 */ ln -sf gxx-hash.h hash.h echo '#include "cp/cp-tree.def"' gencheck.h echo '#include "objc/objc-tree.def"' gencheck.h sed -e "/^ifobjc$/,/^end ifobjc$/d" -e "/^ifc$/d" -e "/^end ifc$/d" /usr/src/g nu/usr.bin/cc/cc_tools/../../../../contrib/gcc/c-parse.in c-parse.y yacc -d -o c-parse.c c-parse.y yacc: e - line 30 of "c-parse.y", syntax error %expect 51 ^ *** Error code 1 Stop. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld across signal changes not quite right
Peter Jeremy writes: | Thanks to Marcel's latest Makefile.inc1 changes (1.92), a -current | buildworld running on an older -current system now progresses much | further - in fact it now completes :-). | | There are, however still a few problems - as far as I can tell, these | are all related to the wrong version of perl being called whilst perl | is being built in the " Building everything.." section. | | I'm not sure how to fix this problem. Unlike our other build tools, | perl is not designed to be able to be cross-built: It builds bits | of itself and assumes they can be safely executed to build other bits. Yes this is very tricky. I run into a lesser issue when switching from threaded perl to unthread perl. This is currently broken since it doesn't link with the just built libs. This is further complicated in that other things sometimes need to find out how perl was built by asking perl. An example is vi with perl support which is also broken under threads. I can't see an obvious around this except to build a "build tools" version for use during the build and then a final version. An issue with this would be how to generate the config.h for the build platform since we currently have those pre-made for our target platforms. This doesn't address the issue of perl needing to report how it was built. I have sent in fixes for the 2 threaded perl issues. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lint broken in -current.
Lint no longer works in -current as cpp seems to have lost the -undef option. Yes, looking into `cpp' is on my list of things to do. 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: ps on 4.0-current
I seem to recall that conversation here in the mailing list. How about a system configuration variable that determines what info like ps (and friends) can access? Personally, I would just prefer to leave it be. There are too many other potential problems with scripts and such that depend upon the info PS provides. *shrug* :) _F At 12:54 AM 11/24/99 +0100, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Brian Somers writes: In the last episode (Nov 23), Brian Somers said: $ ps jtva USER PID PPID PGID SESS JOBC STAT TT TIME COMMAND root 222 1 222 9dac400 Is+ va0:00.01 (getty) $ sudo ps jtva USER PID PPID PGID SESS JOBC STAT TT TIME COMMAND root 222 1 222 9dac400 Is+ va0:00.01 /usr/libexec/getty Pc tt $ head -1 /etc/motd FreeBSD 4.0-CURRENT (HAK) #9: Mon Nov 22 01:09:55 GMT 1999 This looks a bit wrong Now that does look weird. After a bit more investigation, it looks like you can only get the full commandline of your own processes. Root can see all commandlines. Any comments Poul ? Is this anything to do with the recent command line buffering ? Yes, I changed it to this behaviour at warners asking (I think he had the security-meister hard-hat on at the time). I'm personally leaning towards the opinion that the argv is public property and should be visible, but then again, I can see the point in hiding it in some circumstances. I'll stick a sysctl in there which defaults to the "open" position and people who need to hide it can set it to "close" to do so. Will this satisfy everybody ? Warner ? -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Make buildworld blowing up
Anyone have any ideas whats going on here? Yep. ;-) yacc: e - line 30 of "c-parse.y", syntax error %expect 51 ^ *** Error code 1 The problem is rev 1.92 of src/Makefile.inc1. With that change, the tools needed to build GCC aren't made first. I added a few Bison-like features to Byacc that GCC depended on. The non-tradional "%expect" is one of them. If you manually build and install src/usr.bin/yacc/, a `make world' should then work. Acutally, you should also do the same for src/gnu/usr.bin/bison/ as I think you'll hit another problem later in the build. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ps on 4.0-current
On Wed, Nov 24, 1999 at 12:54:15AM +0100, Poul-Henning Kamp wrote: I'm personally leaning towards the opinion that the argv is public property and should be visible, but then again, I can see the point in hiding it in some circumstances. I'll stick a sysctl in there which defaults to the "open" position and people who need to hide it can set it to "close" to do so. Please. Thank you. Not everyone wears the sysadmin hat with the face shield and gas mask, as much as it may currently be in style. If it can work both ways, even better. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ 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,"
Overflow in banner(1)
In the spirit of the newly-formed FreeBSD Auditing Project, I present:
% banner `perl -e 'print "a"x2000'`
Segmentation fault(core dumped)
-
The problem is a trivial one. From /usr/src/usr.bin/banner/banner.c:
/*
* banner - prints large signs
* banner [-w#] [-d] [-t] message ...
*/
#define MAXMSG 1024
...
charmessage[MAXMSG];
...
/* Have now read in the data. Next get the message to be printed. */
if (*argv) {
strcpy(message, *argv);
while (*++argv) {
strcat(message, " ");
strcat(message, *argv);
}
nchars = strlen(message);
} else {
Bzzzt! Wrong!
OpenBSD were never vulnerable to this because they seem to use a different
banner(1) than we do. The issue of whether or not this is likely to be a
serious security risk is left as an exercise to the reader :-)
I'll commit this tomorrow (just wanted to get in a 'first post!' :-)..
Kris
Index: banner.c
===
RCS file: /home/ncvs/src/usr.bin/banner/banner.c,v
retrieving revision 1.6
diff -u -r1.6 banner.c
--- banner.c1999/04/19 04:05:25 1.6
+++ banner.c1999/12/23 10:18:50
@@ -1058,15 +1058,15 @@
/* Have now read in the data. Next get the message to be printed. */
if (*argv) {
- strcpy(message, *argv);
+ strncpy(message, *argv, MAXMSG);
while (*++argv) {
- strcat(message, " ");
- strcat(message, *argv);
+ strlcat(message, " ", MAXMSG);
+ strlcat(message, *argv, MAXMSG);
}
nchars = strlen(message);
} else {
fprintf(stderr,"Message: ");
- (void)fgets(message, sizeof(message), stdin);
+ (void)fgets(message, MAXMSG, stdin);
nchars = strlen(message);
message[nchars--] = '\0'; /* get rid of newline */
}
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 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
Apahce
How I can install Apache_1.3.9 with the option EXTRA_CFLAGS=-DBIG_SECURITY_HOLE from ports ? Thanks. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ps on 4.0-current
In the last episode (Nov 23), Lyndon Nerenberg said: After you verify that this change isn't going to break things that assume they can see the *argv list via ps(1). I.e. lightning bolts that do 'kill -MUMBLE `ps -ax|grep foo`'. Which may not be elegant style, but sometimes is the only workable solution. That won't be affected, because anyone that has kill rights to the process will also see the full processname. Now that I think about it, I can't come up with a case where this is really bad. If you're doing ps'es with intent to kill arbitrary processes (in the name of debugging or whatever), you're probably already root. This was discussed close to death before the changes were committed, and the current behaviour (restricted access) has been agreed by general consensus to be the most appropriate. Making this behaviour tunable would be bad; it adds another option increasing complexity, and with the proposed default in most cases an admin tightening up a system would never know about it in the first place, rendering it useless. I'd strongly recommend leaving things they way they are. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Apahce
On Tue, Nov 23, 1999 at 11:49:28PM -0600, Juan Amado Becerril Castillo wrote: How I can install Apache_1.3.9 with the option EXTRA_CFLAGS=-DBIG_SECURITY_HOLE from ports ? By asking this question of [EMAIL PROTECTED] rather than here. -- -- 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 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: Overflow in banner(1)
On Tue, Nov 23, 1999 at 09:15:35PM -0800, Kris Kennaway wrote: - (void)fgets(message, sizeof(message), stdin); + (void)fgets(message, MAXMSG, stdin); There is nothing wrong with the original line here. Please don't change things that are fine just to change them. We don't want to ofuscate the fix. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Overflow in banner(1)
On Tue, 23 Nov 1999, David O'Brien wrote: On Tue, Nov 23, 1999 at 09:15:35PM -0800, Kris Kennaway wrote: - (void)fgets(message, sizeof(message), stdin); + (void)fgets(message, MAXMSG, stdin); There is nothing wrong with the original line here. Please don't change things that are fine just to change them. We don't want to ofuscate the fix. Obviously not, but I didn't see the point in making it inconsistent. 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.
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: Overflow in banner(1)
- (void)fgets(message, sizeof(message), stdin); + (void)fgets(message, MAXMSG, stdin); There is nothing wrong with the original line here. Please don't change things that are fine just to change them. We don't want to ofuscate Obviously not, but I didn't see the point in making it inconsistent. You could make the "MAXMSG" you added "sizeof(message)" and been consistent. :) -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
bogus kern_proc.c change (Re: ps on 4.0-current)
Dan Nelson wrote: In the last episode (Nov 23), Lyndon Nerenberg said: After you verify that this change isn't going to break things that assume they can see the *argv list via ps(1). I.e. lightning bolts that do 'kill -MUMBLE `ps -ax|grep foo`'. Which may not be elegant style, but sometimes is the only workable solution. That won't be affected, because anyone that has kill rights to the process will also see the full processname. Now that I think about it, I can't come up with a case where this is really bad. If you're doing ps'es with intent to kill arbitrary processes (in the name of debugging or whatever), you're probably already root. It's this bogus change to kern/kern_proc.c. If you back this out it should work as expected. @@ -631,7 +633,7 @@ if (!p) return (0); - if (!PRISON_CHECK(curproc, p)) + if (p_trespass(curproc, p)) return (0); if (req-newptr curproc != p) Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ps on 4.0-current
Christopher Masto wrote: On Wed, Nov 24, 1999 at 12:54:15AM +0100, Poul-Henning Kamp wrote: I'm personally leaning towards the opinion that the argv is public property and should be visible, but then again, I can see the point in hiding it in some circumstances. I'll stick a sysctl in there which defaults to the "open" position and people who need to hide it can set it to "close" to do so. Please. Thank you. Not everyone wears the sysadmin hat with the face shield and gas mask, as much as it may currently be in style. If it can work both ways, even better. Definately! This is NOT AN ACCEPTABLE CHANGE BY DEFAULT! Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ps on 4.0-current
: and people who need to hide it can set it to "close" to do so. : : Please. Thank you. : : Not everyone wears the sysadmin hat with the face shield and gas mask, : as much as it may currently be in style. If it can work both ways, : even better. : :Definately! This is NOT AN ACCEPTABLE CHANGE BY DEFAULT! : :Cheers, :-Peter I'm trying to figure out how what started as a fix to a panic turned into such a big mess. And I don't even think the panic has even been fixed --- it's just been made more obscure. There is a big difference between -e, which very few people use and which is an obvious security risk simply because people do not realize it is available, and displaying argv from a user-run ps which everyone is used to doing. When I first suggested removing -e I did so both for security reasons and because it would have been trivial to do. What we have at the moment is something entirely different. I would be for removing -e, but I would be adamantly opposed to restricting the display of command line arguments - not even with an opt-in sysctl. It's just added baggage. And I don't see much point in trying to make ps and top run faster. They are plenty fast enough already (well, maybe not top, but that's for other reasons unrelated to the display of command line arguments). ps *already* delves (or delved) into kvm to retrieve command line arguments only for processes not swapped out, meaning that running ps never causes processes or data to be swapped in unless you specify the 'f' option. In otherwords, nothing ps does blocks. I can't imagine how changing the way arguments are fetched by encumbering procfs with even more junk would generate a sufficient boost in performance to be either noticeable visually or worth doing at all. It would be nice if the procfs panics were fixed, but not at the cost of all of this. -Matt Matthew Dillon [EMAIL PROTECTED] 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
Re: Overflow in banner(1)
In message [EMAIL PROTECTED] "David O'Brien" writes: : On Tue, Nov 23, 1999 at 09:15:35PM -0800, Kris Kennaway wrote: : - (void)fgets(message, sizeof(message), stdin); : + (void)fgets(message, MAXMSG, stdin); : : There is nothing wrong with the original line here. Please don't change : things that are fine just to change them. We don't want to ofuscate the fix. In fact, the original line is safer than the replaced line. It is safer because message's size might change form MAXMSG to MAXBUF or 24. If you hardwire MAXMSG like this, painful experience has shown that you will get burned. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Overflow in banner(1)
In message [EMAIL PROTECTED] Kris Kennaway
writes:
: I'll commit this tomorrow (just wanted to get in a 'first post!' :-)..
Please don't. Please use a proper fix instead.
: /* Have now read in the data. Next get the message to be printed. */
: if (*argv) {
: - strcpy(message, *argv);
: + strncpy(message, *argv, MAXMSG);
: while (*++argv) {
: - strcat(message, " ");
: - strcat(message, *argv);
: + strlcat(message, " ", MAXMSG);
: + strlcat(message, *argv, MAXMSG);
Can you precompute the length, malloc the buffer and go from there?
wouldn't that be better?
: }
: nchars = strlen(message);
: } else {
: fprintf(stderr,"Message: ");
: - (void)fgets(message, sizeof(message), stdin);
: + (void)fgets(message, MAXMSG, stdin);
This is bad style. Don't make this change.
: nchars = strlen(message);
: message[nchars--] = '\0'; /* get rid of newline */
: }
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Overflow in banner(1)
Hmmm, but now that you have changed message to be a pointer, the
sizeof(message) at the end of the patch will return the size of
a pointer which is 4 and probably not what you want. :-)
I think we should be carefull when we make our security fixes so
that we don't introduce new bugs, which was also the problem that
I had the other day with doscmd.
John
--
John Hay -- [EMAIL PROTECTED]
I'd prefer something like this that I've attached. The move over the
years has been away from artificial limits...
--
Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! /
[EMAIL PROTECTED]`--'
Index: banner.c
===
RCS file: /usr2/ncvs/src/usr.bin/banner/banner.c,v
retrieving revision 1.6
diff -u -r1.6 banner.c
--- banner.c 1999/04/19 04:05:25 1.6
+++ banner.c 1999/11/24 05:41:35
@@ -1018,7 +1018,7 @@
};
char line[DWIDTH];
-char message[MAXMSG];
+char *message;
char print[DWIDTH];
int debug, i, j, linen, max, nchars, pc, term, trace, x, y;
int width = DWIDTH; /* -w option: scrunch letters to 80 columns */
@@ -1058,14 +1058,24 @@
/* Have now read in the data. Next get the message to be printed. */
if (*argv) {
- strcpy(message, *argv);
+ message = strdup(*argv);
+ if (message == NULL)
+ err(1, "strdup");
while (*++argv) {
- strcat(message, " ");
- strcat(message, *argv);
+ char *omessage;
+
+ omessage = message;
+ asprintf(message, "%s %s", message, *argv);
+ if (message == NULL)
+ err(1, "asprintf");
+ free(omessage);
}
nchars = strlen(message);
} else {
fprintf(stderr,"Message: ");
+ message = malloc(MAXMSG);
+ if (message == NULL)
+ err(1, "malloc");
(void)fgets(message, sizeof(message), stdin);
nchars = strlen(message);
message[nchars--] = '\0'; /* get rid of newline */
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: ps on 4.0-current
In message [EMAIL PROTECTED] Forrest Aldrich writes: : Why does ps not show the full path on 4.0 as in 3.3? : (for non-root users) Because you have caught things in the middle of a change. There will be a sysctl that will control this behavior shortly. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Overflow in banner(1)
In message [EMAIL PROTECTED] "David O'Brien" writes: : On Tue, Nov 23, 1999 at 09:15:35PM -0800, Kris Kennaway wrote: : - (void)fgets(message, sizeof(message), stdin); : + (void)fgets(message, MAXMSG, stdin); : : There is nothing wrong with the original line here. Please don't change : things that are fine just to change them. We don't want to ofuscate the fix. In fact, the original line is safer than the replaced line. It is safer because message's size might change form MAXMSG to MAXBUF or 24. If you hardwire MAXMSG like this, painful experience has shown that you will get burned. Well the original line is plain wrong if Brian's patch is being used, because there message is a pointer and the size of a pointer is 4. John -- John Hay -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
