Week 1 — Introduction to Secure Programming and the Application Protection Plan¶

Click inside the slides and use the arrow keys; use the button at the bottom right of the slides or the link above for full screen.

mkdir C:\Dersler; cd C:\Dersler
git clone https://github.com/ucoruh/cen429-secure-programming.git
cd cen429-secure-programming\code
.\build.ps1
cd week-01\01-path-kandirma
.\demo.ps1

sudo apt install -y build-essential cmake gdb valgrind binutils
git clone https://github.com/ucoruh/cen429-secure-programming.git
cd cen429-secure-programming/code
./build.sh
cd week-01/01-path-kandirma
sh demo.sh

0. Before we start¶

This section prepares you for the week. As this is the first week of the course, it builds on no earlier topic: the concept map below defines each of this week's concepts in one sentence and links it to the section where it is explained in full.

This week's concept map¶

1. What is security?¶

Security means protecting a system against a deliberate attacker who wants to harm it; unlike an ordinary software bug, there is a conscious adversary on the other side. To make this concrete, think of a bank's safe. The money inside the safe is the asset. Someone who wants to steal the money is the threat. The safe's lock being faulty is a vulnerability. The thief using that faulty lock is the attack. Risk is the answer to the question "how likely is this event, and how much damage does it cause if it happens?"

Software has the same chain; only the program stands in for the safe, and data stands in for the money.

The three goals of security: CIA¶

When we talk about security, we are almost always trying to protect these three things; together they are known as the CIA triad (confidentiality, integrity, availability):

Three more concepts are often added to these: authentication (are you really who you say you are?), authorization (do you have permission to do this?), and accountability / non-repudiation (who did this, and can they deny it afterward?).

The difference between a bug and a vulnerability¶

Not every software bug is a security hole; but the vast majority of security holes are ordinary software bugs. Once a bug lets an attacker achieve the outcome they want, it becomes a vulnerability.

2. Why "secure programming"?¶

Firewalls, antivirus software, network monitoring... All of these matter, but they cannot rescue a badly written program. The attacker comes in through the door that is left open — the program itself. Secure programming treats security not as a layer bolted on afterward, but as decisions made while writing the code:

• Don't trust input; validate every input (length, type, range, allowed characters).
• Keep secrets in memory for the shortest time possible, and erase them securely once you're done.
• Don't trust the environment the program runs in (environment variables, file permissions, the programs it invokes).
• If an error occurs, stay on the safe side: refuse, shut down, don't leak.
• Turn on the protections the compiler and operating system offer, and test with tools (sanitizers, fuzzing).

Over the term we will apply these principles first in C/C++, then in Java, and then in the world where "the program is in the attacker's hands" (runtime protection, code obfuscation, white-box cryptography).

3. Who is the attacker, and what can they reach?¶

The first question in evaluating any security measure is: "Against whom?" The same countermeasure may be enough against one attacker and useless against another. That's why every project starts by writing down an attacker model.

4. The basic principles of secure design¶

The principles Saltzer and Schroeder wrote in 1975 are still the backbone of secure design today. Keep each one in mind with a one-sentence example:

Let's add one modern principle to these: defence in depth. We don't rely on a single countermeasure; we build layers that complement each other. If one is bypassed, the next one takes over. In week 3 we will see how a sensitive key is carried inside exactly four separate protection layers (a security shell).

5. Overview of application protection: the defence-in-depth map¶

So far we have talked about what security is and against whom we are protecting. Now let's map out the toolbox we will use for the rest of the term. "Application protection" is not a single technique; it is a whole of complementary layers. Each layer answers a different question and stands against a different attacker capability.

Why a single countermeasure is not enough¶

Think of a building. You've fitted a good lock on the door. But if the window is open, the key is under the doormat, or the safe inside has no combination, the lock alone means nothing. It's the same in software:

• Your code can be bug-free, but the attacker can open the binary and read your logic.
• You can hide your logic, but the attacker can stop the running program with a debugger and read its memory.
• You can protect memory against being monitored, but if the key sits in the code as plain text, a single string scan is enough.
• You can hide the key, but the attacker can change a check in the binary (e.g. making the "is the license valid?" question always answer "yes") and bypass the protection entirely.

Each line shows what one countermeasure does not solve. This is the logic of defence in depth: each layer closes the path the previous one left open; the attacker has to defeat all of them at once, and that multiplies the cost.

Seven layers¶

The diagram below orders the layers we will see this term from the inside out. The inner layers deal with "write the code correctly"; the outer layers deal with "what happens once the code is in the attacker's hands?"

Which layer matters when? Choosing by attacker model¶

Not every application needs all seven layers equally. The choice is driven by the attacker model we defined in section 3:

The critical distinction here is: on the server side, your code runs on a machine you control; the attacker only controls the inputs. On the client side (phone, desktop, game console), the attacker owns the program itself: they can copy it, open it, modify it, and re-run it as many times as they like. This model is called the "white-box" attacker, and layers 4, 5, and 6 exist precisely for this attacker.

The white-box attacker's six paths¶

The security guide for a sensitive library running on the client side typically summarizes the attacker's goals in a six-row attack table. Each row is a question that at least one of the layers has to answer:

This table is the starting point for the threats section of a protection plan: for every asset, you write down how each of these six paths is closed off.

The same set of requirements has two more items that state plainly why defence in depth is mandatory:

