See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/45856644

On Implementation of a Safer C Library, ISO/IEC TR 24731

Article · June 2009

Source: arXiv

CITATIONS READS
0 160

3 authors, including:

Serguei Mokhov
Concordia University Montreal
192 PUBLICATIONS 1,045 CITATIONS

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Forensic Lucid View project

MARFCAT View project

All content following this page was uploaded by Serguei Mokhov on 29 February 2016.

The user has requested enhancement of the downloaded file.

arXiv:0906.2512v2 [cs.SE] 27 Jul 2009

On Implementation of a Safer C Library, ISO/IEC TR 24731.

Technical Report

CIISE Security Investigation Initiative

Represented by:

Marc-André Laverdière-Papineau
Serguei A. Mokhov
Djamel Benredjem
{ma laver,mokhov,d benred}@ciise.concordia.ca

Montréal, Québec, Canada

April 2006
Contents

1 Introduction 1
1.1 Security Problems in C Standard Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Introducing ISO/IEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 ISO/IEC TR 24731 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Architecture 3
2.1 Principles and Philosophy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Summary of Siemens Four View Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2.1 Conceptual View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2.2 Module View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2.3 Execution View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2.4 Code View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2.5 Conceptual View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.5.1 Conceptual Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.5.2 Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.5.3 Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.5.4 Resource Budgeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.6 Module View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.6.1 Layering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.6.2 Interface Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Execution View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3.1 Runtime Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3.2 Communication Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3.3 Execution Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 Code View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
i
ii On Implementation of a Safer C Library, ISO/IEC TR 24731.

2.4.1 Source Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.4.2 Intermediate Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4.3 Deployment Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4.4 Make Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4.5 Configuration Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.5 Example for One Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.6 Iterations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.7 Coding Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3 Implementation 12
3.1 Run-time Constraint Handling API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2 Constraint Violation Information Encapsulation API . . . . . . . . . . . . . . . . . . . . . . 12
3.3 Constraint Enumeration and Validator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.4 Constraint Handling Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4 Results 17
4.1 Implemented API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1.1 Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1.1.1 Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1.1.2 Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1.2 Private Constraint Handling API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1.2.1 Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1.2.2 Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2 Constraint Handling In Action – stdio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.3 Constraint Handling In Action – string . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5 Conclusions 25
5.1 Summary of the Difficulties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.2 Limitations So Far . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.3 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.4 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Bibliography 27
Chapter 1

Introduction

1.1 Security Problems in C Standard Functions

The functions standardized as part of ISO C 1999 and their addendums improved very little the security
options from the previously available library.
The largest flaw remained that no function asked for the buffer size of destination buffers for any func-
tion copying data into a user-supplied buffer. According to earlier research we performed [PMB], we know
that error condition handling was the first solution to security vulnerabilities, followed by precondition
validation. The standard C functions typically perform little precondition validation and error handling,
allowing for a wide range of security issues to be introduced in their use.
For example:
char *strncat(char *dest, const char *src, size t n); does not null-terminate, can still
overflow
char *strtok(char * restrict s1, const char * restrict s2); not reentrant
size t strlen(const char *s); can iterate in the memory up to
an invalid page and cause a pro-
gram crash
This effort remained not enough, and many projects developed additional functions, namely:

• OpenBSD strlcpy family [MdR99]

• GNU C extensions [pro]

• Microsoft strsafe.h and others [Cor05]

1.2 Introducing ISO/IEC

The International Standardization Organization (ISO) and the International Electrotechnical Commission
(IEC) are standard-making bodies headquartered in Geneva (Switzerland) [Sec05].
1
2 On Implementation of a Safer C Library, ISO/IEC TR 24731.

Both organizations are constituted from an international membership, with local member organizations
involved in standard-making activities as well. For example, we have the Standards Council of Canada,
American National Standards Institute, Deutsches Institut für Normung, and Association française de
normalisation [ISO06b].
ISO and IEC collaborate closely on standards related to computer equipment and information tech-
nologies.
These organizations established a hierarchical structure under JTC 1 - Joint Technical Committee
on Information Technology. JTC 1 is subdivided in 17 subcommittees, one of which (SC 22) deals with
programming languages, with a working group for each programming languages [ISO06a].
The C language is normalized by ISO/IEC JTC 1/ SC 22/ WG 14. Its members include representatives
from Microsoft, SEI/CMU, Cisco, Intel, etc [SC2]. The Computer Security Laboratory of CIISE, through
Pr. Debbabi, is a member of this Working Group as Canadian representative with voting rights.

1.3 ISO/IEC TR 24731

In the ISO jargon, TR 24731 [WG106] is a Technical Report Type 2 [ISO05, ISO], which means that the
document is not a standard, but a direction for future normalization. This specification is currently in the
draft state.
Titled “TR 24731: Safer C library functions”, it defines 41 new library functions for memory copying,
string handling (both for normal and wide character strings), time printing, sorting, searching etc. Another
inovation it brings is a constraint handling architecture, forcing error handling when certain security-related
preconditions are violated when the functions are called. It also specifies the null-termination of all strings
manipulated through its function and introduces a new unsigned integer type that helps preventing integer
overflows and underflows. It is currently implemented by Microsoft as part of their Visual Studio 2005
[Sea05].
Chapter 2

Architecture

In this chapter, we examine the architecture of our implementation of ISO/IEC TR 24731. We first
introduce our architectural philosophy before informing the reader about the Siemens Four View Model,
an architectural methodology for the conception of large-scale software systems.
Afterwards, we examine each of the view, as architected for our library.
Finally, we conclude with other software engineering matters that were of high importance in the
development of our implementation.

2.1 Principles and Philosophy

