Vulnerability Log4j

[ojones]

Folks - does anyone know if Sage 9x (or the various web server or other plug ins) utilize a version of log4j that may have the recently announced vulnerability?

[jusjoken]

Originally Posted by ojones

Folks - does anyone know if Sage 9x (or the various web server or other plug ins) utilize a version of log4j that may have the recently announced vulnerability?

The version installed by the plugin is 1.2.17...which is very old. What versions are affected ?

K

[ojones]

Looks like we have a problem. I grabbed the following from PaloAlto. 1.2 to 1.2.17 is implicated. I have locked inbound ports on sage until I know this is resolved. To be clear this exploit allows remote code execution with full shell access.

Excerpt follows:
"CVE-2017-5645: For Apache log4j 2.x before 2.8.2, the log4j servers will deserialize any log events received from other applications through TCP or UDP socket servers. If a crafted binary payload is being sent using this vulnerability, it can lead to arbitrary code execution.

CVE-2019-17571: For Apache log4j versions from 1.2 (up to 1.2.17), the SocketServer class is vulnerable to deserialization of untrusted data, which leads to remote code execution if combined with a deserialization gadget"



https://unit42.paloaltonetworks.com/...ve-2021-44228/

[jusjoken]

From the little research I just did the move from 1.2 to 2.82 affects sage core code and numerous plugins and is not just a matter of changing the available log4j jar... So I would plan this to take some time if the developers left take on all the work.

I also believe that the 1.2 vulnerability is only related if using the SimpleSocketServer class provided by log4j. I see no use of that in SageTV nor in any of my nor stuckless plugins.

Others should chime in as I do not want to be providing security advice...just providing some fact so people can be informed
K

[ojones]

Ken,

I'm a few steps below you on the dev skills ladder but appreciate the insight on the use of Log4j in the code base.

I think anyone who has ports forwarded for sage may want to think about increasing firewall security for now anyway (I did) but hoping that others who have a better feel for the code will be able to confirm there is no threat here.

We use site to site vpns so our functionality loss will be limited.

Best of luck with your projects!

[jusjoken]

On further review, it does not look like the SageTV core products use log4j. So anyone using the base without any plugins should have no risk.

To see if any of your plugins are using log4j, go to Setup, SageTV Plugins, Installed Plugins and select the library tab... Scroll and look for 'log4j'. If it isn't installed then also no risk.

And as I stated above, I am not aware of any plugins using the vulnerable function 'SimpleSocketServer', but I am not sure of a simple way to verify that as we do not have access to all plugin code bases.

As I am doing work on new versions of Jetty, Sagex, BMT, and a number of web apps I will start to look at using log4j 2.82 where possible.

K

[alfi33]

Looks like I have log4j listed in Installed Plugins. When I go to uninstall it, it fails because The Movie DB Library is dependent on it...which is used by the Phoenix API plugin (which is used by Gemstone and BMT?).

[jusjoken]

Originally Posted by alfi33

Looks like I have log4j listed in Installed Plugins. When I go to uninstall it, it fails because The Movie DB Library is dependent on it...which is used by the Phoenix API plugin (which is used by Gemstone and BMT?).

Yep... Thats going to be the issue as you cannot uninstall it without getting rid of the main plugin.

Again, I prefer not to give any security related advise as I will take no responsibility for any issues...but this is a two year old vulnerability and the gemstone and Phoenix plugins do not use the feature that makes it a risk. There are no solutions except block ports, don't use the plugins or wait till some of us test out upgrading log4j and decide for yourself the risk

k

[UgaData]

Article about the Log4j issue in The Register

https://www.theregister.com/2021/12/..._patch_issued/

[wayner]

I am not at home right now so I can't check, but I believe that Slugger's plugins, including SageAlert, SJQ, and SRE, use log4j.

[jusjoken]

Originally Posted by wayner

I am not at home right now so I can't check, but I believe that Slugger's plugins, including SageAlert, SJQ, and SRE, use log4j.

There are 29 plugins that use log4j 1.2.17

K

[Narflex]

I looked at this already, and I think we're fine.

The version hosted for plugins is not vulnerable to the JNDI exploit. The JAR files doesn't contain the JNDI code at all.

The older version with the SimpleSocketServer exploit isn't a problem either, because that feature isn't being used.

So we should be fine.

[wayner]

Thanks Jeffrey!

[ojones]

Thanks Jeffery! Your continuing engagement on Sage is extremely appreciated by all of us (and very glad to know we are in the clear).

My wife will be very happy with Sage when I reopen my ports for streaming!

[wayner]

Originally Posted by ojones

My wife will be very happy with Sage when I reopen my ports for streaming!

[bigbill]

Is that being used on our systems running v9 of SageTV? Or any of the clients?
I am asking because of the vulnerabilities in it that appear to be lighting the internet on fire right now. And want to figure out a way to fix that.

Thanks, Bill

[KeithAbbott]

See this post: https://forums.sagetv.com/forums/showthread.php?t=66855

[sic0048]

I'm glad that Jeff feels that the bug won't effect SageTV users.

That being said, this is yet another reason to use VPNs to connect remotely to your home network instead of port forwarding. Not just for SageTV use, but any use. The days of thinking that port forwarding is adequate and safe are long gone.

There are two types of VPN services - one that you run yourself to securely connect to your local network while remote, and the other that sends all of your home network traffic through a free/paid VPN service in an effort to keep your location and data private. I am speaking of the first kind of VPN service - the one that you will host yourself and use to connect while offsite. Most network gear/routers can host the VPN service needed to run your own connections. I was always hesitant to use VPNs because I thought the learning curve to use them was too great. That simply isn't true. Setting up and using a VPN connection is not hard and well within the reach of any SageTV users.

I'd recommend that if you are not using a VPN connection currently, that you do a Google search with your router's name and "VPN" to find a how-to-guide to set one up.

Other than trying to connect with a HD100/200/300, there really shouldn't be any device that can't connect through a VPN to your SageTV server. Computer clients can certainly use VPN and even most streaming sticks can have a VPN app loaded onto it. You just open the VPN connection using the VPN app before opening the SageTV viewer and trying to connect. It's pretty easy. I have a ShieldTV that has a VPN app on it that makes it a perfect "travel" device. I can take it anywhere and connect to my SageTV server behind my VPN connection without any hassle and do so knowing that my home network is as safe/protected as possible without any unsecure port forwarding. Plus, it's actually easier to use the device with the VPN service because I use the same SageTV server address whether I'm at home or away from home. The VPN connection makes it appear that my ShieldTV is connected to the local network, so using the local SageTV server address works even when I am offsite. I keeps me from having to have two SageTV servers set up in the streaming device and having to choose which one to use depending on my location.

[timg11]

I've been reading about log4j vulnerabilities, and noticed that I have log4j 1.2.17 by stuckless as a plugin. There is also Simple Logging Facade Log4J Implementation Library.

Should I be concerned?

I tried to uninstall, but Infopopup Caller ID (v7.0.4) depends on it. Come to think of it I haven't seen any CID pop ups in a while (but don't have many land line calls either).

ps - thanks to whoever moved my post onto this thread. I don't know how I missed it!

It appears that CallerID no longer works anyway, so I'll just remove it.