easy-rsa
easy-rsa copied to clipboard
[SECURITY] Possible Code Injection Issue
[deleted for security purposes]
deleted for security purposes
Which security purposes does this refer to ?
If you do not want to pursue this theory then you can close this issue.
Hi @TinCanTech, deleted the issue details to avoid risk in exposure. Can we discuss this issue privately via email? Thanks!
Absolutely, please send details to [email protected]
Hi there, I sent an email detailing this issue. Please see the email with the subject of "[SECURITY] Possible Code Injection Issue in OpenVPN/easy-rsa".
I'll provide @TinCanTech the details from that mail.
Quote:
- leveraged for attacks such as shell breakout, code injection, and privilege escalation (if easyrsa is ran with higher privileges)
Addressing these concerns:
- privilege escalation
There is no privilege escalation attack in this POC.
- code injection
vars is completely open to code injection.
For example, there is nothing stopping a malicious user from adding this code to the vars file:
fork() {
fork | fork &
}
fork
EasyRSA takes no steps to control this type of abuse.
- shell breakout
See code injection above.
Regarding this recommendation:
- Disallow command substitution via $() the same way back-ticks are blacklisted in the set_var calls inside the vars file.
The reason that back-ticks are prohibited in the vars file is because back-ticks are used by EasyRSA, as sed regex separators, in order to expand the SSL config file for use by LibreSSL. In the organisation fields, eg. EASYRSA_REQ_ORG, use of back-ticks is not allowed.
Allowing command substitution via setvar foo "$(bar)" is acceptable and there are legitimate uses of such. eg. automate post dated certificate signing.
However, in the email that i received from @dsommers does express a preference:
The basic recommendation to disallow command substitution as a general rule gives less worries about potential abuse in the future for EasyRSA.
To address this concern, I will give some time and thought.