The library specification imposes that the functions be in addition of other standard functions, in the same
header files. However, we do not want our implementation to re-implement the standard C library, nor
do we want to augment an existing implementation and be bound to a specific platform. The compromise
solution is to organize the code to be using the low-level implementation of any existing C library, such as
the one from GNU [gp], FreeBSD or OpenBSD.
In short, our principles are:

Platform independence We target systems complying with the POSIX standard.

Standards Compliance We will implement the library using features available only in ISO C99 and
POSIX.

C Library Independence We will architect in a way that prevents us being tied to the underlying C
library.

Realistic Compiler Indepedence A corollary of standards compliance, we will avoid compiler-specific

macros and optimizations as possible. This means that the source code should be free of such
dependencies, but that the build process may be bound to the compiler.

Reasonable Efficiency We will architect and implement an efficient library, but will avoid advanced
programming tricks that improve the efficiency at the cost of maintainability and readability.
3
4 On Implementation of a Safer C Library, ISO/IEC TR 24731.

Simplicity And Maintainability We will target a simplistic and easy to maintain organization of the
source.

Architectural Consistency We will consistently implement our architectural approach. We could say
that we will have a “template” approach.

Separation of Concerns We will isolate separate concerns between modules and within modules to
encourage reuse and code simplicity.

Functional Grouping We will have functional coupling between within a module, meaning that func-
tions will have a commonality of type, such as I/O, string manipulations, etc.

2.2 Summary of Siemens Four View Model

We decided to use the Siemens Four View Model for our architectural description, mostly due to previous
experience using the technology. A detailed description with case studies can be found in [HNS00]. This
methodology is introduced by scientists of Siemens Corporate Research and has been successfully applied to
a variety of systems, many of which with real-time and embedded requirements. Please refer to Figure 2.1
for an abstract presentation of the view. In the context of this project report, we inform the reader of the
basic principles of each view.

2.2.1 Conceptual View

The conceptual view defines the conceptual components and their conceptual connectors, as well as their
conceptual configuration. The architect, in this phase, must also specify resource budgets.

2.2.2 Module View

In the module view, the architect maps the conceptually-defined elements into modules and layers. The
architect must then define the interface to the modules.

2.2.3 Execution View

In the execution view, the architect must define the runtime entities, the communication paths and the
execution configuration. It essentially means the mapping of modules to threads and processes, and to
define the inter-process communication mechanisms to be used. In the case of our library, there are no
threads of execution per se, as such, this architectural step was skipped.

2.2.4 Code View

In the code view, the architect must define the source components, intermediate components and deploy-
ment components, followed by the build procedure and configuration management.
On Implementation of a Safer C Library, ISO/IEC TR 24731. 5

Figure 2.1: High-Level Description of the Four Views [Cha]

2.2.5 Conceptual View

2.2.5.1 Conceptual Overview

We divided our architecture in a few modules, isolating the core functionalities from each library and
grouping functions per library. We also decided to use wrappers to a C library implementation. This
overview can be seen in Figure Figure 2.2.

2.2.5.2 Configurations

The only options in configuration relate to the wrappers to use for a specific C library. Since this is
decided at compilation time and that only one is possible in any case, we decided not to further specify
configurations.

2.2.5.3 Protocols

Because of the simplistic nature of the components (direction function calls) and that all components need
to be re-entrant, we conclude that no protocols are necessary.
6 On Implementation of a Safer C Library, ISO/IEC TR 24731.

Figure 2.2: Conceptual Modules

On Implementation of a Safer C Library, ISO/IEC TR 24731. 7

2.2.5.4 Resource Budgeting

We did not specify any resource budget for any components due to the lack of specific constraints.

2.2.6 Module View

2.2.6.1 Layering

We divided our library between layers when we found significant redundancy for some operations. We
decided to keep the memory copying for wide characters apart from the one without wide characters due
to the risk of integer overflows that could result in faulty logic, and thus deserving a centralization of the
functionality.
The complete view of our layering is included in Figure Figure 2.3.

2.2.6.2 Interface Design

The only interface that needed to be designed was related to the constraint validation. Please refer to the
specification given in section Section 3.1

2.3 Execution View

2.3.1 Runtime Entities

In the case of our library, there are no threads of execution per se, as the thread is provided by the calling
program(s).

2.3.2 Communication Paths

It was resolved that the functions would all communicate through message passing.

2.3.3 Execution Configuration

Coherently with previous decisions, there are no specific execution configurations.

2.4 Code View

2.4.1 Source Components

Each of stdio.h, stdlib.h, string.h, time.h, and wchar.h are mapped into a corresponding directory,
as a module. The folder named test copies the previous structure, and contains test programs exclusively.
The include directory contains the .h files to be included by external programs linking to the library.
8 On Implementation of a Safer C Library, ISO/IEC TR 24731.

Figure 2.3: Layering

On Implementation of a Safer C Library, ISO/IEC TR 24731. 9

Figure 2.4: Directory Tree

10 On Implementation of a Safer C Library, ISO/IEC TR 24731.

The folder named adapters holds a sub-directory per C library implementation to adapt to, and each of
those adapters mirror the base directory structure. Each interface function was implemented in a file with
its name, to facilitate maintainability. Related functions are grouped in the file to which it is the most
logically related.
We established a naming convention for functions as follows:

function The function’s interface for the user.

function impl The function’s implementation, used within the library.

function validate preconditions The function’s precondition validation component.

function component refactored sub-component of a function or common code within functions.

2.4.2 Intermediate Components

In order to facilitate the building process, we decided that each directory of functionality and adapters
will assemble all intermediary (.o) files into an archive (.a).

2.4.3 Deployment Components

The only deployment component will be a .so file that includes our implementation and the underlying
library.

2.4.4 Make Process

