2020-11-18 19:44:30 +00:00
|
|
|
.\"
|
|
|
|
|
.\" SPDX-License-Identifier: BSD-2-Clause-FreeBSD
|
|
|
|
|
.\"
|
|
|
|
|
.\" Copyright 2020 Scott Long
|
|
|
|
|
.\" Copyright 2020 Stefan Eßer
|
|
|
|
|
.\"
|
|
|
|
|
.\" Redistribution and use in source and binary forms, with or without
|
|
|
|
|
.\" modification, are permitted provided that the following conditions
|
|
|
|
|
.\" are met:
|
|
|
|
|
.\" 1. Redistributions of source code must retain the above copyright
|
|
|
|
|
.\" notice, this list of conditions and the following disclaimer.
|
|
|
|
|
.\" 2. Redistributions in binary form must reproduce the above copyright
|
|
|
|
|
.\" notice, this list of conditions and the following disclaimer in the
|
|
|
|
|
.\" documentation and/or other materials provided with the distribution.
|
|
|
|
|
.\"
|
|
|
|
|
.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
|
|
|
|
|
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
|
|
|
|
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
|
|
|
|
|
.\" ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
|
|
|
|
|
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
|
|
|
|
|
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
|
|
|
|
|
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
|
|
|
|
|
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
|
|
|
|
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
|
|
|
|
|
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
|
|
|
|
|
.\" SUCH DAMAGE.
|
|
|
|
|
.\"
|
|
|
|
|
.\" $FreeBSD$
|
|
|
|
|
.\"
|
Change getlocalbase() to not allocate any heap memory
After the commit of the current version, Scott Long pointed out, that an
attacker might be able to cause a use-after-free access if this function
returned the value of the sysctl variable "user.localbase" by freeing
the allocated memory without the cached address being cleared in the
library function.
To resolve this issue, I have proposed the originally suggested version
with a statically allocated buffer in a review (D27370). There was no
feedback on this review and after waiting for more than 2 weeks, the
potential security issue is fixed by this commit. (There was no security
risk in practice, since none of the programs converted to use this
function attempted to free the buffer. The address could only have
pointed into the heap if user.localbase was set to a non-default value,
into r/o data or the environment, else.)
This version uses a static buffer of size LOCALBASE_CTL_LEN, which
defaults to MAXPATHLEN. This does not increase the memory footprint
of the library at this time, since its data segment grows from less
than 7 KB to less than 8 KB, i.e. it will get two 4 KB pages on typical
architectures, anyway.
Compiling with LOCALBASE_CTL_LEN defined as 0 will remove the code
that accesses the sysctl variable, values between 1 and MAXPATHLEN-1
will limit the maximum size of the prefix. When built with such a
value and if too large a value has been configured in user.localbase,
the value defined as ILLEGAL_PREFIX will be returned to cause any
file operations on that result to fail. (Default value is "/dev/null/",
the review contained "/\177", but I assume that "/dev/null" exists and
can not be accessed as a directory. Any other string that can be assumed
not be a valid path prefix could be used.)
I do suggest to use LOCALBASE_CTL_LEN to size the in-kernel buffer for
the user.localbase variable, too. Doing this would guarantee that the
result always fit into the buffer in this library function (unless run
on a kernel built with a different buffer size.)
The function always returns a valid string, and only in case it is built
with a small static buffer and run on a system with too large a value in
user.localbase, the ILLEGAL_PREFIX will be returned, effectively causing
the created path to be non-existent.
Differential Revision: https://reviews.freebsd.org/D27370
2020-12-12 11:23:52 +00:00
|
|
|
.Dd November 25, 2020
|
2020-11-18 19:44:30 +00:00
|
|
|
.Dt GETLOCALBASE 3
|
|
|
|
|
.Os
|
|
|
|
|
.Sh NAME
|
|
|
|
|
.Nm getlocalbase
|
|
|
|
|
.Nd "return the path to the local software directory"
|
|
|
|
|
.Sh LIBRARY
|
|
|
|
|
.Lb libutil
|
|
|
|
|
.Sh SYNOPSIS
|
|
|
|
|
.In libutil.h
|
|
|
|
|
.Ft const char*
|
|
|
|
|
.Fn getlocalbase "void"
|
|
|
|
|
.Sh DESCRIPTION
|
|
|
|
|
The
|
|
|
|
|
.Fn getlocalbase
|
|
|
|
|
function returns the path to the local software base directory.
|
|
|
|
|
Normally this is the
|
|
|
|
|
.Pa /usr/local
|
|
|
|
|
directory.
|
|
|
|
|
First the
|
|
|
|
|
.Ev LOCALBASE
|
|
|
|
|
environment variable is checked.
|
|
|
|
|
If that does not exist then the
|
|
|
|
|
.Va user.localbase
|
|
|
|
|
sysctl is checked.
|
|
|
|
|
If that also does not exist then the value of the
|
|
|
|
|
.Dv _PATH_LOCALBASE
|
|
|
|
|
compile-time variable is used.
|
|
|
|
|
If that is undefined then the default of
|
|
|
|
|
.Pa /usr/local
|
|
|
|
|
is used.
|
|
|
|
|
.Pp
|
Change getlocalbase() to not allocate any heap memory
After the commit of the current version, Scott Long pointed out, that an
attacker might be able to cause a use-after-free access if this function
returned the value of the sysctl variable "user.localbase" by freeing
the allocated memory without the cached address being cleared in the
library function.
To resolve this issue, I have proposed the originally suggested version
with a statically allocated buffer in a review (D27370). There was no
feedback on this review and after waiting for more than 2 weeks, the
potential security issue is fixed by this commit. (There was no security
risk in practice, since none of the programs converted to use this
function attempted to free the buffer. The address could only have
pointed into the heap if user.localbase was set to a non-default value,
into r/o data or the environment, else.)
This version uses a static buffer of size LOCALBASE_CTL_LEN, which
defaults to MAXPATHLEN. This does not increase the memory footprint
of the library at this time, since its data segment grows from less
than 7 KB to less than 8 KB, i.e. it will get two 4 KB pages on typical
architectures, anyway.
Compiling with LOCALBASE_CTL_LEN defined as 0 will remove the code
that accesses the sysctl variable, values between 1 and MAXPATHLEN-1
will limit the maximum size of the prefix. When built with such a
value and if too large a value has been configured in user.localbase,
the value defined as ILLEGAL_PREFIX will be returned to cause any
file operations on that result to fail. (Default value is "/dev/null/",
the review contained "/\177", but I assume that "/dev/null" exists and
can not be accessed as a directory. Any other string that can be assumed
not be a valid path prefix could be used.)
I do suggest to use LOCALBASE_CTL_LEN to size the in-kernel buffer for
the user.localbase variable, too. Doing this would guarantee that the
result always fit into the buffer in this library function (unless run
on a kernel built with a different buffer size.)
The function always returns a valid string, and only in case it is built
with a small static buffer and run on a system with too large a value in
user.localbase, the ILLEGAL_PREFIX will be returned, effectively causing
the created path to be non-existent.
Differential Revision: https://reviews.freebsd.org/D27370
2020-12-12 11:23:52 +00:00
|
|
|
The contents of the string returned by the
|
2020-11-18 19:44:30 +00:00
|
|
|
.Fn getlocalbase
|
|
|
|
|
function shall not be modified.
|
|
|
|
|
.Sh IMPLEMENTATION NOTES
|
|
|
|
|
Calls to
|
|
|
|
|
.Fn getlocalbase
|
|
|
|
|
will perform a setugid check on the running binary before checking the
|
|
|
|
|
environment.
|
Change getlocalbase() to not allocate any heap memory
After the commit of the current version, Scott Long pointed out, that an
attacker might be able to cause a use-after-free access if this function
returned the value of the sysctl variable "user.localbase" by freeing
the allocated memory without the cached address being cleared in the
library function.
To resolve this issue, I have proposed the originally suggested version
with a statically allocated buffer in a review (D27370). There was no
feedback on this review and after waiting for more than 2 weeks, the
potential security issue is fixed by this commit. (There was no security
risk in practice, since none of the programs converted to use this
function attempted to free the buffer. The address could only have
pointed into the heap if user.localbase was set to a non-default value,
into r/o data or the environment, else.)
This version uses a static buffer of size LOCALBASE_CTL_LEN, which
defaults to MAXPATHLEN. This does not increase the memory footprint
of the library at this time, since its data segment grows from less
than 7 KB to less than 8 KB, i.e. it will get two 4 KB pages on typical
architectures, anyway.
Compiling with LOCALBASE_CTL_LEN defined as 0 will remove the code
that accesses the sysctl variable, values between 1 and MAXPATHLEN-1
will limit the maximum size of the prefix. When built with such a
value and if too large a value has been configured in user.localbase,
the value defined as ILLEGAL_PREFIX will be returned to cause any
file operations on that result to fail. (Default value is "/dev/null/",
the review contained "/\177", but I assume that "/dev/null" exists and
can not be accessed as a directory. Any other string that can be assumed
not be a valid path prefix could be used.)
I do suggest to use LOCALBASE_CTL_LEN to size the in-kernel buffer for
the user.localbase variable, too. Doing this would guarantee that the
result always fit into the buffer in this library function (unless run
on a kernel built with a different buffer size.)
The function always returns a valid string, and only in case it is built
with a small static buffer and run on a system with too large a value in
user.localbase, the ILLEGAL_PREFIX will be returned, effectively causing
the created path to be non-existent.
Differential Revision: https://reviews.freebsd.org/D27370
2020-12-12 11:23:52 +00:00
|
|
|
.Pp
|
|
|
|
|
The address returned by
|
|
|
|
|
.Fn getlocalbase
|
|
|
|
|
will point into the executing processes environment if it is the result of
|
|
|
|
|
.Fn getenv "LOCALBASE" ,
|
|
|
|
|
to a static buffer if it is the result of
|
|
|
|
|
.Fn sysctl "user.localbase" ,
|
|
|
|
|
and to a constant string if the compiled in default value is returned.
|
|
|
|
|
.Pp
|
|
|
|
|
The same value will be returned on successive calls during the run-time
|
|
|
|
|
of the program, ignoring any changes to the environment variable or the
|
|
|
|
|
sysctl value that might have been made.
|
|
|
|
|
.Pp
|
|
|
|
|
The
|
|
|
|
|
.Fn getlocalbase
|
|
|
|
|
function can be compiled with a non-default value of LOCALBASE_CTL_LEN.
|
|
|
|
|
A value of 0 will disable fetching of the sysctl value, a value less than
|
|
|
|
|
MAXPATHLEN will put a limit on the maximum string length supported for
|
|
|
|
|
this sysctl value.
|
|
|
|
|
If built with a non-default value of LOCALBASE_CTL_LEN, a value of the
|
|
|
|
|
user.localbase sysctl variable longer than this value will make
|
|
|
|
|
.Fn getlocalbase
|
|
|
|
|
return a valid string that is not a valid path prefix in any filesystem.
|
2020-11-18 19:44:30 +00:00
|
|
|
.Sh RETURN VALUES
|
|
|
|
|
The
|
|
|
|
|
.Fn getlocalbase
|
Change getlocalbase() to not allocate any heap memory
After the commit of the current version, Scott Long pointed out, that an
attacker might be able to cause a use-after-free access if this function
returned the value of the sysctl variable "user.localbase" by freeing
the allocated memory without the cached address being cleared in the
library function.
To resolve this issue, I have proposed the originally suggested version
with a statically allocated buffer in a review (D27370). There was no
feedback on this review and after waiting for more than 2 weeks, the
potential security issue is fixed by this commit. (There was no security
risk in practice, since none of the programs converted to use this
function attempted to free the buffer. The address could only have
pointed into the heap if user.localbase was set to a non-default value,
into r/o data or the environment, else.)
This version uses a static buffer of size LOCALBASE_CTL_LEN, which
defaults to MAXPATHLEN. This does not increase the memory footprint
of the library at this time, since its data segment grows from less
than 7 KB to less than 8 KB, i.e. it will get two 4 KB pages on typical
architectures, anyway.
Compiling with LOCALBASE_CTL_LEN defined as 0 will remove the code
that accesses the sysctl variable, values between 1 and MAXPATHLEN-1
will limit the maximum size of the prefix. When built with such a
value and if too large a value has been configured in user.localbase,
the value defined as ILLEGAL_PREFIX will be returned to cause any
file operations on that result to fail. (Default value is "/dev/null/",
the review contained "/\177", but I assume that "/dev/null" exists and
can not be accessed as a directory. Any other string that can be assumed
not be a valid path prefix could be used.)
I do suggest to use LOCALBASE_CTL_LEN to size the in-kernel buffer for
the user.localbase variable, too. Doing this would guarantee that the
result always fit into the buffer in this library function (unless run
on a kernel built with a different buffer size.)
The function always returns a valid string, and only in case it is built
with a small static buffer and run on a system with too large a value in
user.localbase, the ILLEGAL_PREFIX will be returned, effectively causing
the created path to be non-existent.
Differential Revision: https://reviews.freebsd.org/D27370
2020-12-12 11:23:52 +00:00
|
|
|
function returns a pointer to a string, whose length may exceed MAXPATHLEN,
|
|
|
|
|
if it has been obtained from the environment.
|
2020-11-18 19:44:30 +00:00
|
|
|
.Sh ENVIRONMENT
|
|
|
|
|
The
|
|
|
|
|
.Fn getlocalbase
|
|
|
|
|
library function retrieves the
|
|
|
|
|
.Ev LOCALBASE
|
|
|
|
|
environment variable.
|
|
|
|
|
.Sh ERRORS
|
|
|
|
|
The
|
|
|
|
|
.Fn getlocalbase
|
Change getlocalbase() to not allocate any heap memory
After the commit of the current version, Scott Long pointed out, that an
attacker might be able to cause a use-after-free access if this function
returned the value of the sysctl variable "user.localbase" by freeing
the allocated memory without the cached address being cleared in the
library function.
To resolve this issue, I have proposed the originally suggested version
with a statically allocated buffer in a review (D27370). There was no
feedback on this review and after waiting for more than 2 weeks, the
potential security issue is fixed by this commit. (There was no security
risk in practice, since none of the programs converted to use this
function attempted to free the buffer. The address could only have
pointed into the heap if user.localbase was set to a non-default value,
into r/o data or the environment, else.)
This version uses a static buffer of size LOCALBASE_CTL_LEN, which
defaults to MAXPATHLEN. This does not increase the memory footprint
of the library at this time, since its data segment grows from less
than 7 KB to less than 8 KB, i.e. it will get two 4 KB pages on typical
architectures, anyway.
Compiling with LOCALBASE_CTL_LEN defined as 0 will remove the code
that accesses the sysctl variable, values between 1 and MAXPATHLEN-1
will limit the maximum size of the prefix. When built with such a
value and if too large a value has been configured in user.localbase,
the value defined as ILLEGAL_PREFIX will be returned to cause any
file operations on that result to fail. (Default value is "/dev/null/",
the review contained "/\177", but I assume that "/dev/null" exists and
can not be accessed as a directory. Any other string that can be assumed
not be a valid path prefix could be used.)
I do suggest to use LOCALBASE_CTL_LEN to size the in-kernel buffer for
the user.localbase variable, too. Doing this would guarantee that the
result always fit into the buffer in this library function (unless run
on a kernel built with a different buffer size.)
The function always returns a valid string, and only in case it is built
with a small static buffer and run on a system with too large a value in
user.localbase, the ILLEGAL_PREFIX will be returned, effectively causing
the created path to be non-existent.
Differential Revision: https://reviews.freebsd.org/D27370
2020-12-12 11:23:52 +00:00
|
|
|
function always succeeds and returns a valid pointer to a string.
|
2020-11-18 19:44:30 +00:00
|
|
|
.Sh SEE ALSO
|
|
|
|
|
.Xr env 1 ,
|
|
|
|
|
.Xr src.conf 5 ,
|
|
|
|
|
.Xr sysctl 8
|
|
|
|
|
.Sh HISTORY
|
|
|
|
|
The
|
|
|
|
|
.Nm
|
|
|
|
|
library function first appeared in
|
|
|
|
|
.Fx 13.0 .
|
|
|
|
|
.Sh AUTHORS
|
|
|
|
|
This
|
|
|
|
|
manual page was written by
|
|
|
|
|
.An Scott Long Aq Mt scottl@FreeBSD.org and Stefan Eßer Aq Mt se@FreeBSD.org .
|