Date: Fri, 17 May 1996 13:58:05 -0400 (EDT) From: "Charles C. Figueiredo" <marxx@apocalypse.superlink.net> To: freebsd-current@freebsd.org Subject: Mount Security Problem. Message-ID: <Pine.BSF.3.91.960517135737.403C-200000@apocalypse.superlink.net>
index | next in thread | raw e-mail
[-- Attachment #1 --]
"I don't want to grow up, I'm a BSD kid. There's so many toys in /usr/bin
that I can play with!"
------------------------------------------------------------------------------
Charles C. Figueiredo Marxx marxx@superlink.net
------------------------------------------------------------------------------
[-- Attachment #2 --]
This is a classic example of people not being very security aware while coding.
The problem lies with the fact that a bit of setuid code, is executing virtual file system modules
in a very insecure manor. This is beyond just mount_union.
Here's the critical bit of mount_union:
---------(Cut Here)----------------------------
struct vfsconf *vfc;
vfc = getvfsbyname("union");
if(!vfc && vfsisloadable("union")) {
if(vfsload("union"))
err(1, "vfsload(union)");
endvfsent(); /* flush cache */
vfc = getvfsbyname("union");
----------(Cut Here)---------------------------
Any software, using vfs routines like this, while simultaneously being setuid, runs the risk of
these simple IFS, $PATH, and system() type hacks. Man getvfsbyname(3), and by all means, read the code.
I'll bet somewhere inside the vfs module management routines, an execl() or execv() exists
for modload, I perpose two options:
1 - mount should not call vfsload() if getuid() != geteuid().
2 - Fix the way vfs routines designate hardcoded directories for LKMs.
The environment variable LKMDIR might also present problems in the future.
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.91.960517135737.403C-200000>