SC Manual

0.0(0)
Studied by 0 people
call kaiCall Kai
learnLearn
examPractice Test
spaced repetitionSpaced Repetition
heart puzzleMatch
flashcardsFlashcards
GameKnowt Play
Card Sorting

1/26

encourage image

There's no tags or description

Looks like no tags are added yet.

Last updated 9:38 AM on 6/5/26
Name
Mastery
Learn
Test
Matching
Spaced
Call with Kai

No analytics yet

Send a link to your students to track their progress

27 Terms

1
New cards

Least Privilege

code/processes/users should only have the permissions needed for their job.

2
New cards

Defence in depth

use multiple layers of protection, not one single control.

3
New cards

Secure by default

default settings should be safe unless the user/admin deliberately weakens them.

4
New cards

CWE

Common Weakness Enumeration: category list of software weakness types, e.g. buffer overflow, SQL injection.

5
New cards

CVE

Common Vulnerabilities and Exposures; catalogue of specific publicly known vulnerabilities.

6
New cards

ASLR

Address Space Layout Randomisation; randomises memory locations to make exploitation harder.

7
New cards

TOCTOU

Time-of-Check to Time-of-Use; race where a checked resource changes before it is used.

8
New cards

Four coding practices

  • Validate input.

  • Check bounds.

  • Avoid unsafe library functions.

  • Check return values / handle errors.

  • Use compiler warnings/static analysis.

  • Use safe APIs.

9
New cards

C “not precisely defined” behaviour

  • Implementation-defined: compiler must document what it does.

  • Unspecified: several valid behaviours; compiler does not need to say which one.

  • Undefined behaviour: no requirements at all; compiler can assume it never happens.

10
New cards

Dangling pointer

A pointer that still points to memory after that memory has been freed or gone out of scope. Example: free(p); then later using p.

11
New cards

Always unsafe string functions

  • gets() — no bounds checking.

  • strcpy() — copies until null terminator; destination may overflow.

  • strcat() — appends without knowing remaining space.

  • sprintf() — can overflow output buffer.

12
New cards

Authentication vs authorization

  • Authentication: proving who you are.

  • Authorization: deciding what you are allowed to do.

13
New cards

Static vs dynamic analysis

  • Static: inspect code without running it. Example: compiler warnings, clang-tidy, Coverity.

  • Dynamic: run program and observe behaviour. Example: AddressSanitizer, Valgrind, fuzzing.

14
New cards

Race condition vs data race

  • Race condition: program result depends on timing/order of events.

  • Data race: multiple threads access same memory concurrently, at least one write, without synchronisation.

  • Data race is a specific type of race condition.

15
New cards

Cryptographic hash function

preimage resistance, second-preimage resistance, and collision resistance.

16
New cards

Password storage

Store salted, slow password hashes, e.g. bcrypt/Argon2/scrypt.

17
New cards

Sandboxing

Running code in a restricted environment so even if it is malicious or compromised, it has limited access to the wider system.

18
New cards

Signed integer overflow

In C, signed overflow is undefined behaviour. You cannot safely check overflow after doing the overflowing operation because the compiler may assume it never happened.

19
New cards

The C11 standard distinguishes between implementation-defined, unspecified, and undefined behaviour. Explain the key differences between them and describe why undefined behaviour is particularly dangerous from a security perspective. (Hint: think about what the compiler is permitted to assume.)

  • Implementation-defined: compiler chooses and documents.

  • Unspecified: compiler chooses but need not document.

  • Undefined: anything can happen.

Undefined behaviour is dangerous because the compiler may optimise based on the assumption that the undefined case is impossible. Security checks can be removed or changed.

20
New cards

ASLR purpose and limitations

ASLR makes addresses unpredictable, so attackers cannot easily jump to known code/data locations.

Limitations:

  • Information leaks can reveal addresses.

  • It does not remove the underlying overflow.

  • Low entropy or repeated attempts can defeat it.

  • Non-PIE binaries/libraries may still be predictable.

21
New cards

DAC vs MAC

  • DAC: owner controls access. Example: Unix file owner decides permissions.

  • MAC: system policy controls access. Example: military/classified systems or SELinux.

22
New cards

system() vs exec*

system() invokes a shell, so metacharacters, PATH, environment variables, quoting, and command injection become dangerous.

execve() executes a specific program with explicit argv/envp. Arguments are passed as data, not shell code.

23
New cards

Canonicalization

Converting input into a standard form before checking it. Important because attackers can encode the same path/value multiple ways.

Example: ../secret.txt, URL encoding, symlinks, case differences.

24
New cards

Explain the concept of memory isolation as provided by modern operating systems. What problem does it solve, and what mechanism (hardware or OS) enables it?

Modern OSes give each process its own virtual address space. This prevents one process directly reading/writing another process’s memory. Enabled by hardware MMU + OS page tables.

25
New cards

Economy of Design

Keep security-critical code simple. Complex custom parsing or auth logic is more likely to contain bypasses.

26
New cards

Complete mediation

Every access should be checked. If a system checks permission only at login but not when files are accessed, stale permissions may allow unauthorised access.

27
New cards

signed vs unsigned integer

signed is both positive and negative while unsigned can only be positive.