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

On 23 Jun 2026 14:12, Rainer Deyke via Boost wrote:
> 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?

By the same logic as the browser, if the archive is valid, according to
the archive format specification, Boost.Serialization has to parse it
and present the result to the user. Otherwise, it must fail with an
error. I'm not a Boost.Serialization user, but I'm assuming that this is
currently the case (otherwise, this would be a bug in the library). In
this sense, the library already does validate the data.

Now, the parsed archive may not be valid from the user's application
standpoint (i.e. if the parsed data does not describe a valid state of
the application), but I don't think Boost.Serialization is in a position
to validate it at that level. Or maybe I'm missing something about
Boost.Serialization.

_______________________________________________
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/5JSWEGTQPO6ZXGFBUWABSQAFZR4ZGBT2/