mitigations.md

Mitigation Strategies Analysis for zeromq/zeromq4-x

Mitigation Strategy: Implement Strict High Water Marks (HWM)

Mitigation Strategy: Configure ZMQ_SNDHWM and ZMQ_RCVHWM on all sockets.

• Description:

  1. Identify all ZeroMQ sockets: Review the codebase and identify every instance where a ZeroMQ socket is created (e.g., zmq::socket_t).
  2. Determine appropriate HWM values: For each socket, analyze the expected message rate and size. Start with a low HWM (e.g., 100-1000 messages) and increase it only if performance testing under realistic load shows it's necessary. Consider different HWMs for different socket types (e.g., lower for REQ/REP, higher for PUB/SUB).
  3. Set HWM during socket creation: Immediately after creating the socket, use the appropriate setsockopt calls (or the equivalent in your binding) to set ZMQ_SNDHWM (for sending) and ZMQ_RCVHWM (for receiving). Example (C++):

     zmq::socket_t socket(context, ZMQ_PUB);
     int hwm = 1000;
     socket.setsockopt(ZMQ_SNDHWM, &hwm, sizeof(hwm));
     socket.setsockopt(ZMQ_RCVHWM, &hwm, sizeof(hwm));

  4. Monitor HWM usage: Implement monitoring (if possible with your binding) to track how close the queues are getting to the HWM. Alert if they consistently approach the limit.
  5. Document HWM settings: Clearly document the chosen HWM values and the rationale behind them.

• Threats Mitigated:

  • Denial of Service (DoS) due to unbounded queue growth: (Severity: High) - Prevents an attacker from flooding the socket with messages, exhausting memory or file descriptors.
  • Resource Exhaustion: (Severity: Medium) - Limits the resources (memory, file descriptors) consumed by ZeroMQ.
  • Application Instability: (Severity: Medium) - Prevents crashes or unexpected behavior caused by excessive queue lengths.

• Impact:

  • DoS: Significantly reduces the risk of a successful DoS attack targeting ZeroMQ queues. Risk reduction: High.
  • Resource Exhaustion: Substantially reduces resource consumption. Risk reduction: High.
  • Application Instability: Improves stability by preventing out-of-memory errors and other queue-related issues. Risk reduction: Medium.

• Currently Implemented:

  • Sockets A, B (in module_x.cpp): HWM set to 1000.
  • Socket C (in module_y.cpp): HWM not set.

• Missing Implementation:

  • Socket C (module_y.cpp) needs HWM configuration.
  • Monitoring of HWM usage is not implemented anywhere. This needs to be added to the monitoring system.

Mitigation Strategy: Use Timeouts

Mitigation Strategy: Employ ZMQ_SNDTIMEO and ZMQ_RCVTIMEO on all sockets.

• Description:

  1. Identify all blocking operations: Locate all calls to socket.send() and socket.recv() (or their equivalents in your binding).
  2. Determine appropriate timeout values: Based on the expected network latency and processing time, choose reasonable timeout values. Start with relatively short timeouts (e.g., 1-5 seconds) and adjust based on testing. Consider different timeouts for different operations.
  3. Set timeouts during socket creation: Use setsockopt to set ZMQ_SNDTIMEO and ZMQ_RCVTIMEO. Example (C++):

     zmq::socket_t socket(context, ZMQ_REQ);
     int timeout = 5000; // 5 seconds in milliseconds
     socket.setsockopt(ZMQ_SNDTIMEO, &timeout, sizeof(timeout));
     socket.setsockopt(ZMQ_RCVTIMEO, &timeout, sizeof(timeout));

  4. Handle timeout errors: Wrap send/receive calls in try-catch blocks (or use error checking mechanisms provided by your binding) to handle timeout errors (EAGAIN or similar). Implement appropriate error handling logic (e.g., retry, log, alert).
  5. Document timeout settings: Clearly document the chosen timeout values and the rationale.

• Threats Mitigated:

  • Denial of Service (DoS) due to slow consumers/producers: (Severity: High) - Prevents a slow or unresponsive peer from blocking the application indefinitely.
  • Deadlocks: (Severity: Medium) - Helps prevent deadlocks caused by blocking operations.
  • Application Unresponsiveness: (Severity: Medium) - Prevents the application from becoming unresponsive due to network issues.

• Impact:

  • DoS: Significantly reduces the risk of DoS attacks exploiting slow peers. Risk reduction: High.
  • Deadlocks: Reduces the likelihood of deadlocks. Risk reduction: Medium.
  • Application Unresponsiveness: Improves responsiveness by preventing indefinite blocking. Risk reduction: High.

• Currently Implemented:

  • No timeouts are currently implemented on any sockets.

• Missing Implementation:

  • Timeouts need to be implemented on all ZeroMQ sockets throughout the application. This is a critical missing piece.

Mitigation Strategy: Use CurveZMQ Encryption

Mitigation Strategy: Implement CurveZMQ for all communication.

• Description:

  1. Generate keypairs: Generate CurveZMQ keypairs (public and secret keys) for each communicating entity (client and server). Use a secure method for key generation (e.g., zmq_curve_keypair or a secure random number generator).
  2. Securely store secret keys: Store secret keys securely. This is critical. Consider using a hardware security module (HSM), encrypted storage, or a key management system. Never store secret keys in the source code.
  3. Distribute public keys: Distribute public keys to the appropriate peers. The server's public key must be known to the clients, and vice versa. This can be done through a configuration file, a secure key exchange mechanism, or a trusted third party.
  4. Configure sockets for CurveZMQ:
     • Server: Set ZMQ_CURVE_SERVER to 1, ZMQ_CURVE_PUBLICKEY to the server's public key, and ZMQ_CURVE_SECRETKEY to the server's secret key.
     • Client: Set ZMQ_CURVE_SERVERKEY to the server's public key, ZMQ_CURVE_PUBLICKEY to the client's public key, and ZMQ_CURVE_SECRETKEY to the client's secret key.
     • Example (C++ - Server):

       zmq::socket_t socket(context, ZMQ_REP);
       socket.setsockopt(ZMQ_CURVE_SERVER, 1);
       socket.setsockopt(ZMQ_CURVE_PUBLICKEY, server_public_key, 32);
       socket.setsockopt(ZMQ_CURVE_SECRETKEY, server_secret_key, 32);

  5. Verify key handling in your binding: Ensure your ZeroMQ binding correctly handles CurveZMQ and doesn't introduce vulnerabilities.
  6. Test thoroughly: Test the encrypted communication extensively, including error handling and key rotation.

• Threats Mitigated:

  • Man-in-the-Middle (MitM) Attacks: (Severity: High) - Prevents attackers from intercepting or modifying messages.
  • Eavesdropping: (Severity: High) - Prevents unauthorized access to message content.
  • Data Modification: (Severity: High) - Prevents attackers from tampering with messages.
  • Replay Attacks (with proper nonce/sequence number handling in your application): (Severity: Medium) - CurveZMQ provides encryption, but you need to handle replay prevention at the application level.

• Impact:

  • MitM, Eavesdropping, Data Modification: Eliminates the risk of these attacks if implemented correctly. Risk reduction: Very High.
  • Replay Attacks: Reduces the risk, but application-level logic is still required. Risk reduction: Medium.

• Currently Implemented:

  • No encryption is currently implemented.

• Missing Implementation:

  • CurveZMQ needs to be implemented for all ZeroMQ communication. This is the most critical missing security feature. Key management procedures also need to be defined and implemented.

Mitigation Strategy: Keep libzmq Updated

Mitigation Strategy: Regularly update to the latest stable version of libzmq.

• Description:

  1. Monitor for updates: Subscribe to the ZeroMQ mailing list or regularly check the official website for new releases and security advisories.
  2. Test updates in a staging environment: Before deploying updates to production, thoroughly test them in a staging environment that mirrors the production environment.
  3. Apply updates promptly: Once an update is tested and verified, apply it to the production environment as soon as possible.
  4. Update bindings: Ensure that the ZeroMQ binding/wrapper you are using is also updated to be compatible with the new libzmq version.

• Threats Mitigated:

  • Vulnerabilities in libzmq: (Severity: Variable, potentially High) - Addresses known security vulnerabilities in the underlying ZeroMQ library.

• Impact:

  • Vulnerabilities: Reduces the risk of exploitation of known vulnerabilities. Risk reduction: Variable, potentially High, depending on the vulnerability.

• Currently Implemented:

  • The project is currently using libzmq version 4.3.4.
  • There is no established process for regularly checking for and applying updates.

• Missing Implementation:

  • A formal process for monitoring, testing, and applying libzmq updates needs to be established.
  • Check if 4.3.4 is the latest stable version, and update if necessary.