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

Log4j2 CVE-2021-44228 Vulnerability #49

Closed
retrodaredevil opened this issue Dec 11, 2021 · 1 comment
Closed

Log4j2 CVE-2021-44228 Vulnerability #49

retrodaredevil opened this issue Dec 11, 2021 · 1 comment
Labels
security vulnerability An issue relating to a security vulnerability. These issues may remain open for visibility

Comments

@retrodaredevil
Copy link
Member

This issue is fixed in 07023ee, which as of writing is not in any official SolarThing release yet. This issue serves to document how this vulnerability could affect SolarThing users.

This vulnerability is not caused by SolarThing itself, but by a library that SolarThing uses, Log4j2.

Vulnerability Links

How SolarThing is affected

So first, a little about how the exploit could affect SolarThing. If someone is able to send a request to some SolarThing service that uses Log4j2, it can be exploited.

The most obvious possibility is SolarThing GraphQL, which actually doesn't use Log4j2, so there is no vulnerability there. (SolarThing GraphQL uses the default Logback setup)

The second possibility is for SolarThing programs running that upload to the database. Most of the time, these programs only upload to the database, so there is no possibility for malicious input from outside actors. Unless you have commands enabled. If you have commands enabled, it's entirely possible for a malicious actor to upload data to solarthing-open, which will eventually be downloaded by the program that accepts commands, and potentially logged.

The third possibility is the SolarThing automation program. The automation program queries solarthing-open,

So can someone actually exploit this? If you don't trust the people on your local network for some reason, or have your CouchDB database open to the entire Internet for anyone to upload to solarthing-open, then it might be worth disabling commands for the time being.

Summary

While all setups have this particular vulnerability, if you have a default setup without commands enabled and without an automation program, your SolarThing program is not vulnerable as there is no way that I am aware of to exploit this vulnerability.

Remember this vulnerability could only be exploited by someone with access to your CouchDB database, so you likely do not have to worry about it if you trust the devices on your local network.

When the next version of SolarThing is released, I recommend everyone to upgrade. The next release will fix this vulnerability, plus add some new features (that most people won't use anyway)

If anyone who uses SolarThing ends up reading this and has questions on how their setups could be affected, I'm happy to answers any questions about it.

@retrodaredevil
Copy link
Member Author

Please update to v2021.7.1.

Leaving this issue open for visibility.

@retrodaredevil retrodaredevil added the security vulnerability An issue relating to a security vulnerability. These issues may remain open for visibility label Dec 11, 2021
@retrodaredevil retrodaredevil pinned this issue Dec 29, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
security vulnerability An issue relating to a security vulnerability. These issues may remain open for visibility
Projects
None yet
Development

No branches or pull requests

1 participant