The build process is organized as a hierarchical organization of makefiles. Each makefile cross-reference
the makefiles for its dependencies. The intermediary objects defined are the standard .o that are also
grouped in an archive (.a). The testers are built separately from the library itself for efficiency and faster
compilation.
The make files are designed to adapt to both Linux and Windows/Cygwin platforms by detecting the
presence of Cygwin and using different compiler options consequently.
The documentation generation fits outside of the normal make process and is generated by the doxygen
tool itself.

2.4.5 Configuration Management

We used Subversion (svn) [Tig] in order to manage the source code, makefile, and documentation revisions.

2.5 Example for One Module

In Figure 2.5 and Figure 2.6, we show the example of function call and source file dependencies for a
function implementing vfprintf s.
On Implementation of a Safer C Library, ISO/IEC TR 24731. 11

Figure 2.5: Call dependencies for function vfprintf s

Figure 2.6: File dependencies for function vfprintf s

2.6 Iterations

In order to efficiently reach our architectural goal, we divided the final objectives of the project in the
following steps:

1. Implementation of the body, without precondition validations

2. Implementation of precondition validation and integration

3. Validation of compliance for all testable cases

4. Implementation of adapters to a C library

5. Redefinition of insecure function calls to our function calls

2.7 Coding Standards

In order to produce high-quality code, we decided to normalize on the OpenBSD style. We also decided to
use Doxygen [vH] source code documentation style for its completeness and the automated tool support.
Chapter 3

Implementation

This chapter gives concrete implementation details for the constraint handling API and examples of its
usage. An excessive amount of work was done to have a decent precondition validation and this chapter
mostly focuses on the API aspect of this implementatition. A particular achievement was to fully enable
parsing and restraining of %s and %n modifiers with the flex-based scanner.

3.1 Run-time Constraint Handling API

For precondition validation we deviced an API to encasulate run-time constraint check and violation
information and an appropriate currently registered constraint handler. Later on this was abstracted with
inline function calls reducing the clutter for the libc s programmers such as ourselves and for those who
might maintain it after us.
The standard defines this type to allow custom constraint handlers in stdlib.h:

typedef void (* c o n s t r a i n t _ h a n d l e r _ t ) ( const char * restrict msg , void * restrict ptr , errno_t error ) ;
c o n s t r a i n t _ h a n d l e r _ t s e t _ c o n s t r a i n t _ h a n d l e r _ s ( c o n s t r a i n t _ h a n d l e r _ t handler ) ;
void a bo rt _h a nd le r_ s ( const char * restrict msg , void * restrict ptr , errno_t error ) ;
void i g n o r e _ h a n d l e r _ s ( const char * restrict msg , void * restrict ptr , errno_t error ) ;

Listing 3.1: Standard API for Constraint Handling

In our implementation we mark abort handler s as the default handler for all contraint violations.
That means, after erroring out, the handler calls exit(0) and the application build around libc s termi-
nates.

3.2 Constraint Violation Information Encapsulation API

This is the capsule enclosing the error information we defined. The structure depicts some meta information
about a paramater and its value. An instance of this structure is created for each input parameter to be
validated.
12
On Implementation of a Safer C Library, ISO/IEC TR 24731. 13

Listing 3.2: Synopsys: param validation status t

# include " s t d l i b _ i m p l e m e n t a t i o n . h "

typedef struct _ p a r a m _ v a l i d a t i o n _ s t a t u s _ t
{
e_errcheck errtype ;
const void * value ;
const void * pairvalue ;
const void * result ;
const char * restrict function_name ;
const char * restrict param_name ;
const char * restrict pair_param_name ;
bool error_present ;
} param_validation_status_t ;

Some helper data structures allow us to describe more complex types. The param range t struct
allows specifying the range for a domain value. A reference to the instance of this struct is passed in
the param validation status t.pairvalue field. The object range t struct is supposed to contain the
data describing a memory objec with its starting address and length. The purpose of this is to help with
validation of ranged objects that they do not overlap in memory. The implementor of the library should
provide the two intances of this struct as references in value and pairvalue of the two ranged objects.
Which object reference goes to where is unimportant as the implementation takes care of figuring out the
object precedence.

Listing 3.3: Synopsys: param range t

typedef struct _param_range_t
{
size_t min ;
size_t max ;
} param_range_t ;

Listing 3.4: Synopsys: object range t

typedef struct _object_range_t
{
const void * restrict object_ptr ;
size_t object_length ;
} object_range_t ;
14 On Implementation of a Safer C Library, ISO/IEC TR 24731.

3.3 Constraint Enumeration and Validator

The enumeration in Listing 3.5 defines most common error types to check for and report. These correspond
to the index for the human readable error messages.

typedef enum
{
E_NOERROR = 0 ,
E_NULL_PARAMETER_NOT_ALLOWED = 1,
E_PARAMETER_OUT_OF_RANGE = 2,
E_ENVIRONMENTAL_LIMIT_NOT_MET = 3,
E _ I N V A L I D _ F O R M A T _ P A R A M E T E R _ S = 4 , /* % s */
E _ I N V A L I D _ F O R M A T _ P A R A M E T E R _ N = 5 , /* % n */
E_RSIZE_MAX_EXCEEDED = 6,
E_NOT_ZERO = 7 ,
E_OBJECTS_OVERLAP = 8,
E_NOT_IMPLEMENTED = 9,
E _ T O K E N _ E N D _ N O T _ F O U N D = 10
} e_errcheck ;

Listing 3.5: Enumeration of most common error types to check for.

On Implementation of a Safer C Library, ISO/IEC TR 24731. 15

errno_t __error_out ( p a r a m _ v a l i d a t i o n _ s t a t u s _ t * restrict status ) ;

errno_t _ _ c o n t r a i n t _ v a l i d a t o r _ s ( p a r a m _ v a l i d a t i o n _ s t a t u s _ t * restrict status ) ;
errno_t
_ _ c o n s t r a i n t _ v a l i d a t o r _ o b j e c t _ o v e r l a p ( const char * restrict function_name , const char * restrict
parameterNames , const void * restrict object1Start , const size_t object1Size , const void *
restrict object2Start , const size_t object2Size ) ;
errno_t
_ _ c o n s t r a i n t _ v a l i d a t o r _ v a l u e _ i n r a n g e ( const char * restrict function_name , const char * restrict
parameterName , const size_t value , const size_t lowerBound , const size_t upperBound ) ;
errno_t
_ _ c o n s t r a i n t _ v a l i d a t o r _ n o t _ n u l l ( const char * restrict function_name , const char * restrict
parameter_name , const void * restrict value_ptr ) ;
errno_t
_ _ c o n s t r a i n t _ v a l i d a t o r _ n o t _ n u l l _ a r g s ( const char * restrict function_name , const char * restrict
parameter_name , const char * restrict format , const va_list args ) ;
errno_t
_ _ c o n s t r a i n t _ v a l i d a t o r _ s _ f o r m a t ( const char * restrict function_name , const char * restrict
parameter_name , const char * restrict format , const va_list args ) ;
errno_t
_ _ c o n s t r a i n t _ v a l i d a t o r _ n _ f o r m a t ( const char * restrict function_name , const char * restrict
parameter_name , const char * restrict format , const va_list args ) ;
errno_t
_ _ c o n s t r a i n t _ v a l i d a t o r _ n o t _ z e r o ( const char * restrict function_name , const char * restrict
parameter_name , const size_t value ) ;
errno_t
_ _ c o n s t r a i n t _ v a l i d a t o r _ r s i z e _ l i m i t ( const char * restrict function_name , const char * restrict
parameter_name , const rsize_t value ) ;
void
_ _ r e p o r t _ c o n s t r a i n t _ v i o l a t i o n _ e n d _ o f _ t o k e n _ n o t _ p r e s e n t ( const char * restrict function_name , const
char * restrict paramete r_name ) ;

Listing 3.6: Constraint Validator API

16 On Implementation of a Safer C Library, ISO/IEC TR 24731.

3.4 Constraint Handling Example

Our implementation of the API (in Listing 3.6) does something similar to the code snippet presented in
Listing 3.7.

...
param_validation_status_t format_string_validation ;
_ _ m e m o r y _ z e r o _ f i l l _ r a n g e (& format_string_validation , sizeof ( p a r a m _ v a l i d a t i o n _ s t a t u s _ t ) ) ;
f o r m a t _ s t r i n g _ v a l i d a t i o n . errtype = E _ I N V A L I D _ F O R M A T _ P A R A M E T E R _ S ;
f o r m a t _ s t r i n g _ v a l i d a t i o n . value = format ;
f o r m a t _ s t r i n g _ v a l i d a t i o n . pairvalue = & arg ;
f o r m a t _ s t r i n g _ v a l i d a t i o n . param_name = " format / arg null % s " ;
f o r m a t _ s t r i n g _ v a l i d a t i o n . function_name = " vfprintf_s " ;

error = _ _ c o n t r a i n t _ v a l i d a t o r _ s (& f o r m a t _ s t r i n g _ v a l i d a t i o n ) ;

if ( error != OK )
{
errno = error ;
return error ;
}
...

Listing 3.7: Validation Code

Chapter 4

Results

This chapter summarizes the result achieved as of this writing. This includes implemented API to this
point as well as some concrete results demonstraiting correctness of implementation.

4.1 Implemented API

This is the summary of the implemented API from the library and our internal constraint handling. We
summarized the functions and data types added in ISO/IEC TR 24731 in this section for the sake of
reference.

4.1.1 Library

4.1.1.1 Data Types

Added the following data types: rsize t, errno t, constraint handler t that were necessary to add.

4.1.1.2 Functions

The functions in Listing 4.1 were to the large extend implemented by our team as of this writing. Likewise,
Listing 4.2 lists API not yet addressed. Finally, Listing 4.3 lists API implemented half-way through.

4.1.2 Private Constraint Handling API

4.1.2.1 Data Types

Added the following data types: param validation status t, param range t, object range t that were
necessary to add.
17
18 On Implementation of a Safer C Library, ISO/IEC TR 24731.

