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

Invocation should not invoke arbitrary method #3115

Closed
springkill opened this issue Mar 20, 2024 · 7 comments · Fixed by #3117
Closed

Invocation should not invoke arbitrary method #3115

springkill opened this issue Mar 20, 2024 · 7 comments · Fixed by #3117
Assignees
Labels
Milestone

Comments

@springkill
Copy link

springkill commented Mar 20, 2024

If an application developer passes non-sanitized string to OGNL or similar technologies (which you should never do), an attacker can use org.apache.ibatis.plugin.Invocation in the app's classpath to execute arbitrary code (RCE).

@harawata

This comment was marked as outdated.

@springkill
Copy link
Author

I would like to know if I want to report this vulnerability, which email address should I provide the information to? @harawata

@harawata
Copy link
Member

@springkill ,

Before I let you know my email address, let me check a few things.

For JDK's deserialization vulnerability, you should use JEP-290 filter. See #2079 .

I have received a report about RCE when using SQL provider.
But the reporter used a user input string directly in the SQL returned from a provider, so it was not a MyBatis vulnerability.
Is this not the case you are reporting?

@springkill
Copy link
Author

@harawata ,
The issue I found is not a deserialisation vulnerability, it works on JDK8u402 and applies to the latest version of mybatis3.

@harawata
Copy link
Member

Okay, send it to my Gmail. The account name is the same as GitHub's.

@harawata harawata changed the title A vulnerability that causes RCE Invocation should not invoke arbitrary method Mar 21, 2024
@harawata harawata reopened this Mar 21, 2024
harawata added a commit to harawata/mybatis-3 that referenced this issue Mar 21, 2024
@harawata harawata self-assigned this Mar 21, 2024
@harawata harawata added this to the 3.5.16 milestone Mar 21, 2024
@wuwen5
Copy link
Contributor

wuwen5 commented Aug 13, 2024

@harawata Because I have extended the interception support for ResultSet, it has currently failed. Can we add ResultSet type support or support whitelist type configuration ?

@Intercepts({@Signature(type = ResultSet.class, method = "next", args = {}),
        @Signature(type = ResultSet.class, method = "close", args = {})})
@Slf4j
public class MoreRowCheckInterceptor implements Interceptor {
}

public class StatementProxy implements InvocationHandler {
  ...
   public Object invoke(Object proxy, Method method, Object[] params) throws Throwable {
        try {
            if (EXECUTE_QUERY.equals(method.getName()) || GET_RESULT_SET.equals(method.getName())) {
                final ResultSet rs = (ResultSet) method.invoke(statement, params);
                return rs == null ? null : interceptorChain.pluginAll(rs);
            } else {
                return method.invoke(statement, params);
            }
        } catch (Throwable t) {
            throw ExceptionUtil.unwrapThrowable(t);
        }
    }
  ....
}

@harawata
Copy link
Member

@wuwen5 ,

MyBatis' interceptor does not (and will not) intercepts JDBC API methods.
If you have to intercept them, you need to use another technique.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants