Synopsis: A violation of the SSE-C security guarantees was discovered and has been fixed in RELEASE.2018–07–10T01–42–11Z.
Who is affected: All users who stored objects using the S3 SSE-C API and used the same client-provided key at least twice for different objects.
Recommended Action for Users: All users are advised to upgrade their Minio deployments to the latest version. This issue is fixed in version RELEASE.2018–07–10T01–42–11Z. Users have to re-upload their objects or use S3 SSE-C key rotation.
If you encrypted all your objects in your
bucket on your server
myminioand your 256 bit client key is
32byteslongsecretkeymustbegiven1 then you can run:
mc cp --recursive --encrypt-key "myminio/bucket=32byteslongsecretkeymustbegiven1" myminio/bucket myminio
This will fix the issue for the bucket
bucket. Users have to use the SSE-C key rotation for all encrypted buckets/objects. For more details run:
mc cp -h.
Description: The Minio server encrypts objects whenever a user requests server-side-encryption with customer-provided keys (SSE-C). Our encryption should guarantee that an encrypted object cannot be modified — except dropping parts in case of S3 multipart upload as specified by S3. However the encrypted objects were not cryptographically bound to the object path. This allows an attacker who knows that two objects were encrypted with the same client-provided key and has full access to the storage backend to exchange both objects. Assuming you have two SSE-C encrypted objects
my-bucket/object-2 and both objects were encrypted with the same client-key then such an attacker can replace
object-2 without detection. However, the attacker can NOT decrypt or modify the objects themselves.
The issue was discovered through an internal security audit and a patch has been submitted to fix the vulnerability by cryptographically binding the encrypted object to the object path. This prevents modifying the object path without knowing the client-provided key. The patch has been reviewed and accepted, and a new release has been made.
An attacker can abuse this issue under special conditions to present unexpected objects to S3 clients.