4 ms·

> These lookups are: - "script" - execute expressions using the JVM script execution engine (javax.script) - "dns" - resolve dns records - "url" - load values f

> These lookups are: - "script" - execute expressions using the JVM script execution engine (javax.script) - "dns" - resolve dns records - "url" - load values from urls, including from remote servers Applications using the interpolation defaults in the affected versions may be vulnerable to remote code execution or unintentional contact with remote servers if untrusted configuration values are used So, if you let untrusted users somehow set configuration, then you're vulnerable. Never a bad idea to remove an attack surface, but damn, you'd have to plan 3 - 4 sprints ahead to mess up bad enough to let third parties set config files. (And besides, as log4j2 showed us, if you want to allow that, LDAP is how the cool kids do it.)

usrusr 4y ago
I see no reason to assume that configuration would be the only (or dominant) source of unchecked interpolation inputs. Might be a common use case, but certainly not exclusive. The big issue is that many projects, perhaps deep in the transitive dependency stack, use the library, likely just for some trivial missing convenience methods on the standard lib String (and in the StringUtils of commons-lang/lang3), and once it's on the classpath it will get used by every intern who ever committed something to the code. Most dependors will likely not use interpolation at all so the impact is much lower than in the log4j incident, but a lot of things will need to be checked and/or updated. Commons text is much less ubiquitous than commons lang, but that might just put it in the perfect position for a sneaky transitive presence. According to the sentence before the of about untrusted configurations, "untrusted" configuration includes the default: unless your configuration is explicitly hardened, any call to the string interpolator with unsanitized content is an open door. (the open question is wether calls to the string interpolator exist)
- EdwardDiego 4y ago
  > I see no reason to assume that configuration would be the only (or dominant) source of unchecked interpolation inputs. Given as it was the maintainers who lodged the CVE, and their description that I was quoting, I'm reasonably happy it's a correct statement. I'll be honest, I haven't dived into the code to verify that myself. But if you have, please feel free to share your findings :)

usrusr 4y ago

I see no reason to assume that configuration would be the only (or dominant) source of unchecked interpolation inputs. Might be a common use case, but certainly not exclusive. The big issue is that many projects, perhaps deep in the transitive dependency stack, use the library, likely just for some trivial missing convenience methods on the standard lib String (and in the StringUtils of commons-lang/lang3), and once it's on the classpath it will get used by every intern who ever committed something to the code. Most dependors will likely not use interpolation at all so the impact is much lower than in the log4j incident, but a lot of things will need to be checked and/or updated. Commons text is much less ubiquitous than commons lang, but that might just put it in the perfect position for a sneaky transitive presence. According to the sentence before the of about untrusted configurations, "untrusted" configuration includes the default: unless your configuration is explicitly hardened, any call to the string interpolator with unsanitized content is an open door. (the open question is wether calls to the string interpolator exist)

EdwardDiego 4y ago
> I see no reason to assume that configuration would be the only (or dominant) source of unchecked interpolation inputs. Given as it was the maintainers who lodged the CVE, and their description that I was quoting, I'm reasonably happy it's a correct statement. I'll be honest, I haven't dived into the code to verify that myself. But if you have, please feel free to share your findings :)