Skip to content

Latest commit

 

History

History
137 lines (106 loc) · 10.8 KB

mitigations.md

File metadata and controls

137 lines (106 loc) · 10.8 KB

Mitigation Strategies Analysis for cloudwu/skynet

Mitigation Strategy: 1. Message Authentication and Integrity (HMAC within Skynet)

  • Mitigation Strategy: Implement HMAC-based message authentication using Skynet services.

  • Description:

    1. Dedicated Skynet Security Service: Create a dedicated Skynet service (auth_service) responsible for handling authentication and key management. This service should not perform any other application logic.
    2. Key Management (within Skynet context): The auth_service can manage shared secret keys. While a separate, external KMS is ideal, for a purely Skynet-focused mitigation, the auth_service can:
      • Generate keys.
      • Store keys (encrypted, ideally using a Skynet-specific encryption service if one exists, or a simple C library).
      • Distribute keys to other services via secure Skynet messages (bootstrapping the security). This initial key distribution is the most vulnerable point and requires careful consideration. One approach is to have a pre-shared, very short-lived initial key used only for this distribution.
    3. Message Signing (Sender - Skynet Service):
      • A Skynet service wanting to send an authenticated message first serializes the message data (e.g., using Protocol Buffers).
      • It then sends a request to the auth_service, including the serialized data and the recipient service ID.
      • The auth_service retrieves the appropriate shared secret key, calculates the HMAC, and returns it to the sending service.
      • The sending service includes the HMAC in the final message sent to the recipient.
    4. Message Verification (Receiver - Skynet Service):
      • The receiving Skynet service, upon receiving a message, extracts the HMAC.
      • It sends a request to the auth_service, including the received message data, the sender service ID, and the received HMAC.
      • The auth_service retrieves the shared secret, re-calculates the HMAC, and compares it to the received HMAC. It returns a boolean (valid/invalid) to the receiving service.
      • The receiving service acts based on the auth_service's response.
    5. Nonce/Sequence within Skynet: The auth_service can also manage nonces or sequence numbers, ensuring uniqueness across the Skynet cluster. This adds replay protection.

  • Threats Mitigated:

    • Message Tampering (High Severity): Prevents modification of messages within the Skynet cluster.
    • Message Spoofing (High Severity): Prevents services from impersonating other Skynet services.
    • Replay Attacks (Medium Severity): Prevents replaying of messages within Skynet.

  • Impact:

    • Message Tampering: Risk reduced from High to Low (within Skynet).
    • Message Spoofing: Risk reduced from High to Low (within Skynet).
    • Replay Attacks: Risk reduced from Medium to Low (within Skynet).

  • Currently Implemented:

    • auth_service exists but only handles HMAC calculation. Key management is still external (encrypted config file). Communication with auth_service is not secured.

  • Missing Implementation:

    • Secure key distribution within Skynet.
    • Nonce/sequence number management within auth_service.
    • Securing the communication between services and the auth_service itself (recursive application of this very mitigation!).

