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 automated release from the main branch failed. 🚨

I recommend you give this issue a high priority, so other packages depending on you can benefit from your bug fixes and new features again.

You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. I’m sure you can fix this 💪.

Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.

Once all the errors are resolved, semantic-release will release your package the next time you push a commit to the main branch. You can also manually restart the failed CI job that runs semantic-release.

If you are not sure how to resolve this, here are some links that can help you:

• Usage documentation
• Frequently Asked Questions
• Support channels

If those don’t help, or if this issue is reporting something you think isn’t right, you can always ask the humans behind semantic-release.

Could not access Cargo.toml

Cannot read properties of undefined (reading 'R_OK')

Good luck with your project ✨

Your semantic-release bot 📦🚀

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.

References

time-rs/time#293

See advisory page for additional details.

TLDR

This crate uses both rustls and openssl. Because openssl can be difficult sometimes, it might be better to standardize on rustls.

Description

When using the credentials feature the following 2 dependencies are activated:

1. openidconnect
2. reqwest

openidconnect

The openidconnect dependency is pulled in with its default features:

• oauth2
• rustls-tls

These default features pull in the oauth2 dependency which then pulls in reqwest with rusttls-tls enabled.

reqwest

The reqwest dependency is included with its default features. This pulls in openssl when running on Linux/Docker. The final result of this is that the Zitadel crate includes a reqwest dependency that uses both rustls and openssl.

Suggested Solution

Normally, including extra unneeded dependencies is not a big problem, but openssl can be painful when building some docker images which do not include openssl in the base image (e.g Alpine Linux).

There is a simple one line change for this behaviour to standardize on rusttls and I can make a PR for this.

Hi!

I came across this library and tried to find out how to e.g. modify organization metadata. There is bulk_set_org_metadata, however, the API specification states, that the organization to be modified is set in the headers. Is there a way to set which organization to modify using this client?

This would probably be even more important for things like remove_org, where there is an empty request and the whole information which org to delete is in the headers.

Thank you!

Potential segfault in localtime_r invocations

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.

Workarounds

No workarounds are known.

References

• time-rs/time#293

See advisory page for additional details.

Hi, thank you for creating this crate!

Would it be possbile to update axum to 0.7?

I also wondered how one could pass other states to axum through app.with_state() like a mongodb client while using the User extractor.

Add User Grant has a documented optional parameter "x-zitadel-orgid" which is important for the correct execution of the function.

As far as I can tell, there's currently no way to set this header in the current function.

This also applies to other functions.

Hi, been playing for a bit with this module, but can't get it running properly using Actix.
Is there any examples for that specific framework?

First of all thanks for this great create!

The Problem

Tonic Service Client are designed to be cloned in Multi-Threading/Multiplexing scenarios. There is a section "Multiplexing-Requests" on this in the tonic docs: https://docs.rs/tonic/latest/tonic/transport/struct.Channel.html#multiplexing-requests

As a result a tonic client implements Clone. When using a client build with this crate, a XXXServiceClient<InterceptedService<TonicChannel, ChainedInterceptor>> is returned. Everything except ChainedInterceptor implements Clone.

I need to use the client in a Multiplexing scenario and require the client to implement a lightweight clone to avoid opening a large number of channels.

The Solution

... is not as trivial as I would have though because ServiceAccountInterceptor requires mutability for the token. I changed it to use Interior Mutability instead.

I also had to introduce a new Interceptor trait which I don't like.
The only reason for the new interceptor trait is the ChainedInterceptor chain method which runs calls via the original Interceptor trait on &mut self. This breaks my interior mutability approach though.

I would argue that even if you decide to stick to the old implementation of the ChainedInterceptor , the changed ServiceAccountInterceptor and AccessTokenInterceptor are better off using interior mutability and can still be used in clone-able clients even though we couldn't use the ClientBuilder to obtain them.

PR is coming in a second, let me know if you have any better ideas!

When authenticating with Zitadel it is possible to add additional scopes, e.g urn:zitadel:iam:user:resourceowner and urn:zitadel:iam:user:metadata. If these scopes are used, it is possible to get extra information when calling OIDC Introspection.

Currently, only the default introspection fields are considered and any extra fields are ignored.

Would you be open to a PR that added support for these extra fields? I was thinking of something like using #[serde(flatten)] to support metadata: serde-rs/serde#941 (comment)

Building the zitadel crate, also as a dependency, fails with the following error if you don't have protobuf development files installed:

   Compiling zitadel v3.1.9
error: failed to run custom build command for `zitadel v3.1.9`

Caused by:
  process didn't exit successfully: `/home/emelie/[...]/debug/build/zitadel-18a8719d73ee0e93/build-script-build` (exit status: 1)
  --- stdout
  cargo:rerun-if-changed=external/zitadel/proto
  cargo:rerun-if-changed=external/protoc-gen-validate
  cargo:rerun-if-changed=external/googleapis
  cargo:rerun-if-changed=external/grpc-gateway

  --- stderr
  Error: Custom { kind: Other, error: "protoc failed: google/protobuf/descriptor.proto: File not found.\ngoogle/protobuf/struct.proto: File not found.\nprotoc-gen-openapiv2/options/openapiv2.proto:5:1: Import \"google/protobuf/struct.proto\" was not found or had errors.\nprotoc-gen-openapiv2/options/openapiv2.proto: \"google.protobuf.Value\" is not defined.\nprotoc-gen-openapiv2/options/openapiv2.proto: \"google.protobuf.Value\" is not defined.\nprotoc-gen-openapiv2/options/openapiv2.proto: \"google.protobuf.Value\" is not defined.\nprotoc-gen-openapiv2/options/openapiv2.proto: \"google.protobuf.Value\" is not defined.\nprotoc-gen-openapiv2/options/openapiv2.proto: \"google.protobuf.Value\" is not defined.\nprotoc-gen-openapiv2/options/openapiv2.proto: \"google.protobuf.Value\" is not defined.\nprotoc-gen-openapiv2/options/openapiv2.proto: \"google.protobuf.Value\" is not defined.\nprotoc-gen-openapiv2/options/annotations.proto:5:1: Import \"google/protobuf/descriptor.proto\" was not found or had errors.\nprotoc-gen-openapiv2/options/annotations.proto:6:1: Import \"protoc-gen-openapiv2/options/openapiv2.proto\" was not found or had errors.\nprotoc-gen-openapiv2/options/annotations.proto:10:8: \"google.protobuf.FileOptions\" is not defined.\nprotoc-gen-openapiv2/options/annotations.proto:17:8: \"google.protobuf.MethodOptions\" is not defined.\nprotoc-gen-openapiv2/options/annotations.proto:24:8: \"google.protobuf.MessageOptions\" is not defined.\nprotoc-gen-openapiv2/options/annotations.proto:31:8: \"google.protobuf.ServiceOptions\" is not defined.\nprotoc-gen-openapiv2/options/annotations.proto:38:8: \"google.protobuf.FieldOptions\" is not defined.\n" }
warning: build failed, waiting for other jobs to finish...

As far as I can tell this isn't documented anywhere. Documenting it could be quite helpful, as it's not immediately obvious what the problem is from the error message. On fedora the required package is protobuf-devel, I would assume it's protobuf-dev on apt-based distros.