Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 28 Sep 2009 00:08:17 +0100 (BST)
From:      Robert Watson <rwatson@FreeBSD.org>
To:        Julian Elischer <julian@elischer.org>
Cc:        svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, "Simon L. Nielsen" <simon@FreeBSD.org>
Subject:   Re: svn commit: r197537 - head/sys/vm
Message-ID:  <alpine.BSF.2.00.0909280006140.1694@fledge.watson.org>
In-Reply-To: <4ABFB4D1.5070505@elischer.org>
References:  <200909271449.n8REnpUX027608@svn.freebsd.org> <4ABFB4D1.5070505@elischer.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 27 Sep 2009, Julian Elischer wrote:

>>   Do not allow mmap with the MAP_FIXED argument to map at address zero.
>>   This is done to make it harder to exploit kernel NULL pointer security
>>   vulnerabilities.  While this of course does not fix vulnerabilities,
>>   it does mitigate their impact.
>>     Note that this may break some applications, most likely emulators or
>>   similar, which for one reason or another require mapping memory at
>>   zero.
>
> If you are going to take this approach then it shuel be enabled by a bit in 
> the inherrited process permissions, with a toll to set it, like:
>
> map0 {command}
> where command could be something like "wine".
> use setfib or nice as a template for the tool.
>
> this way only processes that need it are affected.

I think the real question is whether or not any applications we actually care 
about are affected.  If it turns out they are and we need to do something 
special, we can do that, but otherwise perhaps we can just quietly deprecate 
support for mapping at 0x0 and be done with it.

One of my todo list items for 9.x is to implement fine-grained privileges, so 
a reasonable approach to making it flexible/fine-grained is simply to make 
mapping at 0x0 another of those privileges.  Of course, that was a goal for 
8.x and didn't happen, so... :-)

Robert


>
>
>>     This restriction can be disabled with the security.bsd.mmap_zero
>>   sysctl variable.
>>     Discussed with:	rwatson, bz
>>   Tested by:	bz (Wine), simon (VirtualBox)
>>   Submitted by:	jhb
>> 
>> Modified:
>>   head/sys/vm/vm_mmap.c
>> 
>> Modified: head/sys/vm/vm_mmap.c
>> ==============================================================================
>> --- head/sys/vm/vm_mmap.c	Sun Sep 27 14:00:16 2009	(r197536)
>> +++ head/sys/vm/vm_mmap.c	Sun Sep 27 14:49:51 2009	(r197537)
>> @@ -97,6 +97,14 @@ SYSCTL_INT(_vm, OID_AUTO, max_proc_mmap,
>>      "Maximum number of memory-mapped files per process");
>>   /*
>> + * 'mmap_zero' determines whether or not MAP_FIXED mmap() requests for
>> + * virtual address zero are permitted.
>> + */
>> +static int mmap_zero;
>> +SYSCTL_INT(_security_bsd, OID_AUTO, mmap_zero, CTLFLAG_RW, &mmap_zero, 0,
>> +    "Processes may map an object at virtual address zero");
>> +
>> +/*
>>   * Set the maximum number of vm_map_entry structures per process.  Roughly
>>   * speaking vm_map_entry structures are tiny, so allowing them to eat 
>> 1/100
>>   * of our KVM malloc space still results in generous limits.  We want a
>> @@ -229,7 +237,8 @@ mmap(td, uap)
>>  	pos = uap->pos;
>>   	fp = NULL;
>> -	/* make sure mapping fits into numeric range etc */
>> +
>> +	/* Make sure mapping fits into numeric range, etc. */
>>  	if ((uap->len == 0 && !SV_CURPROC_FLAG(SV_AOUT) &&
>>  	     curproc->p_osrel >= 800104) ||
>>  	    ((flags & MAP_ANON) && uap->fd != -1))
>> @@ -267,6 +276,14 @@ mmap(td, uap)
>>  		addr -= pageoff;
>>  		if (addr & PAGE_MASK)
>>  			return (EINVAL);
>> +
>> +		/*
>> +		 * Mapping to address zero is only permitted if
>> +		 * mmap_zero is enabled.
>> +		 */
>> +		if (addr == 0 && !mmap_zero)
>> +			return (EINVAL);
>> +
>>  		/* Address range must be all in user VM space. */
>>  		if (addr < vm_map_min(&vms->vm_map) ||
>>  		    addr + size > vm_map_max(&vms->vm_map))
>
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.0909280006140.1694>