[SECURITY] Possible Code Injection Issue

[jmrcsnchz]

[deleted for security purposes]

[TinCanTech]

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.

[jmrcsnchz]

Hi @TinCanTech, deleted the issue details to avoid risk in exposure. Can we discuss this issue privately via email? Thanks!

[TinCanTech]

Absolutely, please send details to security@openvpn.net

[jmrcsnchz]

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

[dsommers]

I'll provide @TinCanTech the details from that mail.

[TinCanTech]

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