Hall of Fame
The Matrix.org Foundation C.I.C.
No matching tags
No matching tags
algorithm is called Olm in Matrix land, but libolm also implements Megolm which is a variant for efficient encrypted group chats between many participants.Since libolm is currently used in all Matrix clients supporting end-to-end But for now, we're stuck with libolm.To start, I decided to do a bit of fuzzing. libolm already had a fuzzing setup modern LLVM-based coverage by a factor of 2.I also noticed that the fuzzing was done with non-hardened binaries (instead of it much more efficient at discovering bugs.After this, I changed the existing harnesses to use AFL's persistent mode serious bugs in the library but a double-free in the fuzzing harness! overhead, I only run a single AFL instance with ASAN variant of the binary. A-ha!Running the offending input on the ASAN variant of the harness revealed it was in the base64 decoder:Following the stack trace, I quickly pinpointed the root of the bug: the logic byte2 in the base64 input which might not actually be there. encoded, only about 6 bits of useful information ended up in the output value.Still, even a single leaked bit is too much in a cryptographic context. preceded with calls to another function, olm::decode_base64_length, which the olm::decode_base64_length check. base64 inputs from the homeserver: the ciphertext to decrypt, an ephemeral input is longer than expected, this will become a stack buffer overflow.The purpose of olm_pk_decrypt is to decrypt secrets previously stored by a Matrix device on the homeserver. to be restored from the server:This vulnerability is a server-controlled stack buffer overflow in Matrix protections exist to make exploiting bugs such as this harder, such as ASLR.Therefore, to achieve remote code execution, an attacker would need to find This is suboptimal.So the plan for future work is roughly as follows:It's very exciting that we're able to do full-time security research on MatrixAs said here by Matrix.org