Security Model¶

The EmbSec Kit implements a carefully designed security model that balances educational value with safety, creating intentional vulnerabilities that teach real concepts without introducing actual security risks.

Design Philosophy¶

Core Principles¶

1. Isolation: Vulnerabilities are confined to individual labs
2. Intentionality: All vulnerabilities are deliberate and documented
3. Education: Each vulnerability teaches specific security concepts
4. Safety: No unintended vulnerabilities in core SDK
5. Validation: All exploits are testable and deterministic

Vulnerability Architecture¶

Layered Security Model¶

┌─────────────────────────────────┐
│        User Application         │ ← Vulnerable (Labs)
├─────────────────────────────────┤
│          Lab Framework          │ ← Controlled vulnerabilities
├─────────────────────────────────┤
│         EmbSec SDK             │ ← Secure implementation
├─────────────────────────────────┤
│    Hardware Abstraction Layer   │ ← TivaWare (trusted)
└─────────────────────────────────┘

Vulnerability Categories¶

1. Memory Corruption¶

• Buffer Overflows: Stack and heap based
• Format Strings: Arbitrary read/write
• Integer Overflows: Arithmetic errors
• Use-After-Free: Temporal memory safety

2. Logic Flaws¶

• Authentication Bypass: Weak checks
• Race Conditions: TOCTOU bugs
• Crypto Weaknesses: Poor implementations
• Information Disclosure: Data leaks

3. Side Channels¶

• Timing Attacks: Execution variations
• Power Analysis: Consumption patterns
• Fault Injection: Glitching attacks

Flag Generation System¶

Deterministic Flag Generation¶

void generate_flag(const char *lab_name, const char *salt) {
    sha256_context ctx;
    uint8_t hash[32];
    char flag_input[256];

    // Combine inputs for deterministic generation
    snprintf(flag_input, sizeof(flag_input), 
             "embsec:%s:%s:success", lab_name, salt);

    // Generate SHA-256 hash
    sha256_init(&ctx);
    sha256_update(&ctx, (uint8_t*)flag_input, strlen(flag_input));
    sha256_final(&ctx, hash);

    // Format as flag
    printf("embsec{");
    for (int i = 0; i < 32; i++) {
        printf("%02x", hash[i]);
    }
    printf("}\n");
}

Flag Properties¶

• Format: embsec{[64 hex characters]}
• Deterministic: Same inputs → same flag
• Unique: Different per lab and deployment
• Verifiable: Can be regenerated for validation

Vulnerability Patterns¶

Pattern 1: Buffer Overflow¶

// Vulnerable pattern
void vulnerable_function() {
    char buffer[64];
    printf("Enter name: ");
    gets(buffer);  // No bounds checking
}

// Secure alternative in SDK
int embsec_read_line(char *buffer, size_t size) {
    // Bounds-checked input
    return read_until_newline(buffer, size, UART0);
}

Pattern 2: Format String¶

// Vulnerable pattern
void log_activity(const char *user_input) {
    printf(user_input);  // Direct format string
}

// Secure alternative
void log_activity_safe(const char *user_input) {
    printf("%s", user_input);  // Proper formatting
}

Pattern 3: Integer Overflow¶

// Vulnerable pattern
void allocate_buffer(uint8_t size) {
    char *buffer = malloc(size + HEADER_SIZE);  // Can overflow
}

// Secure alternative
void allocate_buffer_safe(size_t size) {
    if (size > MAX_ALLOWED_SIZE) return;
    if (size + HEADER_SIZE < size) return;  // Overflow check
    char *buffer = malloc(size + HEADER_SIZE);
}

Exploit Mitigation Controls¶

Development vs Production¶

# Development build - vulnerabilities enabled
if(CMAKE_BUILD_TYPE STREQUAL "Debug")
    add_compile_definitions(ENABLE_VULNERABILITIES)
endif()

# Production build - vulnerabilities disabled
if(CMAKE_BUILD_TYPE STREQUAL "Release")
    add_compile_definitions(SECURE_BUILD)
endif()

Runtime Protections¶

1. Stack Canaries (optional)

   void function() __attribute__((stack_protect));
   

2. ASLR Simulation (QEMU)

   #ifdef QEMU_BUILD
   void randomize_stack_base();
   #endif
   

3. W^X Enforcement

   // Code sections: Read + Execute
   // Data sections: Read + Write
   // Never: Write + Execute
   

Security Boundaries¶

Trust Boundaries¶

1. User Input: Always untrusted
2. Lab Code: Intentionally vulnerable
3. SDK Code: Trusted and secure
4. Hardware: Assumed secure

Data Flow¶

User Input → Validation → Processing → Output
     ↓           ↓            ↓          ↓
  Untrusted   Boundary    Vulnerable  Controlled

Instructor Considerations¶

Creating New Vulnerabilities¶

1. Identify Learning Objective
2. What security concept to teach?

3. What real-world scenario to simulate?

4. Design Vulnerability

5. Make it realistic but contained
6. Ensure it's exploitable reliably

7. Provide clear indicators of success

8. Implement Safeguards

9. Prevent cascading failures
10. Limit scope of exploitation

11. Add debugging aids

12. Document Thoroughly

13. Explain the vulnerability
14. Provide hints without solutions
15. Include INSTRUCTOR.md notes

Security Review Checklist¶

• Vulnerability is intentional and documented
• Exploit is deterministic and testable
• No unintended attack surfaces
• Flag generation is working correctly
• Debug features don't leak solutions
• Production builds disable vulnerabilities

Incident Response¶

If Unintended Vulnerability Found¶

1. Assess Impact
2. Which components affected?
3. Can it be exploited reliably?

4. Does it affect learning objectives?

5. Patch or Document

6. If educational: Document and integrate

7. If problematic: Patch immediately

8. Update Tests

9. Add regression tests
10. Verify other labs unaffected

Best Practices¶

1. Principle of Least Privilege
2. Labs run with minimal permissions

3. No access to host system

4. Defense in Depth

5. Multiple layers of protection

6. Fail-safe defaults

7. Secure by Default

8. Vulnerabilities require explicit enabling

9. Safe modes for demonstrations

10. Transparency

11. All vulnerabilities documented
12. Clear separation of secure/vulnerable code

Future Enhancements¶

• Exploit detection and logging
• Dynamic difficulty adjustment
• Anti-debugging challenges
• Hardware security modules
• Secure boot simulations