[PATCH 0/1] curl: Fix CVE-2016-3739.

[PATCH 0/1] curl: Fix CVE-2016-3739.

[Leo Famulari]

If your SSL / TLS provider is mbedTLS (formerly PolarSSL), there is a
bug in curl [CVE-2016-3739] that allows an attacker to bypass the full
certificate check by presenting any valid certificate.

So, you might think are connecting to https://example.com, when in fact
the attacker has a certificate for any other domain.

We don't package mbedTLS, but I still think we should provide the fixed
source code.

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-3739
https://curl.haxx.se/docs/adv_20160518.html

Leo Famulari (1):
  gnu: curl: Replace with 7.49.1 [fixes CVE-2016-3739].

 gnu/packages/curl.scm | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

-- 
2.8.4

[PATCH 1/1] gnu: curl: Replace with 7.49.1 [fixes CVE-2016-3739].

[Leo Famulari]

* gnu/packages/curl.scm (curl)[replacement]: New field.
(curl/fixed): New variable.
---
 gnu/packages/curl.scm | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/gnu/packages/curl.scm b/gnu/packages/curl.scm
index 222910b..925602e 100644
--- a/gnu/packages/curl.scm
+++ b/gnu/packages/curl.scm
@@ -40,6 +40,7 @@
 (define-public curl
   (package
    (name "curl")
+   (replacement curl/fixed)
    (version "7.47.0")
    (source (origin
             (method url-fetch)
@@ -123,3 +124,17 @@ tunneling, and so on.")
    (license (license:non-copyleft "file://COPYING"
                                   "See COPYING in the distribution."))
    (home-page "http://curl.haxx.se/")))
+
+(define curl/fixed
+  (package
+    (inherit curl)
+    (source
+     (let ((name "curl")
+           (version "7.49.1"))
+       (origin
+         (method url-fetch)
+           (uri (string-append "https://curl.haxx.se/download/curl-"
+                               version ".tar.lzma"))
+           (sha256
+            (base32
+             "033w3wyawali0rc5s15ywxpjnf476671m595r49sr4vj07idf3al")))))))
-- 
2.8.4

Re: [PATCH 0/1] curl: Fix CVE-2016-3739.

[Ludovic Courtès]

Leo Famulari <leo@famulari.name> skribis:

> If your SSL / TLS provider is mbedTLS (formerly PolarSSL), there is a
> bug in curl [CVE-2016-3739] that allows an attacker to bypass the full
> certificate check by presenting any valid certificate.
>
> So, you might think are connecting to https://example.com, when in fact
> the attacker has a certificate for any other domain.
>
> We don't package mbedTLS, but I still think we should provide the fixed
> source code.

OTOH this will incur additional grafting for no reason, WDYT?

Thanks,
Ludo’.

Re: [PATCH 0/1] curl: Fix CVE-2016-3739.

[ng0]

[-- Attachment #1: Type: text/plain, Size: 925 bytes --]

On 2016-06-12(10:51:14+0200), Ludovic Courtès wrote:
> Leo Famulari <leo@famulari.name> skribis:
>
> > If your SSL / TLS provider is mbedTLS (formerly PolarSSL), there is a
> > bug in curl [CVE-2016-3739] that allows an attacker to bypass the full
> > certificate check by presenting any valid certificate.
> >
> > So, you might think are connecting to https://example.com, when in fact
> > the attacker has a certificate for any other domain.
> >
> > We don't package mbedTLS, but I still think we should provide the fixed
> > source code.
>
> OTOH this will incur additional grafting for no reason, WDYT?
>
> Thanks,
> Ludo’.
>

fyi,

mbedtls is on my list of packages to do, as the webserver hiawatha
depends on it.

Should I announce once it is packaged and the cve fix can be applied
afterwards?

--
♥Ⓐ ng0
For non-prism friendly talk find me on
psyced.org / loupsycedyglgamf.onion

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [PATCH 0/1] curl: Fix CVE-2016-3739.

[Leo Famulari]

On Sun, Jun 12, 2016 at 09:02:32PM +0000, ng0 wrote:
> On 2016-06-12(10:51:14+0200), Ludovic Courtès wrote:
> > Leo Famulari <leo@famulari.name> skribis:
> >
> > > If your SSL / TLS provider is mbedTLS (formerly PolarSSL), there is a
> > > bug in curl [CVE-2016-3739] that allows an attacker to bypass the full
> > > certificate check by presenting any valid certificate.
> > >
> > > So, you might think are connecting to https://example.com, when in fact
> > > the attacker has a certificate for any other domain.
> > >
> > > We don't package mbedTLS, but I still think we should provide the fixed
> > > source code.
> >
> > OTOH this will incur additional grafting for no reason, WDYT?

No reason for things built within our distribution, true.

> fyi,
> 
> mbedtls is on my list of packages to do, as the webserver hiawatha
> depends on it.
> 
> Should I announce once it is packaged and the cve fix can be applied
> afterwards?

We should definitely update curl on core-updates-next, or whatever is
built after the current cycle, and we should not add hiawatha until the
fixed curl is in our tree.

Re: [PATCH 0/1] curl: Fix CVE-2016-3739.

[Ludovic Courtès]

Leo Famulari <leo@famulari.name> skribis:

> On Sun, Jun 12, 2016 at 09:02:32PM +0000, ng0 wrote:
>> On 2016-06-12(10:51:14+0200), Ludovic Courtès wrote:
>> > Leo Famulari <leo@famulari.name> skribis:
>> >
>> > > If your SSL / TLS provider is mbedTLS (formerly PolarSSL), there is a
>> > > bug in curl [CVE-2016-3739] that allows an attacker to bypass the full
>> > > certificate check by presenting any valid certificate.
>> > >
>> > > So, you might think are connecting to https://example.com, when in fact
>> > > the attacker has a certificate for any other domain.
>> > >
>> > > We don't package mbedTLS, but I still think we should provide the fixed
>> > > source code.
>> >
>> > OTOH this will incur additional grafting for no reason, WDYT?
>
> No reason for things built within our distribution, true.

Right.

>> fyi,
>> 
>> mbedtls is on my list of packages to do, as the webserver hiawatha
>> depends on it.
>> 
>> Should I announce once it is packaged and the cve fix can be applied
>> afterwards?
>
> We should definitely update curl on core-updates-next, or whatever is
> built after the current cycle, and we should not add hiawatha until the
> fixed curl is in our tree.

Agreed on both points.  Can you already push the curl update in
core-updates-next?

Though I would like the default curl package to still used GnuTLS.  So I
think curl-with-mbedtls will be a different package anyway.

Thanks,
Ludo’.

Re: [PATCH 0/1] curl: Fix CVE-2016-3739.

[ng0]

[-- Attachment #1: Type: text/plain, Size: 2087 bytes --]

On 2016-06-13(05:07:23+0200), Ludovic Courtès wrote:
> Leo Famulari <leo@famulari.name> skribis:
>
> > On Sun, Jun 12, 2016 at 09:02:32PM +0000, ng0 wrote:
> >> On 2016-06-12(10:51:14+0200), Ludovic Courtès wrote:
> >> > Leo Famulari <leo@famulari.name> skribis:
> >> >
> >> > > If your SSL / TLS provider is mbedTLS (formerly PolarSSL), there is a
> >> > > bug in curl [CVE-2016-3739] that allows an attacker to bypass the full
> >> > > certificate check by presenting any valid certificate.
> >> > >
> >> > > So, you might think are connecting to https://example.com, when in fact
> >> > > the attacker has a certificate for any other domain.
> >> > >
> >> > > We don't package mbedTLS, but I still think we should provide the fixed
> >> > > source code.
> >> >
> >> > OTOH this will incur additional grafting for no reason, WDYT?
> >
> > No reason for things built within our distribution, true.
>
> Right.
>
> >> fyi,
> >>
> >> mbedtls is on my list of packages to do, as the webserver hiawatha
> >> depends on it.
> >>
> >> Should I announce once it is packaged and the cve fix can be applied
> >> afterwards?
> >
> > We should definitely update curl on core-updates-next, or whatever is
> > built after the current cycle, and we should not add hiawatha until the
> > fixed curl is in our tree.
>
> Agreed on both points.  Can you already push the curl update in
> core-updates-next?
>
> Though I would like the default curl package to still used GnuTLS.  So I
> think curl-with-mbedtls will be a different package anyway.
>
> Thanks,
> Ludo’.
>

From the way it was done in Gentoo, I assume this is not needed?
mbedtls is a separate package, and I have libressl as the curlssl provider,
which is a curl built against libressl.

If I am wrong, correct me.
My initial comment was a bit out of place, but I just assume it will
justwork™ on guix, otherwise a curl-with-mbedtls would have to be
created.

Sorry for the confusion.

--
♥Ⓐ ng0
For non-prism friendly talk find me on
psyced.org / loupsycedyglgamf.onion

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [PATCH 0/1] curl: Fix CVE-2016-3739.

[Leo Famulari]

On Mon, Jun 13, 2016 at 03:42:47PM +0000, ng0 wrote:
> From the way it was done in Gentoo, I assume this is not needed?
> mbedtls is a separate package, and I have libressl as the curlssl provider,
> which is a curl built against libressl.
> 
> If I am wrong, correct me.
> My initial comment was a bit out of place, but I just assume it will
> justwork™ on guix, otherwise a curl-with-mbedtls would have to be
> created.
> 
> Sorry for the confusion.

I think the confusion was mine. Unless Hiawatha requires a curl linked
against mbedTLS, I don't think there will be any problem with
CVE-2016-3739 and Hiawatha.

Re: [PATCH 0/1] curl: Fix CVE-2016-3739.

[ng0]

[-- Attachment #1: Type: text/plain, Size: 1841 bytes --]

On 2016-06-13(12:14:14-0400), Leo Famulari wrote:
> On Mon, Jun 13, 2016 at 03:42:47PM +0000, ng0 wrote:
> > From the way it was done in Gentoo, I assume this is not needed?
> > mbedtls is a separate package, and I have libressl as the curlssl provider,
> > which is a curl built against libressl.
> >
> > If I am wrong, correct me.
> > My initial comment was a bit out of place, but I just assume it will
> > justwork™ on guix, otherwise a curl-with-mbedtls would have to be
> > created.
> >
> > Sorry for the confusion.
>
> I think the confusion was mine. Unless Hiawatha requires a curl linked
> against mbedTLS, I don't think there will be any problem with
> CVE-2016-3739 and Hiawatha.
>

I think it will work out alright. The test- and applied systems I had were
hardened gcc with libressl globally, amd64, and a hardened musl system with
openssl, amd64, in case of the musl it is curl built against openssl, the
gcc with curl libressl.

ng0@khazad-dum:~$ equery g hiawatha
 * Searching for hiawatha ...

-- snip --

 * dependency graph for www-servers/hiawatha-10.3-r99
 `--  www-servers/hiawatha-10.3-r99  [~amd64 keyword]
   `--  sys-libs/zlib-1.2.8-r1  (sys-libs/zlib) amd64
   `--  net-libs/mbedtls-2.2.1  (>=net-libs/mbedtls-2.0) amd64  [threads]
   `--  dev-libs/libxslt-1.1.29  (dev-libs/libxslt) amd64
   `--  dev-libs/libxml2-2.9.4  (dev-libs/libxml2) amd64
   `--  sys-devel/make-4.1-r1  (sys-devel/make) amd64
   `--  dev-util/cmake-3.3.1-r1  (>=dev-util/cmake-2.8.2) amd64
   `--  virtual/pkgconfig-0-r1  (virtual/pkgconfig) amd64
   `--  www-apps/hiawatha-monitor-1.3  (www-apps/hiawatha-monitor) [~amd64 keyword]
[ www-servers/hiawatha-10.3-r99 stats: packages (9), max depth (1) ]


--
♥Ⓐ ng0
For non-prism friendly talk find me on
psyced.org / loupsycedyglgamf.onion

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [PATCH 0/1] curl: Fix CVE-2016-3739.

[Leo Famulari]

On Mon, Jun 13, 2016 at 05:07:23PM +0200, Ludovic Courtès wrote:
> Leo Famulari <leo@famulari.name> skribis:
> > We should definitely update curl on core-updates-next, or whatever is
> > built after the current cycle, and we should not add hiawatha until the
> > fixed curl is in our tree.
> 
> Agreed on both points.  Can you already push the curl update in
> core-updates-next?

Done as 32a8eb01e

> Though I would like the default curl package to still used GnuTLS.  So I
> think curl-with-mbedtls will be a different package anyway.

I hadn't noticed that our curl package uses GnuTLS instead of OpenSSL :)