Bug#696681: falconpl: possible security issue due to misuse of the libcurl API
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
Bug#696681: falconpl: possible security issue due to misuse of the libcurl API
On Tue, Dec 25, 2012 at 11:11 PM, Alessandro Ghedini gh...@debian.org wrote:
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.
Sorry! I went to unexpected vacation in the middle of this.
A possible fix should be discussed with the falconpl upstream first.
This is done already:
https://groups.google.com/forum/?fromgroups=#!msg/falconpl/Vnnv0yb-_Bg/Vkl5RFHEk8QJ
(and related discussions on IRC at #falconpl, Freenode)
Should fix go via unstable-testing or testing proposed upload is need
to do in this case? I'm preparing packages right now.
--
Kartik Mistry | IRC: kart_
{0x1f1f, kartikm}.wordpress.com
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696681: falconpl: possible security issue due to misuse of the libcurl API
On Wed, Dec 26, 2012 at 11:16 AM, Kartik Mistry kartik.mis...@gmail.com wrote:
This is done already:
https://groups.google.com/forum/?fromgroups=#!msg/falconpl/Vnnv0yb-_Bg/Vkl5RFHEk8QJ
(and related discussions on IRC at #falconpl, Freenode)
Just a note patch is already merged into upstream [1]
[1]
http://git.falconpl.org/cgit.cgi/falcon/commit/?id=93d94a88a8bb073e609327ceca704b313e1309ff
--
Vasudev Kamath
http://copyninja.info
copyninja@{frndk.de|vasudev.homelinux.net}
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
