Package: falconpl Severity: serious Tags: security Hi,
I recently discovered that falconpl is using the libcurl API in a way that may
not be what the original author intended. In particular I'm referring to the
fact that the CURLOPT_SSL_VERIFYHOST option is treated as it was a boolean value
while in fact it isn't (it may take three different values):
case CURLOPT_SSL_VERIFYHOST:
case CURLOPT_SSL_SESSIONID_CACHE:
{
long bVal = i_data->isTrue() ? 1 : 0;
ret = curl_easy_setopt( curl, iOpt, bVal );
}
break;
(from the file modules/native/curl/src/curl_ext.cpp)
Setting the value to "0" disables the host checks, but setting it to "1" does
not enable them (well, not all of them) and this may lead to security issues.
The correct value to enable all the security checks is "2".
From the libcurl documentation:
> When CURLOPT_SSL_VERIFYHOST is 2, that certificate must indicate that the
> server is the server to which you meant to connect, or the connection fails.
>
> Curl considers the server the intended one when the Common Name field or a
> Subject Alternate Name field in the certificate matches the host name in the
> URL to which you told Curl to connect.
>
> When the value is 1, the certificate must contain a Common Name field, but it
> doesn't matter what name it says. (This is not ordinarily a useful setting).
>
> When the value is 0, the connection succeeds regardless of the names in the
> certificate.
After discussing this with the security team, it was decided that it would be
best if this was fixed before the Wheezy release.
Note that this should be fixed anyway, since as of curl v7.28.1 (which has been
uploaded to experimental) the value "1" is not a valid value anymore and libcurl
will return an error.
A possible fix should be discussed with the falconpl upstream first.
Cheers
--
perl -E '$_=q;$/= @{[@_]};and s;\S+;<inidehG ordnasselA>;eg;say~~reverse'
signature.asc
Description: Digital signature
