Converting java based plugins to 64-bit

[moisescastellano]

2Flint:
Thanks for creating my account.
I have created the plugin here.
I numbered version as 2.0 as it would be confusing to start with 1.0 as Ken Handel's latest version was 1.7

For the download I just upload one of the updated examples: JCatalogue.zip
I do not know how create a examples page like the one Handel created at: http://java.totalcmd.net/V1.7/examples.html
Otherwise I would have to create a plugin per each updated example.
Also how to create the linked pages for changes notes and others, as found in the old plugin main page:
http://totalcmd.net/plugring/tc_java.html

2Ghisler:

"To avoid the duplication of the java library, I could modify the plugin to send the user to a download page, what do you think? The java lib could be improved by adding an install.inf with the type=EXE."

Would this allow installing simply by entering the plugin zip, and would it automatically download and install javalib? If so, that would be great.
But do you think it is worth your effort?: for instance, removing common libraries not used by JCatalogue, it is just under 2 Mb.

[moisescastellano]

Do you mean updating/replacing the plugin on the original page at https://totalcmd.net/plugring/tc_java.html ?

No, I think Ghisler was just suggesting not to duplicate the javalib in each plugin.

[ghisler(Author)]

No, I meant the plugins which user moisescastellano updated to 64-bit. They all contain the 64-bit plugin I compiled. This plugin now shows an error about a missing class if the tc_java library isn't installed. Here it could instead tell the user to download tc_java, and if he clicks yes, redirect them to a landing page on ghisler.com so he can download tc_java.

tc_java itself wouldn't need to be changed, but I could host an updated archive with an added install.inf on my landing page.

[ghisler(Author)]

2moisescastellano
You have certainly heard about the security vulnerability in log4j (CVE-2021-45046).

The javalib distribution includes an old log4j version: 1.2.8 (log4j-1.2.8.jar), which is not vulnerable because the problematic JNDI look up was only added to log4j 2.0.0.

My question is whether JRE will use a newer log4j version if it is installed on the same system.

Also do I understand it correctly that the included log4j.xml file disables logging:

Code: Select all

<log4j:configuration debug="false" threshold="debug"  xmlns:log4j="http://jakarta.apache.org/log4j/">
    <appender name="zeroconf" class="org.apache.log4j.net.ZeroConfSocketHubAppender">
        <param name="Name" value="Total Commander Java Plugin Interface"/>
		<param name="LocationInfo" value="true" /> 
    </appender>
    <!--ROOT Logger-->
    <root>
        <level value="debug" />
        <appender-ref ref="zeroconf" />
    </root>
</log4j:configuration>

because of this combination:
debug="false"
and
threshold="debug"

[nsp]

2moisescastellano
You have certainly heard about the security vulnerability in log4j (CVE-2021-45046).

The javalib distribution includes an old log4j version: 1.2.8 (log4j-1.2.8.jar), which is not vulnerable because the problematic JNDI look up was only added to log4j 2.0.0.

My question is whether JRE will use a newer log4j version if it is installed on the same system.

Also do I understand it correctly that the included log4j.xml file disables logging:

Code: Select all

<log4j:configuration debug="false" threshold="debug"  xmlns:log4j="http://jakarta.apache.org/log4j/">
    <appender name="zeroconf" class="org.apache.log4j.net.ZeroConfSocketHubAppender">
        <param name="Name" value="Total Commander Java Plugin Interface"/>
		<param name="LocationInfo" value="true" /> 
    </appender>
    <!--ROOT Logger-->
    <root>
        <level value="debug" />
        <appender-ref ref="zeroconf" />
    </root>
</log4j:configuration>

because of this combination:
debug="false"
and
threshold="debug"

The vulnerability is more for Server than for local application...
Normally log4j.xml only target log4J 1.xxx by default log4j2 use log4J2.xml and the format is not the same.

log4j1 instrumentation is compatible with log4j2 libraries only if you add an api wrapper in the classpath.

log4j.xml should be edited to debug or get support for a java plugin..


The debug=false in the configuration just disable logging the log4j operations during configuration loading.
threshold=debug is a filter to enable all messages with severity egal or greather to debug for the configuration loading.


to dissable the logging, you have to use:

Code: Select all

    <root>
        <level value="none" />
        <appender-ref ref="zeroconf" />
    </root>

[moisescastellano]

2ghisler:

From what I understand, these vulnerabilities could affect servers running Java code, where user input is being accepted that could, when logged via those Log4J versions, generate JNDI Lookup causing remote code execution or denial of service.

In the plugins we are running the code in our local machine; even if it were used as a server, plugins are not part of the server software, so we are not receiving (and Log4J is not logging) anything received from outside users.

On your specific question, JRE does not use any log4J library installed in the system unless you specify that in the classpath, which here we are doing in the tc_javaplugin.ini properties.

Regarding the log4j.xml, the debug="false" at the beginning is just for debugging the log4J initialization itself. With that xml file, it should be logging at debug level. However, as I wrote in the to-do.txt inside the new JCatalogue.zip:

I have not been able to get the logging for plugins to work. Handel configured the ZeroConfSocketHubAppender by default, that works along with Apache Chainsaw, sending logs visa sockets and showing in a GUI. I installed Chainsaw, but just the initial connections is logged. Also Chainsaw is quite deprecated, having a main page with lots of broken links, and dependencies are hard to find.

So I tried to update the commons-logging and log4j libraries and config them to log in file, but also that did not work.

Then I updated to log4j2, it didn't work either.

I have come to the conclusion that the way the PluginClassLoader loads the jars from javalib is incompatible with Log4j's Loggers instantiation. (and for Handel logging maybe just worked in a previous version)

If you wanna give it a try, let me know if you can make it work.

Finally, out of despair, I have developed a very simple Logger class, with the same API as commons-logging, so code in the plugin is the same just importing that class.

Tomorrow I will be uploading a new version of JCatalogue including that class, and also my own first java plugin.

[moisescastellano]

2nsp: yeah, sorry not having read your post I basically repeated what you said, apart from stating the fact that the plugin is not logging. Maybe could you take a look to that issue?

[ghisler(Author)]

From what I understand, these vulnerabilities could affect servers running Java code, where user input is being accepted that could, when logged via those Log4J versions, generate JNDI Lookup causing remote code execution or denial of service.

Can't they also affect clients? On the example page, there are a html browser, an image viewer, and a video and audio player. They all use external input, so it depends on what the plugins are logging whether they could be attacked. Just like the servers which log certain request fields, the client may be logging certain server responses.

On your specific question, JRE does not use any log4J library installed in the system unless you specify that in the classpath, which here we are doing in the tc_javaplugin.ini properties.

I have searched the .class files, and they are referring to "org/apache/commons/logging/Log", which then calls log4J. The question is what the Log library in the current JRE calls.

[moisescastellano]

Can't they also affect clients? On the example page, there are a html browser

The thing is, there is no outsider users sending data to the plugin in your local machine, unless there were such a thing like a server plugin, than I cannot think of (as a potential use) for Total Commander.

The Browser java plugin and the html browser it displays, both are processes executed in the same local machine. The plugin could theoretically get the input of the user in the browser and log it, but in that case the Log4J vulnerability would just allow the user to hack himself.

I have searched the .class files, and they are referring to "org/apache/commons/logging/Log", which then calls log4J. The question is what the Log library in the current JRE calls.

