diff options
Diffstat (limited to 'build/tools/HLSLcc/May_2014/src/cbstring/security.txt')
| -rw-r--r-- | build/tools/HLSLcc/May_2014/src/cbstring/security.txt | 221 |
1 files changed, 0 insertions, 221 deletions
diff --git a/build/tools/HLSLcc/May_2014/src/cbstring/security.txt b/build/tools/HLSLcc/May_2014/src/cbstring/security.txt deleted file mode 100644 index 9761409..0000000 --- a/build/tools/HLSLcc/May_2014/src/cbstring/security.txt +++ /dev/null @@ -1,221 +0,0 @@ -Better String library Security Statement ----------------------------------------- - -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 -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 -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 -application secure or free from implementation failures. However, it is the -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 -uses Bstrlib. - -=============================================================================== - -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 -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 -level of an established theory. - -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 -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 -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. - -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. - -3. Constant string protection - -Bstrlib implements runtime enforced constant and read-only string semantics. -I.e., bstrings which are declared as constant via the bsStatic() macro cannot -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 -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 -correctly. - -4. Aliased bstring support - -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 -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 -strings have been released back to memory. Created bstrings or CBStrings -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 -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 -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 -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 -buffer management. - -8. Double freeing - -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 -(though this behaviour is not guaranteed and should not be relied on). - -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: - - struct tagbstring hw = bsStatic ("Hello, world"); - bstring cpHw = bstrcpy (&hw); - - #ifdef NOT_QUITE_AS_SAFE - bdestroy (cpHw); /* Never fail */ - bdestroy (cpHw); /* Error sometimes detected at runtime */ - bdestroy (&hw); /* Error detected at run time */ - #else - bstrFree (cpHw); /* Never fail */ - bstrFree (cpHw); /* Will do nothing */ - bstrFree (&hw); /* Will lead to a compile time error */ - #endif - -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 -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 -loss is very low, since: - - 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. - C) the library comes with various functions which deal with this issue - (namely: bfromcstr(), bstr2cstr (), and bSetCstrChar ()) - -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 -carefully auditted by anyone using a system in which CHAR_BIT is not 8. - -12. EBCDIC/ASCII/UTF-8 data representation attacks. - -Bstrlib uses ctype.h functions to ensure that it remains portable to non- -ASCII systems. It also checks range to make sure it is well defined even for -data that ANSI does not define for the ctype functions. - -Obscure issues: -............... - -13. Data attributes - -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. - |