Add ~40 index terms to this chapter. A couple of minor tweaks to
doc.docbook.mk are needed for this to work with GEN_INDEX defined but that will be committed soon enough. Reviewed by: -doc (months ago)
This commit is contained in:
parent
6296820335
commit
acd6619ae0
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=9451
2 changed files with 214 additions and 2 deletions
en_US.ISO8859-1/books/developers-handbook/secure
en_US.ISO_8859-1/books/developers-handbook/secure
|
@ -1,7 +1,7 @@
|
||||||
<!--
|
<!--
|
||||||
The FreeBSD Documentation Project
|
The FreeBSD Documentation Project
|
||||||
|
|
||||||
$FreeBSD: doc/en_US.ISO_8859-1/books/developers-handbook/secure/chapter.sgml,v 1.3 2001/04/18 19:33:27 dd Exp $
|
$FreeBSD: doc/en_US.ISO_8859-1/books/developers-handbook/secure/chapter.sgml,v 1.4 2001/05/14 03:15:19 murray Exp $
|
||||||
-->
|
-->
|
||||||
|
|
||||||
<chapter id="secure">
|
<chapter id="secure">
|
||||||
|
@ -40,26 +40,61 @@
|
||||||
|
|
||||||
<para>Buffer Overflows have been around since the very
|
<para>Buffer Overflows have been around since the very
|
||||||
beginnings of the Von-Neuman <xref linkend="COD"> architecture.
|
beginnings of the Von-Neuman <xref linkend="COD"> architecture.
|
||||||
|
|
||||||
|
<indexterm><primary>buffer overflow</primary></indexterm>
|
||||||
|
<indexterm><primary>Von-Neuman</primary></indexterm>
|
||||||
|
|
||||||
They first gained widespread notoriety in 1988 with the Morris
|
They first gained widespread notoriety in 1988 with the Morris
|
||||||
Internet worm. Unfortunately, the same basic attack remains
|
Internet worm. Unfortunately, the same basic attack remains
|
||||||
|
|
||||||
|
<indexterm><primary>Morris Internet worm</primary></indexterm>
|
||||||
|
|
||||||
effective today. Of the 17 CERT security advisories of 1999, 10
|
effective today. Of the 17 CERT security advisories of 1999, 10
|
||||||
|
|
||||||
|
<indexterm>
|
||||||
|
<primary>CERT</primary><secondary>security advisories</secondary>
|
||||||
|
</indexterm>
|
||||||
|
|
||||||
of them were directly caused by buffer-overflow software bugs.
|
of them were directly caused by buffer-overflow software bugs.
|
||||||
By far the most common type of buffer overflow attack is based
|
By far the most common type of buffer overflow attack is based
|
||||||
on corrupting the stack.</para>
|
on corrupting the stack.</para>
|
||||||
|
|
||||||
|
<indexterm><primary>stack</primary></indexterm>
|
||||||
|
<indexterm><primary>arguments</primary></indexterm>
|
||||||
|
|
||||||
<para>Most modern computer systems use a stack to pass arguments
|
<para>Most modern computer systems use a stack to pass arguments
|
||||||
to procedures and to store local variables. A stack is a last
|
to procedures and to store local variables. A stack is a last
|
||||||
in first out (LIFO) buffer in the high memory area of a process
|
in first out (LIFO) buffer in the high memory area of a process
|
||||||
image. When a program invokes a function a new "stack frame" is
|
image. When a program invokes a function a new "stack frame" is
|
||||||
|
|
||||||
|
<indexterm><primary>LIFO</primary></indexterm>
|
||||||
|
<indexterm>
|
||||||
|
<primary>process image</primary>
|
||||||
|
<secondary>stack pointer</secondary>
|
||||||
|
</indexterm>
|
||||||
|
|
||||||
created. This stack frame consists of the arguments passed to
|
created. This stack frame consists of the arguments passed to
|
||||||
the function as well as a dynamic amount of local variable
|
the function as well as a dynamic amount of local variable
|
||||||
space. The "stack pointer" is a register that holds the current
|
space. The "stack pointer" is a register that holds the current
|
||||||
|
|
||||||
|
<indexterm><primary>stack frame</primary></indexterm>
|
||||||
|
<indexterm><primary>stack pointer</primary></indexterm>
|
||||||
|
|
||||||
location of the top of the stack. Since this value is
|
location of the top of the stack. Since this value is
|
||||||
constantly changing as new values are pushed onto the top of the
|
constantly changing as new values are pushed onto the top of the
|
||||||
stack, many implementations also provide a "frame pointer" that
|
stack, many implementations also provide a "frame pointer" that
|
||||||
is located near the beginning of a stack frame so that local
|
is located near the beginning of a stack frame so that local
|
||||||
variables can more easily be addressed relative to this
|
variables can more easily be addressed relative to this
|
||||||
value. <xref linkend="COD"> The return address for function
|
value. <xref linkend="COD"> The return address for function
|
||||||
|
|
||||||
|
<indexterm><primary>frame pointer</primary></indexterm>
|
||||||
|
<indexterm>
|
||||||
|
<primary>process image</primary>
|
||||||
|
<secondary>frame pointer</secondary>
|
||||||
|
</indexterm>
|
||||||
|
<indexterm><primary>return address</primary></indexterm>
|
||||||
|
<indexterm><primary>stack-overflow</primary></indexterm>
|
||||||
|
|
||||||
calls is also stored on the stack, and this is the cause of
|
calls is also stored on the stack, and this is the cause of
|
||||||
stack-overflow exploits since overflowing a local variable in a
|
stack-overflow exploits since overflowing a local variable in a
|
||||||
function can overwrite the return address of that function,
|
function can overwrite the return address of that function,
|
||||||
|
@ -157,12 +192,25 @@ int main() {
|
||||||
stack-overflows is to always use length restricted memory and
|
stack-overflows is to always use length restricted memory and
|
||||||
string copy functions. <function>strncpy</function> and
|
string copy functions. <function>strncpy</function> and
|
||||||
<function>strncat</function> are part of the standard C library.
|
<function>strncat</function> are part of the standard C library.
|
||||||
|
|
||||||
|
<indexterm>
|
||||||
|
<primary>string copy functions</primary>
|
||||||
|
<secondary>strncpy</secondary>
|
||||||
|
</indexterm>
|
||||||
|
<indexterm>
|
||||||
|
<primary>string copy functions</primary>
|
||||||
|
<secondary>strncat</secondary>
|
||||||
|
</indexterm>
|
||||||
|
|
||||||
These functions accept a length value as a parameter which
|
These functions accept a length value as a parameter which
|
||||||
should be no larger than the size of the destination buffer.
|
should be no larger than the size of the destination buffer.
|
||||||
These functions will then copy up to `length' bytes from the
|
These functions will then copy up to `length' bytes from the
|
||||||
source to the destination. However there are a number of
|
source to the destination. However there are a number of
|
||||||
problems with these functions. Neither function guarantees NUL
|
problems with these functions. Neither function guarantees NUL
|
||||||
termination if the size of the input buffer is as large as the
|
termination if the size of the input buffer is as large as the
|
||||||
|
|
||||||
|
<indexterm><primary>NUL termination</primary></indexterm>
|
||||||
|
|
||||||
destination. The length parameter is also used inconsistently
|
destination. The length parameter is also used inconsistently
|
||||||
between strncpy and strncat so it is easy for programmers to get
|
between strncpy and strncat so it is easy for programmers to get
|
||||||
confused as to their proper usage. There is also a significant
|
confused as to their proper usage. There is also a significant
|
||||||
|
@ -172,6 +220,9 @@ int main() {
|
||||||
specified.</para>
|
specified.</para>
|
||||||
|
|
||||||
<para>In OpenBSD, another memory copy implementation has been
|
<para>In OpenBSD, another memory copy implementation has been
|
||||||
|
|
||||||
|
<indexterm><primary>OpenBSD</primary></indexterm>
|
||||||
|
|
||||||
created to get around these problem. The
|
created to get around these problem. The
|
||||||
<function>strlcpy</function> and <function>strlcat</function>
|
<function>strlcpy</function> and <function>strlcat</function>
|
||||||
functions guarantee that they will always null terminate the
|
functions guarantee that they will always null terminate the
|
||||||
|
@ -181,8 +232,21 @@ int main() {
|
||||||
<function>strlcat</function> instructions have been in FreeBSD
|
<function>strlcat</function> instructions have been in FreeBSD
|
||||||
since 3.5.</para>
|
since 3.5.</para>
|
||||||
|
|
||||||
|
<indexterm>
|
||||||
|
<primary>string copy functions</primary>
|
||||||
|
<secondary>strlcpy</secondary>
|
||||||
|
</indexterm>
|
||||||
|
|
||||||
|
<indexterm>
|
||||||
|
<primary>string copy functions</primary>
|
||||||
|
<secondary>strlcat</secondary>
|
||||||
|
</indexterm>
|
||||||
|
|
||||||
<sect3><title>Compiler based run-time bounds checking</title>
|
<sect3><title>Compiler based run-time bounds checking</title>
|
||||||
|
|
||||||
|
<indexterm><primary>bounds checking</primary>
|
||||||
|
<secondary>compiler-based</secondary></indexterm>
|
||||||
|
|
||||||
<para>Unfortunately there is still a very large assortment of
|
<para>Unfortunately there is still a very large assortment of
|
||||||
code in public use which blindly copies memory around without
|
code in public use which blindly copies memory around without
|
||||||
using any of the bounded copy routines we just discussed.
|
using any of the bounded copy routines we just discussed.
|
||||||
|
@ -190,6 +254,9 @@ int main() {
|
||||||
add-ons and libraries exist to do Run-time bounds checking in
|
add-ons and libraries exist to do Run-time bounds checking in
|
||||||
C/C++.</para>
|
C/C++.</para>
|
||||||
|
|
||||||
|
<indexterm><primary>StackGuard</primary></indexterm>
|
||||||
|
<indexterm><primary>gcc</primary></indexterm>
|
||||||
|
|
||||||
<para>StackGuard is one such add-on that is implemented as a
|
<para>StackGuard is one such add-on that is implemented as a
|
||||||
small patch to the gcc code generator. From the StackGuard
|
small patch to the gcc code generator. From the StackGuard
|
||||||
website, http://immunix.org/stackguard.html :
|
website, http://immunix.org/stackguard.html :
|
||||||
|
@ -212,6 +279,8 @@ int main() {
|
||||||
returns."</para></blockquote>
|
returns."</para></blockquote>
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
|
<indexterm><primary>buffer overflow</primary></indexterm>
|
||||||
|
|
||||||
<para>Recompiling your application with StackGuard is an
|
<para>Recompiling your application with StackGuard is an
|
||||||
effective means of stopping most buffer-overflow attacks, but
|
effective means of stopping most buffer-overflow attacks, but
|
||||||
it can still be compromised.</para>
|
it can still be compromised.</para>
|
||||||
|
@ -220,6 +289,11 @@ int main() {
|
||||||
|
|
||||||
<sect3><title>Library based run-time bounds checking</title>
|
<sect3><title>Library based run-time bounds checking</title>
|
||||||
|
|
||||||
|
<indexterm>
|
||||||
|
<primary>bounds checking</primary>
|
||||||
|
<secondary>library-based</secondary>
|
||||||
|
</indexterm>
|
||||||
|
|
||||||
<para>Compiler-based mechanisms are completely useless for
|
<para>Compiler-based mechanisms are completely useless for
|
||||||
binary-only software for which you cannot recompile. For
|
binary-only software for which you cannot recompile. For
|
||||||
these situations there are a number of libraries which
|
these situations there are a number of libraries which
|
||||||
|
@ -248,12 +322,23 @@ int main() {
|
||||||
|
|
||||||
<sect1><title>SetUID issues</title>
|
<sect1><title>SetUID issues</title>
|
||||||
|
|
||||||
|
<indexterm><primary>seteuid</primary></indexterm>
|
||||||
|
|
||||||
<para>There are at least 6 different IDs associated with any
|
<para>There are at least 6 different IDs associated with any
|
||||||
given process. Because of this you have to be very careful with
|
given process. Because of this you have to be very careful with
|
||||||
the access that your process has at any given time. In
|
the access that your process has at any given time. In
|
||||||
particular, all seteuid applications should give up their
|
particular, all seteuid applications should give up their
|
||||||
privileges as soon as it is no longer required.</para>
|
privileges as soon as it is no longer required.</para>
|
||||||
|
|
||||||
|
<indexterm>
|
||||||
|
<primary>user IDs</primary>
|
||||||
|
<secondary>real user ID</secondary>
|
||||||
|
</indexterm>
|
||||||
|
<indexterm>
|
||||||
|
<primary>user IDs</primary>
|
||||||
|
<secondary>effective user ID</secondary>
|
||||||
|
</indexterm>
|
||||||
|
|
||||||
<para>The real user ID can only be changed by a superuser
|
<para>The real user ID can only be changed by a superuser
|
||||||
process. The <application>login</application> program sets this
|
process. The <application>login</application> program sets this
|
||||||
when a user initially logs in and it is seldom changed.</para>
|
when a user initially logs in and it is seldom changed.</para>
|
||||||
|
@ -270,6 +355,8 @@ int main() {
|
||||||
|
|
||||||
<sect1 id="chroot"><title>Limiting your program's environment</title>
|
<sect1 id="chroot"><title>Limiting your program's environment</title>
|
||||||
|
|
||||||
|
<indexterm><primary>chroot()</primary></indexterm>
|
||||||
|
|
||||||
<para>The traditional method of restricting access to a process
|
<para>The traditional method of restricting access to a process
|
||||||
is with the <function>chroot()</function> system call. This
|
is with the <function>chroot()</function> system call. This
|
||||||
system call changes the root directory from which all other
|
system call changes the root directory from which all other
|
||||||
|
@ -297,6 +384,8 @@ int main() {
|
||||||
|
|
||||||
<sect2><title>FreeBSD's jail functionality</title>
|
<sect2><title>FreeBSD's jail functionality</title>
|
||||||
|
|
||||||
|
<indexterm><primary>jail</primary></indexterm>
|
||||||
|
|
||||||
<para>The concept of a Jail extends upon the
|
<para>The concept of a Jail extends upon the
|
||||||
<function>chroot()</function> by limiting the powers of the
|
<function>chroot()</function> by limiting the powers of the
|
||||||
superuser to create a true `virtual server'. Once a prison is
|
superuser to create a true `virtual server'. Once a prison is
|
||||||
|
@ -344,6 +433,9 @@ int main() {
|
||||||
|
|
||||||
<sect2><title>POSIX.1e Process Capabilities</title>
|
<sect2><title>POSIX.1e Process Capabilities</title>
|
||||||
|
|
||||||
|
<indexterm><primary>POSIX.1e Process Capabilities</primary></indexterm>
|
||||||
|
<indexterm><primary>TrustedBSD</primary></indexterm>
|
||||||
|
|
||||||
<para>Posix has released a working draft that adds event
|
<para>Posix has released a working draft that adds event
|
||||||
auditing, access control lists, fine grained privileges,
|
auditing, access control lists, fine grained privileges,
|
||||||
information labeling, and mandatory access control.</para>
|
information labeling, and mandatory access control.</para>
|
||||||
|
@ -364,6 +456,9 @@ int main() {
|
||||||
resources, IPC, mmaps, the file system working directory, file
|
resources, IPC, mmaps, the file system working directory, file
|
||||||
descriptors, the # of open files, etc.</para>
|
descriptors, the # of open files, etc.</para>
|
||||||
|
|
||||||
|
<indexterm><primary>positive filtering</primary></indexterm>
|
||||||
|
<indexterm><primary>data validation</primary></indexterm>
|
||||||
|
|
||||||
<para>You should never assume that you can catch all forms of
|
<para>You should never assume that you can catch all forms of
|
||||||
invalid input that a user might supply. Instead, your
|
invalid input that a user might supply. Instead, your
|
||||||
application should use positive filtering to only allow a
|
application should use positive filtering to only allow a
|
||||||
|
@ -373,6 +468,8 @@ int main() {
|
||||||
extra careful about paths ("../", "/"), symbolic links, and
|
extra careful about paths ("../", "/"), symbolic links, and
|
||||||
shell escape characters.</para>
|
shell escape characters.</para>
|
||||||
|
|
||||||
|
<indexterm><primary>Perl Taint mode</primary></indexterm>
|
||||||
|
|
||||||
<para>Perl has a really cool feature called "Taint" mode which
|
<para>Perl has a really cool feature called "Taint" mode which
|
||||||
can be used to prevent scripts for using data derived outside
|
can be used to prevent scripts for using data derived outside
|
||||||
the program in an unsafe way. This mode will check command line
|
the program in an unsafe way. This mode will check command line
|
||||||
|
@ -390,6 +487,15 @@ int main() {
|
||||||
other words, a programmer incorrectly assumed that a particular
|
other words, a programmer incorrectly assumed that a particular
|
||||||
event would always happen before another.</para>
|
event would always happen before another.</para>
|
||||||
|
|
||||||
|
<indexterm><primary>race conditions</primary>
|
||||||
|
<secondary>signals</secondary></indexterm>
|
||||||
|
|
||||||
|
<indexterm><primary>race conditions</primary>
|
||||||
|
<secondary>access checks</secondary></indexterm>
|
||||||
|
|
||||||
|
<indexterm><primary>race conditions</primary>
|
||||||
|
<secondary>file opens</secondary></indexterm>
|
||||||
|
|
||||||
<para>Some of the common causes of race conditions are signals,
|
<para>Some of the common causes of race conditions are signals,
|
||||||
access checks, and file opens. Signals are asynchronous events
|
access checks, and file opens. Signals are asynchronous events
|
||||||
by nature so special care must be taken in dealing with them.
|
by nature so special care must be taken in dealing with them.
|
||||||
|
|
|
@ -1,7 +1,7 @@
|
||||||
<!--
|
<!--
|
||||||
The FreeBSD Documentation Project
|
The FreeBSD Documentation Project
|
||||||
|
|
||||||
$FreeBSD: doc/en_US.ISO_8859-1/books/developers-handbook/secure/chapter.sgml,v 1.3 2001/04/18 19:33:27 dd Exp $
|
$FreeBSD: doc/en_US.ISO_8859-1/books/developers-handbook/secure/chapter.sgml,v 1.4 2001/05/14 03:15:19 murray Exp $
|
||||||
-->
|
-->
|
||||||
|
|
||||||
<chapter id="secure">
|
<chapter id="secure">
|
||||||
|
@ -40,26 +40,61 @@
|
||||||
|
|
||||||
<para>Buffer Overflows have been around since the very
|
<para>Buffer Overflows have been around since the very
|
||||||
beginnings of the Von-Neuman <xref linkend="COD"> architecture.
|
beginnings of the Von-Neuman <xref linkend="COD"> architecture.
|
||||||
|
|
||||||
|
<indexterm><primary>buffer overflow</primary></indexterm>
|
||||||
|
<indexterm><primary>Von-Neuman</primary></indexterm>
|
||||||
|
|
||||||
They first gained widespread notoriety in 1988 with the Morris
|
They first gained widespread notoriety in 1988 with the Morris
|
||||||
Internet worm. Unfortunately, the same basic attack remains
|
Internet worm. Unfortunately, the same basic attack remains
|
||||||
|
|
||||||
|
<indexterm><primary>Morris Internet worm</primary></indexterm>
|
||||||
|
|
||||||
effective today. Of the 17 CERT security advisories of 1999, 10
|
effective today. Of the 17 CERT security advisories of 1999, 10
|
||||||
|
|
||||||
|
<indexterm>
|
||||||
|
<primary>CERT</primary><secondary>security advisories</secondary>
|
||||||
|
</indexterm>
|
||||||
|
|
||||||
of them were directly caused by buffer-overflow software bugs.
|
of them were directly caused by buffer-overflow software bugs.
|
||||||
By far the most common type of buffer overflow attack is based
|
By far the most common type of buffer overflow attack is based
|
||||||
on corrupting the stack.</para>
|
on corrupting the stack.</para>
|
||||||
|
|
||||||
|
<indexterm><primary>stack</primary></indexterm>
|
||||||
|
<indexterm><primary>arguments</primary></indexterm>
|
||||||
|
|
||||||
<para>Most modern computer systems use a stack to pass arguments
|
<para>Most modern computer systems use a stack to pass arguments
|
||||||
to procedures and to store local variables. A stack is a last
|
to procedures and to store local variables. A stack is a last
|
||||||
in first out (LIFO) buffer in the high memory area of a process
|
in first out (LIFO) buffer in the high memory area of a process
|
||||||
image. When a program invokes a function a new "stack frame" is
|
image. When a program invokes a function a new "stack frame" is
|
||||||
|
|
||||||
|
<indexterm><primary>LIFO</primary></indexterm>
|
||||||
|
<indexterm>
|
||||||
|
<primary>process image</primary>
|
||||||
|
<secondary>stack pointer</secondary>
|
||||||
|
</indexterm>
|
||||||
|
|
||||||
created. This stack frame consists of the arguments passed to
|
created. This stack frame consists of the arguments passed to
|
||||||
the function as well as a dynamic amount of local variable
|
the function as well as a dynamic amount of local variable
|
||||||
space. The "stack pointer" is a register that holds the current
|
space. The "stack pointer" is a register that holds the current
|
||||||
|
|
||||||
|
<indexterm><primary>stack frame</primary></indexterm>
|
||||||
|
<indexterm><primary>stack pointer</primary></indexterm>
|
||||||
|
|
||||||
location of the top of the stack. Since this value is
|
location of the top of the stack. Since this value is
|
||||||
constantly changing as new values are pushed onto the top of the
|
constantly changing as new values are pushed onto the top of the
|
||||||
stack, many implementations also provide a "frame pointer" that
|
stack, many implementations also provide a "frame pointer" that
|
||||||
is located near the beginning of a stack frame so that local
|
is located near the beginning of a stack frame so that local
|
||||||
variables can more easily be addressed relative to this
|
variables can more easily be addressed relative to this
|
||||||
value. <xref linkend="COD"> The return address for function
|
value. <xref linkend="COD"> The return address for function
|
||||||
|
|
||||||
|
<indexterm><primary>frame pointer</primary></indexterm>
|
||||||
|
<indexterm>
|
||||||
|
<primary>process image</primary>
|
||||||
|
<secondary>frame pointer</secondary>
|
||||||
|
</indexterm>
|
||||||
|
<indexterm><primary>return address</primary></indexterm>
|
||||||
|
<indexterm><primary>stack-overflow</primary></indexterm>
|
||||||
|
|
||||||
calls is also stored on the stack, and this is the cause of
|
calls is also stored on the stack, and this is the cause of
|
||||||
stack-overflow exploits since overflowing a local variable in a
|
stack-overflow exploits since overflowing a local variable in a
|
||||||
function can overwrite the return address of that function,
|
function can overwrite the return address of that function,
|
||||||
|
@ -157,12 +192,25 @@ int main() {
|
||||||
stack-overflows is to always use length restricted memory and
|
stack-overflows is to always use length restricted memory and
|
||||||
string copy functions. <function>strncpy</function> and
|
string copy functions. <function>strncpy</function> and
|
||||||
<function>strncat</function> are part of the standard C library.
|
<function>strncat</function> are part of the standard C library.
|
||||||
|
|
||||||
|
<indexterm>
|
||||||
|
<primary>string copy functions</primary>
|
||||||
|
<secondary>strncpy</secondary>
|
||||||
|
</indexterm>
|
||||||
|
<indexterm>
|
||||||
|
<primary>string copy functions</primary>
|
||||||
|
<secondary>strncat</secondary>
|
||||||
|
</indexterm>
|
||||||
|
|
||||||
These functions accept a length value as a parameter which
|
These functions accept a length value as a parameter which
|
||||||
should be no larger than the size of the destination buffer.
|
should be no larger than the size of the destination buffer.
|
||||||
These functions will then copy up to `length' bytes from the
|
These functions will then copy up to `length' bytes from the
|
||||||
source to the destination. However there are a number of
|
source to the destination. However there are a number of
|
||||||
problems with these functions. Neither function guarantees NUL
|
problems with these functions. Neither function guarantees NUL
|
||||||
termination if the size of the input buffer is as large as the
|
termination if the size of the input buffer is as large as the
|
||||||
|
|
||||||
|
<indexterm><primary>NUL termination</primary></indexterm>
|
||||||
|
|
||||||
destination. The length parameter is also used inconsistently
|
destination. The length parameter is also used inconsistently
|
||||||
between strncpy and strncat so it is easy for programmers to get
|
between strncpy and strncat so it is easy for programmers to get
|
||||||
confused as to their proper usage. There is also a significant
|
confused as to their proper usage. There is also a significant
|
||||||
|
@ -172,6 +220,9 @@ int main() {
|
||||||
specified.</para>
|
specified.</para>
|
||||||
|
|
||||||
<para>In OpenBSD, another memory copy implementation has been
|
<para>In OpenBSD, another memory copy implementation has been
|
||||||
|
|
||||||
|
<indexterm><primary>OpenBSD</primary></indexterm>
|
||||||
|
|
||||||
created to get around these problem. The
|
created to get around these problem. The
|
||||||
<function>strlcpy</function> and <function>strlcat</function>
|
<function>strlcpy</function> and <function>strlcat</function>
|
||||||
functions guarantee that they will always null terminate the
|
functions guarantee that they will always null terminate the
|
||||||
|
@ -181,8 +232,21 @@ int main() {
|
||||||
<function>strlcat</function> instructions have been in FreeBSD
|
<function>strlcat</function> instructions have been in FreeBSD
|
||||||
since 3.5.</para>
|
since 3.5.</para>
|
||||||
|
|
||||||
|
<indexterm>
|
||||||
|
<primary>string copy functions</primary>
|
||||||
|
<secondary>strlcpy</secondary>
|
||||||
|
</indexterm>
|
||||||
|
|
||||||
|
<indexterm>
|
||||||
|
<primary>string copy functions</primary>
|
||||||
|
<secondary>strlcat</secondary>
|
||||||
|
</indexterm>
|
||||||
|
|
||||||
<sect3><title>Compiler based run-time bounds checking</title>
|
<sect3><title>Compiler based run-time bounds checking</title>
|
||||||
|
|
||||||
|
<indexterm><primary>bounds checking</primary>
|
||||||
|
<secondary>compiler-based</secondary></indexterm>
|
||||||
|
|
||||||
<para>Unfortunately there is still a very large assortment of
|
<para>Unfortunately there is still a very large assortment of
|
||||||
code in public use which blindly copies memory around without
|
code in public use which blindly copies memory around without
|
||||||
using any of the bounded copy routines we just discussed.
|
using any of the bounded copy routines we just discussed.
|
||||||
|
@ -190,6 +254,9 @@ int main() {
|
||||||
add-ons and libraries exist to do Run-time bounds checking in
|
add-ons and libraries exist to do Run-time bounds checking in
|
||||||
C/C++.</para>
|
C/C++.</para>
|
||||||
|
|
||||||
|
<indexterm><primary>StackGuard</primary></indexterm>
|
||||||
|
<indexterm><primary>gcc</primary></indexterm>
|
||||||
|
|
||||||
<para>StackGuard is one such add-on that is implemented as a
|
<para>StackGuard is one such add-on that is implemented as a
|
||||||
small patch to the gcc code generator. From the StackGuard
|
small patch to the gcc code generator. From the StackGuard
|
||||||
website, http://immunix.org/stackguard.html :
|
website, http://immunix.org/stackguard.html :
|
||||||
|
@ -212,6 +279,8 @@ int main() {
|
||||||
returns."</para></blockquote>
|
returns."</para></blockquote>
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
|
<indexterm><primary>buffer overflow</primary></indexterm>
|
||||||
|
|
||||||
<para>Recompiling your application with StackGuard is an
|
<para>Recompiling your application with StackGuard is an
|
||||||
effective means of stopping most buffer-overflow attacks, but
|
effective means of stopping most buffer-overflow attacks, but
|
||||||
it can still be compromised.</para>
|
it can still be compromised.</para>
|
||||||
|
@ -220,6 +289,11 @@ int main() {
|
||||||
|
|
||||||
<sect3><title>Library based run-time bounds checking</title>
|
<sect3><title>Library based run-time bounds checking</title>
|
||||||
|
|
||||||
|
<indexterm>
|
||||||
|
<primary>bounds checking</primary>
|
||||||
|
<secondary>library-based</secondary>
|
||||||
|
</indexterm>
|
||||||
|
|
||||||
<para>Compiler-based mechanisms are completely useless for
|
<para>Compiler-based mechanisms are completely useless for
|
||||||
binary-only software for which you cannot recompile. For
|
binary-only software for which you cannot recompile. For
|
||||||
these situations there are a number of libraries which
|
these situations there are a number of libraries which
|
||||||
|
@ -248,12 +322,23 @@ int main() {
|
||||||
|
|
||||||
<sect1><title>SetUID issues</title>
|
<sect1><title>SetUID issues</title>
|
||||||
|
|
||||||
|
<indexterm><primary>seteuid</primary></indexterm>
|
||||||
|
|
||||||
<para>There are at least 6 different IDs associated with any
|
<para>There are at least 6 different IDs associated with any
|
||||||
given process. Because of this you have to be very careful with
|
given process. Because of this you have to be very careful with
|
||||||
the access that your process has at any given time. In
|
the access that your process has at any given time. In
|
||||||
particular, all seteuid applications should give up their
|
particular, all seteuid applications should give up their
|
||||||
privileges as soon as it is no longer required.</para>
|
privileges as soon as it is no longer required.</para>
|
||||||
|
|
||||||
|
<indexterm>
|
||||||
|
<primary>user IDs</primary>
|
||||||
|
<secondary>real user ID</secondary>
|
||||||
|
</indexterm>
|
||||||
|
<indexterm>
|
||||||
|
<primary>user IDs</primary>
|
||||||
|
<secondary>effective user ID</secondary>
|
||||||
|
</indexterm>
|
||||||
|
|
||||||
<para>The real user ID can only be changed by a superuser
|
<para>The real user ID can only be changed by a superuser
|
||||||
process. The <application>login</application> program sets this
|
process. The <application>login</application> program sets this
|
||||||
when a user initially logs in and it is seldom changed.</para>
|
when a user initially logs in and it is seldom changed.</para>
|
||||||
|
@ -270,6 +355,8 @@ int main() {
|
||||||
|
|
||||||
<sect1 id="chroot"><title>Limiting your program's environment</title>
|
<sect1 id="chroot"><title>Limiting your program's environment</title>
|
||||||
|
|
||||||
|
<indexterm><primary>chroot()</primary></indexterm>
|
||||||
|
|
||||||
<para>The traditional method of restricting access to a process
|
<para>The traditional method of restricting access to a process
|
||||||
is with the <function>chroot()</function> system call. This
|
is with the <function>chroot()</function> system call. This
|
||||||
system call changes the root directory from which all other
|
system call changes the root directory from which all other
|
||||||
|
@ -297,6 +384,8 @@ int main() {
|
||||||
|
|
||||||
<sect2><title>FreeBSD's jail functionality</title>
|
<sect2><title>FreeBSD's jail functionality</title>
|
||||||
|
|
||||||
|
<indexterm><primary>jail</primary></indexterm>
|
||||||
|
|
||||||
<para>The concept of a Jail extends upon the
|
<para>The concept of a Jail extends upon the
|
||||||
<function>chroot()</function> by limiting the powers of the
|
<function>chroot()</function> by limiting the powers of the
|
||||||
superuser to create a true `virtual server'. Once a prison is
|
superuser to create a true `virtual server'. Once a prison is
|
||||||
|
@ -344,6 +433,9 @@ int main() {
|
||||||
|
|
||||||
<sect2><title>POSIX.1e Process Capabilities</title>
|
<sect2><title>POSIX.1e Process Capabilities</title>
|
||||||
|
|
||||||
|
<indexterm><primary>POSIX.1e Process Capabilities</primary></indexterm>
|
||||||
|
<indexterm><primary>TrustedBSD</primary></indexterm>
|
||||||
|
|
||||||
<para>Posix has released a working draft that adds event
|
<para>Posix has released a working draft that adds event
|
||||||
auditing, access control lists, fine grained privileges,
|
auditing, access control lists, fine grained privileges,
|
||||||
information labeling, and mandatory access control.</para>
|
information labeling, and mandatory access control.</para>
|
||||||
|
@ -364,6 +456,9 @@ int main() {
|
||||||
resources, IPC, mmaps, the file system working directory, file
|
resources, IPC, mmaps, the file system working directory, file
|
||||||
descriptors, the # of open files, etc.</para>
|
descriptors, the # of open files, etc.</para>
|
||||||
|
|
||||||
|
<indexterm><primary>positive filtering</primary></indexterm>
|
||||||
|
<indexterm><primary>data validation</primary></indexterm>
|
||||||
|
|
||||||
<para>You should never assume that you can catch all forms of
|
<para>You should never assume that you can catch all forms of
|
||||||
invalid input that a user might supply. Instead, your
|
invalid input that a user might supply. Instead, your
|
||||||
application should use positive filtering to only allow a
|
application should use positive filtering to only allow a
|
||||||
|
@ -373,6 +468,8 @@ int main() {
|
||||||
extra careful about paths ("../", "/"), symbolic links, and
|
extra careful about paths ("../", "/"), symbolic links, and
|
||||||
shell escape characters.</para>
|
shell escape characters.</para>
|
||||||
|
|
||||||
|
<indexterm><primary>Perl Taint mode</primary></indexterm>
|
||||||
|
|
||||||
<para>Perl has a really cool feature called "Taint" mode which
|
<para>Perl has a really cool feature called "Taint" mode which
|
||||||
can be used to prevent scripts for using data derived outside
|
can be used to prevent scripts for using data derived outside
|
||||||
the program in an unsafe way. This mode will check command line
|
the program in an unsafe way. This mode will check command line
|
||||||
|
@ -390,6 +487,15 @@ int main() {
|
||||||
other words, a programmer incorrectly assumed that a particular
|
other words, a programmer incorrectly assumed that a particular
|
||||||
event would always happen before another.</para>
|
event would always happen before another.</para>
|
||||||
|
|
||||||
|
<indexterm><primary>race conditions</primary>
|
||||||
|
<secondary>signals</secondary></indexterm>
|
||||||
|
|
||||||
|
<indexterm><primary>race conditions</primary>
|
||||||
|
<secondary>access checks</secondary></indexterm>
|
||||||
|
|
||||||
|
<indexterm><primary>race conditions</primary>
|
||||||
|
<secondary>file opens</secondary></indexterm>
|
||||||
|
|
||||||
<para>Some of the common causes of race conditions are signals,
|
<para>Some of the common causes of race conditions are signals,
|
||||||
access checks, and file opens. Signals are asynchronous events
|
access checks, and file opens. Signals are asynchronous events
|
||||||
by nature so special care must be taken in dealing with them.
|
by nature so special care must be taken in dealing with them.
|
||||||
|
|
Loading…
Reference in a new issue