Saturday, June 28, 2014

Vulnerability assessment

[Edit] There is a new follow up to this story.

I've received an answer from Don Bailey. He blames the situation on a lack of communication. OK. In an attempt to bring the discussion to a more neutral level, this post is dedicated at providing a hopefully clear, concise and factual description of the situation. I hope it will help the reader to properly assess the risk level.

  • There was a vulnerability, it was fully described by Ludwig Strigeus and tracked for correction on the LZ4 issue board
  • The vulnerability is fixed. Update is recommended for 32-bits applications
  • The vulnerability requires uncommon conditions to be exploitable :
    • Input data supplied by untrusted source
    • Large block sizes, preferably ~16MB (beyond LZ4 file format specification)
    • 32-bits applications only
  • These conditions are not met by currently known programs using LZ4
    • For a list of them, get to the LZ4 homepage. It's correct to state that some yet unknown application may match these conditions. That's why the reference version has been fixed
    • Edit : One use case has been found, involving custom scripts to receive untrusted data from external sources using a Python version of LZ4 while not enforcing block size limits. The targeted Python version was using an unprotected version of the decoder. Conclusion remains the same : the Python version has been updated to cover such situation, and is a recommended upgrade
  • The Linux Kernel version, which is different and supplied by LG, has this vulnerability too
  • Linux Kernel programs (which are the only ones to access kernel functions) do not match the conditions that would make it exploitable
  • The Linux Kernel version is nonetheless being fixed too, to avoid any future risk for future versions of the kernel

Hope it helps.

2 comments:

  1. Here are some more actual facts for those reading Tann's incorrect "facts"

    http://blog.securitymouse.com/2014/07/i-was-wrong-proving-lz4-exploitable.html

    ReplyDelete
  2. You seem to not be up to date Erik ...

    http://fastcompression.blogspot.fr/2014/07/software-vulnerabilities-how-it-works.html

    ReplyDelete