• The application must not rely solely on security functions that have no assurance of their own: features like the OS's protections, a keychain, an app sandbox, or a hardware-backed key store vary from device to device and can be disabled by the attacker.
• Mechanisms the platform provides (e.g. the OS's crypto library) can be used, but only in addition to the application's own protections.

Defensive programming is listed item by item in the same place: every input and output is checked; assets are processed for the shortest time possible; assets are never passed in the clear even across interfaces inside the code; delays are added against timing-correlation attacks; and a secure erase function that wipes the data is used once the work is done. We will apply every one of these rules over the course of the term.

The cost of protection: every layer has a price¶

Adding a layer is never free; security involves a constant trade-off between speed and complexity — the goal is not infinite protection but balanced protection, with the remaining risk written down explicitly. When writing a protection plan, you weigh these four costs for every layer:

1. Performance: Obfuscated code runs slower (e.g. control-flow flattening can slow a function down several times over). Integrity checking and debugger detection also cost CPU time.
2. Size: Obfuscation, virtualisation, and table-based white-box cryptography make the binary bigger.
3. Development and maintenance: Bugs in obfuscated code are hard to debug; crash reports become unreadable. That's why obfuscation is applied only to sensitive sections, and symbol-mapping files are kept somewhere safe.
4. False positives: An overly sensitive root or emulator check can punish a legitimate user (e.g. a phone with developer options turned on).

That's why every countermeasure in a protection plan is written with its justification: "We protect this asset, against this attacker, at this cost." A countermeasure with no written justification is either unnecessary or in the wrong place.

The path we'll follow through the semester¶

We will fill in this map by opening up one layer each week:

Try it yourself¶

1. What is the attacker model for an offline password manager (all data on the user's computer)? Which of the seven layers matter most? Why?
2. Under what conditions is the statement "our app runs on the server, we don't need obfuscation" true, and under what conditions is it false?
3. A game company uses only obfuscation to stop cheating. Which attack path stays open?

6. The application protection plan¶

The security of a piece of software is not left to chance; it is managed with a written plan. In products that go through security certification at an independent lab, this plan turns into a security guide hundreds of pages long. In this course, you too will write a small version of one for your term project. The backbone of the plan is:

The plan is not written once and forgotten: every time the product changes (a new feature, a bug fix, a new release) you return to step 1 and update the plan.

1. Scope: What are we evaluating? Saying "version 2.1" alone is not enough — which binary, which source code, which hash value? In certification this is called the target of evaluation.
2. Architecture and interfaces: What are the components, which channel do they talk to each other over, and how is identity verified on each channel?
3. Assets: every piece of data to be protected is listed one by one: where does it live, when is it created, when is it erased, does it need confidentiality (C) or integrity (I)?
4. Threats: who is the attacker (see section 3), and by what path can they reach each asset?
5. Countermeasures: for each threat, which countermeasure, in which layer?
6. Verification: how is it proven that each countermeasure actually works — a unit test, a bypass attempt?
7. Residual risk: the risks that cannot be closed, or are knowingly accepted, and why (e.g. performance).

The plan's two core tools: the interface table and the asset table¶

Steps 2 and 3 of the plan are written with two tables; we will use this same method throughout the whole term. Let's see the method on an example architecture: a mobile app that makes contactless payments over the phone's NFC, and a security library that does its critical work. Part of the library is in Java, while the most security-sensitive part runs in a native layer written in C/C++.

Notice two things in this diagram:

• The phone box is labelled "untrusted environment." The phone is in the user's — i.e., a potential attacker's — hands. It may be rooted, it may have a debugger attached. That's why the design starts from the assumption "I do not trust the phone."
• Every arrow labelled with a letter is an interface. The following table is filled in for each interface:

And a slice of the asset table (the values are synthetic):

7. Threat modelling: STRIDE and attack trees¶

Threat modelling means asking, systematically, "if I were the attacker, how would I attack this?" One of the most common methods is STRIDE, developed at Microsoft: each letter is a family of threats and the security property it breaks.

Applying it is simple: draw the system's data flow diagram (external entities, processes, data stores, data flows, and trust boundaries), then ask all six letters for every element, one by one. Every arrow that crosses a trust boundary is where the most threats come from.

Attack tree¶

In an attack tree, the root is the attacker's goal; the branches below it are the ways to reach that goal. In an OR node one branch is enough; in an AND node all of them are required. Once the tree is drawn, the cheapest path and the key points to defend fall out on their own.

Two conclusions follow immediately from this tree: (1) Path C is expensive because it requires breaking two layers at once — that's defence in depth at work. (2) Path B has three alternatives; that means the key in memory is the weakest point, and it needs dedicated countermeasures (this week's Demo 2, runtime protection in week 6, white-box in week 11).

8. Going deeper into threat modelling: the data flow diagram, STRIDE in detail, and risk scoring¶

In the previous section we met STRIDE and the attack tree. In this section we'll learn to apply the method step by step, like an engineer: how do we draw the diagram, which letters do we ask of each element, and how do we rank the dozens of threats that come out of it?

The four elements of a data flow diagram (DFD) and the trust boundary¶

The diagram used in threat modelling is a simplified version of the data flow diagram you know from software engineering courses. There are only five symbols:

The concept of the trust boundary is the heart of the method. The moment a piece of data crosses a trust boundary, it becomes "data that came from the other side" and cannot be used without validation. Most threats are born at these crossings. A practical rule: color every arrow that crosses a trust boundary red in your diagram, and start your review there.

Which letter applies to which element?¶

Not every element is exposed to all six threats. The "STRIDE-per-element" table that Microsoft popularized shows which questions actually make sense:

¹ If the data store is an audit log, the repudiation threat is asked too: if the record is deleted or altered, who did what can no longer be proven.

The logic of the table is intuitive: a data flow (e.g. a network packet) cannot be spoofed, because it has no "identity"; but it can be eavesdropped on (I), altered (T), or cut off (D). A process, on the other hand, is exposed to all six threats: it can be impersonated, its code can be altered, its memory can be read, it can be crashed, its privilege can be abused.

Questions to ask for each letter, and typical countermeasures¶

Ranking threats: likelihood × impact¶

Threat modelling on a medium-sized system easily produces 50–100 threats. You cannot close all of them at once. That's why every threat gets a risk score. The simplest method is to score likelihood and impact from 1 to 3 and multiply them:

When determining likelihood, ask what the attacker needs: does it require physical access, or can it be done over the internet? Does it need special tooling or expertise? Can the attack be automated? When determining impact, go back to the asset table: which asset is affected, how many users are affected, what is the financial or legal consequence?

Four responses to a threat¶

For every threat, you consciously choose one of four options and write it into the plan:

1. Mitigate: Add a countermeasure. The most commonly chosen response.
2. Eliminate: Remove entirely the feature that causes the threat. E.g. if a "remember my password" feature isn't necessary, never writing it at all zeroes out the threat of the password being stored on disk. This is the strongest response.
3. Transfer: Hand the risk off to someone else. E.g. never storing card data at all and leaving it to the payment service provider, or an insurance policy.
4. Accept: Knowingly take on the risk and write down the justification. E.g. "We take no countermeasure against the chip being physically opened and examined; the cost of this attack is higher than the value it protects."

9. Worked example: writing a protection plan step by step¶

Now let's apply all the tools from the previous three sections, start to finish, on a small application. This example will serve as a template for the first deliverable of your term project.

Step 0 — Define the application¶

Let "Vault" be a password vault, written in C++, running on the desktop:

• The user sets a master password. The vault encrypts the records inside it (site name, username, password) with a key derived from this master password and stores them in a single file.
• The user can copy a record's password to the clipboard.
• Optionally, the encrypted vault file can be sent to a backup server.
• The application downloads new versions from an update server.

Step 1 — Scope¶

The "out of scope" row matters: writing down explicitly what you are not protecting is as valuable as writing down what you are.

Step 2 — Architecture and interfaces¶

Step 3 — Assets¶

The "Protection" column uses four values: C (confidentiality), I (integrity), I+ (integrity plus accountability and authentication: the data's origin must also be verified; in the field this is provided by an authentication code shared with the server), and N (no protection needed). Asset tables used in the field also record each asset's size, the source of its value, its default value, and which table or file it lives in; static, dynamic, and cryptographic assets are listed in separate tables.

Step 4 — Threats (STRIDE, interface by interface)¶

Step 5 — Countermeasures¶

Step 6 — Verification plan¶

For every countermeasure, you write down the answer to "how do I prove this works?" If a countermeasure has no test, it counts as if it doesn't exist in the evaluator's eyes.

Step 7 — Residual risk¶

Common mistakes¶

• Forgetting assets: writing only "user data" and never listing keys, tokens, counters, configuration files, and the code itself (which is an asset whose integrity must be protected).
• Drawing the trust boundary wrong: putting the client application you wrote yourself in the "trusted" box. If the client runs on the user's machine, it is untrusted.
• Not matching a countermeasure to a threat: saying "we use TLS" is incomplete without saying which threat TLS closes (eavesdropping and tampering) and which it does not (data at the server, the client itself).
• A countermeasure with no test: saying "we erase the password from memory" and never checking whether the compiler removed that erasure (this week's Demo 2 is exactly this).

10. At program start-up: an untrusted environment¶

When a program starts running, it does not start with a blank page. It inherits a lot from whoever launched it: environment variables (PATH, LD_PRELOAD, IFS...), open file descriptors, the working directory, umask, resource limits. If the program trusts these, then whoever controls them also controls the program's behaviour. The first chapter of our source book (Viega & Messier, recipes 1.1–1.9) deals with exactly this topic of "secure start-up."

Demo 1 — Fooling the program via PATH¶

When you call a command without an absolute path, the shell searches the folders in the PATH variable from left to right and runs the first one it finds:

On Windows the situation is even worse: cmd.exe searches the working directory before PATH, and it also tries extensions like .bat and .cmd. Even which folder you run the program from can change which file actually runs.

Buggy code:

#ifdef _WIN32
#define KOMUT "hostname"
#else
#define KOMUT "date"
#endif

int main(void)
{
    printf("=== Aylik Satis Raporu ===\n");
    fflush(stdout);

    /* HATA: çıplak komut adı + kabuk + devralınan ortam (PATH, ...) */
    int durum = system(KOMUT);
    ...
}

Run the demo:

cd code\week-01\01-path-kandirma
.\demo.ps1

cd code/week-01/01-path-kandirma
sh demo.sh

ADIM 1 — Normal calisma: program gercek date'i buluyor
=== Aylik Satis Raporu ===
Rapor tarihi: Sat Sep 19 19:11:32 +03 2026

ADIM 2 — Saldiri: PATH'in basina sahte/ klasoru ekleniyor
$ PATH="$PWD/sahte:$PATH" ./bin/linux/rapor
=== Aylik Satis Raporu ===
Rapor tarihi:
  !!! SAHTE 'date' calisti !!!
  Program PATH uzerinden kandirildi. ...

ADIM 3 — Duzeltilmis surum ayni saldiri altinda
=== Aylik Satis Raporu ===
Rapor tarihi: Sat Sep 19 19:11:32 +03 2026

The fake date here only prints a message. A real attacker, at the very same point, could do anything they wanted with all the privileges of whoever runs the program. If the program runs with elevated privilege (e.g. a system service), this is a direct privilege escalation.

The fixed code does three things at once: 1) an absolute path, 2) no shell, 3) a small, known environment.