Yes, because of the log4j.xml config file, commons-logging is going to use Log4J. The JRE does not include a Log4J library, it calls the commons-logging-*.jar and log4j*.jar inside the javalib (the one extracted from Hansel's javalib.tgz) directory. This javadir is used because the plugin sets the classpath according to the tc_javaplugin.ini properties, which points to it.

[nsp]

2nsp: yeah, sorry not having read your post I basically repeated what you said, apart from stating the fact that the plugin is not logging. Maybe could you take a look to that issue?

Logging is working as designed !
By default, it use zeroconf socket hub.. So you need an old version of chainsaw with zeroconf plugin to view it.
[IMO]The best is to use a file apender, this is a sample log4j.xml

Code: Select all

<log4j:configuration debug="false" threshold="debug"  xmlns:log4j="http://jakarta.apache.org/log4j/">
  <appender name="file"                                              
  class="org.apache.log4j.RollingFileAppender">                      
    <param name="append" value="false" />                            
    <param name="maxFileSize" value="10Mb" />                        
    <param name="maxBackupIndex" value="5" />                        
    <param name="immediateFlush" value="true" />                     
    <param name="file" value="./javalib.log" /> <!-- Change location as you want to any folder with write permision 
                                                     ./ folder will point to the plugin folder by default -->                         
    <layout class="org.apache.log4j.PatternLayout">                  
      <param name="ConversionPattern"                                
      value="%d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n" />        
    </layout>                                                        
  </appender>                                                        
    <!--ROOT Logger-->
    <root>
        <level value="error" />
        <appender-ref ref="file" />
    </root>
 <category name="tcplugins">
    <priority value="debug" />
  </category>   
</log4j:configuration>

latest version of log4j 1.xx is log4j 1.2 17 from 2012. It is broken for JRE/JDK above 9 so you will have to use log4j2 if you need java > 8 !

[moisescastellano]

Hi! I have now created my first own plugin: DiskDirCrc.
I have commented on it in this post

[moisescastellano]

2nsp:
Thanks. I used a new version of Chainsaw, it still had a zeroconf tab in the GUI, but it only logged the initial connection.
I tried log4j but maybe the problem is I was using Java 11, did not know it was broken as you said.
And I also updated to log4j2, but it did not work either, have you tried with it? Maybe muy log4j2 config file was wrong.
I will try again; in the meanwhile I just created a very basic Logger por the plugin

[nsp]

2nsp:
Thanks. I used a new version of Chainsaw, it still had a zeroconf tab in the GUI, but it only logged the initial connection.
I tried log4j but maybe the problem is I was using Java 11, did not know it was broken as you said.
And I also updated to log4j2, but it did not work either, have you tried with it? Maybe muy log4j2 config file was wrong.
I will try again; in the meanwhile I just created a very basic Logger por the plugin

To update to log4j2 with commons_logging can be a bit tricky, the best is to recompile all with alt least jdk 1.8 and replace commons_logging with slf4j and then use log4j2 or whatever.

By the way, to not have any message of missing JRE if jdk 1.6 is not installed, you must install javalib inside %commander_PATH% and define the path to jvm.dll in the tc_javaplugin.ini file (JVM_DLL property and corresponding JVM_PATH ).

@moisescastellano @ghisler
Do you have a visual studio project with all 64bit plugin interface wcx64, wdx64, wlx64 ... ? I'm interested to build a java decompiler lister based on cfr from the jad sample...

[moisescastellano]

Java plugin examples by Handel are now updated and available at the GitHub project.
(Note: I do not know yet how create a examples page like the one Handel created at totalcmd.net: http://java.totalcmd.net/V1.7/examples.html)

Changes:

2021-dec-18
-----------
- cleaning from extra libraries not specific for each plugin, most of them are now under 1 Mb
- further testing have been done, look at the 64-bit update comment in the table: https://github.com/moisescastellano/tcmd-java-plugin/blob/main/examples_64bit.md
- some of them need more rework, check the to do at https://github.com/moisescastellano/tcmd-java-plugin/blob/main/to-do.md

2021-dec-14
-----------
Now, every java plugin:
1. Works as an independent 64-bit plugin in TC64. Still works in TC32.
2. May be installed as usual, just entering the zip, without further ado.

Changes for 64-bit version (from 32-bit original java plugin by Ken Handel):
----------------------------------------------------------------------------
- included the new (wcx64 / wfx64 / wlx64 / wdx64) dll, recompiled by Ghisler (author of Total Commander), from Handel sources
- included the javalib dirs: Now every Java plugin installs just entering the zip, without further ado
- modified tc_javaplugin.ini accordingly (to refer the new location of javalib)
- included text file with some extra info for the 64-version
- repackaged as .zip (.tgz needed first to be un-tgz-ed to tar, also not so standard)

[moisescastellano]

@moisescastellano @ghisler
Do you have a visual studio project with all 64bit plugin interface wcx64, wdx64, wlx64 ... ? I'm interested to build a java decompiler lister based on cfr from the jad sample...

2nsp
The visual studio project is the one Handel created (http://java.totalcmd.net/V1.7/Projects.tgz), but read above in this thread the changes Ghisler made to recompile for 64bit. Also he sent me the project with the changes in configuration via mail, you can ask him or contact me (see the GitHub page in the previous post for contact).

However probably you dont need it: the dll for wlx64 is the same for all plugins (also for wcx64, wdx64, wfx64). You can take it from any of the examples updated to 64-bit I uploaded at https://github.com/moisescastellano/tcmd-java-plugin/blob/main/examples_64bit.md

Specifically the jad decompiler plugin by Handel works fine and is updated at: https://github.com/moisescastellano/tcmd-java-plugin/raw/main/examples/v2.1/JADDemo.zip