Hi HAProxy security team,
This is a hardening / documentation-clarity report, not a claim of active
exploitation against a default configuration. Flagging for your threat-model
review.
Finding
HAProxy registers four AES sample converters in src/ssl_sample.c (around
lines 2846-2851):
{ "aes_gcm_enc", sample_conv_aes, ... }, /* authenticated (GCM) */
{ "aes_gcm_dec", sample_conv_aes, ... }, /* authenticated (GCM) */
{ "aes_cbc_enc", sample_conv_aes, ... }, /* unauthenticated CBC */
{ "aes_cbc_dec", sample_conv_aes, ... }, /* unauthenticated CBC */
The GCM variants include an AEAD tag; the CBC variants do not. aes
*process()in src/ssl_sample.c:325 dispatches to EVP_aes**_cbc() when the
gcm flag is
clear, and the caller does not perform any MAC verification over the
ciphertext.
If an administrator chains aes_cbc_dec with an attacker-controlled
ciphertext
source -- for example:
http-request set-var(txn.session) \
req.cook(session),aes_cbc_dec(base64("..."),base64("..."))
then request-level failure signals (deny/allow/variable-empty) form a
padding-oracle distinguisher over PKCS#7 padding validity in the decrypted
plaintext (the Vaudenay attack family, CWE-310). Well-understood plaintext-
recovery techniques apply; a remote attacker sending ~128 requests per
plaintext byte can recover a cookie encrypted with that key.
Why this report
The two converter families (GCM, CBC) appear side-by-side in the sample
converter table. An administrator who reaches for one may reasonably assume
the other behaves equivalently. The current doc/configuration.txt entries
for
aes*cbc** do not warn that they are unauthenticated primitives unsafe for
attacker-controlled ciphertext, and do not cross-reference the authenticated
alternative.
This is primarily a secure-default / documentation concern. We are not
claiming HAProxy itself is vulnerable in a default configuration. We are
asking:
1.
Does the team consider aes_cbc_dec chained to request-phase input to be
admin-misconfiguration (outside the threat model) or a primitive that
HAProxy should not be exposing without a louder warning?
2.
If the latter, we would like to propose a three-step hardening:
(a) Documentation update for aes
*cbc_enc / aes_cbc_dec in doc/configuration.txt explicitly noting: (i)
unauthenticated, (ii) vulnerable to padding-oracle attacks with
attacker-controlled ciphertext, (iii) prefer aes_gcm** for any untrusted
input.
(b) Optional: emit a config-parse warning when aes*cbc** appears in a
converter chain sourced from request-phase samples (req.cook, req.hdr,
req.body, etc.). Similar to the way HAProxy already warns on certain
deprecated constructs.
(c) Longer-term: consider deprecating aes*cbc** in favour of the
authenticated GCM variants, with a removal timeline in a future major
release. RFC 7518 Section 5 (JSON Web Encryption) and RFC 8452 both
recommend authenticated encryption by default.
What I looked at
- src/ssl_sample.c:325-420 aes_process() — CBC branch, no MAC generation
or verification.
- src/ssl_sample.c:2846-2851 converter registrations.
- doc/configuration.txt entries for aes_gcm_enc, aes_gcm_dec,
aes_cbc_enc,
aes_cbc_dec — confirmed no warning on the CBC variants.
No external disclosure is planned before hearing the team's position. Happy
to draft a doc patch for option (a) if that is the direction the team
prefers, or to file a public issue/PR if the team considers this out of
security-list scope.
Regards,
Andrey Vasilevsky (aka anvanster)
[email protected]
Cell: (971) 232-0502
http://www.linkedin.com/in/andreyvasilevsky
