models

content/en/Info/BF Classes/_CDS/Model.md

@@ -1,6 +1,6 @@
 ---
 weight: 1
-title: "Bugs Model"
+title: "Model"
 ---
 # BF Crypto Data Security (\_CDS) Bugs Model<br/>_`Irena Bojanova, PI & Lead, NIST Bugs Framework (BF), 2014 – ~~~~`_
 
@@ -24,4 +24,10 @@ The operations under CPH are on encrypting plain text and decrypting cipher text
 
 The operations under DSV are on signing and verifying. Verification takes a key and either plaintext or ciphertext, signs or hashes it, then passes the result to the user. The user uses the same key or the other key from the key-pair to verify data integrity or source. Note that hash alone without any other mechanism cannot be used to verify source or to protect data integrity against attackers. However, it can be used to protect data integrity against channel errors.
 
-In the cases of symmetric encryption (see Figure 1), one secretly shared key (shKey) is used. The source encrypts with shKey, and the user decrypts also with shKey. In the cases of asymmetric encryption, pairs of mathematically related keys are used. The source pair is a public key (pbKeySrc) and a private key (prKeySrc); the user pair is pbKeyUsr and prKeyUsr. The source encrypts with pbKeyUsr and signs with prKeySrc. The user decrypts with prKeyUsr and verifies with pbKeySrc.
+In the cases of symmetric encryption (see Figure 1), one secretly shared key (shKey) is used. The source encrypts with shKey, and the user decrypts also with shKey. In the cases of asymmetric encryption, pairs of mathematically related keys are used. The source pair is a public key (pbKeySrc) and a private key (prKeySrc); the user pair is pbKeyUsr and prKeyUsr. The source encrypts with pbKeyUsr and signs with prKeySrc. The user decrypts with prKeyUsr and verifies with pbKeySrc.
+
+## BF Crypto Data Safety
+
+The BF Crypto Data Security (_CDS)  Bugs Model addresses temporal type safety by defining the proper flow of operations along the x-axis. For example, data must declared propely to aviod wrap-around (e.g., integer overflow). 
+
+The[Data Validation (DVL)](/BF/info/bf-classes/_inp/dvl) and [DVR](/BF/info/bf-classes/_inp/dvr) BF classes define the list of possible consequences when these temporal rules are not followed.

content/en/Info/BF Classes/_DAT/Model.md

@@ -8,17 +8,23 @@ Data Type bugs could be introduced at any of the _declaration_, _name resolution
 
 The BF Data Type Bugs model (Figure 1) helped us identify the phases and the operations where such bugs could occur. The phases correspond to the BF Data Type Bugs classes: _Declaration Bugs (DCL)_, _Name Resolution (NRS)_, _Type Conversion Bugs (TCV)_, and _Type Computation Bugs (TCM)_. All data type operations are grouped by phase. The presented operations flow helps in identifying possible chains of bugs/weaknesses.
 <br/><br/>
-{{< img src="images/BF Models/_DAT.svg" caption="Figure 1. BF Data Type Bugs Model. Comprises phases, corresponding to the BF classes DCL, NRS, TCV, and TCM. Shows the data type operations flow: blue arrows – the main flow; purple arrows – flow when resolved data types get bound to objects, functions, or generic data types according to their declarations; blue arrows – flow when casting (explicit conversion) is expected before the call; green arrows – flow when the value will get coerced (implicitly converted) to the parameter data type or the return data type, correspondingly" >}}
+{{< img src="images/BF Models/_DAT Model.svg" caption="Figure 1. BF Data Type Bugs Model. Comprises phases, corresponding to the BF classes DCL, NRS, TCV, and TCM. Shows the data type operations flow: blue arrows – the main flow; purple arrows – flow when resolved data types get bound to objects, functions, or generic data types according to their declarations; blue arrows – flow when casting (explicit conversion) is expected before the call; green arrows – flow when the value will get coerced (implicitly converted) to the parameter data type or the return data type, correspondingly" >}}
 <br/>
 The operations under DCL are on declaring entities and on defining objects data and functions implementations: _Declare_ and _Define_.
 
 The operations under NRS are on resolving referred names and on binding their data types and the objects data, and on resolving called functions and binding their implementations: _Refer_ and _Call_.The NRS operations are tied to the name resolution and binding that the Type System performs. Figure 2 shows the corresponding sub-model. Note that the object data value is bound via the _Initialize_ and _Write_ operations of the BF Memory Use Bugs (MUS) class.
 <br/><br/>
