[strongSwan] User openssl's PUBKEY_VERIFY instead of gmp's for CVE-2017-11185

[karthik kumar]

Thanks for your answer. I have a one further question,

I increased the priority of gmp plugin,
*/etc/strongswan/strongswan.d/charon/gmp.conf: load = 2 *

*/etc/strongswan/strongswan.d/charon/openssl.conf: load = yes*

and it results in gmp plugin loading first and then openssl, sample log line


*Aug 20 03:48:20 00[LIB] loading feature
PUBKEY_VERIFY:RSA_EMSA_PKCS1_SHA256 in plugin 'gmp' *

*Aug 20 03:48:20 00[LIB] loading feature
PUBKEY_VERIFY:RSA_EMSA_PKCS1_SHA256 in plugin 'openssl'*

Does this mean *PUBKEY_VERIFICATION *will be done by openssl or gmp plugin
? I am confused because,
* I have increased the priory of gmp plugin, but openssl is loaded at the
last. I am thinking whichever is loaded last will override ?
* when both plugins have priority = 1 (load = yes) openssl is loaded first
and then gmp.


Thanks


On Sun, Aug 20, 2017 at 8:22 PM, karthik kumar <kumarkarthikn at gmail.com>
wrote:

>
> On Sun, 20 Aug 2017 at 8:06 PM, Noel Kuntze <noel.kuntze+strongswan-users-
> ml at thermi.consulting> wrote:
>
>>
>>
>> On 20.08.2017 09:49, karthik kumar wrote:
>> > Hi,
>> >    We are trying to mitigate CVE-2017-11185. We use older than 5.6.0
>> version of strongswan and upgrading will take significant time/effort.
>> >
>> Why don't you patch?
>>
>> > The vulnerability is while gmp plugin doing signature verification, and
>> I found that the same feature is provided by openssl (and gcrypt) so our
>> plan is to use openssl plugin,
>> > /
>> > /
>> > /OPENSSL is enabled /
>> > /Aug 19 19:14:41 00[LIB] loading feature PUBKEY_VERIFY:RSA_EMSA_PKCS1_NULL
>> in plugin 'openssl'/
>> > /Aug 19 19:14:41 00[LIB] loading feature PUBKEY_VERIFY:RSA_EMSA_PKCS1_SHA1
>> in plugin 'openssl'/
>> > /Aug 19 19:14:41 00[LIB] loading feature PUBKEY_VERIFY:RSA_EMSA_PKCS1_SHA224
>> in plugin 'openssl'/
>> > /Aug 19 19:14:41 00[LIB] loading feature PUBKEY_VERIFY:RSA_EMSA_PKCS1_SHA256
>> in plugin 'openssl'/
>> > /Aug 19 19:14:41 00[LIB] loading feature PUBKEY_VERIFY:RSA_EMSA_PKCS1_SHA384
>> in plugin 'openssl'/
>> > /.... <and so on>/
>> > /
>> > /
>> > /GMP/
>> > Aug 19 19:14:41 00[LIB] loading feature PUBKEY_VERIFY:RSA_EMSA_PKCS1_NULL
>> in plugin 'gmp'
>> > Aug 19 19:14:41 00[LIB] loading feature PUBKEY_VERIFY:RSA_EMSA_PKCS1_SHA1
>> in plugin 'gmp'
>> > Aug 19 19:14:41 00[LIB] loading feature PUBKEY_VERIFY:RSA_EMSA_PKCS1_SHA224
>> in plugin 'gmp'
>> > Aug 19 19:14:41 00[LIB] loading feature PUBKEY_VERIFY:RSA_EMSA_PKCS1_SHA256
>> in plugin 'gmp'
>> > Aug 19 19:14:41 00[LIB] loading feature PUBKEY_VERIFY:RSA_EMSA_PKCS1_SHA384
>> in plugin 'gmp'
>> > ... <and so on>
>> >
>> > I have a couple of questions,
>> > a. how do I determine if its safe to disable (load = no) the gmp plugin
>> ? I compared all features of GMP listed in the log against openssl plugin
>> features, and all of them are available in Openssl plugin. Is that enough
>> or anything else I should consider checking before turning off gmp plugin ?
>> (i have tested disabling gmp in my local and esp packets are created and
>> sent properly)
>> >
>> Your testing is faulty. strongSwan does not send ESP packets or does any
>> traffic processing. It only sets up SAs and SPs. You need to check if the
>> key exchange works.
>>
>> > b. I tried to increase the priority of openssl (load = 2) plugin. But I
>> can't find a way to verify that signature verification is done by openssl
>> plugin and not gmp plugin. Is there a way I can verify that ? (or rather
>> how do I verify which plugin is executing certain feature when the same
>> feature is provided by two loaded plugins)
>> >
>> AFAIK There is no way to check that as of now. The logs mention the order
>> of the plugins when they are loaded, if the logger configuration is
>> correct. You can use the logs to figure out what plugin provides the
>> functionality (it's the one that is loaded first).
>>
>> > Thanks
>> >
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20170821/71f9889a/attachment.html>