Image

Image

"The complexity of the Qmage codec is very high -- QMG files may choose from a wide range of different custom compression schemes, each of them handled by a lengthy and obscure decompression routine. There are dozens of functions with over 4 kB in length in the library, with the single longest function (QuramQumageDecoder32bit24bit) being 40 kB (!) long. This translates to tens of thousands lines of C code that likely have never been subject to much scrutiny in the form of a security audit or fuzz testing. I conclude this based on the fact that the code seems to be lacking any kind of bounds checking at any point of the file parsing, and it crashes instantly with almost every trivial modification to a valid testcase (e.g. when the dimensions of the image are slightly increased)."There is some good news, however. Firstly, the vulnerability is specific to software that ships with Samsung Android devices since late 2014 / early 2015. That means if you're using an Android smartphone from a different manufacturer you should not be at risk from this vulnerability. Secondly, Google Project Zero has not released its proof-of-concept code, preferring to release a video demonstration instead. That reduces the chances of someone taking the attack code and adapting it for their own malicious purposes against unpatched Samsung smartphones. Thirdly, Jurczyk says that a successful attack typically requires 50-300 MMS messages to be sent to the targeted device before it successfully bypasses some of Android's built-in security measures. As such an attack takes approximately 100 minutes (the actual length of time can depend upon a number of factors) to succeed. Finally, and most importantly, Jurczyk responsibly informed Samsung of the critical security vulnerability in January, but has delayed public disclosure of the issue until this week - giving time for the phone manufacturer to develop a fix (SVE-2020-16747) for its many millions of users.
Editor’s Note: The opinions expressed in this guest author article are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc.