Closed qxyuan853 closed 4 months ago
Thanks for the feedback!
Thanks for the feedback. Excuse me, which country are you from?
There was a problem with the previous pr merge. rpc calls can no longer pass exceptions。
Thanks for the feedback. Excuse me, which country are you from?
Hi, I'm a student recently focused on Java deserialization vulnerability mining and exploitability research. We found that this kind of vulnerability patch is easy to incomplete (E.g. Issue#226), so I try to submit a patch to help fix it.
I found the prior patch for issue #226 only updated the Fury
, but it didn't quite beef up the deserialization security. It didn't tweak Fury's default blacklist or dial up the security levels. Therefore, I submitted the patches, though, shakes things up by slotting in custom blacklists for a niftier guard strategy.
All serialization schemes that declare metadata directly from data have this problem. And the problems are endless, the headaches
所有直接从数据声明元数据的序列化方案都有这个问题。问题无穷无尽,令人头疼
Yeah, it's a headache, and even different users and different deployment environments should require different levels of defense. So I suggest Solon can be configured with a more flexible, user-defined deserialization defense mechanism. For example, to further improve the blacklist, or to change the AllowListChecker.CheckLevel (to set different levels of stringency) according to business needs. If it's convenient, can we exchange emails to further discuss the default blacklist configuration?
And thanks for your efforts in reviewing my prs. I was very sorry to find out that there were some issues in prior ones. I've been more into bug hunting and suggesting blacklist tweaks until now, so this is my first stab at a PR fix. I do my best efforts to review this patch, but I might still miss some corner cases. I'd be grateful for the check you made before the official release.
That's good advice. Later I made the serialization blacklist a standard interface.
Summary
Solon has two serialization protocols
nami.coder.fury
andsolon.serialization.fury
. However, we found that these two protocols are not sufficiently secure, and multiple modules that introduce them are at risk of RCE (Remote Code Execution) attacks. An attacker could complete a remote code execution attack by sending carefully constructed serialized data.Vulnerable modules
The vulnerability affects functional modules related to the use of
nami.coder.fury
andsolon.serialization.fury
. Some simple attack replications are illustrated below.PoC
Example #1 (
demo7001-simple_protostuff
).import org.noear.solon.Solon; import org.noear.solon.annotation.Mapping; import org.noear.solon.annotation.Remoting; import demo7001.protocol.UserModel; import demo7001.protocol.UserService;
@Mapping("/user/") @Remoting public class RpcService implements UserService { public static void main(String[] args) { Solon.start(RpcService.class, args); }
}
package demo7001.protocol;
public interface UserService { UserModel getUser(Integer userId, Object user); }
package demo7001.protocol;
import lombok.Data;
@Data public class UserModel { private long id; private String name; private int sex; private String label; }
The attacker could use
ysoserial
(https://github.com/frohoff/ysoserial) to set up a malicious LDAP server. In this example, we use the well-known exploit chain CommonsCollections4 fromysoserial
to accomplish the subsequent attack. Of course, many other chains exist to choose from.(b) POC
POC.java
Attack Results
Impact
This attack can cause remote arbitrary code execution.
Example#2 (
demo3041-gateway
)@Component public class UserServiceImpl implements UserService { @Inject UserDao userDao;
}
public interface UserService { UserModel getUser(String name); }
Attack Results
Impact
This attack can cause remote arbitrary code execution.
Vulnerable Code in
nami.coder.fury
A vulnerability similar to the one described above exists when calling FuryDecoder to deserialize data, which can lead to an RCE attack.