From 86cbb86e86ee9f2c926624b671ac2516494bfe47 Mon Sep 17 00:00:00 2001 From: =josephproject1 <=joseph.kaberuka@glasgow.ac.uk> Date: Wed, 8 Nov 2023 17:04:12 +0200 Subject: [PATCH 01/13] uintptr_t does not maintain provenance information --- pointerProvenanceIssue.c | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) create mode 100644 pointerProvenanceIssue.c diff --git a/pointerProvenanceIssue.c b/pointerProvenanceIssue.c new file mode 100644 index 0000000..94d9761 --- /dev/null +++ b/pointerProvenanceIssue.c @@ -0,0 +1,27 @@ + +#include +#include + +int main () { + +int myArray[10]; + +uintptr_t ptr = (uintptr_t)&myArray[0]; //storing the address as uintptr_t + +//performing an invalid operation - accessing a non existent element + +uintptr_r myPtr = ptr + sizeof(int)* 20; + +//trying to accessing the memory using an invalid pointer + +int myValue = *(int*)myPtr // no memory safety checks + +printf("invalid value : %d\n ",myValue); + + +return 0; + +} + + + From 24ca03a4e5c56ad455183978966b84de4af2c05d Mon Sep 17 00:00:00 2001 From: =josephproject1 <=joseph.kaberuka@glasgow.ac.uk> Date: Wed, 8 Nov 2023 17:28:28 +0200 Subject: [PATCH 02/13] Provenance of the pointer tracks --- CHERIProvenanceOfPointer.c | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) create mode 100644 CHERIProvenanceOfPointer.c diff --git a/CHERIProvenanceOfPointer.c b/CHERIProvenanceOfPointer.c new file mode 100644 index 0000000..ee30f60 --- /dev/null +++ b/CHERIProvenanceOfPointer.c @@ -0,0 +1,22 @@ +#include +#include + +int main(){ + +int myArray[10]; + +int *ptr = &myArray[0]; // storing the pointer as a capability + +//perform a capability safe operation - accessing a valid element + +int myValue = *ptr; + +// access within bounds + +int *new_ptr = ptr + 5; + +printf("valid value : %d\n", myValue); + +return 0; + +} From 589bfa36da9b6e849031147251f5a100cfa75da8 Mon Sep 17 00:00:00 2001 From: =josephproject1 <=joseph.kaberuka@glasgow.ac.uk> Date: Wed, 8 Nov 2023 18:53:13 +0200 Subject: [PATCH 03/13] CHERI facilitates sweeping revocation technique --- CHERIcapabilitySweepingRevocation.c | 47 +++++++++++++++++++++++++++++ 1 file changed, 47 insertions(+) create mode 100644 CHERIcapabilitySweepingRevocation.c diff --git a/CHERIcapabilitySweepingRevocation.c b/CHERIcapabilitySweepingRevocation.c new file mode 100644 index 0000000..8592e96 --- /dev/null +++ b/CHERIcapabilitySweepingRevocation.c @@ -0,0 +1,47 @@ +#include +#include +int main() { + +//create a capability to a memory region + +int data[10] = {0}; + +cheri_object data_cap; + +data_cap = cheri_build_data_cap(data, sizeof(data), CHERI_PERM_LOAD|CHERI_PERM_STORE); + +//read and write access capability + +int* cap_ptr = cheri_cast(int*, data_cap); + +//read and write data + +cap_ptr[0] = 42; + +int value = cap_ptr[0]; + +printf("initial value: %d\n", value); + +//let's simulate a security breach or a vulnerability detection + +//decide to revoke or write access to the memory region + +cheri_set_perms(&data_cap,CHERI_PERM_LOAD);//revoke write permissions + +//attempting to write after revoking triggers an exception + +//uncommenting this line would trigger a capability violation exception + +//cap_ptr[1]=99; + +//however,read access remains allowed + +int read_value = cap_ptr[1]; + +printf("read only value: %d\n", read_value); + +return 0; + + +} + From c8a0b5335779d61d711039bf111e6d2aa10de4f3 Mon Sep 17 00:00:00 2001 From: =josephproject1 <=joseph.kaberuka@glasgow.ac.uk> Date: Thu, 9 Nov 2023 12:25:37 +0200 Subject: [PATCH 04/13] Insecure encapsulation access --- LackofSecureEncapsulationIssue.c | 51 ++++++++++++++++++++++++++++++++ 1 file changed, 51 insertions(+) create mode 100644 LackofSecureEncapsulationIssue.c diff --git a/LackofSecureEncapsulationIssue.c b/LackofSecureEncapsulationIssue.c new file mode 100644 index 0000000..97ab6f5 --- /dev/null +++ b/LackofSecureEncapsulationIssue.c @@ -0,0 +1,51 @@ +#include +#include + +struct Student { + +char name[100]; + +int age; + +}; + +struct Student* create_student(char name*, int age); + +struct Student* student = (struct Student*)malloc(sizeof(struct Student)); + +if(student){ + +strcpy(student->name, name); + +student->age = age; + +} + +return student; + +} + +int main() { + +struct Student* student1 = create_student("Alice", 20); + +struct Student* student2 = create_student("Bob", 22); + +//unintentional access to students data (no encapsulation) + +printf("student1: %s,%d\n", student2->name, student2->age); + +free(student1); +free(student2); + +return 0; + +} + + + + + + + + From bba7a98fd43067c0e3014500f92d3a594ca29557 Mon Sep 17 00:00:00 2001 From: =josephproject1 <=joseph.kaberuka@glasgow.ac.uk> Date: Thu, 9 Nov 2023 12:42:14 +0200 Subject: [PATCH 05/13] Secure encapsulation --- CHERISecureEncapsulation.c | 52 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 52 insertions(+) create mode 100644 CHERISecureEncapsulation.c diff --git a/CHERISecureEncapsulation.c b/CHERISecureEncapsulation.c new file mode 100644 index 0000000..c5fc6cf --- /dev/null +++ b/CHERISecureEncapsulation.c @@ -0,0 +1,52 @@ +#include +#include +#include + +struct Student{ + +char name[100]; + +int age; + +}; + +//component1 + +void component1(void* studentCapability){ + +struct Student* student = cheri_setbounds(studentCapability,sizeof(struct Student)); + +strcpy(student->name,"Alice"); + +student->age=20; + +} + +//component2 + +void component2(void* studentCapability){ + +struct Student* student = cheri_setbounds(studentCapability,sizeof(struct Student)); + +printf("componet2 reads: Name: %s, Age: %d\n", student->name, student->age); + +} + +int main (){ + +//memory allocation for the student data + +struct Student sharedStudent; + +void* studentCapability = cheri_setbounds(&sharedStudent,sizeof(struct Student)); + +//components use capability to access the shared student data + +component1(studentCapability); +component2(studentCapability); + +return 0; + +} + + From 4e54d5550724c094375766986b3cbb80907a2021 Mon Sep 17 00:00:00 2001 From: =josephproject1 <=joseph.kaberuka@glasgow.ac.uk> Date: Thu, 9 Nov 2023 12:52:13 +0200 Subject: [PATCH 06/13] In address space protection issue --- LacksSingleInAddressSpaceProtection.c | 30 +++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) create mode 100644 LacksSingleInAddressSpaceProtection.c diff --git a/LacksSingleInAddressSpaceProtection.c b/LacksSingleInAddressSpaceProtection.c new file mode 100644 index 0000000..20a97aa --- /dev/null +++ b/LacksSingleInAddressSpaceProtection.c @@ -0,0 +1,30 @@ +#include +#include + +char sharedData[100]; + +//component1 +void component1(){ + +strcpy(sharedData, "Data from component1"); + +} + +//component2 +void component2(){ + +printf("component2 reads: %s\n", sharedData); + +} + +int main(){ + +component1(); + +component2(); + +return 0; + +} + + From 2ef4cc8dc1e8d6a84ff6ab993d8160d0aa0d41bd Mon Sep 17 00:00:00 2001 From: =josephproject1 <=joseph.kaberuka@glasgow.ac.uk> Date: Thu, 9 Nov 2023 13:01:53 +0200 Subject: [PATCH 07/13] Single in address space protection --- CHERIIn-Address-Space-Protection.c | 41 ++++++++++++++++++++++++++++++ 1 file changed, 41 insertions(+) create mode 100644 CHERIIn-Address-Space-Protection.c diff --git a/CHERIIn-Address-Space-Protection.c b/CHERIIn-Address-Space-Protection.c new file mode 100644 index 0000000..b4e6bd7 --- /dev/null +++ b/CHERIIn-Address-Space-Protection.c @@ -0,0 +1,41 @@ +#include + +struct capData { + +char data[100]; + +}; + +void component1(){ + +struct capData* sharedData =(struct capData*)cheri_malloc(sizeof(struct capData)); + +strcpy(sharedData->data, "Data from component1"); + +//.. some code to pass sharedData to component2 + +} + +//component2 + +void component2(struct capData* sharedData) { + +printf("component2 read: %s\n",sharedData ->data); + +} + +int main() { + + +struct capData* sharedData = NULL; + +component1(&sharedData); +component2(sharedData);//ensures that capability restricts access + +cheri_free(sharedData); + +return 0; + +} + + From ed9b42d332b333f1a200dff4134fb99f4c993a40 Mon Sep 17 00:00:00 2001 From: =josephproject1 <=joseph.kaberuka@glasgow.ac.uk> Date: Thu, 9 Nov 2023 13:21:31 +0200 Subject: [PATCH 08/13] Application compartmentalization --- ApplicationCompartmentalization.c | 45 +++++++++++++++++++++++++++++++ 1 file changed, 45 insertions(+) create mode 100644 ApplicationCompartmentalization.c diff --git a/ApplicationCompartmentalization.c b/ApplicationCompartmentalization.c new file mode 100644 index 0000000..857134c --- /dev/null +++ b/ApplicationCompartmentalization.c @@ -0,0 +1,45 @@ +#include +#include + +void componentA(){ + +char buffer[128]; + +//Assume cap_A is a capability for component A's memory + +_capability char* buffer_cap = cheri_setbounds(buffer, sizeof(buffer)); + +gets(buffer_cap); //protected by componentA's capability + +printf("componentA : You entered : %s\n", buffer); + +} + +void componentB (){ + +int secret_data =42; + +//Assume cap_B is a capability for component B's memory + +// componentB has no access to componentA's memory + + + +_capability int* secret_data_cap = cheri_setbounds(&secret_data, sizeof(secret_data)); + +printf("componentB secret data is %d\n", *secret_data_cap); + +} + +int main() { + +// component A and component B are isolated with separate capabilities + +componentA(); +componentB(); + +return 0; + +} + + From 5824d98874869dad6553e8cc72ae9725e3dcaa52 Mon Sep 17 00:00:00 2001 From: = <=> Date: Mon, 20 Nov 2023 13:24:34 +0200 Subject: [PATCH 09/13] Morello stack buffer over flow protection --- bufferOverflow.c | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) create mode 100644 bufferOverflow.c diff --git a/bufferOverflow.c b/bufferOverflow.c new file mode 100644 index 0000000..88b81ae --- /dev/null +++ b/bufferOverflow.c @@ -0,0 +1,27 @@ +#include + +void foo(char *str) + +{ + +char buffer[12]; + +/* The following statement will result in a buffer overflow */ + +strcpy(buffer, str); + +} + +int main() + +{ + +char *str = "This is definitely longer than 12"; + + +foo(str); + + +return 1; + +} From ca22001279978e1db0a39aed4c3ab9f08fc3c57d Mon Sep 17 00:00:00 2001 From: =josephproject1 <=> Date: Tue, 28 Nov 2023 14:40:21 +0200 Subject: [PATCH 10/13] =Morello protects a vulnerable program --- ExploitingBufferOverflow.c | 38 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 38 insertions(+) create mode 100644 ExploitingBufferOverflow.c diff --git a/ExploitingBufferOverflow.c b/ExploitingBufferOverflow.c new file mode 100644 index 0000000..0a0734b --- /dev/null +++ b/ExploitingBufferOverflow.c @@ -0,0 +1,38 @@ +#include +#include +#include + +int foo(char *str) + +{ + +char buffer[100]; + +/* The following statement has a buffer overflow problem */ + +strcpy(buffer, str); + +return 1; + + +} + + +int main(int argc, char **argv) + +{ + +char str[300]; + +FILE *riskfile; + +riskfile = fopen("riskfile", "r"); + +fread(str, sizeof(char), 300, riskfile); + +foo(str); + +printf("returned \n"); + +return 1; +} From 1047199f18710df48d21e60fe22041903e718b15 Mon Sep 17 00:00:00 2001 From: = <=> Date: Sun, 3 Dec 2023 17:28:52 +0200 Subject: [PATCH 11/13] StackMachineBufferOverflow --- StackMachineBufferOverflowExample1.rst | 107 +++++++++++++++++++++++++ 1 file changed, 107 insertions(+) create mode 100644 StackMachineBufferOverflowExample1.rst diff --git a/StackMachineBufferOverflowExample1.rst b/StackMachineBufferOverflowExample1.rst new file mode 100644 index 0000000..648f488 --- /dev/null +++ b/StackMachineBufferOverflowExample1.rst @@ -0,0 +1,107 @@ +========================== +"Buffer Overflow" Example +========================== + +Stack machine +------------- +For a typical C program, its memory is divided into different segments and stack is one of the segments. +Stack: The stack is used for storing local variables defined inside functions, data related to function calls including: +for example, return address, etc... + +The use of stack memory example +------------------------------- + +.. code-block:: C + + /** + * Stack and function call + */ + int x = 50; + int main() + { + int a = 5; //stored on stack + int b = 10; //stored on stack + static int y; + // allocation of memory on heap + int * myPtr = (int *) malloc(2*sizeof(int)); + // values 20 and 25 are stored on heap + myPtr[0]=20; //stored on heap + myPtr[1]=25; //stored on heap + + free(myPtr); + return(1); + } +In the above program, the variables a and b inside the program are local variables and they are stored on the program stack. +Notice that the variable myPtr is also a local variable, it is also stored on the stack. However, myPtr as a pointer, +pointing to a block of memory and dynamically allocated using malloc();the values 20, and 25 assigned to myPtr[0], +and myPtr[1], are stored on the heap. + +The understanding of how data is arranged inside a program memory helps to understand how buffer overflow attack and +Vulnerability works. + +Since buffer overflow can happen on both stack and heap, the ways to exploit them are somehow different and in the program +example below we focus on stack buffer overflow and it is important to understant what information that could be stored on +the program memory stack, as shown in the above program example. + +Stack is used for storing data in function calls. Normally, when a program runs it executes a series of function calls. +Whenever a function is called, a space is created and allocated on the stack for the execution of that function. + + +.. code-block:: function + /** + * function code + */ + + void myFunc(float x, float y) + { + float a, float b; + a = x*y; + b = x+y; + } + +When myFunc is called, a block of memory space will be allocated on top of the program stack and the values of the arguments, +will also be pushed into the stack. +When myFunc finishes, its return instructions, will be placed into the top of the program stack, and this is +a return address. + +Stack Buffer Overflow Vulnerability and attack +----------------------------------------------- +When a program needs to copy a memory, data from one place need to be copied to another place. +Before this happen, a program needs to allocate sufficient memory space to be able to copy for the destination buffer. +When more that are copied to the destination buffer than the amoout of allocated space, this creates a buffer overflow. + +.. code-block:: C + + /** + * buffer overflow program + */ + + #include + void foo(char *str) + { + + char buffer[12]; + + /* The following statement will result in a buffer overflow */ + + strcpy(buffer, str); + + } + int main() + + { + + char *str = "This is definitely longer than 12"; + foo(str); + return 1; + + } +The program stack memory for the aboe code, the local array buffer [] in foo () function has 12 bytes of memory. +The function foo() uses strcpy() to copy the string from str to the target buffer. +It is important to know that, normally this strcpy() function will not until it finds a number 0 in the above string. +Given that the provided string is longer that 12 bytes, strcpy() will need to overwrite some portion of the program stack, +and this causes a buffer overflow. +Some programming languages such as Java, can detect straightaway this simple mistake, when buffer is over-run. +But pointer languages, such as C or C++, can find hard to detect it. +As consequence, buffer overflow can cause a program to crash due to the corruption of the data beyond the buffer, +but could also enable adversaries or attackers to gain control of that program. From 36a20912e7df242e8981fa9e03cdb751f2178344 Mon Sep 17 00:00:00 2001 From: = <=> Date: Sun, 3 Dec 2023 18:23:26 +0200 Subject: [PATCH 12/13] StackMachineVulnerableProgram --- ...ineExploitingVulnerableProgramExample2.rst | 63 +++++++++++++++++++ 1 file changed, 63 insertions(+) create mode 100644 StackMachineExploitingVulnerableProgramExample2.rst diff --git a/StackMachineExploitingVulnerableProgramExample2.rst b/StackMachineExploitingVulnerableProgramExample2.rst new file mode 100644 index 0000000..32da6be --- /dev/null +++ b/StackMachineExploitingVulnerableProgramExample2.rst @@ -0,0 +1,63 @@ +======================================= +"Exploiting Buffer Overflow" Example 2 +======================================= + +In the first StackMachineBufferOverflowExample 1 shared from the project repository, adverasaries or attackers cannot easily take full control, +or advantage of it. +In this program, we can get a vulnerable buffer overflow program to run our code, this means, the attacker can take full control of the program. + +Stack Machine Vulnerable Program +-------------------------------- +.. code-block:: C + + /** + * vulnerable program with provided user input control + */ + /* This program has a buffer overflow vulnerability. */ + + #include + #include + #include + + int foo(char *str) + { + char buffer[100]; + /* The following statement has a buffer overflow problem */ + strcpy(buffer, str); + + return 1; + } + + int main(int argc, char **argv) + { + char str[300]; // reads 300 bytes + FILE *riskfile; + riskfile = fopen("riskfile", "r"); + fread(str, sizeof(char), 300, riskfile); + foo(str); + printf("returned \n"); + + return 1; + } + +The above program reads 300 bytes of data from a file "riskfile". It copies the 300 bytes to a buffer of size 100. +This creates a buffer overflow. + +In this program, the contents to be copied are in the full control of the user, and this is a likely scenario with real applications, +where the user provides input to the programs. + +As opposed to the first Stack Machine buffer overflow example1, in this program, the attacker can take advantage since the user can +control what to copy to the program memory buffer. + +Therefore, after we overflow the buffer, we can get the program run our code, possible malicious code can take advantage. +If the attacker places malicious code into the memory of the running program, which is not that hard, when the program start reading from +the "riskfile", the malicious code could be loaded into the str [] array, and when the program starts copying the content of this +str[] to the buffer, the malicious code will then be stored on the program stack. + +Therefore, the attacker can then force the running program to jump to the malicious code already in the program memory. +With buffer overflow vulnerability, we can overwrite the return address. + +If we know the address of malicious code, the attacker can use this address to overwrite the return address. +As result, when the function foo() returns, it could jump to the new address where the attacker malicious code is stored. + + From 17e36b8742633e0e13ebc23a00ce48dae660a4e1 Mon Sep 17 00:00:00 2001 From: = <=> Date: Tue, 26 Dec 2023 15:36:14 +0200 Subject: [PATCH 13/13] MorelloPreventionofAnotherStackMachineBufferOverflowExample2 --- ...therStackMachineBufferOverflowExample2.rst | 34 +++++++++++++++++++ 1 file changed, 34 insertions(+) create mode 100644 MorelloPreventionofAnotherStackMachineBufferOverflowExample2.rst diff --git a/MorelloPreventionofAnotherStackMachineBufferOverflowExample2.rst b/MorelloPreventionofAnotherStackMachineBufferOverflowExample2.rst new file mode 100644 index 0000000..6832cab --- /dev/null +++ b/MorelloPreventionofAnotherStackMachineBufferOverflowExample2.rst @@ -0,0 +1,34 @@ +=============================================== +"StackMachineBufferOverflowDetection" Example +=============================================== + +Buffer Overflow Protection +-------------------------- +For stack-based buffer overflow attackers or adversaries, need to modify the return address. +This means, if we can detect this modification before returning from a f(x) we can prevent it. There are different ways to achieve this +1. We can store a copy of the return address not on the stack, so that it cannot be overwitten via a buffer overflow +2. We can put a protection or a countermeasure strategy between a return address and the buffer + +N.B Though we are not implementing any of those measures, Morello detects this vulnerability, terminates and prevents it + + +.. code-block:: C + /* + Buffer overflow detection + */ + #include + #include + + void foo(char *str) + { + char buffer[12]; + /* Buffer Overflow Vulnerability */ + strcpy(buffer, str); + } + int main(int argc, char *argv[]) + { + foo(argv[1]); + printf("returned \n\n"); + return 0; + } +Morello detects buffer overflow again in this program and terminates it \ No newline at end of file