Date: Thu, 18 Nov 1999 00:18:51 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Kelly Yancey <kbyanc@posi.net> Cc: Warner Losh <imp@village.org>, freebsd-security@FreeBSD.ORG Subject: Re: kernel stack contents visible from userland Message-ID: <199911180818.AAA79001@apollo.backplane.com> References: <Pine.BSF.4.05.9911172021110.18418-100000@kronos.alcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:On Wed, 17 Nov 1999, Warner Losh wrote:
:
:> These patches look good. I wonder if there might be an easier way to
:> accomplish this. I don't see anything here that is a security risk,
:> per se, since most of the stat struct is always filled in before the
:> copyout. Which fields in stat are not explicitly used? I would have
:> expected them all to be filled in in all cases. It would likely be
:> faster to just wonk on st_lspare and st_qspare[2] in cvstat...
:>
:
: I wrote new patches which were less intrusive and only cleared the spare
:fields rather than bzero'ing the entire structure. I've submitted the
:patches with PR kern/14966.
I've committed your patch to -current and -stable!
: On a related note, these patches still solve my original problem of
:being able to compare stat structures. I found that, at least on
:FreeBSD/i386, I can reliably memcmp() two stat structures and determine
:when a file's status has changed (even on filesystems without ctime). All
:is right in the world. :)
:
: Thanks for the feedback,
:
: Kelly
:
:--
:Kelly Yancey - kbyanc@posi.net - Richmond, VA
In general, it's a really bad idea to compare structures with memcmp().
It's so bad that I believe direct compares were removed from a draft
ANSI C standard prior to the final. If you use memcmp() to compare stat
structures you aren't going to be portable (i.e. the same bug you found
in FreeBSD might exist in other UNIXes).
-Matt
Matthew Dillon
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199911180818.AAA79001>