Mike Drob created SOLR-16045:
--------------------------------
Summary: [SOLR 8] PKIAuthenticationPlugin uses encryption instead
of signatures
Key: SOLR-16045
URL: https://issues.apache.org/jira/browse/SOLR-16045
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Components: Authentication
Reporter: Mike Drob
Assignee: Mike Drob
Fix For: 9.0, 8.11.2
Our PKIAuthenticationPlugin uses a very weak cipher when sending SolrAuth
header information. There are several factors involved here:
* The Java cipher suite represented by {{RSA/ECB/NoPadding}} is completely
deterministic.
* The only way to rotate a server's public key is via restart because we have
no way to reload the PublicKeyHandler.
An older example of why ECB is a poor choice for data integrity is [the ECB
Penguin|https://words.filippo.io/the-ecb-penguin/]
A mitigation to the associated risk here is that all transport should already
be occurring over a secure channel (i.e. HTTPS), so the risk of a
man-in-the-middle attack is low. However, there are other concerns.
RSA/ECB/NoPadding does not include a MAC, so is susceptible to false parsing.
If the encryption key has rotated then we are susceptible to issues like
SOLR-15961
Further, in cases where the parsing fails, we can end up [logging the plaintext
and cipher text of the authentication
header|https://github.com/apache/solr/blob/main/solr/core/src/java/org/apache/solr/security/PKIAuthenticationPlugin.java#L191].
Even without the plaintext, and having only the cipher text, it would not be
too challenging for an attacker to extract a key given that they know the
format of the header to be {{SolrAuth <nodeName> base64(enc(<user>
<timestamp>))}} and user is often the literal {{$}} string and timestamp is a
recent long in millis.
There are other, better, more modern cipher algorithms that can be used, and I
am still researching which ones would work for us, what key initialization
would look like, etc. Additionally, changing this on upgrade would not permit a
rolling restart. At a minimum, we would need a "bridge" 8.11.2 release so that
users can upgrade from 8.x -> 8.11.2 -> 9.0. In this scenario, we would need
the following behavior:
|| ||encryption||decryption||
|8.x|RSA/ECB/NoPadding|RSA/ECB/NoPadding|
|8.11.2|RSA/ECB/NoPadding|RSA/ECB/NoPadding
*OR* New Alg|
|9.x|New Alg|New Alg|
Alternative options are to discard rolling restart capability going from 8->9,
ask users to disable PKI Authentication for their clusters, or require users to
bridge via 9.0 before upgrading to further 9.x releases. None of those
alternatives sound palatable to me, but the community may disagree.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
