Bug#919098: libzmq5: remote execution vulnerability

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug#919098: libzmq5: remote execution vulnerability

Luca Boccassi-3
Package: libzmq5
Version: 4.2.0-1
Severity: important
Tags: patch security upstream fixed-upstream

Dear Maintainer,

A remote execution vulnerability has been reported in zeromq. Full
details can be found on the upstream issue tracker [1].

The issue is fixed in upstream version v4.3.1, just released, or with
the attached patch which is targeted for v4.2.1 (stretch).

I would highly recommend to upgrade to the latest version for Buster,
and to consider at least an upload to stable-p-u with the patch.

As mentioned in the upstream tracker and the changelog, the issue can
be mitigated by ASLR and by authentication via CURVE/GSSAPI. As far as
I am aware no CVEs have been assigned nor have been requested as of
now.

--
Kind regards,
Luca Boccassi

[1] https://github.com/zeromq/libzmq/issues/3351

pointer_overflow.patch (1K) Download Attachment
signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#919098: libzmq5: remote execution vulnerability

Luca Boccassi-3
On Sat, 12 Jan 2019 16:54:42 +0000 Luca Boccassi <[hidden email]>
wrote:

> Package: libzmq5
> Version: 4.2.0-1
> Severity: important
> Tags: patch security upstream fixed-upstream

> Dear Maintainer,

> A remote execution vulnerability has been reported in zeromq. Full
> details can be found on the upstream issue tracker [1].

> The issue is fixed in upstream version v4.3.1, just released, or with
> the attached patch which is targeted for v4.2.1 (stretch).

> I would highly recommend to upgrade to the latest version for Buster,
> and to consider at least an upload to stable-p-u with the patch.

> As mentioned in the upstream tracker and the changelog, the issue can
> be mitigated by ASLR and by authentication via CURVE/GSSAPI. As far
as
> I am aware no CVEs have been assigned nor have been requested as of
> now.

> -- 
> Kind regards,
> Luca Boccassi

> [1] https://github.com/zeromq/libzmq/issues/3351

Sorry, I fat-fingered the patch refresh and the variable name is wrong.
Corrected version attached.

--
Kind regards,
Luca Boccassi

pointer_overflow_4.2.5.patch (1K) Download Attachment
signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#919098: libzmq5: remote execution vulnerability

Luca Boccassi-3
On Sat, 12 Jan 2019 17:29:23 +0000 Luca Boccassi <[hidden email]>
wrote:

> On Sat, 12 Jan 2019 16:54:42 +0000 Luca Boccassi <[hidden email]>
> wrote:
> > Package: libzmq5
> > Version: 4.2.0-1
> > Severity: important
> > Tags: patch security upstream fixed-upstream
> > 
> > Dear Maintainer,
> > 
> > A remote execution vulnerability has been reported in zeromq. Full
> > details can be found on the upstream issue tracker [1].
> > 
> > The issue is fixed in upstream version v4.3.1, just released, or
with
> > the attached patch which is targeted for v4.2.1 (stretch).
> > 
> > I would highly recommend to upgrade to the latest version for
Buster,
> > and to consider at least an upload to stable-p-u with the patch.
> > 
> > As mentioned in the upstream tracker and the changelog, the issue
can

> > be mitigated by ASLR and by authentication via CURVE/GSSAPI. As far
> as
> > I am aware no CVEs have been assigned nor have been requested as of
> > now.
> > 
> > -- 
> > Kind regards,
> > Luca Boccassi
> > 
> > [1] https://github.com/zeromq/libzmq/issues/3351

> Sorry, I fat-fingered the patch refresh and the variable name is
wrong.
> Corrected version attached.

Despite the name of the file, it's actually for 4.2.1 (stretch). Sorry,
juggling many emails and bug trackers at the moment...

--
Kind regards,
Luca Boccassi

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#919098: libzmq5: remote execution vulnerability

László Böszörményi (GCS)
On Sat, Jan 12, 2019 at 8:33 PM Luca Boccassi <[hidden email]> wrote:
> On Sat, 12 Jan 2019 17:29:23 +0000 Luca Boccassi <[hidden email]>
> wrote:
> > Sorry, I fat-fingered the patch refresh and the variable name is
> wrong.
> > Corrected version attached.
>
> Despite the name of the file, it's actually for 4.2.1 (stretch). Sorry,
> juggling many emails and bug trackers at the moment...
 No problem. But I ask for a help with 4.3.1 as one of its tests fail
