Date: Tue, 12 Dec 2000 11:25:03 -0700 From: Warner Losh <imp@village.org> To: Dag-Erling Smorgrav <des@ofug.org> Cc: assar@FreeBSD.ORG, Matt Dillon <dillon@earth.backplane.com>, kris@citusc.usc.edu, arch@FreeBSD.ORG Subject: Re: Safe string formatting in the kernel Message-ID: <200012121825.LAA31285@harmony.village.org> In-Reply-To: Your message of "12 Dec 2000 15:42:29 %2B0100." <xzpelzd66qy.fsf@flood.ping.uio.no> References: <xzpelzd66qy.fsf@flood.ping.uio.no> <xzpsnnuq1hy.fsf@flood.ping.uio.no> <20001211185610.A1741@citusc.usc.edu> <200012120259.eBC2xfb99004@earth.backplane.com> <5lhf4ap8cv.fsf@assaris.sics.se>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <xzpelzd66qy.fsf@flood.ping.uio.no> Dag-Erling Smorgrav writes: : Because there are other issues than just overflowing the buffer. : There's the issue of truncation (a lot of code uses snprintf() etc. : without checking if the resulting string was actually truncated, which : may be a security risk of its own), and there's the issue of using : large amounts of stack space for buffers (procfs and linprocfs are : notorious offenders in both these areas, but they're not the only : ones) Both strl* and snprintf have a return value so that if you truncate, you can detect it and do something different in the buffer overflow case. There are many times that you want to have a bounded uppper bound on the length of the string (path names spring to mind). There have been zero problems with truncating long strings in the security lists to date. I've not yet seen anything that looks close to an attack with string truncation causing any sorts of problems. : Vulnerabilities were recently found in the procfs code which were : successfully solved with snprintf(), but could have been (and : hopefully will be) solved in a much more elegant and future-proof : manner using sbufs. Just be careful that your dynamic string growing things don't violate the hard limit invariants in the kernel. If it produces paths longer than 1023 characters, for example, it is wrong. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200012121825.LAA31285>