Re: [CHECKER] Help Needed!

Re: [CHECKER] Help Needed!

[Andi Kleen]

Manfred Spraul <manfred@colorfullife.com> writes:
 
> P.S.: On i386, you can access both kernel and user space after
> set_fs(KERNEL_DS), or if you use __get_user() and bypass
> access_ok(). Thus the __get_user() in arch/i386/kernel/traps.c,
> function show_registers is correct. This is the only instance I'm
> aware of where this is used, and noone else should be doing that. It
> fails on other archs, e.g. on sparc.

It is used in a couple more of places in the x86-64 architecture specific
code. Of course it is legal there too.

Also there are some corner cases; e.g. some architecture specific
code (particularly the 32bit emulations) just does access_ok or 
get_user/put_user (with implied access_ok) on the first element 
of a structure and then accesses the other elements with __*_user.
This works because these architectures have an unmapped hole at the 
end of the user address space.

But in most other cases (in general outside arch/) it is very likely
a bug and a security hole.

-Andi

Re: [CHECKER] Help Needed!

[Manfred Spraul]

Andi Kleen wrote:

>Manfred Spraul <manfred@colorfullife.com> writes:
> 
>  
>
>>P.S.: On i386, you can access both kernel and user space after
>>set_fs(KERNEL_DS), or if you use __get_user() and bypass
>>access_ok(). Thus the __get_user() in arch/i386/kernel/traps.c,
>>function show_registers is correct. This is the only instance I'm
>>aware of where this is used, and noone else should be doing that. It
>>fails on other archs, e.g. on sparc.
>>    
>>
>
>It is used in a couple more of places in the x86-64 architecture specific
>code. Of course it is legal there too.
>
>Also there are some corner cases; e.g. some architecture specific
>code (particularly the 32bit emulations) just does access_ok or 
>get_user/put_user (with implied access_ok) on the first element 
>of a structure and then accesses the other elements with __*_user.
>This works because these architectures have an unmapped hole at the 
>end of the user address space.
>  
>
This is different bug:
- bug 1 is access user space without the functions from <asm/uaccess.h>, 
or access user space after set_fs(KERNEL_DS), or access kernel space 
without set_fs(KERNEL_DS).
- bug 2 is not enough access_ok() calls, e.g. __put_user without a 
preceeding access_ok() check, either explicit or implicit due to an 
copy_from_user().

--
    Manfred

Re: [CHECKER] Help Needed!

[Chris Wright]

* Junfeng Yang (yjf@stanford.edu) wrote:
> 
> It seems to us that create_dev can only be called at boot time (the
> "__init" attribute), so devfs_name must be an untainted kernel pointer.
> The warning on line 437 isn't a real error.

Yes.

> However, this pointer is finally passed into strncpy_from_user through the
> call chain [ sys_symlink (devfs_name, name) --> getname (oldname) -->
> do_getname(filename, _) --> strncpy_from_user (_, filename, _)].  Is it
> okay to call *_from_user functions with the second arguements untainted?
> What will access_ok(VERIFY_READ, src, 1) return?

This checks against the current addr_limit which depends on the context.
KERNEL_DS lets this check succeed.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

Re: [CHECKER] Help Needed!

[Junfeng Yang]

Thanks a lot for your explanation! That clarifies everything.

-Junfeng

On Mon, 21 Apr 2003, Manfred Spraul wrote:

> Junfeng wrote:
>
> >It seems to us that create_dev can only be called at boot time (the
> >"__init" attribute), so devfs_name must be an untainted kernel pointer.
> >The warning on line 437 isn't a real error.
> >
> >However, this pointer is finally passed into strncpy_from_user through the
> >call chain [ sys_symlink (devfs_name, name) --> getname (oldname) -->
> >do_getname(filename, _) --> strncpy_from_user (_, filename, _)].  Is it
> >okay to call *_from_user functions with the second arguements untainted?
> >What will access_ok(VERIFY_READ, src, 1) return?
> >
> >
> The copy_{to,from}_user functions can access either user or kernel space.
> after set_fs(KERNEL_DS), they access kernel space, after
> set_fs(USER_DS), they access user space.
>
> The initial boot thread starts with set_fs(KERNEL_DS), and is switched
> back to set_fs(USER_DS) in search_binary_handler (fs/exec.c), called
> during exec of /sbin/init.
>
> --
>     Manfred
>
> P.S.: On i386, you can access both kernel and user space after
> set_fs(KERNEL_DS), or if you use __get_user() and bypass access_ok().
> Thus the __get_user() in arch/i386/kernel/traps.c, function
> show_registers is correct. This is the only instance I'm aware of where
> this is used, and noone else should be doing that. It fails on other
> archs, e.g. on sparc.
>

Re: [CHECKER] Help Needed!

[Manfred Spraul]

Junfeng wrote:

>It seems to us that create_dev can only be called at boot time (the
>"__init" attribute), so devfs_name must be an untainted kernel pointer.
>The warning on line 437 isn't a real error.
>
>However, this pointer is finally passed into strncpy_from_user through the
>call chain [ sys_symlink (devfs_name, name) --> getname (oldname) -->
>do_getname(filename, _) --> strncpy_from_user (_, filename, _)].  Is it
>okay to call *_from_user functions with the second arguements untainted?
>What will access_ok(VERIFY_READ, src, 1) return?
>  
>
The copy_{to,from}_user functions can access either user or kernel space.
after set_fs(KERNEL_DS), they access kernel space, after 
set_fs(USER_DS), they access user space.

The initial boot thread starts with set_fs(KERNEL_DS), and is switched 
back to set_fs(USER_DS) in search_binary_handler (fs/exec.c), called 
during exec of /sbin/init.

--
    Manfred

P.S.: On i386, you can access both kernel and user space after 
set_fs(KERNEL_DS), or if you use __get_user() and bypass access_ok(). 
Thus the __get_user() in arch/i386/kernel/traps.c, function 
show_registers is correct. This is the only instance I'm aware of where 
this is used, and noone else should be doing that. It fails on other 
archs, e.g. on sparc.

[CHECKER] Help Needed!

[Junfeng Yang]

Hi,

We run a checker that warns about derefence of user-pointer errors on
linux-2.5.63 and got the following warning message in
init/do_mounts.c:create_dev, which needs clarifications.

---------------------------------------------------------
/home/junfeng/linux-2.5.63/init/do_mounts.c:437:create_dev: ERROR:TAINTED:442:437:dereferencing tainted ptr 'devfs_name'

	sys_unlink(name);
	if (!do_devfs)
		return sys_mknod(name, S_IFBLK|0600, dev);

Error--->
	if (devfs_name && devfs_name[0]) {
		if (strncmp(devfs_name, "/dev/", 5) == 0)
			devfs_name += 5;
		sprintf(path, "/dev/%s", devfs_name);
		if (sys_access(path, 0) == 0)
Start --->
			return sys_symlink(devfs_name, name);
	}
	if (!dev)
		return -1;


It seems to us that create_dev can only be called at boot time (the
"__init" attribute), so devfs_name must be an untainted kernel pointer.
The warning on line 437 isn't a real error.

However, this pointer is finally passed into strncpy_from_user through the
call chain [ sys_symlink (devfs_name, name) --> getname (oldname) -->
do_getname(filename, _) --> strncpy_from_user (_, filename, _)].  Is it
okay to call *_from_user functions with the second arguements untainted?
What will access_ok(VERIFY_READ, src, 1) return?

As usual, any response will be greatly apppreciated.  Thanks a lot!

-Junfeng