int fprintf_s ( FILE * restrict stream , const char * restrict format , ...) ;
int fscanf_s ( FILE * restrict stream , const char * restrict format , ...) ;
int printf_s ( const char * restrict format , ...) ;
int scanf_s ( const char * restrict format , ...) ;
int snprintf_s ( char * restrict s , rsize_t n , const char * restrict format , ...) ;
int sprintf_s ( char * restrict s , rsize_t n , const char * restrict format , ...) ;
int sscanf_s ( const char * restrict s , const char * restrict format , ...) ;
int vfprintf_s ( FILE * restrict stream , const char * restrict format , va_list arg ) ;
int vfscanf_s ( FILE * restrict stream , const char * restrict format , va_list arg ) ;
int vprintf_s ( const char * restrict format , va_list arg ) ;
int vscanf_s ( const char * restrict format , va_list arg ) ;
int vsnprintf_s ( char * restrict s , rsize_t n , const char * restrict format , va_list arg ) ;
int vsprintf_s ( char * restrict s , rsize_t n , const char * restrict format , va_list arg ) ;
int vsscanf_s ( const char * restrict s , const char * restrict format , va_list arg ) ;
c o n s t r a i n t _ h a n d l e r _ t s e t _ c o n s t r a i n t _ h a n d l e r _ s ( c o n s t r a i n t _ h a n d l e r _ t handler ) ;
void a bo rt _h a nd le r_ s ( const char * restrict msg , void * restrict ptr , errno_t error ) ;
void i g n o r e _ h a n d l e r _ s ( const char * restrict msg , void * restrict ptr , errno_t error ) ;
errno_t wctomb_s ( int * restrict status , char * restrict s , rsize_t smax , wchar_t wc ) ;
errno_t mbstowcs_s ( size_t * restrict retval , wchar_t * restrict dst , rsize_t dstmax , const char *
restrict src , rsize_t len ) ;
errno_t wcstombs_s ( size_t * restrict retval , char * restrict dst , rsize_t dstmax , const wchar_t *
restrict src , rsize_t len ) ;
errno_t memcpy_s ( void * restrict s1 , rsize_t s1max , const void * restrict s2 , rsize_t n ) ;
errno_t memmove_s ( void * s1 , rsize_t s1max , const void * s2 , rsize_t n ) ;
errno_t strcpy_s ( char * restrict s1 , rsize_t s1max , const char * restrict s2 ) ;
errno_t strncpy_s ( char * restrict s1 , rsize_t s1max , const char * restrict s2 , rsize_t n ) ;
errno_t strcat_s ( char * restrict s1 , rsize_t s1max , const char * restrict s2 ) ;
errno_t strncat_s ( char * restrict s1 , rsize_t s1max , const char * restrict s2 , rsize_t n ) ;
char * strtok_s ( char * restrict s1 , rsize_t * restrict s1max , const char * restrict s2 , char **
restrict ptr ) ;
int fwprintf_s ( FILE * restrict stream , const wchar_t * restrict format , ...) ;
int fwscanf_s ( FILE * restrict stream , const wchar_t * restrict format , ...) ;
int snwprintf_s ( wchar_t * restrict s , rsize_t n , const wchar_t * restrict format , ...) ;
int swprintf_s ( wchar_t * restrict s , rsize_t n , const wchar_t * restrict format , ...) ;
int swscanf_s ( const wchar_t * restrict s , const wchar_t * restrict format , ...) ;
int vfwprintf_s ( FILE * restrict stream , const wchar_t * restrict format , va_list arg ) ;
int vfwscanf_s ( FILE * restrict stream , const wchar_t * restrict format , va_list arg ) ;
int vsnwprintf_s ( wchar_t * restrict s , rsize_t n , const wchar_t * restrict format , va_list arg ) ;
int vswprintf_s ( wchar_t * restrict s , rsize_t n , const wchar_t * restrict format , va_list arg ) ;
int vswscanf_s ( const wchar_t * restrict s , const wchar_t * restrict format , va_list arg ) ;
int vwprintf_s ( const wchar_t * restrict format , va_list arg ) ;
int vwscanf_s ( const wchar_t * restrict format , va_list arg ) ;
int wprintf_s ( const wchar_t * restrict format , ...) ;
int wscanf_s ( const wchar_t * restrict format , ...) ;

Listing 4.1: Implemented Safer C Library API

On Implementation of a Safer C Library, ISO/IEC TR 24731. 19

char * gets_s ( char *s , rsize_t n ) ;

errno_t getenv_s ( size_t * restrict len , char * restrict value , rsize_t maxsize , const char *
restrict name ) ;
void * bsearch_s ( const void * key , const void * base , rsize_t nmemb , rsize_t size , int (* compar ) (
const void *k , const void *y , void * context ) , void * context ) ;
errno_t qsort_s ( void * base , rsize_t nmemb , rsize_t size , int (* compar ) ( const void *x , const void *
y , void * context ) , void * context ) ;
errno_t strerror_s ( char *s , rsize_t maxsize , errno_t errnum ) ;
size_t strerrorlen_s ( errno_t errnum ) ;
size_t strnlen_s ( const char *s , size_t maxsize ) ;
errno_t asctime_s ( char *s , rsize_t maxsize , const struct tm * timeptr ) ;
errno_t ctime_s ( char *s , rsize_t maxsize , const time_t * timer ) ;
struct tm * gmtime_s ( const time_t * restrict timer , struct tm * restrict result ) ;
struct tm * localtime_s ( const time_t * restrict timer , struct tm * restrict result ) ;
errno_t wcscpy_s ( wchar_t * restrict s1 , rsize_t s1max , const wchar_t * restrict s2 ) ;
errno_t wcsncpy_s ( wchar_t * restrict s1 , rsize_t s1max , const wchar_t * restrict s2 , rsize_t n ) ;
errno_t wmemcpy_s ( wchar_t * restrict s1 , rsize_t s1max , const wchar_t * restrict s2 , rsize_t n ) ;
errno_t wmemmove_s ( wchar_t * s1 , rsize_t s1max , const wchar_t * s2 , rsize_t n ) ;
errno_t wcscat_s ( wchar_t * restrict s1 , rsize_t s1max , const wchar_t * restrict s2 ) ;
errno_t wcsncat_s ( wchar_t * restrict s1 , rsize_t s1max , const wchar_t * restrict s2 , rsize_t n ) ;
wchar_t * wcstok_s ( wchar_t * restrict s1 , rsize_t * restrict s1max , const wchar_t * restrict s2 ,
wchar_t ** restrict ptr ) ;
size_t wcsnlen_s ( const wchar_t *s , size_t maxsize ) ;
errno_t wcrtomb_s ( size_t * restrict retval , char * restrict s , rsize_t smax , wchar_t wc , mbstate_t
* restrict ps ) ;
errno_t mbsrtowcs_s ( size_t * restrict retval , wchar_t * restrict dst , rsize_t dstmax , const char
** restrict src , rsize_t len , mbstate_t * restrict ps ) ;
errno_t wcsrtombs_s ( size_t * restrict retval , char * restrict dst , rsize_t dstmax , const wchar_t
** restrict src , rsize_t len , mbstate_t * restrict ps ) ;