-{{< img src="images/BF Models/_DAT 2.svg" caption="Figure 2. Name Resolution and Biding" >}}
+{{< img src="images/BF Models/_DAT 2 Model.svg" caption="Figure 2. Name Resolution and Biding" >}}
 <br/>
 The operations under TCV are on explicit conversion and on implicit conversion into a different data type of a passed in/out of a function data value: _Cast_ and _Coerce_.
 
 The operations under TCM are on calculating (an arithmetic operation – part of an algebraic expression) and on evaluating (a boolean operation – part of a condition): _Calculate_ and _Evaluate_.
 
 The possible flow between operations from different phases is depicted with arrows in Figure 1. A declared and defined entity is referred in source code via its name. Names, referred to in remote scopes, get resolved via resolved names- paces; resolved data types get bound to objects, functions, or generic data types according to their declarations (see the purple arrow flow). A resolved and bound object may be converted to another data type and used in computations as an argument or as a return of a called function, or to call a member function. A passed in argument is expected to be of the declared parameter data type and the passed out result is expected to be of the return data type. Otherwise, casting (explicit conversion) is expected before the call (see the blue arrows flow) or the value will get coerced (implicitly converted) to the parameter data type or the return data type, correspondingly (see the green arrows flow). Note that the green arrows flow is about passed in/out objects – it starts only from NRS Call, it never starts from DCL Declare. The presented operations flow helps in identifying possible chains of bugs and weaknesses.
 
+## BF Type Safety
+
+The BF Data Type (_DAT)  Bugs Model addresses temporal type safety by defining the proper flow of operations along the x-axis. For example, data must declared propely to aviod wrap-around (e.g., integer overflow). 
+
+The[Data Validation (DVL)](/BF/info/bf-classes/_inp/dvl) and [DVR](/BF/info/bf-classes/_inp/dvr) BF classes define the list of possible consequences when these temporal rules are not followed.
+

content/en/Info/BF Classes/_INP/Model.md

@@ -21,4 +21,10 @@ Validation is about accepting or rejecting data based on its syntax: it checks i
 
 Verification is about accepting or rejecting data based on its semantics: it checks if data have proper value (meaning). For example, checking if a start date is before an end date, or checking the type of an XML document against a PowerPoint XSD (XML Schema Definition) is data verification. Once data semantics is checked, it may be corrected via assigning a new value or via removing data. An example of data correction would be setting the size to the buffer’s upper bound when the size that is supplied is larger than that upper bound. The verify and correct operations use specific policies to, for example, check data against a value (incl. NULL or list of values), quantity, range, type, or other business rules.
 
-Data check bugs could be introduced at any of the _data validation_ and _data verification_ phases. Each bug or weakness involves one data check operation: validate, sanitize, verify, or correct. Each operation is over already-canonicalized1 data and the policy (the rules) against which it gets checked.
+Data check bugs could be introduced at any of the _data validation_ and _data verification_ phases. Each bug or weakness involves one data check operation: validate, sanitize, verify, or correct. Each operation is over already-canonicalized1 data and the policy (the rules) against which it gets checked.
+
+## BF Input/Output Safety
+
+The BF Input/Output (_INP) Bugs Model addresses temporal input/output safety by defining the proper flow of operations along the x-axis. For example, input data must be validated and sanitized to aviod injection. 
+
+The[Data Validation (DVL)](/BF/info/bf-classes/_inp/dvl) and [DVR](/BF/info/bf-classes/_inp/dvr) BF classes define the list of possible consequences when these temporal rules are not followed.

content/en/Info/BF Classes/_MEM/Model.md

@@ -1,10 +1,10 @@
 ---
-weight: 3
+weight: 1
 title: "Model"
 ---
 # BF Memory (\_MEM) Bugs Model <br/>_`Irena Bojanova, PI & Lead, NIST Bugs Framework (BF), 2014 – ~~~~`_
 
-Each memory related bug or weakness involves one memory operation. Each _operation_ is over a region of memory or over the address needed to reach it. That memory is used for storing data and has an important property: it is finite. It has _boundaries_ and it has _size_. This piece of memory, with a well-defined size, is called an _object_ and is used to store a primitive data or a data structure. The object are data (value), data type, address, and size. The memory address should be held by at least one _pointer_ or determined as an offset on the stack, otherwise the object will be unreachable. 
+Each memory related bug or weakness involves one memory operation. Each _operation_ is over a region of memory or over the address needed to reach it. That memory is used for storing data and has an important property: it is finite. It has _boundaries_ and it has _size_. This piece of memory, with a well-defined size is called an _object_; It is of a primitive data type or a data structure. The memory address should be held by at least one _pointer_ or determined as an offset on the stack, otherwise the object will be unreachable. The operands to a memory operation are the object and the pointer, which as properties of the object are: data (value), data type, address, and size.  
 
 Memory bugs could be introduced at any of the phases of an object’s lifecycle: _address formation_, _allocation_, _use_, and _deallocation_. The phases correspond to the BF memory bugs classes: Memory Addressing Bugs (MAD), Memory Management Bugs (MMN) -- cover both the Memory Allocation (MAL) and the Memory Deallocation (MDL phases), and Memory Use Bugs (MUS). 
 
