Memory Layout of C Programs. A typical memory representation of C program consists of following sections. 1.
Text segment 2. Initialized data segment 3. Uninitialized data segment 4. Stack 5. A typical memory layout of a running process 1. As a memory region, a text segment may be placed below the heap or stack in order to prevent heaps and stack overflows from overwriting it. Usually, the text segment is sharable so that only a single copy needs to be in memory for frequently executed programs, such as text editors, the C compiler, the shells, and so on. 2. Note that, data segment is not read-only, since the values of the variables can be altered at run time. This segment can be further classified into initialized read-only area and initialized read-write area.
For instance the global string defined by char s[] = “hello world” in C and a C statement like int debug=1 outside the main (i.e. global) would be stored in initialized read-write area. 3. 4. PC Assembly Language. Common vulnerabilities guide for C programmers. Intro Most vulnerabilities in C are related to buffer overflows and string manipulation.
In most cases, this would result in a segmentation fault, but specially crafted malicious input values, adapted to the architecture and environment could yield to arbitrary code execution. You will find below a list of the most common errors and suggested fixes/solutions. (Some tips for C++ are available here.) gets The stdio gets() function does not check for buffer length and always results in a vulnerability. Vulnerable code #include <stdio.h>int main () { char username[8]; int allow = 0; printf ("Enter your username, please: "); gets(username); // user inputs "malicious" if (grantAccess(username)) { allow = 1; } if (allow !
Mitigation Prefer using fgets (and dynamically allocated memory!) #include <stdio.h>#include <stdlib.h>#define LENGTH 8int main () { char* username, *nlptr; int allow = 0; username = malloc(LENGTH * sizeof(*username)); if (! Strcpy ("String copied: %s\n", dst); return 0;} sprintf. What is memory safety? - The PL Enthusiast. I am in the process of putting together a MOOC on software security, which goes live in October.
At the moment I’m finishing up material on buffer overflows, format string attacks, and other sorts of vulnerabilities in C. After presenting this material, I plan to step back and say, “What do these errors have in common? They are violations of memory safety.” Then I’ll state the definition of memory safety, say why these vulnerabilities are violations of memory safety, and conversely say why memory safety, e.g., as ensured by languages like Java, prevents them. No problem, right? My goal with this post is to work out a definition of memory safety for C that is semantically clean, rules out code that seems intuitively unsafe, but does not rule out code that seems reasonable. For the purposes of this post, we are generally considering whether a program execution is memory safe or not. Not in my house The wikipedia page on memory safety provides a similar definition.
Infinite spacing. What is type safety? - The PL Enthusiast. In response to my previous post defining memory safety (for C), one commenter suggested it would be nice to have a post explaining type safety.
Type safety is pretty well understood, but it’s still not something you can easily pin down. In particular, when someone says, “Java is a type-safe language,” what do they mean, exactly? Are all type-safe languages “the same” in some way? What is type safety getting you, for particular languages, and in general? In fact, what type safety means depends on language type system’s definition.
Basic Type Safety An intuitive notion of type safety is pithily summarized by the phrase, “Well typed programs cannot go wrong.” Going wrong Programming languages are defined by their syntax — what programs you’re allowed to write down — and semantics — what those programs mean. Well typed ⟹ Cannot go wrong In a type-safe language, the language’s type system is a particular way of ensuring that only the “right” (non-wrong) programs go through.
Beyond the Basics.