CVE-2019-16771

Versions of Armeria 0.85.0 through and including 0.96.0 are vulnerable to HTTP response splitting, which allows remote attackers to inject arbitrary HTTP headers via CRLF sequences when unsanitized data is used to populate the headers of an HTTP response. This vulnerability has been patched in 0.97.0. Potential impacts of this vulnerability include cross-user defacement, cache poisoning, Cross-site scripting (XSS), and page hijacking.

Versions of Armeria 0.85.0 through and including 0.96.0 are vulnerable to HTTP response splitting, which allows remote attackers to inject arbitrary HTTP headers via CRLF sequences when unsanitized data is used to populate the headers of an HTTP response. This vulnerability has been patched in 0.97.0. Potential impacts of this vulnerability include cross-user defacement, cache poisoning, Cross-site scripting (XSS), and page hijacking.

## 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.

## 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.

Las versiones 0.85.0 hasta la 0.96.0 incluyéndola de Armeria, son vulnerables a una división de la respuesta HTTP, lo que permite a atacantes remotos inyectar encabezados HTTP arbitrarios por medio de secuencias CRLF cuando datos no saneados son usados para llenar los encabezados de una respuesta HTTP. Esta vulnerabilidad ha sido parcheada en la versión 0.97.0. Impactos potenciales de esta vulnerabilidad incluyen la desfiguración de usuarios cruzados, el envenenamiento de la caché, un ataque de tipo Cross-site scripting (XSS) y el secuestro de páginas.