on ppc64el architecture [1].
The minimal log I see:
"FAIL: tests/test_hwm_pubsub
===========================

Assertion failed: check () (src/msg.cpp:347)
FAIL tests/test_hwm_pubsub (exit status: 134)"

Can you give me pointers, what to check, how can I help fixing this?
Other architectures could build it without any problem.

Regards,
Laszlo/GCS
[1] https://buildd.debian.org/status/fetch.php?pkg=zeromq3&arch=ppc64el&ver=4.3.1-1&stamp=1547321006&raw=0

Reply | Threaded
Open this post in threaded view
|

Bug#919098: libzmq5: remote execution vulnerability

Luca Boccassi-3
On Sat, 12 Jan 2019, 19:53 László Böszörményi (GCS) <[hidden email] wrote:
On Sat, Jan 12, 2019 at 8:33 PM Luca Boccassi <[hidden email]> wrote:
> On Sat, 12 Jan 2019 17:29:23 +0000 Luca Boccassi <[hidden email]>
> wrote:
> > Sorry, I fat-fingered the patch refresh and the variable name is
> wrong.
> > Corrected version attached.
>
> Despite the name of the file, it's actually for 4.2.1 (stretch). Sorry,
> juggling many emails and bug trackers at the moment...
 No problem. But I ask for a help with 4.3.1 as one of its tests fail
on ppc64el architecture [1].
The minimal log I see:
"FAIL: tests/test_hwm_pubsub
===========================

Assertion failed: check () (src/msg.cpp:347)
FAIL tests/test_hwm_pubsub (exit status: 134)"

Can you give me pointers, what to check, how can I help fixing this?
Other architectures could build it without any problem.

Regards,
Laszlo/GCS
[1] https://buildd.debian.org/status/fetch.php?pkg=zeromq3&arch=ppc64el&ver=4.3.1-1&stamp=1547321006&raw=0

Hi,

I've seen that test fail sometimes on the very very slow windows CI we use upstream, I've never reproduced it locally or on porter machines or on the PPC Linux CI we use upstream.
I'd suggest to just try to ask wanna-build for a give back, and it will most likely pass. If it still fails I'll hop on a porter box tomorrow.

One thing I haven't seen mentioned in the changelog for 4.3.1-1 in Sid - as I wrote in NEWS, libzmq3-dev should get a dependency on the -dev packages of the libraries that libzmq5 links against, so that pkgconfig can work, as we now use Requires.private.

Kind regards,
Luca Boccassi
Reply | Threaded
Open this post in threaded view
|

Bug#919098: libzmq5: remote execution vulnerability

László Böszörményi (GCS)
On Sun, Jan 13, 2019 at 1:27 AM Luca Boccassi <[hidden email]> wrote:

> On Sat, 12 Jan 2019, 19:53 László Böszörményi (GCS) <[hidden email] wrote:
>>  No problem. But I ask for a help with 4.3.1 as one of its tests fail
>> on ppc64el architecture [1].
>> The minimal log I see:
>> "FAIL: tests/test_hwm_pubsub
>> ===========================
>>
>> Assertion failed: check () (src/msg.cpp:347)
>> FAIL tests/test_hwm_pubsub (exit status: 134)"
> I've seen that test fail sometimes on the very very slow windows CI we use upstream, I've never reproduced it locally or on porter machines or on the PPC Linux CI we use upstream.
> I'd suggest to just try to ask wanna-build for a give back, and it will most likely pass. If it still fails I'll hop on a porter box tomorrow.
 Tested on plummer and about half the time this test is failed. Once
from ten times an other test is failed as well. I chose to upload my
build instead of a give back as that may fail as well.

> One thing I haven't seen mentioned in the changelog for 4.3.1-1 in Sid - as I wrote in NEWS, libzmq3-dev should get a dependency on the -dev packages of the libraries that libzmq5 links against, so that pkgconfig can work, as we now use Requires.private.
 Indeed, I've read the NEWS and wanted to populate the -dev
