The Snappy code here https://searchfox.org/mozilla-central/rev/3c8a7970944daaf917b547dffc0790bcd37cadc1/dom/localstorage/SnappyUtils.cpp#62 resizes `nsACString dest` with the uncompressed length of the data. Since the uncompressed length is larger than the compressed length, this can overflow when calling `setLength` which takes 32-bit for the length. The result will be an out-of-bounds write while decompressing. I talked to :janv about this and since local storage is limited to 5MB per origin, this shouldn't ever be exploitable from content. However, I don't know where this limit is enforced and maybe it is possible to circumvent that via IPC and feed larger data into the SnappyUtils. Leaving unclassified until we have investigated this further.
Bug 1741210 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
The Snappy code here https://searchfox.org/mozilla-central/rev/3c8a7970944daaf917b547dffc0790bcd37cadc1/dom/localstorage/SnappyUtils.cpp#62 resizes `nsACString dest` with the uncompressed length of the data. Since the uncompressed length is larger than the compressed length, this can overflow when calling `setLength` which takes 32-bit for the length. The result will be an out-of-bounds write while decompressing. I talked to :janv about this and since local storage is limited to 5MB per origin, this shouldn't ever be exploitable from content. However, I don't know where this limit is enforced and maybe it is possible to circumvent that via IPC and feed larger data into the SnappyUtils. Leaving unclassified until we have investigated this further. Found with `-Wshorten-64-to-32` with some custom filters on top of it + manual code inspection.