char *const arguman[]     = { "date", NULL };
char *const temiz_ortam[] = { "PATH=/usr/bin:/bin", "LANG=C", NULL };

pid_t pid;
int hata = posix_spawn(&pid, "/bin/date", NULL, NULL,
                       arguman, temiz_ortam);

/* 1) C:\Windows\System32\hostname.exe — tam yol */
GetSystemDirectoryW(sistem, MAX_PATH);
swprintf(program, MAX_PATH, L"%ls\\hostname.exe", sistem);

/* 3) ortam bloğunda yalnız SystemRoot */
swprintf(ortam, MAX_PATH + 16, L"SystemRoot=%ls", kok);

/* 2) cmd.exe yok: program doğrudan başlatılır */
CreateProcessW(program, komut_satiri, NULL, NULL, FALSE,
               CREATE_UNICODE_ENVIRONMENT, ortam, NULL, &si, &pi);

11. Secure start-up: what to do in a program's first lines¶

Demo 1 showed how a single inherited environment variable (PATH) can turn all of a program's security upside down. PATH is not the only danger. The first chapter of our source book (Recipes 1.1–1.9) lists what a program should do in the first lines of its main() function. In this section we will update that list for today's systems and work through it step by step.

What does a program have when it starts?¶

When a process is started with exec (CreateProcess on Windows), it inherits the following from its parent:

The rule is simple: do not trust anything the program itself did not set up. The program's first job is to bring this inherited state to a known, safe state.

Step 1 — Clean the environment (Recipe 1.1)¶

There are two approaches: deleting the bad variables one by one (a blocklist), or wiping the environment entirely and rebuilding only what's needed (an allowlist). A blocklist is always incomplete, because you cannot know today which variable will turn out to be dangerous tomorrow. The right approach is the allowlist:

#include <stdlib.h>
#include <string.h>

static void ortami_temizle(void)
{
    const char *tz = getenv("TZ");          /* korunacak değişkeni önce kopyala */
    char tz_kopya[64] = "";
    if (tz && strlen(tz) < sizeof tz_kopya)
        strcpy(tz_kopya, tz);

    clearenv();                              /* glibc; taşınabilir değil (aşağıya bakın) */
    setenv("PATH", "/usr/bin:/bin", 1);      /* bilinen, yazılamaz dizinler */
    if (tz_kopya[0])
        setenv("TZ", tz_kopya, 1);
}

