Armeria is an open source microservice framework. In affected versions an attacker can access an Armeria server's local file system beyond its restricted directory by sending an HTTP request whose path contains %2F (encoded /), such as /files/..%2Fsecrets.txt, bypassing Armeria's path validation logic. Armeria 1.13.4 or above contains the hardened path validation logic that handles %2F properly. This vulnerability can be worked around by inserting a decorator that performs an additional validation on the request path.
Impact Spring supports Matrix variables. When Spring integration is used, Armeria calls Spring controllers via TomcatService or JettyService with the path that may contain matrix variables. In this situation, the Armeria decorators might not invoked because of the matrix variables. Let's see the following example: // Spring controller @GetMapping("/important/resources") public String important() {...}
// Armeria decorator ServerBuilder sb = ... sb.decoratorUnder("/important/", authService); If an attacker sends a request with /important;a=b/resources, the request would bypass the authrorizer
Patches - https://github.com/line/armeria-ghsa-wvp2-9ppw-337j/commit/9b0ec3e099cc05fbff11d7f1012a1dddb0000d0c
Workarounds Users can add decorators using regex. e.g. "regex:^/important."
Multiple timing attack vulnerabilities leading to the recovery of secrets based on the use of non-constant time compare function
Impact
String comparison method in multiple authentication validation in Armeria were known to be vulnerable to timing attacks. This vulnerability is caused by the insecure implementation of equals method from java.lang.String. While this attack is not practically possible, an attacker still has a potential to attack if the victim's server validates user by using equals method.
We would like to thank @chrsow for pointing out the issue.
Potentially vulnerable codes
https://github.com/line/armeria/blob/f0d870fde1088114070be31b67f7df0a21e835c6/core/src/main/java/com/linecorp/armeria/server/auth/OAuth2Token.java#L54 https://github.com/line/armeria/blob/f0d870fde1088114070be31b67f7df0a21e835c6/core/src/main/java/com/linecorp/armeria/server/auth/BasicToken.java#L64
Patches
There are two options to patch this issue.
1. Remove equals method; it has been exclusively used for test cases and was never used in any OSS projects that are using Armeria. (But it is worth noting that there are possibilities of closed projects authenticating users by utilizing equals method)
2. Use MessageDigest.isEqual to compare the credential instead.
Workarounds
1. Update to the latest version (TBD)
2-1. Users can prevent these vulnerabilities by modifying and implementing timing attack preventions by themselves.
2-2. Precisely speaking, it is possible to compare credentials by securely comparing them after calling methods to directly return the input (namely Object. accessToken(), Object.username() and Object.password()).
References - https://cwe.mitre.org/data/definitions/208.html - https://security.stackexchange.com/questions/111040/should-i-worry-about-remote-timing-attacks-on-string-comparison
Side Note
Since it is a theoretical attack, there is no PoC available from neither the vendor nor the security team.