@@ -17,12 +17,18 @@ The operations under MAD (Figure 1) are on forming or modifying a pointer: _Init
 
 The operations under MUS are on reading or writing the content of an object through one of its pointers: _Initialize_, _Read_, _Write_, _Clear_, and _Dereference_. Bugs in object initialization could lead to use of random or malicious data. Bugs in write could alter data wrongly. Bugs in Clear could leak confidential information such as passwords and cryptographic private keys. Bugs in Dereference are practically unsuccessful reading or unsuccessful writing.
 
-The operations under MMN are on creating an object or extending it through one of its pointers: Allocate, Extend, and Reallocate–Extend (i.e., the MAL phase), and operations on destroying or reducing an object through one of its pointer: Deallocate, Reduce, and Reallocate–Reduce (i.e., the MDL phase). The MMN operations affect the boundaries and the size of the object. Bugs in Reallocate may concern multiple pointers to the same object. Allocation in excess or failure to deallocate unused objects could exhaust memory. Excessive reduction of allocated memory could lead to an object that is too small for the data it needs to store.
+The operations under MMN are on creating an object or extending it through one of its pointers: Allocate, Extend, and Reallocate–Extend (i.e., the MAL phase), and operations on destroying or reducing an object through one of its pointers: Deallocate, Reduce, and Reallocate–Reduce (i.e., the MDL phase). The MMN operations affect the boundaries and the size of the object. Bugs in Reallocate may concern multiple pointers to the same object. Allocation in excess or failure to deallocate unused objects could exhaust memory. Excessive reduction of allocated memory could lead to an object that is too small for the data it needs to store.
 
 The possible flow between operations from different phases is depicted on Figure 1 with colored arrows: blue is for the main flow; green is for allocation at a specific address; red is for the extra flow in case of reallocation.
 
 Following the blue arrows, the very first operation is MMN Allocate (i.e., MAL Allocate) an object. Following the green arrows, the first operation is MAD Initialize Pointer. Next operation, following the blue arrows, should be MAD Initialize the Pointer to the address returned by Allocate. While, following the green arrows, next operation should be MMN Allocate (i.e., MAL Allocate) an object at the address the pointer holds.
 
 After an object is allocated and its pointer is initialized, it can be used via MUS Read or MUS Write. The boundaries and the size of an object are set at allocation, then they can be changed by any MMN operation.
 
-If an object is owned by more than one pointer, MMN Reallocate (i.e., MAL Reallocate and MDL Reallocate) should be followed by MAD Reposition over all these owners. A MMN Deallocate (i.e., MDL Deallocate) an object operation should properly be followed by MAD Reassign of all its pointers to either `NULL` or another object.
+If an object is owned by more than one pointer, MMN Reallocate (i.e., MAL Reallocate and MDL Reallocate) should be followed by MAD Reposition over all these owners. A MMN Deallocate (i.e., MDL Deallocate) an object operation should properly be followed by MAD Reassign of all its pointers to either `NULL` or another object.
+
+## BF Memory Safety
+
+The BF Memory (_MEM) Bugs Model addresses temporal memory safety by defining the proper flow of operations over the owner (pointer) or object along the x-axis. It also addresses spatial memory safety via the operations that affect object boundaries along the y-axis. For example, an object must be allocated before use and deallcated before its pointer is reassigned, it must not be read before it is initialized and must be cleared before it is deallocated, and it must not be used after it is deallocated. These correspond to unintialized/uncleared object, memory leaks, and use after free/return safety. The size of the object is always strictly defined, and the pointer must not exceed its boundaries. This corresponds to buffer overflow/underflow safety. 
+
+The BF [Memory Addressing Bugs (MAD)](/BF/info/bf-classes/_mem/mad/), [Memory Management Bugs (MMN)](/BF/info/bf-classes/_mem/mmn/), and [Memory Use Bugs (MUS)](/BF/info/bf-classes/_mem/mus/) classes define the list of possible consequences when these temporal or spatial rules are not followed.