If you need to use a variable (e.g. the user's HOME), treat it like an input: limit its length, verify it has the expected shape (Recipe 3.6). On Windows the environment is inherited the same way; there, alongside PATH, the DLL search order is also a danger (Step 6 below).

Step 2 — Tidy up file descriptors (Recipe 1.5)¶

There are two separate problems:

1. If 0, 1, 2 are closed: The attacker starts the program with its standard output closed. The first file the program opens (e.g. a password file) gets descriptor 1. Every subsequent printf then writes into that file.
2. Extra open descriptors: The parent hands the child a file or socket it left open without marking close-on-exec. The child can use that descriptor to reach a resource it normally couldn't.

#include <fcntl.h>
#include <unistd.h>
#include <stdlib.h>

static void tanitici_duzenle(void)
{
    for (int fd = 0; fd <= 2; fd++) {
        if (fcntl(fd, F_GETFD) == -1) {           /* kapalı mı? */
            int yeni = open("/dev/null", O_RDWR);
            if (yeni != fd)                        /* tam olarak o numarayı almalı */
                abort();
        }
    }
    /* Linux 5.9+ / glibc 2.34+: tek çağrıda 3 ve üstünü kapat */
    close_range(3, ~0U, 0);
}

On older systems, close() is called in a loop up to sysconf(_SC_OPEN_MAX); if the limit is very large (e.g. a million) this can be slow, which is why close_range was added. For files you open yourself, always use the O_CLOEXEC flag, so they don't leak into a child process you launch later.

Step 3 — Restrict the permissions of new files (Recipe 2.7)¶

#include <sys/stat.h>
umask(077);     /* yeni dosyalar yalnız sahibine açık: rw------- */

umask is a mask: the bits set in it are subtracted from the permissions you pass to open(). With 077, no bits are left for group and others. Even so, write the permission explicitly when opening a sensitive file: open(path, O_WRONLY | O_CREAT | O_EXCL, 0600). O_EXCL refuses to open the file if it already exists (e.g. if it's a link the attacker pre-created); recall the TOCTOU demo from week 2.

Step 4 — Disable crash dumps (Recipe 1.9)¶

When a program crashes, the operating system may write the process's entire memory to a file to help with debugging. If that memory holds a password, a key, or decrypted data, all of it ends up sitting on disk as plain text. Demo 2's password can be found in exactly this way.

#include <sys/resource.h>
#include <sys/prctl.h>

static void dokumu_kapat(void)
{
    struct rlimit r = { 0, 0 };
    setrlimit(RLIMIT_CORE, &r);            /* çekirdek dökümü boyutu 0 */
    prctl(PR_SET_DUMPABLE, 0, 0, 0, 0);    /* döküm yok, aynı kullanıcı bile ptrace ile bağlanamaz */
}

#include <windows.h>

static void dokumu_kapat(void)
{
    /* Çökme iletişim kutusunu ve kritik hata kutularını kapat */
    SetErrorMode(SEM_FAILCRITICALERRORS | SEM_NOGPFAULTERRORBOX);
}

Step 5 — Drop unneeded privilege (Recipes 1.2–1.4)¶

If your program needs elevated privilege temporarily to do one thing (e.g. opening a port below 1024), it must drop that privilege permanently right after doing that thing.

#include <unistd.h>
#include <stdlib.h>

static void yetkiyi_birak(void)
{
    uid_t u = getuid();
    gid_t g = getgid();

    if (setresgid(g, g, g) != 0) abort();   /* önce grup: sonra buna yetkimiz kalmaz */
    if (setresuid(u, u, u) != 0) abort();   /* gerçek, etkin ve saklı kimliğin üçü de */

    uid_t r, e, s;
    getresuid(&r, &e, &s);
    if (r != u || e != u || s != u) abort();  /* bıraktığını DOĞRULA */
}

Three details are critical: (1) group first, then user — if you drop the user first, you no longer have the privilege to change the group. (2) seteuid(), which changes only the effective identity, is temporary; the saved identity stays privileged and privilege can be regained (week 2, Demo 13). (3) The result of dropping privilege is always verified; a setuid() call whose return value goes unchecked has caused real-world bugs.

On Windows the same idea is implemented with a restricted token: CreateRestrictedToken builds a token with administrator groups and privileges stripped out, and the risky work is done in a child process running with that token (Recipe 1.2). A stronger approach is privilege separation (Recipe 1.4): splitting the program into two processes — a small piece that needs privilege, and a large piece that runs unprivileged. A browser running every tab in an unprivileged "sandbox" process is today's version of this idea.

Step 6 — Care when loading other programs and libraries (Recipes 1.6–1.8)¶

The Windows DLL search order problem is the twin of the PATH problem: if the program finds the library it wants in a folder the attacker left behind, that library's code runs with the program's privilege (CWE-427).

All together: guvenli_baslat()¶

int main(int argc, char **argv)
{
    tanitici_duzenle();   /* Adım 2 — Windows: gerek yok, tanıtıcılar varsayılan olarak devralınmaz */
    ortami_temizle();     /* Adım 1 — Windows: SetDefaultDllDirectories + PATH doğrulaması */
    umask(077);           /* Adım 3 — Windows: dosyayı açıkça kısıtlı DACL ile oluştur */
    dokumu_kapat();       /* Adım 4 — Windows: SetErrorMode */
    yetkiyi_birak();      /* Adım 5 — Windows: kısıtlanmış belirteç / ayrı süreç */

    /* ... programın asıl işi ... */
    return 0;
}

The order is not arbitrary: descriptors and the environment must be tidied up before the program does anything else, because every later step (e.g. writing an error message) depends on them.

12. Secrets left in memory¶

What happens to a password after you use it? The variable goes out of scope, but the memory is not erased; those bytes sit there until something else is written over them. If an attacker can see that memory, they read the secret. There are more situations where memory can be seen than you might think:

• The crash dump (core dump) file created when the program crashes,
• The swap area and the hibernation file, where the operating system writes memory to disk,
• A debugger attaching to the process,
• Another piece of code that later reuses the same memory reading its old contents.

Demo 2 — The password left in memory¶

unsigned long giris_yap(const char *dosya)
{
    char parola[64];
    /* düşük düzey okuma: parola yalnız bu dizide durur */
    int fd = dosya_ac(dosya);
    int n = (int)dosya_oku(fd, parola, sizeof(parola) - 1);
    ...
    unsigned long anahtar = anahtar_turet(parola, (size_t)n);

#if SILME == 1
    memset(parola, 0, sizeof(parola));         /* "ölü yazma" */
#elif SILME == 2
  #ifdef _WIN32
    SecureZeroMemory(parola, sizeof(parola));  /* kaldırılamaz */
  #else
    explicit_bzero(parola, sizeof(parola));    /* kaldırılamaz */
  #endif
#endif
    return anahtar;
}

cd code\week-01\02-bellekte-parola
.\demo.ps1

cd code/week-01/02-bellekte-parola
sh demo.sh

ADIM 1 — Parolayi hic silmeyen surum
  SONUC: parola dokumde 1 yerde BULUNDU  ->  Gizli-Parola-2026

ADIM 2 — memset ile silen surum (-O2)
  SONUC: parola dokumde 1 yerde BULUNDU  ->  Gizli-Parola-2026

ADIM 3 — explicit_bzero ile silen surum (-O2)
  SONUC: parola dokumde bulunamadi

Neden? giris_yap() fonksiyonunun makine kodu:
  memset surumunde silme komutu sayisi    ->  0
  explicit surumunde explicit_bzero cagrisi ->  1

The second step is surprising: the code plainly writes memset, yet the password is still in memory! The reason is the compiler's optimisation. The compiler reasons like this: "the parola array is never read after this line; writing zeros into it has no effect on the program's result. So this write is redundant, I can remove it." This is called dead store elimination. This optimisation, which speeds up ordinary programs, leaves a secret sitting in memory in security code. This isn't unique to GCC either: MSVC with /O2 on Windows produces the same result. See for yourself: on Linux, search for giris_yap with objdump -d bin/linux/parola_memset | less; in Visual Studio, put a breakpoint on giris_yap and open Debug > Windows > Disassembly. There isn't a single instruction belonging to memset.

13. Process memory: where does your data live?¶

To understand overflow bugs, we first need to know how a program's memory is laid out. A process running on Linux has virtual memory laid out roughly like this:

When a function is called, a stack frame is allocated for it on the stack. Local variables sit side by side in this frame. C does not check when the end of an array is reached: if you write a 17^th byte into an ad[16] array, C does not stop you, and that byte overwrites whatever comes right after it in memory.

Let's look at the structure from Demo 3:

struct oturum {
    char ad[16];
    int  yonetici;   /* 0 = normal kullanıcı */
};

x86-64 processors are little-endian: an integer's least significant byte sits at the lowest address. That's why writing 'B' (0x42) into the first byte of yonetici turns the integer into 66 — and any non-zero value means "administrator."

14. Buffer overflows: how they happen, how to prevent them¶

In the previous section we saw the regions of a process's memory. Now let's meet the oldest, and still the most common, bug in that memory. A buffer overflow is when a program writes more data into an array than the space allocated for it. The overflowing bytes don't vanish; they get written into the memory right next to the array — that is, on top of other variables. "Out-of-bounds write" (CWE-787) has sat near the top of the CWE Top 25 list for years.

Why does C overflow so easily?¶

In languages like Java, C#, and Python, when you try to write past the end of an array, the runtime stops you (ArrayIndexOutOfBoundsException). In C and C++, however:

1. An array is nothing more than consecutive bytes in memory; it does not know its own size.
2. When you pass an array to a function, only its starting address goes along (char *); the size information is lost.
3. Strings are not a separate type; they are a char array marked at the end with a '\0' byte. Functions like strcpy, strcat, and sprintf copy the source until they see the zero byte; they never ask how much room the destination has.
4. The compiler adds no bounds checking, so as not to give up speed.

The result: checking the bound is entirely the programmer's responsibility. Forget it once, and the bug is there.

A stack overflow, step by step¶

The function below copies a username into a small local array:

void selamla(const char *ad)
{
    int  yetkili = 0;
    char tampon[16];

    strcpy(tampon, ad);          /* ad 16 bayttan uzunsa? */
    printf("Merhaba %s\n", tampon);
    if (yetkili) { /* ... */ }
}

When the function is called, a stack frame is created for it. Inside that frame sit the local variables, the address of the previous frame, and the return address that says where to go once the function ends. A simplified view (lowest address at the top; the real layout varies by compiler):

There are three cases:

The last part of the third row is what makes an overflow this dangerous: whoever controls the return address controls which code the program runs next. This was the entry point for most outbreaks from the Morris worm in 1988 to Slammer in 2003 (week 2). Today's operating systems and compilers add protections that make this path much harder (below), but the bug itself is still in your code, and the protections don't close every case. In this course we care about how the bug happens, is found, and is prevented — not about how to exploit it.

Types of overflow¶

Off-by-one: the most innocent-looking overflow¶

char ad[8];
for (int i = 0; i <= 8; i++)     /* 9 kez döner: ad[8] dizinin dışında */
    ad[i] = kaynak[i];

char ad[8];
strncpy(ad, kaynak, sizeof ad);  /* kaynak ≥ 8 ise ad '\0' ile BİTMEZ */
printf("%s\n", ad);              /* printf dizinin sonundan okumaya devam eder */

strncpy's name is misleading: it is not a safe strcpy. If the source is longer than the destination it does not add a terminator; if it's shorter, it needlessly pads the rest of the destination with zeros. Even a single-byte overflow is enough to change the low byte of an adjacent variable, or a saved frame address.

Dangerous functions and what to use instead¶

The right pattern: validate first, then copy with a bound¶

#include <stdio.h>
#include <string.h>

int selamla(const char *ad)
{
    char tampon[16];
    size_t n = strnlen(ad, sizeof tampon);

    if (n == sizeof tampon)            /* 15 karakterden uzun: reddet, sessizce kesme */
        return -1;

    memcpy(tampon, ad, n);
    tampon[n] = '\0';
    printf("Merhaba %s\n", tampon);
    return 0;
}

This pattern makes three decisions:

1. With strnlen, the length is measured over at most the buffer size in bytes; even if the source never terminates, the read never goes past the bound.
2. Long input is rejected. Silently truncating is sometimes correct (e.g. a title to be displayed on screen), but when a credential, a file path, or a command is truncated, its meaning can change: /home/ayse/gizli_rapor.txt truncated can become /home/ayse/gizli. From a security standpoint, rejecting ambiguous input is safer.
3. The terminator is written explicitly, in every case.

In C++, the language does the same job for you:

#include <string>
#include <iostream>

void selamla(const std::string &ad)
{
    if (ad.size() > 15) throw std::invalid_argument("ad cok uzun");
    std::string tampon = ad;                   /* kendi belleğini kendi yönetir */
    std::cout << "Merhaba " << tampon << '\n';
}

Who catches the overflow? Layers of defence¶

Defence against overflows is layered too. The innermost layer is correct code; the outer layers limit the damage when a bug slips through:

We will examine each of these protections in week 4 by turning them on and off one at a time. This week keep this idea in mind: a protection makes exploitation harder; it does not fix the bug. When the canary is corrupted, it terminates the program — meaning the attacker can still crash the program even if they can't hijack control flow. That, too, is a denial of service.

Catching an overflow with AddressSanitizer¶

If you compile the buggy selamla function above with the sanitizer turned on and call it with a 20-character name, the overflow is caught before the program's logic is even corrupted. The output looks like this (abridged; addresses change on every run). You will produce a report of the same kind yourself with Demo 3's giris_asan target:

==12345==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffd...
WRITE of size 21 at 0x7ffd... thread T0
    #0 in strcpy
    #1 in selamla  ornek.c:7
    #2 in main     ornek.c:15
Address 0x7ffd... is located in stack of thread T0 at offset 48 in frame
    #0 in selamla  ornek.c:3
  This frame has 1 object(s):
    [32, 48) 'tampon' <== Memory access at offset 48 overflows this variable

Read it in this order: what happened (a stack overflow, a 21-byte write), where it happened (ornek.c line 7, strcpy), which variable (tampon, 16 bytes: the 32–48 range; the access is at 48, i.e. it starts exactly one byte past the bound). The sanitizer slows the program down roughly twofold and increases memory use; that's why it is used in test builds, not in release builds.

15. Demo 3 — Privilege escalation via buffer overflow¶

struct oturum o;
o.yonetici = 0;

strcpy(o.ad, argv[1]);  /* HATA: hedefin 16 bayt olduğu hiç denetlenmiyor */

if (o.yonetici)
    printf(">>> YONETICI paneline erisim verildi! <<<\n");

The demo compiles the same buggy code in four different ways and tries the same attack:

cd code\week-01\03-tasma-giris
.\demo.ps1

cd code/week-01/03-tasma-giris
sh demo.sh

ADIM 1 — Normal giris
$ ./bin/linux/giris ayse
Hos geldin, ayse
yonetici alani = 0 (0x00000000)
Normal kullanici oturumu.

ADIM 2 — Saldiri: 16 bayttan 1 bayt fazla ad (17 karakter)
$ ./bin/linux/giris AAAAAAAAAAAAAAAAB
Hos geldin, AAAAAAAAAAAAAAAAB
yonetici alani = 66 (0x00000042)
>>> YONETICI paneline erisim verildi! <<<

ADIM 3 — Ayni saldiri, AddressSanitizer ile derlenmis surumde
$ ./bin/linux/giris_asan AAAAAAAAAAAAAAAAB
Hos geldin, AAAAAAAAAAAAAAAAB
yonetici alani = 66 (0x00000042)
>>> YONETICI paneline erisim verildi! <<<
   ^ ASan sessiz kaldi: tasma yapinin ICINDE kaldi.

ADIM 4 — Yapinin disina tasan uzun ad, ASan surumu
==1750==ERROR: AddressSanitizer: stack-buffer-overflow on address ...
WRITE of size 41 at 0x7fffffffe8c4 thread T0

ADIM 5 — Ayni kisa saldiri, _FORTIFY_SOURCE=2 ile derlenmis surumde
$ ./bin/linux/giris_denetimli AAAAAAAAAAAAAAAAB
*** buffer overflow detected ***: terminated
   (program, derleyicinin ekledigi denetimle durduruldu)

ADIM 6 — Duzeltilmis surum
$ ./bin/linux/giris_guvenli AAAAAAAAAAAAAAAAB
Reddedildi: ad 1-15 karakter; yalniz harf, rakam, _ ve - olabilir.

The flow is the same on Windows. Only in step 5, strcpy_s knows the target is 16 bytes, so it sees the overflow and stops the program:

> .\bin\windows\giris_denetimli.exe AAAAAAAAAAAAAAAAB
*** Guvenli kutuphane islevi tasmayi algiladi: program durduruldu ***
   (cikis kodu: 3)

Three lessons come out of this demo:

1. A single byte of overflow is enough. The attacker doesn't need to crash the program; changing a single flag can be enough to escalate privilege.
2. Tools have limits. AddressSanitizer places a "forbidden zone" around every object in memory; but because the overflow stayed inside the same struct (ad → yonetici), it didn't catch it. It caught it immediately once the overflow went outside the struct. _FORTIFY_SOURCE (Linux) and strcpy_s (Windows), on the other hand, knew the target (o.ad) was 16 bytes, so they caught the short overflow too. Don't rely on a single tool.
3. The real fix lives in the code. Tools find the bug; fixing it is the programmer's job.

/* İzin listesi: 1–15 karakter; harf, rakam, '_' ve '-' */
static int ad_gecerli_mi(const char *s)
{
    size_t n = strnlen(s, 16);
    if (n == 0 || n >= 16)
        return 0;
    for (size_t i = 0; i < n; i++) {
        unsigned char c = (unsigned char)s[i];
        if (!isalnum(c) && c != '_' && c != '-')
            return 0;
    }
    return 1;
}
...
if (!ad_gecerli_mi(argv[1])) { /* reddet */ }
struct oturum o = { .yonetici = 0 };          /* güvenli varsayılan */
snprintf(o.ad, sizeof(o.ad), "%s", argv[1]);  /* boyutu bilen kopya */

16. Integers and the signed-length bug¶

In C, int is signed, while size_t is unsigned. Computers store negative numbers in two's complement: the 64-bit representation of -1 is 0xFFFFFFFFFFFFFFFF. Read as unsigned, that same bit pattern is 18,446,744,073,709,551,615. Functions like memcpy, malloc, and read take a size_t for their size parameter; so the moment a negative int is passed to them, it turns into a gigantic number.

Demo 4 — The signed-length bug¶

#define KAYIT_BOYUTU 16

static int kaydi_kopyala(char *hedef, const char *kaynak, int uzunluk)
{
    /* HATA: alt sınır (negatif değer) denetlenmiyor */
    if (uzunluk > KAYIT_BOYUTU)
        return -1;
    memcpy(hedef, kaynak, uzunluk);   /* int -> size_t: -1 -> 2^64 - 1 */
    return 0;
}

cd code\week-01\04-isaretli-uzunluk
.\demo.ps1

cd code/week-01/04-isaretli-uzunluk
sh demo.sh

ADIM 0 — Derleyici bu hatayi goruyor mu?
$ gcc -Wall -Wextra -fsyntax-only -I../../common kopya.c
   -> Uyari yok: -Wall -Wextra bu donusumu bildirmez.
$ gcc -Wsign-conversion -fsyntax-only -I../../common kopya.c
kopya.c:21:27: warning: conversion to 'size_t' from 'int'
               may change the sign of the result [-Wsign-conversion]

ADIM 1 — Normal kullanim
$ ./bin/linux/kopya 8
Kopyalandi: ORNEK-KA

ADIM 2 — Cok buyuk uzunluk: denetim yakalar
$ ./bin/linux/kopya 100
Reddedildi: uzunluk cok buyuk.

ADIM 3 — Saldiri: negatif uzunluk denetimi atlatir
$ ./bin/linux/kopya -1
Segmentation fault
   (cikis kodu: 139 — 139 = bellek hatasi, SIGSEGV)

ADIM 4 — Ayni saldiri, AddressSanitizer ile
==1823==ERROR: AddressSanitizer: negative-size-param: (size=-1)

ADIM 5 — Duzeltilmis surum
$ ./bin/linux/kopya_guvenli -1 ; ./bin/linux/kopya_guvenli 12abc ; ./bin/linux/kopya_guvenli 8
Reddedildi: uzunluk 0-16 arasinda bir tamsayi olmali.
Reddedildi: uzunluk 0-16 arasinda bir tamsayi olmali.
Kopyalandi (8 bayt): ORNEK-KA

On Windows you see two differences. In step 3 the program ends with code 0xC0000409: Windows notices the stack is corrupted and terminates the process immediately. In step 0, MSVC's C compiler gives no warning at all, even with /Wall; the same code compiled as C++ does produce a warning:

> cl /Zs /W4 kopya.c                 (C olarak derle)
   -> Uyari yok: MSVC'nin C derleyicisi bu donusumu /Wall ile bile bildirmez.
> cl /Zs /W4 /w44365 /TP kopya.c     (ayni kod, C++ olarak)
kopya.c(21): warning C4365: 'argument': conversion from 'int' to 'size_t', signed/unsigned mismatch

The check asks "is uzunluk > 16?"; -1 answers "no" to that question, so it gets through. A length field in a packet coming over the network, a record size in a file header — any number the attacker controls can lead to this bug. The compiler could have warned us, but only if we asked: -Wsign-conversion is not in GCC's default warnings, and MSVC's C compiler doesn't have it at all. Knowing which warnings are on, and reading them, is a free security tool; a tool's silence does not mean the code is correct.

static int uzunluk_oku(const char *metin, size_t *sonuc)
{
    char *son;
    errno = 0;
    long deger = strtol(metin, &son, 10);
    if (errno != 0 || son == metin || *son != '\0')
        return -1;                       /* sayı değil ya da taştı */
    if (deger < 0 || deger > KAYIT_BOYUTU)
        return -1;                       /* hem alt hem üst sınır */
    *sonuc = (size_t)deger;
    return 0;
}

We will go deeper into this wider family of integer bugs — overflow, sign conversion, boundary values — in week 4's undefined-behaviour section.

17. Memory management and security¶

A buffer overflow happens when we forget how much we're writing. The bugs in this section happen when we forget who owns a piece of memory and how long it stays valid. In C and C++, memory allocated from the heap lives until the programmer frees it; the language does not track this lifetime for you.

The four lifetimes of memory¶

The lifecycle of dynamic memory has four steps: allocate → validate → use → free. A distinct class of bug lives at each step.

Classes of error¶

Use-after-free: why is it so dangerous?¶

typedef struct { char ad[32]; int yetki; } Kullanici;

Kullanici *aktif = malloc(sizeof *aktif);
Kullanici *onbellek = aktif;          /* ikinci bir sahip daha */
/* ... */
free(aktif);                          /* oturum kapandı */
aktif = NULL;                         /* aktif güvende, ama onbellek hâlâ eski adresi tutuyor */

char *not = malloc(sizeof(Kullanici));  /* bellek yöneticisi aynı bloğu yeniden verebilir */
strcpy(not, "....");                    /* not yazılıyor */

if (onbellek->yetki) { /* ... */ }      /* UAF: artık 'not'un baytlarını okuyor */

free does not return memory to the operating system; it puts it on the memory manager's "free" list. The next malloc of the same size will most likely get the same block back. The stale pointer (onbellek) is now pointing at a completely different object. The program's logic reads bytes that were written for some other purpose as "the user's privilege." This is why UAF bugs are one of the largest classes of browser and operating system vulnerabilities.

The aktif = NULL; line in the example is a good habit, but it only protects that one pointer. The real problem is that more than one pointer claims ownership of the same block. The solution is an ownership rule:

We will exploit a UAF step by step in C/C++ and catch it with AddressSanitizer in week 4.

Fixed versions of the other errors¶

/* Hatalı: n büyükse n * sizeof(Kayit) taşar, küçük bir blok ayrılır */
Kayit *k = malloc(n * sizeof(Kayit));

/* Doğru 1: calloc boyut çarpımında taşmayı denetler ve belleği sıfırlar */
Kayit *k = calloc(n, sizeof(Kayit));
if (k == NULL) return HATA_BELLEK;

/* Doğru 2: yeniden boyutlandırmada reallocarray (glibc 2.26+, BSD) */
Kayit *yeni = reallocarray(k, n2, sizeof(Kayit));
if (yeni == NULL) { free(k); return HATA_BELLEK; }   /* k'yi kaybetme */
k = yeni;

/* Hatalı: realloc başarısız olursa NULL döner ve eski blok hâlâ ayrılmış durumdadır;
   onu gösteren tek işaretçinin üzerine yazdık → sızıntı */
tampon = realloc(tampon, yeni_boyut);

realloc has a second hidden problem: if the block moves, the old block is freed but not zeroed. If it held a secret, the old copy sits somewhere in memory forever. Don't use realloc for buffers that hold secrets; allocate a new block, copy into it, and erase the old one before freeing it.

Erasing secrets from memory (Recipe 13.2)¶

Demo 2, in the "Secrets left in memory" section, showed that the compiler can see the line memset(parola, 0, ...) as "a write to somewhere that's never read afterward" (a dead store) and remove it entirely. To prevent this, functions the compiler will not remove are used:

#include <string.h>
#ifdef _WIN32
#  include <windows.h>
#endif

static void cen429_sil(void *p, size_t n)
{
#if defined(_WIN32)
    SecureZeroMemory(p, n);
#elif defined(__GLIBC__) || defined(__OpenBSD__) || defined(__FreeBSD__)
    explicit_bzero(p, n);
#else
    volatile unsigned char *v = (volatile unsigned char *)p;
    while (n--) *v++ = 0;
#endif
}

Where the erasure happens matters too. A secret can have more copies than you think:

• Structs passed by value to a function (a copy is left on the stack on every call).
• The old block left behind when realloc moves it.
• std::string's small-string optimisation (SSO) and its copies; std::string does not erase its contents when it's destroyed.
• I/O buffers (the stdin buffer that fgets reads into).
• The operating system's swap file and hibernation file (below).

Preventing memory from being written to disk (Recipe 13.3)¶

Under memory pressure, the operating system writes rarely used pages to the swap area (Linux swap, Windows pagefile.sys). When the computer enters hibernation, all of memory is written to disk. No matter how well you erase your secret from memory, a copy may already have been written to disk in the meantime. The countermeasure is to lock the pages holding secrets:

#include <sys/mman.h>

unsigned char anahtar[32];
if (mlock(anahtar, sizeof anahtar) != 0) {
    /* RLIMIT_MEMLOCK aşılmış olabilir; hatayı raporla ama sırrı yine de sil */
}
/* ... anahtarı kullan ... */
cen429_sil(anahtar, sizeof anahtar);
munlock(anahtar, sizeof anahtar);

#include <windows.h>

unsigned char anahtar[32];
if (!VirtualLock(anahtar, sizeof anahtar)) {
    /* çalışma kümesi sınırı aşılmış olabilir */
}
/* ... anahtarı kullan ... */
SecureZeroMemory(anahtar, sizeof anahtar);
VirtualUnlock(anahtar, sizeof anahtar);

Locking works at the page level (typically 4 KB). When you lock a small array, the entire page containing it gets locked. The amount of memory that can be locked is limited; so lock only a small, separate region that holds keys — not the whole program.

All together: a secure buffer¶

Gathering the rules above into a single small module makes it easier to get this right everywhere:

typedef struct {
    unsigned char *veri;
    size_t         boyut;
} GizliTampon;

/* Ayırır, sıfırlar, belleği kilitler. Başarısızsa -1. */
int  gizli_ayir(GizliTampon *t, size_t boyut);

/* Güvenli siler, kilidi açar, serbest bırakır; t->veri = NULL yapar. İki kez çağrılabilir. */
void gizli_birak(GizliTampon *t);

#include <stdlib.h>
#include <sys/mman.h>
#include "gizli_tampon.h"

int gizli_ayir(GizliTampon *t, size_t boyut)
{
    t->veri = calloc(1, boyut);
    if (!t->veri) return -1;
    t->boyut = boyut;
    (void)mlock(t->veri, boyut);                 /* başarısızlık ölümcül değil */
    return 0;
}

void gizli_birak(GizliTampon *t)
{
    if (!t->veri) return;                        /* çift bırakmaya karşı */
    cen429_sil(t->veri, t->boyut);
    munlock(t->veri, t->boyut);
    free(t->veri);
    t->veri  = NULL;
    t->boyut = 0;
}

In C++ the same idea is put into a class's destructor; that way, once the object goes out of scope — even if an exception is thrown — the erasure happens automatically. This is called RAII (Resource Acquisition Is Initialization):

class GizliAnahtar {
public:
    explicit GizliAnahtar(std::size_t n) : v_(n) { kilitle(v_.data(), n); }
    ~GizliAnahtar() { cen429_sil(v_.data(), v_.size()); kilidi_ac(v_.data(), v_.size()); }
    GizliAnahtar(const GizliAnahtar&) = delete;              /* kopya yok: sır çoğalmasın */
    GizliAnahtar& operator=(const GizliAnahtar&) = delete;
    unsigned char* veri() { return v_.data(); }
private:
    std::vector<unsigned char> v_;
};

Deleting the copy constructor is a deliberate decision: copying an object that holds a secret means a second copy somewhere else in memory that might be forgotten and never erased.

Tools that find memory errors¶

Try it yourself: memory¶

1. Does char *p = malloc(10); free(p); free(p); always crash? Why is it "dangerous even if it doesn't crash"?
2. How do you erase a password held in std::string parola; once you're done with it? Is parola.clear() enough?
3. A server leaks 100 bytes on every request. If it receives 1000 requests a second, how long does it take to exhaust 4 GB of memory? Which STRIDE letter is this?

18. Protected code partitioning and secure processing under encryption¶

Not every line of a program is equally sensitive. Code that draws a menu on screen and code that decrypts data with a key do not deserve the same level of care. Protected code partitioning means dividing the program into regions by sensitivity and turning the most sensitive region into a small, isolated core equipped with the strongest protections. Secure processing under encryption means ensuring that sensitive data (even sensitive code) is never in the clear outside this core.

Why partition? The trusted computing base¶

In security, the trusted computing base (TCB) is all the code of which we say "if this part is buggy, security collapses." The bigger the TCB, the higher the chance it contains a bug, and the harder it is to review. The practical translation of Saltzer and Schroeder's economy of mechanism principle (section 4) is: shrink the TCB.

Example: in a 200,000-line application, if the code that works with keys is 2,000 lines and is split into a separate module, penetration testing and code review can concentrate on those 2,000 lines. Obfuscation and integrity checking are applied only to that module; the performance cost is paid only there too (see "The cost of protection").

Partitioning options¶

Where you put the protected core depends on your attacker model and your platform:

The strongest protection is usually removing the secret from the client entirely. When that isn't possible (e.g. the phone needs to make offline payments), hardware support is sought. When that isn't available either (or isn't present on every device), the secret has to be protected in software, and this is exactly the situation the obfuscation, RASP, and white-box techniques we'll see through the term are for.

The interface between partitions: narrow, validated, secret-free¶

The value of partitioning depends entirely on the quality of the boundary interface. If you keep the key in a separate module and then hand it out through a function called anahtar_al() ("get key"), you have gained nothing. Three rules for the interface:

1. Don't hand out the secret, do the work. The core does not return the key; it performs the operation with the key and returns only the result. What's handed out instead of the key is a handle (an opaque identifier).
2. Validate everything that crosses the boundary. The core treats every parameter coming from the outer region like untrusted input (size, range, format).
3. Never pass data across the boundary in the clear. Sensitive data that must cross the boundary does so encrypted and integrity-protected. Otherwise, the attacker hooks the interface function and reads the data in transit.

typedef struct KasaAnahtari KasaAnahtari;          /* opak tür: içi dışarıdan görünmez */

/* Ana paroladan anahtarı türetip çekirdeğin içinde tutar; parolayı siler. */
int  kasa_ac(const char *parola, size_t parola_uzunlugu,
             const unsigned char tuz[16], KasaAnahtari **cikti);

/* Anahtarla şifreler / çözer; anahtarın kendisi hiçbir zaman dışarı çıkmaz. */
int  kasa_sifrele(KasaAnahtari *a, const unsigned char *acik, size_t n,
                  unsigned char *sifreli, size_t kapasite, size_t *yazilan);
int  kasa_coz(KasaAnahtari *a, const unsigned char *sifreli, size_t n,
              unsigned char *acik, size_t kapasite, size_t *yazilan);

/* Anahtarı güvenli siler ve serbest bırakır. */
void kasa_kapat(KasaAnahtari *a);

In C, an opaque type (a struct that is only declared, with its definition not in the header file) blocks calling code from directly accessing the key's bytes at the language level. Of course, an attacker in the same process can still read the memory; an opaque type prevents programming mistakes, not an attacker. Additional layers are needed against an attacker.

Misusing the interface: the decryption oracle and code lifting¶

Hiding the key well is not enough. The attacker can use your own function without ever finding the key:

• Decryption oracle: The attacker calls the kasa_coz function directly with data of their own choosing. The key stays secret, but the attacker gets to decrypt anything they want.
• Code lifting: The attacker copies the protected function (even with its embedded key) straight out of the binary and runs it as a black box in their own program. They never need to extract the key at all.

The countermeasures, therefore, go beyond "hide the key":

Secure processing under encryption: narrowing the window of exposure¶

A sensitive piece of data exists in three states throughout its lifecycle: at rest (disk), in transit (network), and in use (memory, registers). Encrypting the first two is standard; the hard one is the third, because the data has to be decrypted at some point to be processed. (We will cover protecting data at rest and in transit in detail in week 3.) The goal is to narrow this window of exposure as much as possible, in both time and space:

The techniques that achieve this:

1. Just-in-time decryption: the data is decrypted only inside the function that will use it, and erased before that function returns.
2. Masking in memory: while it's not in use, the key is kept XORed with a random mask generated at runtime. Instead of the key itself sitting in one place in memory, there are two meaningless pieces.
3. Splitting: the key, or some value, is broken into pieces that sit in different places in memory (even inside different functions); they are only combined at the moment of use.
4. Code encryption (dynamic decryption): not just data — the code of the most sensitive functions sits encrypted in the binary too; it is decrypted into memory at runtime, run, then re-encrypted. Details in weeks 4 and 9.
5. Processing without ever exposing the key: in white-box cryptography, the key is embedded into computation tables in such a way that it never exists in the clear in memory during the operation (week 11).

#include <stdint.h>
#include <stddef.h>

typedef struct {
    uint8_t maske[32];     /* açılışta rastgele üretilir */
    uint8_t ortulu[32];    /* anahtar XOR maske */
} OrtuluAnahtar;

/* Yalnız kullanım anında, çağıranın verdiği geçici tampona birleştirir. */
static void anahtari_ac(const OrtuluAnahtar *o, uint8_t gecici[32])
{
    for (size_t i = 0; i < 32; i++)
        gecici[i] = o->ortulu[i] ^ o->maske[i];
}

void imzala(const OrtuluAnahtar *o, const uint8_t *veri, size_t n, uint8_t etiket[32])
{
    uint8_t k[32];
    anahtari_ac(o, k);
    kripto_hmac_sha256(k, sizeof k, veri, n, etiket);   /* işlem: code/common/cen429_kripto.h */
    cen429_sil(k, sizeof k);                     /* açıklık penceresi burada kapanır */
}

The limits of partitioning¶

• A module inside the same process provides no real isolation against an attacker who runs in that same process (e.g. a tool that hooks the program). In that case, the real protection is RASP and obfuscation.
• At an inter-process or client–server boundary, the communication channel itself is a new attack surface; it needs mutual authentication and integrity (week 3).
• Hardware isolation (TEE, secure element) is strong, but the code running inside it still has to be bug-free; buffer overflows have been found in TEE applications too.

19. Secure development process: keeping the plan alive¶

A protection plan is not tested on the day it's written — it's tested every time the product changes. A new feature, a bug fix, or a library update can unknowingly neutralize a carefully built countermeasure. This section describes the processes that let the plan live alongside the product. In certified products, these processes are reviewed at least as closely as the code itself.

The secure software development lifecycle¶

Microsoft's Security Development Lifecycle (SDL) and NIST's Secure Software Development Framework (SSDF, SP 800-218) both say that security must be spread across every stage of software:

Unique version identity: "is what was reviewed the same as what shipped?"¶

When an evaluator reviews a product, their report is valid for exactly that binary. A file shipped under the same version number but differing by even a single line is a product that was never reviewed. That's why every build must carry a unique, verifiable identity:

1. Semantic version (e.g. 1.4.2): for humans.
2. Source code identity: the hash of the git commit the build was made from.
3. Binary hash: the SHA-256 of the shipped file; the user or evaluator can verify for themselves that the file they downloaded matches this value.

execute_process(COMMAND git rev-parse --short=12 HEAD
                WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}
                OUTPUT_VARIABLE GIT_KIMLIK OUTPUT_STRIP_TRAILING_WHITESPACE)
target_compile_definitions(kasa PRIVATE SURUM="1.4.2" GIT_KIMLIK="${GIT_KIMLIK}")

if (argc > 1 && strcmp(argv[1], "--surum") == 0) {
    printf("kasa %s (%s)\n", SURUM, GIT_KIMLIK);
    return 0;
}

Get-FileHash .\kasa.exe -Algorithm SHA256

sha256sum ./kasa

The same discipline comes back at the end of the term: in Week 14, once obfuscation enters the build pipeline, which version was produced with which transformation and seed is again tracked through this identity and its hash values.

Change management: seven steps¶

In a mature development team, no change goes directly to the main branch. The typical process, adapted from IT service management, has seven steps:

The most important step from a security standpoint is the security impact analysis done between steps 3 and 4: "which asset, which interface, which threat, and which countermeasure does this change touch?" If the answer is "none," the change can move fast; if it touches a countermeasure, that countermeasure's tests are re-run, and the evaluator is notified if needed. In certified products, an evaluation that re-reviews only the changed part based on this analysis is called a delta evaluation (week 13).

The same discipline is applied in the source code repository:

• Main branches are protected; only authorized people can merge into them.
• Every change is reviewed by at least one other developer.
• Releases are tagged (preferably with a signed tag).
• External access to the repository requires multi-factor authentication.
• The build environment is protected too: the supply-chain attacks we'll see in week 2 target code that gets into the build server.

The trade-off log: a record of conscious decisions¶

Security is almost always a trade-off with something: performance, usability, ease of maintenance. A mature team keeps these decisions in writing. A trade-off that isn't logged can't answer "why is it like this?" six months later, and looks like a bug in an evaluator's eyes.

The third row of the table is especially instructive: one security countermeasure (integrity checking) required loosening another security setting (non-debuggability). A decision like this is defensible when it's written down with its rationale and its compensating countermeasure; when it isn't, it's a finding.

How protections affect the build pipeline¶

Countermeasures like integrity checking also change the build process. For the program to be able to check the hash of its own code, the correct hash value has to be embedded into the program — but embedding the hash changes the program, which changes the hash. This loop is solved with a multi-pass build: build once, measure the hash, embed it obfuscated into the code, rebuild; the measured region is designed so it does not include the embedded value. In the field, five-pass signed builds are used, where values like the signing certificate's hash, the package hash, and the code hash are embedded one after another. Steps like this go wrong if done by hand, so they are turned into a build script and documented. In week 6 we will build this loop ourselves with a small example.

Measuring the cost of protections¶

The last piece of the protection plan is measurement. Saying "we added obfuscation" is not enough; you have to show the product still runs at an acceptable speed. A simple method: run the critical operation (e.g. a payment, opening a vault) 20 times in both the protected and unprotected versions, and report the shortest, longest, and average time. A concrete target — such as keeping a contactless payment's total time under half a second — determines which protection can go where.

20. This week's toolbox¶

21. Term project: this week¶

In the term project you will develop a C/C++ application "as if it were going through a security certification" and write a security guide for it (20–30 pages). This week's tasks:

• Form your team (individual or up to 4 people) and choose your topic (the topic list is in the project guide).
• Create your project repository and project plan (work packages, timeline, task assignment) on GitHub; get the plan approved.
• Draft the first sections of the security guide:
  • S0 Cover page and revision history
  • S2 Product overview — what does your application do?
  • S3 Architecture and interface table (in the table format from section 6)
  • S4 Attacker model, STRIDE table, and an attack tree
  • S5 Asset list (draft): for every asset, its location, creation → deletion, and C/I/I+ class
• Fill in steps 0–4 of the seven-step template from the "Worked example" section, for your own project.

| ID | End A | End B | Authentication | Confidentiality / integrity | Description |
| -- | ----- | ----- | --------------- | ---------------------------- | ----------- |
| A  | Console app | Security DLL | ... | ... | ... |

22. On your own¶

These exercises are not graded; they are for reinforcing the lesson. All of them are done on top of the demos in the code/week-01 folder, and only on your own computer.

Get-ChildItem -Recurse -Filter *.c code\week-01 |
  Select-String -Pattern 'strcpy|strcat|sprintf|gets\(|scanf'

grep -rnE 'strcpy|strcat|sprintf|gets\(|scanf' code/week-01 --include=*.c

23. Self-check¶

24. Resources and further reading¶

Textbook — J. Viega, M. Messier, Secure Programming Cookbook for C and C++, O'Reilly, 2003:

• Recipe 1.1 (cleaning the environment), 1.2–1.4 (restricting and separating privileges), 1.5 (file descriptors), 1.9 (preventing crash dumps)
• Recipe 3.3 (preventing buffer overflow), 3.5 (integer conversion and overflow)
• Recipe 13.2 (secure erasure from memory), 13.3 (preventing memory from being written to disk)
• Recipe 12.1 (understanding software protection)

Open sources

• J. H. Saltzer, M. D. Schroeder, "The Protection of Information in Computer Systems", 1975.
• OWASP Threat Modelling; Microsoft STRIDE.
• MITRE CWE: CWE-14, CWE-121, CWE-122, CWE-125, CWE-193, CWE-195, CWE-226, CWE-316, CWE-401, CWE-415, CWE-416, CWE-426, CWE-427, CWE-476, CWE-787.
• SEI CERT C Coding Standard: STR31-C (allocating enough space when copying strings), INT31-C (integer conversions), MSC06-C (beware of compiler optimisations), ENV33-C (do not call system()), MEM30-C (do not access freed memory), MEM31-C (free dynamic memory), MEM35-C (allocate sufficient memory), POS36-C (the order of dropping privilege), POS37-C (verify that privilege was successfully dropped).
• Microsoft Security Development Lifecycle (SDL); NIST SP 800-218 Secure Software Development Framework (SSDF).
• A. Shostack, Threat Modelling: Designing for Security, Wiley, 2014 (data flow diagrams and STRIDE per element).