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.

Sign up for GitHub

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

Jump to bottom

CVE-2021-44228: Request to Upgrade Log4j #429

Closed
konkodi210 opened this issue Dec 11, 2021 · 20 comments · Fixed by #430
Closed

CVE-2021-44228: Request to Upgrade Log4j #429

konkodi210 opened this issue Dec 11, 2021 · 20 comments · Fixed by #430
Assignees
@jld23

Comments

@konkodi210
Copy link

Describe the bug
Currently SASPY uses log4j 2.12 version has major vulnerabilities. Please refer below link for more details. I request you please help us with updated release which uses latest version of log4j where issue is addressed

https://nvd.nist.gov/vuln/detail/CVE-2021-44228
https://www.lunasec.io/docs/blog/log4j-zero-day/

Version: 3.7.6
jld23 added a commit that referenced this issue Dec 13, 2021
@jld23
Update log4j versions to address Issue #429 (#430)
11afd9f 
* update logj4 to 2.15.0

* bump version

* update classpath versions for log4j
@jld23
Copy link
Contributor

jld23 commented Dec 13, 2021

@konkodi210 The latest version of log4j (2.15.0) have been incorporated into main. See my note that all the testware matches before and after.
I'll wait until tomorrow to push the release to pypi. I'd love it if you have a chance to try it out.
Please let me know if you encounter any issues.
Thanks for reporting this issue.

@jld23 jld23 self-assigned this Dec 13, 2021
@jld23 jld23 linked a pull request Dec 13, 2021 that will close this issue
Update log4j versions to address Issue #429 #430
Merged
@binnisb
Copy link

binnisb commented Dec 14, 2021

Are any of the SAS dependencies using Log4J? Will this force them to use 2.15 as well?

@brentgunderson
Copy link

Does 2.15 continue to have vulnerabilities?: https://www.zdnet.com/article/second-log4j-vulnerability-found-apache-log4j-2-16-0-released/

jld23 pushed a commit to jld23/saspy that referenced this issue Dec 15, 2021
update log4j issue sassoftware#429
8d504e0
jld23 added a commit to jld23/saspy that referenced this issue Dec 15, 2021
@jld23
Merge branch 'main' into issue-sassoftware#429
8e70d0c
jld23 added a commit that referenced this issue Dec 15, 2021
@jld23
Issue #429 (#432)
baf80d3 
* update logj4 to 2.15.0

* bump version

* update classpath versions for log4j

* update log4j issue #429
@jld23
Copy link
Contributor

jld23 commented Dec 15, 2021

@binnisb, I can't speak for certain but I don't think it will force other components to use 2.15. The jars are shipped for ease of use in establishing an IOM connection to SAS. In the earliest versions of SASPy users had to specify their own classpath now that is done on behalf of the user here.

@tomweber-sas do you have anything to add?

@jld23
Copy link
Contributor

jld23 commented Dec 15, 2021

@brentgunderson, Just completed the PR with log4j 2.16. This is at main but not yet pushed to pypi or conda.

Any feedback is welcome.

@pcompieta
Copy link

log4j 2.15 still present in 'iomclient' folder -- likely needs to be removed

jld23 added a commit that referenced this issue Dec 15, 2021
@jld23
Issue #429 (#433)
9c6b759 
* update logj4 to 2.15.0

* bump version

* update classpath versions for log4j

* update log4j issue #429

* remove 2.15 jars
@jld23
Copy link
Contributor

jld23 commented Dec 15, 2021

@pcompieta Thank you! I had them deleted in my fork but somehow in the merge of the PR they didn't get cleaned up.
log4j 2.15 versions have been removed.

@jld23
Copy link
Contributor

jld23 commented Dec 15, 2021

New release of SASPy has been created (v3.7.7) and it has been pushed to pypi

I'm closing this issue. Please report any problems.

@jld23 jld23 closed this as completed Dec 15, 2021
@tomweber-sas
Copy link
Contributor

tomweber-sas commented Dec 17, 2021 •
edited
Loading

