ppkarwasz commented on PR #540: URL: https://github.com/apache/commons-configuration/pull/540#issuecomment-2646164846
> > What I understand here is that even if you allow external users to supply configuration files and you process them through Commons Configuration, no DoS or code execution will be triggered. > > Yes, that was my assumption - I could of course very well be wrong about that, I'm by no means a Commons Configuration expert. I am not an expert either. My remarks are mostly based on the difficulty to parse untrusted configuration files in a secure way. Parsing simple key/value configuration files should be safe, but features like [customizable entity resolver](https://commons.apache.org/proper/commons-configuration/userguide/howto_xml.html#Default_Entity_Resolution), [expression engines](https://commons.apache.org/proper/commons-configuration/userguide/howto_hierarchical.html#Expression_engines) or [declaring and creating beans](https://commons.apache.org/proper/commons-configuration/userguide/howto_beans.html#Declaring_and_Creating_Beans) are _à priori_ dangerous. > > This is IMHO impossible to guarantee and we will have to publish CVEs like the recent one in Logback: [CVE-2024-12798](https://www.cve.org/CVERecord?id=CVE-2024-12798). > > AFAICT we _do_ publish CVEs like that for Commons Configuration (e.g. https://www.cve.org/CVERecord?id=CVE-2022-33980 ). Are you aware of any places where Commons Configuration allows triggering code execution or DoS 'by design'? I think I am understanding better the problem now. We want to guarantee that "by default" Commons Configuration is safe for parsing untrusted data, but if users enable some features like the `script` lookup or use `BeanHelper`, they need to restrict themselves to **trusted** data and duly document this fact. Maybe we should list the sensitive features in the security models, so we don't receive reports like "if an attacker has access to the configuration file and `BeanHelper` is used, he can instantiate **any** Java class (including `MLet` and similar). > FWIW: I don't have a strong opinion on whether we 'should' consider configuration trusted or allow untrusted input - we should just clearly document the expectations ;) . I don't have a strong opinion either. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