Mitigation Strategy: 2. Lua Sandboxing (Skynet Service-Specific)

  • Mitigation Strategy: Implement Lua sandboxing specifically tailored to each Skynet service.

  • Description:

    1. Per-Service Sandboxes: Each Skynet service that uses Lua should have its own isolated sandbox environment. Do not use a single global sandbox for all services.
    2. Whitelist by Service Needs: The whitelist of allowed Lua functions and modules should be specific to the needs of each service. A service that only needs to process data should have a much smaller whitelist than a service that needs to interact with other Skynet services.
    3. Skynet API Wrapper: Create a safe, controlled API (written in C and exposed to Lua) for interacting with other Skynet services. This API should be the only way for Lua code within a service to communicate with the rest of the Skynet cluster. This API should:
      • Validate all inputs from Lua.
      • Enforce access control (which services can be called).
      • Handle message serialization and authentication (using the auth_service from Mitigation #1).
    4. Load Lua in Service Context: When a Skynet service starts, it should load its Lua code into its dedicated sandbox environment. This ensures that each service's Lua code is isolated from other services.

  • Threats Mitigated:

    • Arbitrary Code Execution (Critical Severity): Prevents malicious Lua code within one Skynet service from affecting other services or the underlying system.
    • Unauthorized Skynet Service Access (High Severity): Prevents a compromised Lua service from calling arbitrary Skynet services.
    • Information Disclosure (Medium Severity): Limits the ability of a compromised Lua service to access data belonging to other services.

  • Impact:

    • Arbitrary Code Execution: Risk reduced from Critical to Low (within the scope of a single service).
    • Unauthorized Skynet Service Access: Risk reduced from High to Low.
    • Information Disclosure: Risk reduced from Medium to Low (between services).

  • Currently Implemented:

    • Basic sandboxing is implemented for the user_service, but the Skynet API wrapper is incomplete.

  • Missing Implementation:

    • Sandboxing is not implemented for all Lua-based services.
    • The Skynet API wrapper is not fully implemented and does not enforce access control or handle authentication.
    • No per-service sandboxes; a single, global sandbox is used (incorrectly).

Mitigation Strategy: 3. Secure C/Lua Interface (within Skynet Services)

  • Mitigation Strategy: Secure the C/Lua interface within each Skynet service.

  • Description:

    1. Minimize C API Surface: Each Skynet service should expose a minimal C API to its Lua code. This reduces the attack surface.
    2. Data Serialization (Service-Specific): Use a consistent data format (e.g., Protocol Buffers) for all data passed between C and Lua within a service. This avoids direct manipulation of Lua tables or C structures.
    3. C-Side Validation (Service-Specific): The C code of each Skynet service must rigorously validate all data received from its Lua code. This is critical for preventing C-level vulnerabilities.
    4. Safe Skynet API: The Skynet API wrapper (mentioned in Mitigation #2) should be implemented in C and should be the only way for Lua to interact with other Skynet services. This API handles the complexities of message passing, serialization, and authentication, presenting a safe interface to Lua.

  • Threats Mitigated:

    • Buffer Overflows (Critical Severity): Prevents buffer overflows in the C code of a Skynet service due to malicious input from its Lua code.
    • Format String Vulnerabilities (Critical Severity): Prevents format string vulnerabilities in the C code of a Skynet service.
    • Type Confusion (High Severity): Prevents type confusion vulnerabilities in the C code of a Skynet service.
    • Code Injection (Critical): Prevents injection of malicious C code through the Lua interface of a service.

  • Impact:

    • Buffer Overflows: Risk reduced from Critical to Low (within a service).
    • Format String Vulnerabilities: Risk reduced from Critical to Low (within a service).
    • Type Confusion: Risk reduced from High to Low (within a service).
    • Code Injection: Risk reduced from Critical to Low (within a service).

  • Currently Implemented:

    • Protocol Buffers are used in some services for C/Lua communication, but not consistently. Input validation is inconsistent.

  • Missing Implementation:

    • Consistent use of Protocol Buffers across all services.
    • Comprehensive input validation in the C code of all services that interact with Lua.
    • Full implementation of the secure Skynet API wrapper.

Mitigation Strategy: 4. Service Isolation (Skynet-Specific Enforcement)

  • Mitigation Strategy: Enforce service isolation using Skynet's architecture.

  • Description:

    1. Service Decomposition: Design the application as a collection of small, independent Skynet services. This is fundamental to Skynet's design.
    2. Minimize Inter-Service Communication: Services should only communicate with other services they absolutely need to. Avoid unnecessary dependencies.
    3. Skynet Message Filtering (Authorization): Implement a Skynet service (e.g., gatekeeper_service) that acts as a message filter. This service would:
      • Receive all inter-service messages.
      • Check an access control list (ACL) to determine if the sending service is authorized to send messages to the receiving service.
      • Forward the message only if authorized; otherwise, drop the message and log the attempt.
      • The ACL could be stored in the gatekeeper_service's configuration (less secure) or managed by the auth_service (more secure).
    4. Skynet Name Resolution Control: If using Skynet's name resolution service, ensure that services can only resolve the names of other services they are allowed to communicate with. This adds another layer of isolation.

  • Threats Mitigated:

    • Privilege Escalation (High Severity): Prevents a compromised service from accessing other services it shouldn't.
    • Lateral Movement (High Severity): Makes it harder for an attacker to move from one compromised service to another.
    • Unauthorized Service Calls (High): Prevents services from making unauthorized calls to other services.

  • Impact:

    • Privilege Escalation: Risk reduced from High to Medium.
    • Lateral Movement: Risk reduced from High to Medium.
    • Unauthorized Service Calls: Risk reduced from High to Low.

  • Currently Implemented:

    • Basic service decomposition exists, but no message filtering or authorization.

  • Missing Implementation:

    • gatekeeper_service (message filtering service) is not implemented.
    • No access control lists (ACLs).
    • No control over Skynet name resolution.