Hey, I'm sorry I was on vacation when this came in (at sea for 8 days in the pacific scuba diving w/ no form of communication of any kind; was wonderful :) but back to business).

I want to address the various things in this from the different vulnerabilities in log4j and classpath questions.
First, saspy does not expose any of these various log4j vulnerabilities, so which of these versions it uses it effectively moot. SASPy doesn't use log4j, doesn't initialize it and thus there are no logs being written. So, there's no way for an end user to cause user provided malicious strings to be appended to the logs, such that these vulnerabilities could be exploited.
Second, having a given jar file (whatever version) in the saspy/java/iomclient directory on disk, doesn't make anything else on the system ever use that file, so simply having it there can't cause any other exposure.

As for the classpath, you can still code the classpath yourself, overriding what saspy generates on it's own, so you can easily provide or specify whatever log4j jars you feel are vulnerability free (if there are any). But again, it's moot as saspy doesn't initialize or use the log4j subsystem.

I recently upgraded the log4j provided by saspy to the 2.12.1 version, since previously it had the 1.2 which was past EOL. That version (2.12.7) was the highest version still supporting java 7, which is the documented lowest version of Java supported by SASPy. This new version of log4j that has been promoted, now requires Java V8 or higher, so that backward compatibility is now gone. We will have to document that V8 of java is now the minimum supported. Luckily, Java 7 EOL is fast approaching, but I don't like to just push breaking changes without warning or documenting them. So, I'll have to address that next.

No doubt they will continue to find arbitrary vulnerabilities in whatever version there is, but whatever the case, SASPy won't expose them as it isn't using, or even initializing, the log4j subsystem. Also, you can override whatever version you want by providing it on the classpath you provide if you want.

Please let me know if you have any questions or follow up concerns about any of this! Happy to further the conversation.

Thanks,
Tom

@tomweber-sas tomweber-sas reopened this Dec 17, 2021
@dimon222
Copy link

dimon222 commented Dec 17, 2021 •
edited
Loading

@tomweber-sas what if malicious username or host have been passed to saspy? Does saspy ever print user provided details for method's or functions of saspy?

@tomweber-sas
Copy link
Contributor

Thanks @dimon222, in that case, the connection will fail due to invalid credentials. Neither the id nor pw will be logged via log4j since log4j is not used in the saspy client. So there is no exposure. It will simply fail to establish a connection.
This was a good question and I welcome more. Security is a serious thing and I want to be as transparent as possible with any issues. Understanding how things work is the first step.
So, the follow up question you may ask is what about on the SAS server side? Although there is no logging, and thus no possible exposure on the saspy client, the credentials were provided to the IOM client and sent to the object spawner, which failed the connection. Did it log something with log4j? Maybe. Certainly not the pw. If it logs the id, that would be no different than a connection from any client and still has nothing to do with saspy. Also, even if saspy was running on the same machine as the object spawner, workspace server, the jar file in the saspy deployment would not be used by anything else, not the obj spawner nor workspace server. So, still no exposure based upon the version of the jar in the saspy repo. I can't speak to if there is or isn't any issues on the SAS server side, or what versions of any jar that side uses as that is completely independent of saspy, or any SAS client actually.
Thanks!
Tom

@tomweber-sas
Copy link
Contributor

Oh, sorry I'm on my phone at lunch and missed the rest of your question. I don't print out anything about credentials. And I can't think of any user input that would be printed otherwise. Anything saspy prints would be with pythons print() which goes to pythons stout and had nothing to do with log4j, as that's a Java thing. So again, there's no exposure possible with the log4j jars included in saspy.

@pcompieta
Copy link

pcompieta commented Dec 18, 2021 via email

@tomweber-sas
Copy link
Contributor

