- Remove extraneous / in comment.
- Clarify documentation of overflow detection. - Remove extraneous spaces at the end of lines.
This commit is contained in:
websnarf
parent
981cb838f4
commit
2a17f97443
167
security.txt
167
security.txt
|
|
@ -8,35 +8,35 @@ by Paul Hsieh
|
|||
Introduction
|
||||
------------
|
||||
|
||||
The Better String library (hereafter referred to as Bstrlib) is an attempt to
|
||||
provide improved string processing functionality to the C and C++ languages.
|
||||
At the heart of the Bstrlib is the management of "bstring"s which are a
|
||||
significant improvement over '\0' terminated char buffers. See the
|
||||
The Better String library (hereafter referred to as Bstrlib) is an attempt to
|
||||
provide improved string processing functionality to the C and C++ languages.
|
||||
At the heart of the Bstrlib is the management of "bstring"s which are a
|
||||
significant improvement over '\0' terminated char buffers. See the
|
||||
accompanying documenation file bstrlib.txt for more information.
|
||||
|
||||
DISCLAIMER: THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS 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 COPYRIGHT OWNER 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
|
||||
DISCLAIMER: THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS 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 COPYRIGHT OWNER 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.
|
||||
|
||||
Like any software, there is always a possibility of failure due to a flawed
|
||||
implementation. Nevertheless a good faith effort has been made to minimize
|
||||
such flaws in Bstrlib. Also, use of Bstrlib by itself will not make an
|
||||
implementation. Nevertheless a good faith effort has been made to minimize
|
||||
such flaws in Bstrlib. Also, use of Bstrlib by itself will not make an
|
||||
application secure or free from implementation failures. However, it is the
|
||||
author's conviction that use of Bstrlib can greatly facilitate the creation
|
||||
author's conviction that use of Bstrlib can greatly facilitate the creation
|
||||
of software meeting the highest possible standards of security.
|
||||
|
||||
Part of the reason why this document has been created, is for the purpose of
|
||||
security auditing, or the creation of further "Statements on Security" for
|
||||
software that is created that uses Bstrlib. An auditor may check the claims
|
||||
below against Bstrlib, and use this as a basis for analysis of software which
|
||||
Part of the reason why this document has been created, is for the purpose of
|
||||
security auditing, or the creation of further "Statements on Security" for
|
||||
software that is created that uses Bstrlib. An auditor may check the claims
|
||||
below against Bstrlib, and use this as a basis for analysis of software which
|
||||
uses Bstrlib.
|
||||
|
||||
===============================================================================
|
||||
|
|
@ -45,15 +45,15 @@ Statement on Security
|
|||
---------------------
|
||||
|
||||
This is a document intended to give consumers of the Better String Library
|
||||
who are interested in security an idea of where the Better String Library
|
||||
stands on various security issues. Any deviation observed in the actual
|
||||
library itself from the descriptions below should be considered an
|
||||
who are interested in security an idea of where the Better String Library
|
||||
stands on various security issues. Any deviation observed in the actual
|
||||
library itself from the descriptions below should be considered an
|
||||
implementation error, not a design flaw.
|
||||
|
||||
This statement is not an analytical proof of correctness or an outline of one
|
||||
but rather an assertion similar to a scientific claim or hypothesis. By use,
|
||||
testing and open independent examination (otherwise known as scientific
|
||||
falsifiability), the credibility of the claims made below can rise to the
|
||||
testing and open independent examination (otherwise known as scientific
|
||||
falsifiability), the credibility of the claims made below can rise to the
|
||||
level of an established theory.
|
||||
|
||||
Common security issues:
|
||||
|
|
@ -61,29 +61,30 @@ Common security issues:
|
|||
|
||||
1. Buffer Overflows
|
||||
|
||||
The Bstrlib API allows the programmer a way to deal with strings without
|
||||
having to deal with the buffers containing them. Ordinary usage of the
|
||||
The Bstrlib API allows the programmer a way to deal with strings without
|
||||
having to deal with the buffers containing them. Ordinary usage of the
|
||||
Bstrlib API itself makes buffer overflows impossible.
|
||||
|
||||
Furthermore, the Bstrlib API has a superset of basic string functionality as
|
||||
compared to the C library's char * functions, C++'s std::string class and
|
||||
Microsoft's MFC based CString class. It also has abstracted mechanisms for
|
||||
dealing with IO. This is important as it gives developers a way of migrating
|
||||
Furthermore, the Bstrlib API has a superset of basic string functionality as
|
||||
compared to the C library's char * functions, C++'s std::string class and
|
||||
Microsoft's MFC based CString class. It also has abstracted mechanisms for
|
||||
dealing with IO. This is important as it gives developers a way of migrating
|
||||
all their code from a functionality point of view.
|
||||
|
||||
2. Memory size overflow/wrap around attack
|
||||
|
||||
Bstrlib is, by design, impervious to memory size overflow attacks. The
|
||||
reason is it is resiliant to length overflows is that bstring lengths are
|
||||
bounded above by INT_MAX, instead of ~(size_t)0. So length addition
|
||||
overflows cause a wrap around of the integer value making them negative
|
||||
causing balloc() to fail before an erroneous operation can occurr. Attempted
|
||||
conversions of char * strings which may have lengths greater than INT_MAX are
|
||||
detected and the conversion is aborted.
|
||||
By design, Bstrlib is impervious to memory size overflow attacks. The
|
||||
reason is that it detects length overflows and leads to a result error before
|
||||
the operation attempts to proceed. Attempted conversions of char* strings
|
||||
which may have lengths greater than INT_MAX are detected and the conversion
|
||||
is aborted. If the memory to hold the string exceeds the available memory
|
||||
for it, again, the result is aborted without changing the prior state of the
|
||||
strings.
|
||||
|
||||
It is unknown if this property holds on machines that don't represent
|
||||
integers as 2s complement. It is recommended that Bstrlib be carefully
|
||||
auditted by anyone using a system which is not 2s complement based.
|
||||
These behaviors rely on the use of 2s complement by the underlying machine
|
||||
architecture. It is unknown if these properties hold on machines that do
|
||||
not represent integers as 2s complement. It is recommended that Bstrlib be
|
||||
carefully auditted by anyone using a system which is not 2s complement based.
|
||||
|
||||
3. Constant string protection
|
||||
|
||||
|
|
@ -93,7 +94,7 @@ be modified or deallocated directly through the Bstrlib API, and this cannot
|
|||
be subverted by casting or other type coercion. This is independent of the
|
||||
use of the const_bstring data type.
|
||||
|
||||
The Bstrlib C API uses the type const_bstring to specify bstring parameters
|
||||
The Bstrlib C API uses the type const_bstring to specify bstring parameters
|
||||
whose contents do not change. Although the C language cannot enforce this,
|
||||
this is nevertheless guaranteed by the implementation of the Bstrlib library
|
||||
of C functions. The C++ API enforces the const attribute on CBString types
|
||||
|
|
@ -101,59 +102,59 @@ correctly.
|
|||
|
||||
4. Aliased bstring support
|
||||
|
||||
Bstrlib detects and supports aliased parameter management throughout the API.
|
||||
Bstrlib detects and supports aliased parameter management throughout the API.
|
||||
The kind of aliasing that is allowed is the one where pointers of the same
|
||||
basic type may be pointing to overlapping objects (this is the assumption the
|
||||
ANSI C99 specification makes.) Each function behaves as if all read-only
|
||||
parameters were copied to temporaries which are used in their stead before
|
||||
the function is enacted (it rarely actually does this). No function in the
|
||||
Bstrlib uses the "restrict" parameter attribute from the ANSI C99
|
||||
basic type may be pointing to overlapping objects (this is the assumption the
|
||||
ANSI C99 specification makes.) Each function behaves as if all read-only
|
||||
parameters were copied to temporaries which are used in their stead before
|
||||
the function is enacted (it rarely actually does this). No function in the
|
||||
Bstrlib uses the "restrict" parameter attribute from the ANSI C99
|
||||
specification.
|
||||
|
||||
5. Information leaking
|
||||
|
||||
In bstraux.h, using the semantically equivalent macros bSecureDestroy() and
|
||||
bSecureWriteProtect() in place of bdestroy() and bwriteprotect() respectively
|
||||
will ensure that stale data does not linger in the heap's free space after
|
||||
In bstraux.h, using the semantically equivalent macros bSecureDestroy() and
|
||||
bSecureWriteProtect() in place of bdestroy() and bwriteprotect() respectively
|
||||
will ensure that stale data does not linger in the heap's free space after
|
||||
strings have been released back to memory. Created bstrings or CBStrings
|
||||
are not linked to anything external to themselves, and thus cannot expose
|
||||
are not linked to anything external to themselves, and thus cannot expose
|
||||
deterministic data leaking. If a bstring is resized, the preimage may exist
|
||||
as a copy that is released to the heap. Thus for sensitive data, the bstring
|
||||
should be sufficiently presized before manipulated so that it is not resized.
|
||||
bSecureInput() has been supplied in bstraux.c, which can be used to obtain
|
||||
input securely without any risk of leaving any part of the input image in the
|
||||
as a copy that is released to the heap. Thus for sensitive data, the bstring
|
||||
should be sufficiently presized before manipulated so that it is not resized.
|
||||
bSecureInput() has been supplied in bstraux.c, which can be used to obtain
|
||||
input securely without any risk of leaving any part of the input image in the
|
||||
heap except for the allocated bstring that is returned.
|
||||
|
||||
6. Memory leaking
|
||||
|
||||
Bstrlib can be built using memdbg.h enabled via the BSTRLIB_MEMORY_DEBUG
|
||||
Bstrlib can be built using memdbg.h enabled via the BSTRLIB_MEMORY_DEBUG
|
||||
macro. User generated definitions for malloc, realloc and free can then be
|
||||
supplied which can implement special strategies for memory corruption
|
||||
detection or memory leaking. Otherwise, bstrlib does not do anything out of
|
||||
the ordinary to attempt to deal with the standard problem of memory leaking
|
||||
(i.e., losing references to allocated memory) when programming in the C and
|
||||
C++ languages. However, it does not compound the problem any more than exists
|
||||
either, as it doesn't have any intrinsic inescapable leaks in it. Bstrlib
|
||||
does not preclude the use of automatic garbage collection mechanisms such as
|
||||
supplied which can implement special strategies for memory corruption
|
||||
detection or memory leaking. Otherwise, bstrlib does not do anything out of
|
||||
the ordinary to attempt to deal with the standard problem of memory leaking
|
||||
(i.e., losing references to allocated memory) when programming in the C and
|
||||
C++ languages. However, it does not compound the problem any more than exists
|
||||
either, as it doesn't have any intrinsic inescapable leaks in it. Bstrlib
|
||||
does not preclude the use of automatic garbage collection mechanisms such as
|
||||
the Boehm garbage collector.
|
||||
|
||||
7. Encryption
|
||||
|
||||
Bstrlib does not present any built-in encryption mechanism. However, it
|
||||
supports full binary contents in its data buffers, so any standard block
|
||||
based encryption mechanism can make direct use of bstrings/CBStrings for
|
||||
Bstrlib does not present any built-in encryption mechanism. However, it
|
||||
supports full binary contents in its data buffers, so any standard block
|
||||
based encryption mechanism can make direct use of bstrings/CBStrings for
|
||||
buffer management.
|
||||
|
||||
8. Double freeing
|
||||
|
||||
Freeing a pointer that is already free is an extremely rare, but nevertheless
|
||||
Freeing a pointer that is already free is an extremely rare, but nevertheless
|
||||
a potentially ruthlessly corrupting operation (its possible to cause Win 98 to
|
||||
reboot, by calling free mulitiple times on already freed data using the WATCOM
|
||||
CRT.) Bstrlib invalidates the bstring header data before freeing, so that in
|
||||
many cases a double free will be detected and an error will be reported
|
||||
many cases a double free will be detected and an error will be reported
|
||||
(though this behaviour is not guaranteed and should not be relied on).
|
||||
|
||||
Using bstrFree pervasively (instead of bdestroy) can lead to somewhat
|
||||
Using bstrFree pervasively (instead of bdestroy) can lead to somewhat
|
||||
improved invalid free avoidance (it is completely safe whenever bstring
|
||||
instances are only stored in unique variables). For example:
|
||||
|
||||
|
|
@ -173,21 +174,21 @@ instances are only stored in unique variables). For example:
|
|||
9. Resource based denial of service
|
||||
|
||||
bSecureInput() has been supplied in bstraux.c. It has an optional upper limit
|
||||
for input length. But unlike fgets(), it is also easily determined if the
|
||||
buffer has been truncated early. In this way, a program can set an upper limit
|
||||
on input sizes while still allowing for implementing context specific
|
||||
truncation semantics (i.e., does the program consume but dump the extra
|
||||
for input length. But unlike fgets(), it is also easily determined if the
|
||||
buffer has been truncated early. In this way, a program can set an upper
|
||||
limit on input sizes while still allowing for implementing context specific
|
||||
truncation semantics (i.e., does the program consume but dump the extra
|
||||
input, or does it consume it in later inputs?)
|
||||
|
||||
10. Mixing char *'s and bstrings
|
||||
|
||||
The bstring and char * representations are not identical. So there is a risk
|
||||
when converting back and forth that data may lost. Essentially bstrings can
|
||||
contain '\0' as a valid non-terminating character, while char * strings
|
||||
cannot and in fact must use the character as a terminator. The risk of data
|
||||
contain '\0' as a valid non-terminating character, while char * strings
|
||||
cannot and in fact must use the character as a terminator. The risk of data
|
||||
loss is very low, since:
|
||||
|
||||
A) the simple method of only using bstrings in a char * semantically
|
||||
A) the simple method of only using bstrings in a char * semantically
|
||||
compatible way is both easy to achieve and pervasively supported.
|
||||
B) obtaining '\0' content in a string is either deliberate or indicative
|
||||
of another, likely more serious problem in the code.
|
||||
|
|
@ -199,10 +200,10 @@ Marginal security issues:
|
|||
|
||||
11. 8-bit versus 9-bit portability
|
||||
|
||||
Bstrlib uses CHAR_BIT and other limits.h constants to the maximum extent
|
||||
possible to avoid portability problems. However, Bstrlib has not been tested
|
||||
on any system that does not represent char as 8-bits. So whether or not it
|
||||
works on 9-bit systems is an open question. It is recommended that Bstrlib be
|
||||
Bstrlib uses CHAR_BIT and other limits.h constants to the maximum extent
|
||||
possible to avoid portability problems. However, Bstrlib has not been tested
|
||||
on any system that does not represent char as 8-bits. So whether or not it
|
||||
works on 9-bit systems is an open question. It is recommended that Bstrlib be
|
||||
carefully auditted by anyone using a system in which CHAR_BIT is not 8.
|
||||
|
||||
12. EBCDIC/ASCII/UTF-8 data representation attacks.
|
||||
|
|
@ -216,6 +217,6 @@ Obscure issues:
|
|||
|
||||
13. Data attributes
|
||||
|
||||
There is no support for a Perl-like "taint" attribute, however, an example of
|
||||
There is no support for a Perl-like "taint" attribute, however, an example of
|
||||
how to do this using C++'s type system is given as an example.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue