samply / beam Goto Github PK

the config being in shared and the confusing way it is initialized need to be refactored at some point.

Marvin Attack: potential key recovery through timing sidechannels

Impact

Due to a non-constant-time implementation, information about the private key is leaked through timing information which is observable over the network. An attacker may be able to use that information to recover the key.

Patches

No patch is yet available, however work is underway to migrate to a fully constant-time implementation.

Workarounds

The only currently available workaround is to avoid using the rsa crate in settings where attackers are able to observe timing information, e.g. local use on a non-compromised computer is fine.

References

This vulnerability was discovered as part of the "Marvin Attack", which revealed several implementations of RSA including OpenSSL had not properly mitigated timing sidechannel attacks.

See advisory page for additional details.

It would be a good idea to publish JSON Scheme descriptions for the API. Additionally, these schemes can be used for validation and better error messages.

Currently, Beam shows the following log on expired certificates:

beam-demo-proxy-1  | 2022-08-15T06:51:12.168419Z  INFO shared::crypto: Updating certificates ...
beam-demo-proxy-1  | 2022-08-15T06:51:12.433494Z DEBUG shared::crypto: Received 3 certificates (3 of which were new).
beam-demo-proxy-1  | 2022-08-15T06:51:12.511630Z DEBUG shared::crypto: Certificate update successfully completed.
beam-demo-proxy-1  | 2022-08-15T06:51:12.511687Z  WARN shared::crypto: Unable to find cert <...> even after update.
beam-demo-proxy-1  | Error: Communication with <...>.PKI failed: Unable to fetch your certificate from vault. Is your local Client ID really <...>?

However on expired certificates, the output should be clearer.

The tests querying the v1/tasks resource fail after being redirected. Please fix the underlying issue for a passedtest result.

Currently, all newly retrieved certificates are tested for validity. As invalid (i.e., expired) certificates are not stored, they are retrieved and checked in every update operation. This can be optimized by managing a blacklist of certificates, that are dropped without further processing. Furthermore, the amount of queries to the central CA might have room for improvement.

Until now, the /v1/health resource just returns a fixed 200 OK reply. This is acceptable for basic connectivity and and uptime monitoring, however a more involved healtch check evaluation everything required for an operational status would be nice.

Marvin Attack: potential key recovery through timing sidechannels

Impact

Due to a non-constant-time implementation, information about the private key is leaked through timing information which is observable over the network. An attacker may be able to use that information to recover the key.

Patches

No patch is yet available, however work is underway to migrate to a fully constant-time implementation.

Workarounds

The only currently available workaround is to avoid using the rsa crate in settings where attackers are able to observe timing information, e.g. local use on a non-compromised computer is fine.

References

This vulnerability was discovered as part of the "Marvin Attack", which revealed several implementations of RSA including OpenSSL had not properly mitigated timing sidechannel attacks.

See advisory page for additional details.

The Broker could serve a (HTTP Basic Auth protected) metrics endpoint, providing information such as:

• Memory Usage
• Number of tasks in queue
• Tasks/Results stratified by ProxyId and/or Metadata
• Mean Time between Task and Result creation (filtered/stratified by Metadata)

The Prometheus crate might be a good candidate for implementing the reports.

Upon startup, perform sanity check of a) certificate and b) claimed Client ID. In case of mismatch, crash on startup.

Potential segfault in the time crate

Impact

Unix-like operating systems may segfault due to dereferencing a dangling pointer in specific circumstances. This requires an environment variable to be set in a different thread than the affected functions. This may occur without the user's knowledge, notably in a third-party library.

The affected functions from time 0.2.7 through 0.2.22 are:

• time::UtcOffset::local_offset_at
• time::UtcOffset::try_local_offset_at
• time::UtcOffset::current_local_offset
• time::UtcOffset::try_current_local_offset
• time::OffsetDateTime::now_local
• time::OffsetDateTime::try_now_local

The affected functions in time 0.1 (all versions) are:

• at
• at_utc
• now

Non-Unix targets (including Windows and wasm) are unaffected.

Patches

Pending a proper fix, the internal method that determines the local offset has been modified to always return None on the affected operating systems. This has the effect of returning an Err on the try_* methods and UTC on the non-try_* methods.

Users and library authors with time in their dependency tree should perform cargo update, which will pull in the updated, unaffected code.

Users of time 0.1 do not have a patch and should upgrade to an unaffected version: time 0.2.23 or greater or the 0.3 series.

Workarounds

No workarounds are known.

See advisory page for additional details.

If the long-polling of tasks or results is disrupted by session terminations (e.g. caused by latency spikes), the proxy client is not informed of that connection loss. An alternative, transparent long-polling mechanism could look like the following:

The long polling wait_time is set as a maximum wait time. If no wait_time is given, a sensible default cap is chosen (e.g. 1 minute). The proxy chooses a lower wait time for repeated long-polls to the broker, up to the chosen maximum time. The timeout for that connection is chosen using a learning mechanism analyzing previous requests (and optionally an echo endpoint in the broker) and converging to an optimal time.

In case of a fast, unimpeded connection, the result is returned – as expected by the application – as fast as it is available in the broker or at least partially after wait_count. In case of a broken session, the connection is transparently reinitialized by the proxy.

The certificate cache is a single-writer-multiple-reader data structure and could benefit from a lockfree design for reading.
This would reduce the need for async methods, hence increase usability in traits.

The --json convenience option combining the method, content type headers, and data flag was introduced in cURL version 7.82.0. However, Debian only ships cURL 7.74.0, so the Getting Started should refrain from using it and mention all parameters.

A local beam-proxy instance seems to not re-validate an expired certificate on new requests, leading to false http 415 responses. To reload the fresh signed certificate from the beam-broker a restart of the local beam-proxy is necessary.

For future audit and pruning features, as well as the possibility to change queued tasks (e.g., add recipients) it might be a good idea to add CreateTimestamp and ModifyTimestamp fields to MsgTaskRequest and MsgTaskResult. What do you think?

Currently, the debug output of encrypted messages print the payload as a vector of decimal encoded bytes. This takes up a lot of space without giving significant information. It would be great to improve the debug log by compacting the output to a hex encoded string.

I had a task body with missing id. The error message is always only Invalid body.