dependencies. But then the security fix took over and I missed the new
-dev dependencies. I'm going to fix it.
May you look into the test failure and I can fix the two things in one upload?

Thanks,
Laszlo/GCS

Reply | Threaded
Open this post in threaded view
|

Bug#919098: libzmq5: remote execution vulnerability

Luca Boccassi-3
On Sun, 2019-01-13 at 14:16 +0100, László Böszörményi (GCS) wrote:

> On Sun, Jan 13, 2019 at 1:27 AM Luca Boccassi <[hidden email]>
> wrote:
> > On Sat, 12 Jan 2019, 19:53 László Böszörményi (GCS) <[hidden email]
> >  wrote:
> > >  No problem. But I ask for a help with 4.3.1 as one of its tests
> > > fail
> > > on ppc64el architecture [1].
> > > The minimal log I see:
> > > "FAIL: tests/test_hwm_pubsub
> > > ===========================
> > >
> > > Assertion failed: check () (src/msg.cpp:347)
> > > FAIL tests/test_hwm_pubsub (exit status: 134)"
> >
> > I've seen that test fail sometimes on the very very slow windows CI
> > we use upstream, I've never reproduced it locally or on porter
> > machines or on the PPC Linux CI we use upstream.
> > I'd suggest to just try to ask wanna-build for a give back, and it
> > will most likely pass. If it still fails I'll hop on a porter box
> > tomorrow.
>
>  Tested on plummer and about half the time this test is failed. Once
> from ten times an other test is failed as well. I chose to upload my
> build instead of a give back as that may fail as well.
I might have an idea on how to make it more reliable, I'm testing on
kyoto right now, as I've seen there's definitely an issue with another
test helper doing unaligned pointer access which triggers a sigbus on
sparc64 (it's not a problem in the library thankfully, just in the unit
test itself).

> > One thing I haven't seen mentioned in the changelog for 4.3.1-1 in
> > Sid - as I wrote in NEWS, libzmq3-dev should get a dependency on
> > the -dev packages of the libraries that libzmq5 links against, so
> > that pkgconfig can work, as we now use Requires.private.
>
>  Indeed, I've read the NEWS and wanted to populate the -dev
> dependencies. But then the security fix took over and I missed the
> new
> -dev dependencies. I'm going to fix it.
> May you look into the test failure and I can fix the two things in
> one upload?
>
> Thanks,
> Laszlo/GCS
Yes, I have a couple of hours to work on this right now, will send
patches as soon as I can.

--
Kind regards,
Luca Boccassi

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#919098: libzmq5: remote execution vulnerability

Luca Boccassi-3
On Sun, 2019-01-13 at 13:21 +0000, Luca Boccassi wrote:

> On Sun, 2019-01-13 at 14:16 +0100, László Böszörményi (GCS) wrote:
> > On Sun, Jan 13, 2019 at 1:27 AM Luca Boccassi <[hidden email]>
> > wrote:
> > > On Sat, 12 Jan 2019, 19:53 László Böszörményi (GCS) <[hidden email]
> > > rg
> > >  wrote:
> > > >  No problem. But I ask for a help with 4.3.1 as one of its
> > > > tests
> > > > fail
> > > > on ppc64el architecture [1].
> > > > The minimal log I see:
> > > > "FAIL: tests/test_hwm_pubsub
> > > > ===========================
> > > >
> > > > Assertion failed: check () (src/msg.cpp:347)
> > > > FAIL tests/test_hwm_pubsub (exit status: 134)"
> > >
> > > I've seen that test fail sometimes on the very very slow windows
> > > CI
> > > we use upstream, I've never reproduced it locally or on porter
> > > machines or on the PPC Linux CI we use upstream.
> > > I'd suggest to just try to ask wanna-build for a give back, and
> > > it
> > > will most likely pass. If it still fails I'll hop on a porter box
> > > tomorrow.
> >
> >  Tested on plummer and about half the time this test is failed.
> > Once
> > from ten times an other test is failed as well. I chose to upload
> > my
> > build instead of a give back as that may fail as well.
>
> I might have an idea on how to make it more reliable, I'm testing on
> kyoto right now, as I've seen there's definitely an issue with
> another
> test helper doing unaligned pointer access which triggers a sigbus on
> sparc64 (it's not a problem in the library thankfully, just in the
> unit
> test itself).
I'm seeing very strange behaviour on plummer, with a message which
internal metadata is getting overwritten. Didn't see that on sparc64 or
on my machines, very weird. I'm still looking.

