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!

[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.

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] potential dereference of user pointer errors

[Chris Wright]

* Jan Kasprzak (kas@informatics.muni.cz) wrote:
> Chris Wright wrote:
> : Both cosa_readmem and cosa_download don't seem to do any validation of
> : the user supplied ptr at all before dereferncing it in get_user.  And
> : it'd make sense to use 'code' in cosa_reamdme (as in cosa_download)
> : instead of 'd->code'.  Jan, does this look OK?
> 
> 	Yes, you are right. I've missed this. However, it is not
> as bad as it looks like, because you need the CAP_SYS_RAWIO to
> exploit this. I agree this patch should be applied.

Thanks for the confirmation.
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

[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

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