https://lakefs.io/ logo
Join Slack
Powered by
No immediate action from us. But Spark users will ...
# dev
a
No immediate action from us. But Spark users will probably be vulnerable, regardless of whether or not they use lakeFS clients (depending on how much 3rd parties can control what they log). Operators should set the relevant property to avoid loading executable code from user-supplied urls. But this is a nasty bug, and one that was completely avoidable. https://www.theregister.com/2021/12/10/log4j_remote_code_execution_vuln_patch_issued/ I reckon once an actual official patch is available, we can bump versions in our Java clients.
👍 3
CloudFlare have a great part up, as usual: https://blog.cloudflare.com/inside-the-log4j2-vulnerability-cve-2021-44228/ You will want to read it, then run one or both of the mitigations provided. The easiest is to set property 
log4j2.formatMsgNoLookups=true
. This is CVE-2021-44228, and because it is driven by data it may be a very big deal. I shall be producing a full analysis for whether our clients ever log user-supplied data by tomorrow: the clients do see object keys (paths) and may log or include them as errors, these are user-controlled and thus suspect. I shall also determine whether our JVM clients assemble log4jv2. That said, at this point switching off this whole lookup mess as detailed in the above blog or CVE is the only safe course of action.
We seem good with this: no clients in github.com/treeverse/lakeFS appear to package log4j. HOWEVER actually running them in any Spark or other JVM may expose you, IF a vulnerable log4j is loaded. BE SAFE: Set 
log4j2.formatMsgNoLookups=true
or use some other workaround.
4 Views
Open in Slack
PreviousNext
Powered by