Yes @pcompieta, I looked at the Apache statement on this (https://logging.apache.org/log4j/2.x/index.html) and saw 2.12.2 was available and would be compatible w/ saspy as it is and address this security problem. Thanks for pointing that out too!

You are right in that just stating saspy doesn't expose any log4j vulnerabilities won't necessarily satisfy all IT requirements for all companies, so just upgrading to the version that passes the scans is necessary. I'm working on providing both 2.12.2 and 2.16.0 (which is there now) and defaulting to use 2.12.2 in the classpath I build. I am adding a new configuration definition key 'log4j' which will allow you to override (I still build the class path for you) and use the 2,16.0 versions. You can also provide 'classpath' which will be used instead of me building out the claspath (I would see the path I build and use it, only replacing the log4j jars with what you want), so you can always use any version you want.
I'm working on this today and will hopefully get this out and built into a new release so that Java 7 support will be back by default, along with the ability to use the 2.16.0 jars, if that's what is needed with only adding

    'log4j' : '2.16.0',

to your config definition, or adding it on the sas = saspy.SASsession(..., log4j='2.16.0') method.

What do you think about this? Solve all the case, like you're thinking? Am I missing anything?
Thanks!
Tom

@tomweber-sas
Copy link
Contributor

FYI, I just pushed this and built v3.7.8. This uses 2.12.2 but you can tell it to use 2.16.0 if you want, and have Java 8 or higher.
Also, I see that they have now found another possible vulnerability in 2.16.0 and it's addressed in 2.17.0, but I'm not jumping through that hoop till they find more and have a 'final' (yeah, right), version that no scans complain about. Again, none of these can be exposed by saspy as log4j isn't used, but I'll try to keep up with the craziness so that you all can keep using saspy at your companies!

Thanks,
Tom

@tomweber-sas
Copy link
Contributor

oh, https://sassoftware.github.io/saspy/configuration.html#attn-log4j-vulnerabilities-found-in-dec-2021 FYI

@pcompieta
Copy link

pcompieta commented Dec 21, 2021 via email

@tomweber-sas
Copy link
Contributor

Thanks Paolo, yep that's the next one I mentioned they found to then make 2.17.0, which I guess 2.12.3 has that change in it too.

But, I'm not planning on making daily new versions of saspy w/ every new jar they come up with when this is all impossible to be a real problem in the first place; at least for saspy, and probably 90% of all java programs that exist. Even if I used log4j, it would be to write diagnostic records to a log file to help with debugging. That use case can't expose any of these obtuse code paths they are finding where these problems can occur, anyway. None of these issues are about if you write a record to a file that has user provided 'bad stuff' in it, then that somehow causes a problem, because it doesn't. I can write 'sudo rm -rf /*' to a file and guess what terrible things happen to my system? Nothing. Writing log record to a file w/ log4j is probably the most commonly used case, but isn't the code path that can expose these vulnerabilities.

So, until this settles down, I'm going to leave saspy as is with these, current as of yesterday (pass blind scans w/ no context as to if there even a problem or not), jars in place. Once there's a 'final' good set of jars, I'll update to those, if that happens.

For a site that just has to have all log4j files wiped from their system, and only use some version that seems to pass a scan some particular day, that is easily addressed by just deleting the log4j jars from saspy/java/iomclient and providing the classpath to saspy which has the paths to the blessed log4j jar files in place of what saspy would have had in the classpath it generated (along w/ the rest of the classpath saspy normally generates, of course; just change the log4j part of the path). That can be done w/ any version of saspy, in fact.

Again, thanks for your input and help on this! Very much appreciated.
Tom

@tomweber-sas
Copy link
Contributor

Just an FYI. SASPy V4.0.0 is now production and has 2,12,4 and 2,17,1, as they are the latest versions for all these log4j problems.

@tomweber-sas
Copy link
Contributor

With the latest log4j jars pushed into the current release, and it looking like those may be the last ones now, for some time. I'll go ahead and close out this issue. If more problems are found, and more releases created to get around them, I'll update again. But for now it looks like the dust has settled.
As always, if you need anything else, just reach out!
Tom

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@jld23 jld23

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Update log4j versions to address Issue #429 jld23/saspy
7 participants
@binnisb @dimon222 @jld23 @pcompieta @tomweber-sas @brentgunderson @konkodi210