[doctorpangloss]

Pretty wild!

Serialization bugs are the worst, since receiving weird, untrusted data happens all the time. People think this is about Java and class names and stuff, but it's really about receiving multimedia and decoding it in a performant way.

When will people discover all the vulnerabilities in video codecs, fonts and shaders?

[cjbprime]

Thankfully, file formats are actually one of the more tractable places to find bugs these days, thanks to the rise of fuzzers running on extreme levels of compute resources.

[ljackman]

Agreed. A lot of serialisation support in mainstream languages seem to stand in stark contrast to the principles of langsec [1].

This bug reminded me a bit of Heartbleed actually; it’s pretty different but has that one similarity of two payload lengths, one reported and one actual, disagreeing and not being reconciled, causing memory bugs.

Even with memory safe languages, when you go beyond basic serialisation and look at libraries like Jackson for Java, you discover _very_ questionable designs such as providing an API that makes it all too convenient to switch on a feature which allows user-provided strings to control which classes to instantiate. They solve this using a blacklist of “known bad classes”, which seems to be a workaround rather than acknowledging that many features of common serialisation libraries are a fully loaded uzi pointing at the developer’s foot.

It seems common implementations of serialisation and deserialisation have prioritised ease of use for the developer over declaring clear, bounded intent, and this seems to apply from ad hoc C parsing of network payloads all the way up to automatic serialisation in memory-safe languages.

[1] http://langsec.org/

[kevingadd]

Lots of project zero's previous work has been focused on fonts and video codecs (along with realtime voice/video chat). It's worth reviewing their blog, they published some stuff on facetime recently.

[java-man]

I am afraid never - security is never a design goal, even when security is the main purpose of the software (OpenSSL/ heartbleed).

[miloignis]

That's why I think formally verified implementations are so critical, and why Project Everest (formally verified TLS) is so cool: https://project-everest.github.io/

[johnisgood]

Also: https://github.com/Componolit/libsparkcrypto

[java-man]

Not an ADA guy, just curious:

1. does this library provide a way to clear secrets from memory?

2. does it provide means to ensure that the secrets will not be swapped to disk on page fault or copied in memory?

3. does it bignum implementation provide a way to clear the internal buffer?

thank you.

[johnisgood]

Hey! I only found https://github.com/Componolit/libsparkcrypto/blob/0a3a3c5ed7.... I hope someone who is more acquainted will help us out.

In any case, you should read:

- https://www.auto.tuwien.ac.at/~blieb/AE2017/presentations/ae...

- https://www.auto.tuwien.ac.at/~blieb/AE2017/presentations/Ha...

- https://dwheeler.com/secure-programs/Secure-Programs-HOWTO/p...

- https://dwheeler.com/lovelace/s17s5.htm