Listing 4.2: Not Implemented Safer C Library API

errno_t tmpfile_s ( FILE * restrict * restrict streamptr ) ;

errno_t tmpnam_s ( char *s , rsize_t maxsize ) ;
errno_t fopen_s ( FILE * restrict * restrict streamptr , const char * restrict filename , const char *
restrict mode ) ;
errno_t freopen_s ( FILE * restrict * restrict newstreamptr , const char * restrict filename , const
char * restrict mode , FILE * restrict stream ) ;

Listing 4.3: Partially Implemented Safer C Library API

20 On Implementation of a Safer C Library, ISO/IEC TR 24731.

errno_t _ _ v a l i d a t e _ n _ f o r m a t ( const char * restrict format , va_list args ) ;

errno_t _ _ v a l i d a t e _ s _ f o r m a t ( const char * restrict format , va_list args ) ;
errno_t _ _ v a l i d a t e _ s n _ f o r m a t ( const char * restrict format , va_list arg ) ;

/* c o n s t r a i n t v a l i d a t o r ; c o n s t r a i n t _ v a l i d a t o r _ s . c */

errno_t __error_out ( bool errflag , p a r a m _ v a l i d a t i o n _ s t a t u s _ t * restrict status ) ;

errno_t _ _ c o n s t r a i n t _ v a l i d a t o r _ s ( p a r a m _ v a l i d a t i o n _ s t a t u s _ t * restrict status ) ;

errno_t
_ _ c o n s t r a i n t _ v a l i d a t o r _ o b j e c t _ o v e r l a p ( const char * restrict function_name , const char * restrict
parameterNames , const void * restrict object1Start , const size_t object1Size , const void *
restrict object2Start , const size_t object2Size ) ;

errno_t
_ _ c o n s t r a i n t _ v a l i d a t o r _ v a l u e _ i n r a n g e ( const char * restrict function_name , const char * restrict
parameterName , const size_t value , const size_t lowerBound , const size_t upperBound ) ;

errno_t
_ _ c o n s t r a i n t _ v a l i d a t o r _ n o t _ n u l l ( const char * restrict function_name , const char * restrict
parameter_name , const void * restrict value_ptr ) ;

errno_t
_ _ c o n s t r a i n t _ v a l i d a t o r _ s _ f o r m a t ( const char * restrict function_name , const char * restrict
parameter_name , const char * restrict format , const va_list args ) ;

errno_t
_ _ c o n s t r a i n t _ v a l i d a t o r _ n _ f o r m a t ( const char * restrict function_name , const char * restrict
parameter_name , const char * restrict format , const va_list args ) ;

errno_t
_ _ c o n s t r a i n t _ v a l i d a t o r _ n o t _ z e r o ( const char * restrict function_name , const char * restrict
parameter_name , const size_t value ) ;

errno_t
_ _ c o n s t r a i n t _ v a l i d a t o r _ r s i z e _ l i m i t ( const char * restrict function_name , const char * restrict
parameter_name , const rsize_t value ) ;

void
_ _ r e p o r t _ c o n s t r a i n t _ v i o l a t i o n _ e n d _ o f _ t o k e n _ n o t _ p r e s e n t ( const char * restrict function_name , const
char * restrict paramete r_name ) ;

Listing 4.4: Implemented Constraint Handling API

errno_t _ _ v a l i d a t e _ a r g s _ n o t _ n u l l ( const char * restrict format , va_list args ) ;

errno_t
_ _ c o n s t r a i n t _ v a l i d a t o r _ n o t _ n u l l _ a r g s ( const char * restrict function_name , const char * restrict
parameter_name , const char * restrict format , const va_list args ) ;

Listing 4.5: Not Implemented Constraint Handling API

On Implementation of a Safer C Library, ISO/IEC TR 24731. 21

4.1.2.2 Functions

The functions in Listing 4.4 were to the large extend implemented by our team as of this writing. Likewise,
Listing 4.5 lists API not yet addressed.

4.2 Constraint Handling In Action – stdio

Test code is in Listing 4.6.

/*
* Sloppy P r o g r a m m i n g Test Cases
*/

# define _ _ S T D C _ W A N T _ L I B _ E X T 1 _ _ 1
# include " stdio . h "
# include " stdlib . h "

# include < unistd .h >

# include < string .h >

int
main ( int argc , char ** argv )
{
int valid = 1;

set_constraint_handler_s ( ignore_handler_s );

if ( argc > 1)
{
printf ( " Sloppy programming zone : [[% s ]]\ n " , argv [1]) ;
printf_s ( argv [1]) ;
printf ( " \ n \ n " ) ;
}

printf_s ( " valid s = [% s ]\ n " , " valid " ) ;

printf_s ( " valid n1 = [%%%% n ]\ n \ n " , & valid ) ;
printf_s ( " invalid n2 = [%%% n ]\ n \ n " , & valid ) ;
printf_s ( " valid n3 = [%% n ]\ n \ n " , & valid ) ;
printf_s ( " invalid n4 = [% n ]\ n \ n " , & valid ) ;

printf_s ( " invalid s = [% s ]\ n " , NULL ) ;

printf_s ( " invalid n = [% n ]\ n \ n " , & argc ) ;

printf ( " return value for %% n : [% d ]\ n " , printf_s ( " % n \ n " , & argc ) ) ;
printf ( " return value for %% s : [% d ]\ n " , printf_s ( " % s \ n " , NULL ) ) ;

return 0;
}

