Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question concerning CVE-2019-17543 #801

Closed
rfrohl opened this issue Oct 16, 2019 · 2 comments
Closed

Question concerning CVE-2019-17543 #801

rfrohl opened this issue Oct 16, 2019 · 2 comments

Comments

@rfrohl
Copy link

rfrohl commented Oct 16, 2019

Hi,
I am looking into CVE-2019-17543 [0][1], specifically I am trying to verify if the issue is present since 2014 as stated in the comment [2].

I am testing lz4 version 1.8 and tried to reproduce the issue using an asan build. The command used to reproduce was 'lz4 -1 -l reproducer outfile'.

Verified that libasan.so was used by lz4 and liblz4.so.1.8.0, verified that the correct liblz4 library is used and that the reproduce is the correct. But still do not see a problem with the old version(v1.8.0).

It would be great if someone could provide some feedback/background concerning the statement, that the problem is present since 2014.

Please note that I used a patch for lz4 which forces the lz4 binary to use the shared library instead of inlining all the LZ4_* functions. But I think that should not cause any problems.

[0] #756
[1] http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-17543
[2] https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=15941#c1

@Cyan4973
Copy link
Member

This is a relatively hard to trigger bug.

Yes, it has been in the lurking for a long time, but the conditions required to trigger it are not trivial. Actually, in most systems, including the lz4 frame format and API, the bug is just out of reach. That's what makes it so difficult to discover, and since it also requires multiple uncommon constraints on the encoder side, which are out of direct control from an external actor (in contrast with the payload), this bug is rarely "reachable", making it a poor exploit vector.

Note that the CLI is immune to this bug, as it does not present the required constraints to be exposed, hence the suggested reproduction command lz4 -1 -l outfile should not work. The CLI is considered safe, for all versions. It's only a few specific / uncommon usages of the API which are at risk.

We invite all users of LZ4 to upgrade to v1.9.2, to reduce exposure to risks, but the risk is low : specifically, the lz4 CLI is safe, and all "common" usages of the API (covered by the documentation) are safe too.

@rfrohl
Copy link
Author

rfrohl commented Oct 17, 2019

Thanks for the answer, that clarifies why the reproduce does not work in my test case!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants