GHSA-hfr4-8rjc-97m2: Active Storage: Possible circumvention of file size limits in Active Storage direct uploads to Google Cloud Storage
Impact ActiveStorage::Service::GCSService#urlfordirectupload does not bind the declared content length into the signed direct-upload URL, and #headersfordirectupload returns no length constraint, so the URL authorizes an upload body of any size. A direct-upload client could store a file larger than the bytesize it declared, and the resulting blob keeps the declared size, possibly bypassing application file size validations and quotas. This is the weakness that CVE-2020-8162 fixed in the S3 service.
Applications that store files in Google Cloud Storage and accept direct uploads are affected.
Details The fixed releases sign an x-goog-content-length-range header that matches the blob's declared bytesize and return it from headersfordirectupload, so Cloud Storage rejects an upload body of any other size. Browsers send this header with the direct upload, so a bucket's CORS configuration must list x-goog-content-length-range in responseHeader, or browser direct uploads fail after the upgrade. The Active Storage CHANGELOG and the CORS example in the Active Storage guide show the change.
Releases The fixed releases are available at the normal locations.
Patches for those who cannot upgrade at once: - 8.1: https://github.com/rails/rails/commit/e19916cea31cbfb0030b165ae853b741f8dd57a7.patch - 8.0: https://github.com/rails/rails/commit/7fe85a72a789eae5ee070ce3ee1dad10a8a5f70c.patch
Credit This issue was responsibly reported by HackerOne researcher f4cts.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
rubygems/activestorageto a version that resolves this vulnerability.Fixed in 8.0.5.2 - Upgrade
Upgrade
rubygems/activestorageto a version that resolves this vulnerability.Fixed in 8.1.4.1 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 8.0 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 8.1 - Configuration
List x-goog-content-length-range in the bucket CORS responseHeader configuration so browser direct uploads continue to work after upgrading.
Google Cloud Storage bucket CORS configuration responseHeader = x-goog-content-length-range
Event History
Frequently Asked Questions
Which deployments are affected?
Applications using Active Storage with Google Cloud Storage that accept direct uploads are affected. The issue concerns direct-upload URLs generated by the GCS service.
What does an attacker need to exploit this?
An attacker needs to act as a direct-upload client and declare a smaller byte size than the body they upload. The signed URL does not constrain the actual upload size, while the resulting blob retains the smaller declared size.
What is the impact on application controls?
Application file-size validation and storage quota controls may be bypassed because they can rely on the blob's declared size rather than the larger uploaded object size. This issue affects integrity, not confidentiality or availability, according to the supplied severity vector.
What configuration change may be required when applying the fix?
For browser-based direct uploads, the Google Cloud Storage bucket CORS configuration must include x-goog-content-length-range in responseHeader. Without this, browser direct uploads fail after upgrading to a fixed release.