2020-08-10: Just another Null Byte Poison via Unicode variant (MuPDF mutool RCE)

Null Byte Poison is a neat little attack that usually can be applied when "length+data"-type strings get converted into "zero-terminated"-type strings. It's a well known problem though that haunted PHP scripts for several years, and even visited the browser world. Nowadays a lot of languages (or rather: runtime environments of these languages) have built-in protections against it (including PHP!) - for instance see this Python example:

>>> open("\0") Traceback (most recent call last): File "<stdin>", line 1, in <module> ValueError: embedded null character

Unicode brought another similar problem to the table in the form of two ways (one invalid-yet-working) to encode a Null Byte without using an actual \x00 byte - this allows to, depending on the scenario, either bypass a Null Byte Poison detection, or actually inject a Null Byte into a "zero-terminated"-type string at a later processing stage (which is sometimes useful):

UTF-8 overlong sequence : \xC0\x80

: UTF-7 being UTF-7: +AAA-

In the above cases when the strings get decoded to Unicode we (might) see Null Bytes popping up in the data. Thankfully all decent UTF-8 decoders deal properly with overlong sequences and nothing modern uses UTF-7 anyway (with the notable exception of Express.JS in some scenarios).

While playing with a path traversal bug in mutool (details below) I've found yet another Unicode-related way to inject a Null Byte into a string. This method actually relies on a decoder bug and is pretty case-specific, but I think it's worth testing for as I wouldn't be surprised to find it again in similar scenarios in the future.

The bug in question resided in this code (mupdf/source/fitz/time.c):

Read more... [ 5 comments ]