/* EOF */

Listing 4.6: Example of a Test Program for stdio to test and reject invalid %s and %n cases.
22 On Implementation of a Safer C Library, ISO/IEC TR 24731.

Output is in Listing 4.7.

bash -2.05 b$ test / stdio / test % n

Sloppy programming zone : [[% n ]]
printf_s () : invalid format parameter (% n is disallowed ) : format / args % n

valid s = [% s ]
valid s = [ valid ]
valid n1 = [ n ]

valid n1 = [%% n ]

invalid n2 = [ printf_s () : invalid format parameter (% n is disallowed ) : format / args % n

valid n3 = [ n ]

valid n3 = [% n ]

invalid n4 = [ printf_s () : invalid format parameter (% n is disallowed ) : format / args % n

printf_s () : invalid format parameter ( NULL argument for % s ) : format / args null % s
invalid n = [ printf_s () : invalid format parameter (% n is disallowed ) : format / args % n
printf_s () : invalid format parameter (% n is disallowed ) : format / args % n
return value for % n : [22]
printf_s () : invalid format parameter ( NULL argument for % s ) : format / args null % s
return value for % s : [22]
bash -2.05 b$

Listing 4.7: Output

4.3 Constraint Handling In Action – string

Test code is in Listing 4.8.

On Implementation of a Safer C Library, ISO/IEC TR 24731. 23

# define _ _ S T D C _ W A N T _ L I B _ E X T 1 _ _ 1
# include " string . h "
# include < errno .h >
# include < stdio .h >
# include < string .h >
# include " stdlib . h "

int main ( int argc , char ** argv ) {

char buffer1 [1024];
char buffer2 [1024];

set_constraint_handler_s ( ignore_handler_s );

/* Failure tests */
printf ( " strcpy_s failure test :\ t " ) ;
strcpy_s ( buffer1 , 1024 , NULL ) ;
printf ( " strncpy_s failure test :\ t " ) ;
strncpy_s ( buffer1 , 10 , buffer2 , 50) ;
printf ( " strncat_s failure test :\ t " ) ;
strcat_s ( buffer1 , -1 , buffer2 ) ;
printf ( " strncat_s failure test :\ t " ) ;
strncat_s ( NULL , 1024 , NULL , 50) ;
printf ( " strncat_s failure test :\ t " ) ;
strncat_s ( buffer1 , 1024 , buffer1 -10 , 50) ;
printf ( " memcpy_s failure test :\ t " ) ;
memcpy_s ( buffer1 , 1024 , buffer2 , -1) ;
printf ( " memmove_s failure test :\ t " ) ;
memmove_s ( buffer1 , 1023 , NULL , 1024) ;

/* Normal o p e r a t i o n tests */
strcpy_s ( buffer1 , 1024 , " test string " ) ;
printf ( " strcpy_s : % s \ n " , buffer1 ) ;
strncpy_s ( buffer2 , 1024 , buffer1 , 1024) ;
printf ( " strncpy_s : % s \ n " , buffer2 ) ;
strcat_s ( buffer1 , 1024 , buffer2 ) ;
printf ( " strcat_s : % s \ n " , buffer1 ) ;
...
printf ( " strnlen_s ( buffer1 ) : % u \ n " , strlength ) ;
size_t errlen = strerrorlen_s ( EINVAL ) ;
printf ( " strerrorlen_s ( EINVAL ) : % u \ n " , errlen ) ;
strerror_s ( buffer2 , 1014 , EINVAL ) ;
printf ( " % s \ n " , buffer2 ) ;
rsize_t l = strnlen_s ( buffer1 , 100) ;
char * strktokresult = NULL ;
char * token = strtok_s ( buffer1 , &l , " " , & strktokresult ) ;
printf ( " strtok_s token : %s , remaining length : %u , remaining substring : % s \ n " , token , l ,
strktokresult ) ;
token = strtok_s ( NULL , &l , " gt " , & strktokresult ) ; /* Should be found */
...
/* Move printfs to a real test file */
size_t s = strnlen_s ( " 12345 " , 10) ;
printf ( " size : % u \ n " , s ) ;
}

Listing 4.8: Example of a Test Program for string to test and reject invalid cases.
24 On Implementation of a Safer C Library, ISO/IEC TR 24731.

Output is in Listing 4.9.

bash -2.05 b$ test / string / test

strcpy_s failure test : strcpy_s () : has invalid NULL pointer argument : s2
strncpy_s failure test : strncat_s failure test : strcat_s () : rsize_t value exceeds RSIZE_MAX :
s1max
strncat_s failure test : strncat_s () : has invalid NULL pointer argument : s1
strncat_s failure test : strncat_s () : two data structures overlap in memory : s1 and s2
memcpy_s failure test : memcpy_s () : rsize_t value exceeds RSIZE_MAX : n
memmove_s failure test : memmove_s () : has invalid NULL pointer argument : s2
strcpy_s : test string
strncpy_s : test string
strcat_s : test stringtest string
strncat_s : test stringtest stringtest string
memmove_s : test stringtest stringtest string
memcpy_s : test stringtest stringtest string
strnlen_s ( buffer1 ) : 33
strerrorlen_s ( EINVAL ) : 0
test string
strtok_s token : test , remaining length : 28 , remaining substring : stringtest stringtest string
strtok_s token : strin , remaining length : 21 , remaining substring : est stringtest string
strtok_s () : token end not found within defined bounds : * ptr
strtok_s token : est stringtest string , remaining length : 0 , remaining substring :
size : 5
bash -2.05 b$

Listing 4.9: Output

Chapter 5

Conclusions

Here were briefly address the following topics:

• Difficulties

• Limitations

• Acknowledgments

• Future Work

5.1 Summary of the Difficulties

1. Parsing/processing of varargs and %n in particular

2. Deciding on default values

3. Implementing strtok s and its wide character equivalent

5.2 Limitations So Far

• Incomplete implementation (of approx. 45%) of the entire API

• Lack of thorough testing for all the implemented API

5.3 Acknowledgments

• Dr. Prabir Bhattacharya

• Dr. Mourad Debbabi

• ISO

• Open Source Community and the GLIBC Team [gp]

25
26 On Implementation of a Safer C Library, ISO/IEC TR 24731.

5.4 Future Work

This project, being a derivative of the standard C library, will see a major effort put into the testing of
the library. Furthermore, a large part of the project (transforming the obsolete calls to wrappers to the
newer ones) makes the assumption that the buffer free size is easily obtainable, an assumption which may
not necessarily hold true in all circumstances. As such, it is possible that we will have to develop novel
algorithms to ensure that this portability is possible, or it may also be that this portability is not 100%
attainable. Furthermore, we will need to investigate good potential software for performance and security
testing of our improved solution. Thus, we will focus on:

• Completion of implementation,

• Addition more comprehensive test cases by the developers and the OSS community,

• Application for EAL5,

• Inclusion into the Linux kernel as a standard.

Bibliography

[Cha] Dr. P. Chalin. Soen 344 slides. http://www.cs.concordia.ca/∼chalin/courses/06W/

SOEN344/.

[Cor05] Microsoft Corp. Using the strsafe.h functions, 2005. http://msdn.microsoft.com/library/

default.asp?url=/library/en-us/winui/winui/windowsuserinterface/resources/
strings/usingstrsafefunctions.asp.

[gp] glibc project. Gnu c library. http://www.gnu.org/software/libc/.

[HNS00] Christine Hofmeister, Robert Nord, and Dilip Soni. Applied Software Architecture. Addison-
Wesley, 2000.

[ISO] ISO. ISO/TR Technical Report. http://www.iso.org/iso/en/stdsdevelopment/

whowhenhow/proc/deliverables/iso tr.html.

[ISO05] ISO/IEC. ISO/IEC Directives, Part 2: Rules for the structure and drafting of International
Standards, 5th edition, 2005. http://isotc.iso.org/livelink/livelink.exe/4230517/
ISO IEC Directives Part 2 Rules for the structure and drafting of International
Standards 2004 5th edition pdf format .pdf?func=doc.Fetch&nodeid=4230517.

[ISO06a] ISO. JTC 1, 2006. http://www.iso.org/iso/en/stdsdevelopment/tc/tclist/

TechnicalCommitteeDetailPage.TechnicalCommitteeDetail?COMMID=1.

[ISO06b] ISO. Member bodies, 2006. http://www.iso.org/iso/en/aboutiso/isomembers/

MemberList.MemberSummary?MEMBERCODE=10.

[MdR99] T. C. Miller and T. de Raadt. strlcpy and strlcatconsistent, safe string copy and concatenation. In
Proceedings of the FREENIX Track, 1999 USENIX Annual Technical Conference, pages 175–178.
USENIX Association, 1999. http://www.usenix.org/publications/library/proceedings/
usenix99/full papers/millert/millert.pdf.

[PMB] M-A Laverdière Papineau, S. Mokhov, and D. Benredjem. Statistical classification of vulnerabil-
ity solutions in the linux kernels 2.4/2.6. Submitted to IEEE COMPSAC, pending acceptance.

[pro] GCC project. Extensions to the c language family. http://gcc.gnu.org/onlinedocs/gcc-3.

3.1/gcc/C-Extensions.html.
27
28 On Implementation of a Safer C Library, ISO/IEC TR 24731.

[SC2] ISO/IEC JTC1 SC22/WG14. Draft minutes for 25-28 september 2005 meeting of iso/iec jtc1
sc22/wg14 and incits j11. http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1145.pdf.

[Sea05] R. Seacord. Secure Coding in C and C++. SEI Series. Addison-Wesley, 2005.

[Sec05] ISO Central Secretariat. ISO in brief, 2005. http://www.iso.org/iso/en/prods-services/

otherpubs/pdf/isoinbrief 2005-en.pdf.

[Tig] Tigris. Subversion. http://subversion.tigris.org/.

[vH] Dimitry van Heesch. Doxygen manual for version 1.4.6. ftp://ftp.stack.nl/pub/users/
dimitri/doxygen manual-1.4.6.pdf.zip.

[WG106] ISO/IEC JTC1 SC22 WG14. Programming language c - specification for safer more secure c
library functions. Technical Report ISO/IEC TR 24731, ISO, 2006. Draft status at time of
writing.
 Index

API Library, 17
abort handler s, 12 Private Constraint Handling, 17
constraint handler t, 17 Introduction, 1
errno t, 17
Methodology
exit(0), 12
Principles and Philosophy, 3
object range t, 13, 17
pairvalue, 13 Results, 17
param range t, 13, 17
param validation status t, 13, 17 Siemens Four View Model, 4
param validation status t.pairvalue, 13 Code View, 4
rsize t, 17 Conceptual View, 4
strlcpy, 1 Execution View, 4
strtok s, 25 Module View, 4
value, 13
Tools
Architecture, 3
libc s, 12
Conclusions, 25 svn, 10

Files
.a, 10
.h, 7
.o, 10
.so, 10
adapters, 10
include, 7
makefile, 10
stdio.h, 7
stdlib.h, 7, 12
string.h, 7
strsafe.h, 1
time.h, 7
wchar.h, 7

Implementation, 12
Implemented API, 17
29

View publication stats