Re: CVE-2026-11460 - security flaw in serialization

On 6/23/26 10:07, Andrey Semashev via Boost wrote:
> I believe, it works in the same definition of "works" as for the other
> file types you mention. That is, the user B can download and use the
> archive, but he has no way of knowing whether the file he downloaded is
> the same as the one uploaded by user A. This includes possible tampering
> or unintentional corruption in transit. The user B also doesn't know
> whether the file he downloaded is safe to use. E.g. is the JavaScript
> safe to run? Does the image file have some embedded data that exploits a
> vulnerability in the image parsing library? etc.

Tampering is not an interesting threat.  If Alice wants to download a 
file from Bob and instead receives a tampered file from Charlie, then 
that is only a problem if Alice trusts Bob more than Charlie.  On the 
open internet, Alice shouldn't trust Bob at all, so a tampered file from 
Charlie is not more dangerous than the original file from Bob.

If the browser allows hostile Javascript to be dangerous to the user, 
then that is a serious security issue with the browser.  If an image 
parsing library has an exploitable vulnerability, then that is a serious 
security issue with both the library and the browser that uses it. 
These are bugs, critical bugs, that must be fixed immediately.

There is no guarantee that an image downloaded from the internet is the 
particular image you wanted.  However, there are only two possible valid 
responses a browser can have to a hostile image file.  If it's a valid 
image file that can be displayed, then the browser must display it (even 
though it may not be the image the user wanted).  If it's invalid or 
otherwise can't be displayed, the browser must cleanly handle the error 
without corrupting the process.  The situation is analogous to the 
strong exception guarantee: the operation can succeed or fail, but 
either way it can't leave the system in an unspecified, much less a 
compromised, state.

Meanwhile, the attitude of Boost.Serialization is that passing invalid 
data in results in undefined behavior, which means that it leaves the 
system in a compromised state by default, and there's not even a way to 
validate the data beforehand.  The only choice is to trust the data, 
which means trusting the data source.

Do you see the difference?


-- 
Rainer Deyke - [email protected]

_______________________________________________
Boost mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://lists.boost.org/mailman3/lists/boost.lists.boost.org/
Archived at: https://lists.boost.org/archives/list/[email protected]/message/SMF4RRT37C6QV5UXT2UGLXZJG246I57R/