In the meanwhile, I've found and fixed the issue with the other 3 tests
that seemingly randomly fail - it's not random at all, it's just that
they were left with hard-coded IPC file paths, so collisions might
happen. I've fixed them to use random paths like the others (those were
test_use_fd, test_reconnect_ivl, test_rebind_ipc and test_pair_ipc).

Also in the meanwhile, this issue has been assigned CVE-2019-6250, so
I'm CC'ing the Debian Security team, as they might want to create a
DSA.

Dear Security Team, as noted in this ticket this issue affects Stretch
and Buster (src:zeromq3 from 4.2.0 to 4.3.0).

--
Kind regards,
Luca Boccassi

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#919098: libzmq5: remote execution vulnerability

Luca Boccassi-3
On Sun, 2019-01-13 at 15:04 +0000, Luca Boccassi wrote:

> On Sun, 2019-01-13 at 13:21 +0000, Luca Boccassi wrote:
> > On Sun, 2019-01-13 at 14:16 +0100, László Böszörményi (GCS) wrote:
> > > On Sun, Jan 13, 2019 at 1:27 AM Luca Boccassi <[hidden email]>
> > > wrote:
> > > > On Sat, 12 Jan 2019, 19:53 László Böszörményi (GCS) <gcs@debian
> > > > .o
> > > > rg
> > > >  wrote:
> > > > >  No problem. But I ask for a help with 4.3.1 as one of its
> > > > > tests
> > > > > fail
> > > > > on ppc64el architecture [1].
> > > > > The minimal log I see:
> > > > > "FAIL: tests/test_hwm_pubsub
> > > > > ===========================
> > > > >
> > > > > Assertion failed: check () (src/msg.cpp:347)
> > > > > FAIL tests/test_hwm_pubsub (exit status: 134)"
> > > >
> > > > I've seen that test fail sometimes on the very very slow
> > > > windows
> > > > CI
> > > > we use upstream, I've never reproduced it locally or on porter
> > > > machines or on the PPC Linux CI we use upstream.
> > > > I'd suggest to just try to ask wanna-build for a give back, and
> > > > it
> > > > will most likely pass. If it still fails I'll hop on a porter
> > > > box
> > > > tomorrow.
> > >
> > >  Tested on plummer and about half the time this test is failed.
> > > Once
> > > from ten times an other test is failed as well. I chose to upload
> > > my
> > > build instead of a give back as that may fail as well.
> >
> > I might have an idea on how to make it more reliable, I'm testing
> > on
> > kyoto right now, as I've seen there's definitely an issue with
> > another
> > test helper doing unaligned pointer access which triggers a sigbus
> > on
> > sparc64 (it's not a problem in the library thankfully, just in the
> > unit
> > test itself).
>
> I'm seeing very strange behaviour on plummer, with a message which
> internal metadata is getting overwritten. Didn't see that on sparc64
> or
> on my machines, very weird. I'm still looking.
Unfortunately I haven't figured out the test_hwm_pubsub failure yet.
I'd suggest to patch it out for now if it's urgent to do a new upload.
I'll keep investigating later tonight and report back.

It is definitely not related to the fix for the security issue, though.
I've bisected it, and it fails all the way back to when test_hwm_pubsub
was extended to run on TCP and IPC other than inproc by commit
eb3e63e22f64c6974959458dd90db30959c2ebf1 upstream.

> In the meanwhile, I've found and fixed the issue with the other 3
> tests
> that seemingly randomly fail - it's not random at all, it's just that
> they were left with hard-coded IPC file paths, so collisions might
> happen. I've fixed them to use random paths like the others (those
> were
> test_use_fd, test_reconnect_ivl, test_rebind_ipc and test_pair_ipc).

Patches for these are attached.

--
Kind regards,
Luca Boccassi

test_sigbus_sparc64.patch (1008 bytes) Download Attachment
test_hardcoded_ipc_path.patch (6K) Download Attachment
signature.asc (499 bytes) Download Attachment