Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.security > #5409 > unrolled thread

Re: [SECURITY] [DSA 4187-1] linux security update

Back to article view | Back to linux.debian.security

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [SECURITY] [DSA 4187-1] linux security update Dominic Hargreaves <dom@earth.li> - 2018-05-03 01:10 +0200
    Re: [SECURITY] [DSA 4187-1] linux security update Ben Hutchings <benh@debian.org> - 2018-05-03 02:50 +0200
      Re: [SECURITY] [DSA 4187-1] linux security update richard lucassen <mailinglists@lucassen.org> - 2018-05-03 11:10 +0200
        Re: [SECURITY] [DSA 4187-1] linux security update Konstantin Khomoutov <kostix@bswap.ru> - 2018-05-03 12:00 +0200
        Re: [SECURITY] [DSA 4187-1] linux security update Paul Wise <pabs@debian.org> - 2018-05-04 04:10 +0200
          Re: [SECURITY] [DSA 4187-1] linux security update Richard Lucassen <spamtrap@xaq.nl> - 2018-05-04 10:20 +0200
          Re: [SECURITY] [DSA 4187-1] linux security update Davide Prina <davide.prina@gmail.com> - 2018-05-04 21:30 +0200
            Re: [SECURITY] [DSA 4187-1] linux security update Henrique de Moraes Holschuh <hmh@debian.org> - 2018-05-05 16:00 +0200

#5409 — Re: [SECURITY] [DSA 4187-1] linux security update

On Tue, May 01, 2018 at 05:12:02PM +0000, Ben Hutchings wrote:
> -------------------------------------------------------------------------
> Debian Security Advisory DSA-4187-1                   security@debian.org
> https://www.debian.org/security/                            Ben Hutchings
> May 01, 2018                          https://www.debian.org/security/faq
> -------------------------------------------------------------------------
> 
> Package        : linux
> CVE ID         : CVE-2015-9016 CVE-2017-0861 CVE-2017-5715 CVE-2017-5753
>                  CVE-2017-13166 CVE-2017-13220 CVE-2017-16526 CVE-2017-16911
>                  CVE-2017-16912 CVE-2017-16913 CVE-2017-16914 CVE-2017-18017
>                  CVE-2017-18203 CVE-2017-18216 CVE-2017-18232 CVE-2017-18241
>                  CVE-2018-1066 CVE-2018-1068 CVE-2018-1092 CVE-2018-5332
>                  CVE-2018-5333 CVE-2018-5750 CVE-2018-5803 CVE-2018-6927
>                  CVE-2018-7492 CVE-2018-7566 CVE-2018-7740 CVE-2018-7757
>                  CVE-2018-7995 CVE-2018-8781 CVE-2018-8822 CVE-2018-1000004
>                  CVE-2018-1000199
> 
> Several vulnerabilities have been discovered in the Linux kernel that
> may lead to a privilege escalation, denial of service or information
> leaks.

There are multiple reports on #ganeti that this update breaks networking
in certain circumstances, probably multiple tun/tap device configurations.
No more details or a proper bug report yet as I haven't experienced this
myself, but mentioning in case it saves anyone else breakage.

Cheers,
Dominic.

[toc] | [next] | [standalone]

#5410

[Multipart message — attachments visible in raw view] — view raw

On Thu, 2018-05-03 at 00:06 +0100, Dominic Hargreaves wrote:
> On Tue, May 01, 2018 at 05:12:02PM +0000, Ben Hutchings wrote:
> > -------------------------------------------------------------------------
> > Debian Security Advisory DSA-4187-1                   security@debian.org
> > https://www.debian.org/security/                            Ben Hutchings
> > May 01, 2018                          https://www.debian.org/security/faq
> > -------------------------------------------------------------------------
> > 
> > Package        : linux
> > CVE ID         : CVE-2015-9016 CVE-2017-0861 CVE-2017-5715 CVE-2017-5753
> >                  CVE-2017-13166 CVE-2017-13220 CVE-2017-16526 CVE-2017-16911
> >                  CVE-2017-16912 CVE-2017-16913 CVE-2017-16914 CVE-2017-18017
> >                  CVE-2017-18203 CVE-2017-18216 CVE-2017-18232 CVE-2017-18241
> >                  CVE-2018-1066 CVE-2018-1068 CVE-2018-1092 CVE-2018-5332
> >                  CVE-2018-5333 CVE-2018-5750 CVE-2018-5803 CVE-2018-6927
> >                  CVE-2018-7492 CVE-2018-7566 CVE-2018-7740 CVE-2018-7757
> >                  CVE-2018-7995 CVE-2018-8781 CVE-2018-8822 CVE-2018-1000004
> >                  CVE-2018-1000199
> > 
> > Several vulnerabilities have been discovered in the Linux kernel that
> > may lead to a privilege escalation, denial of service or information
> > leaks.
> 
> There are multiple reports on #ganeti that this update breaks networking
> in certain circumstances, probably multiple tun/tap device configurations.
> No more details or a proper bug report yet as I haven't experienced this
> myself, but mentioning in case it saves anyone else breakage.[...]

I believe I understand this. Creating a tun/tap device using a name
pattern such as "tun%d" (or empty name) will now fail if the number
substituted is not 0.  There is an upstream fix for this that I failed
to spot in time.

Ben.

-- 
Ben Hutchings - Debian developer, member of kernel, installer and LTS teams

[toc] | [prev] | [next] | [standalone]

#5411

On Thu, 03 May 2018 01:44:06 +0100
Ben Hutchings <benh@debian.org> wrote:

> > There are multiple reports on #ganeti that this update breaks
> > networking in certain circumstances, probably multiple tun/tap
> > device configurations. No more details or a proper bug report yet
> > as I haven't experienced this myself, but mentioning in case it
> > saves anyone else breakage.[...]
> 
> I believe I understand this. Creating a tun/tap device using a name
> pattern such as "tun%d" (or empty name) will now fail if the number
> substituted is not 0.  There is an upstream fix for this that I failed
> to spot in time.

There is also an big increase in time before random is initialized:

[  182.811840] random: crng init done

This is a machine on bare metal. On other environments like proxmox I've
seen:

[  303.993638] random: crng init done

Downgrading to the previous kernel resolves the problem (normally a few
seconds). One of the consequences is that openntpd (or a program like
rdate) hangs until the crng is initialized.

R.
-- 
richard lucassen
http://contact.xaq.nl/

[toc] | [prev] | [next] | [standalone]

#5412

On Thu, May 03, 2018 at 10:53:00AM +0200, richard lucassen wrote:

> > > There are multiple reports on #ganeti that this update breaks
> > > networking in certain circumstances, probably multiple tun/tap
> > > device configurations. No more details or a proper bug report yet
> > > as I haven't experienced this myself, but mentioning in case it
> > > saves anyone else breakage.[...]
> > 
> > I believe I understand this. Creating a tun/tap device using a name
> > pattern such as "tun%d" (or empty name) will now fail if the number
> > substituted is not 0.  There is an upstream fix for this that I failed
> > to spot in time.
> 
> There is also an big increase in time before random is initialized:
> 
> [  182.811840] random: crng init done
> 
> This is a machine on bare metal. On other environments like proxmox I've
> seen:
> 
> [  303.993638] random: crng init done
> 
> Downgrading to the previous kernel resolves the problem (normally a few
> seconds). One of the consequences is that openntpd (or a program like
> rdate) hangs until the crng is initialized.

I'd think it's a fix for [1], [2] but it does not appear on the list of
CVEs fixed.

1. https://security-tracker.debian.org/tracker/CVE-2018-1108
2. https://bugs.chromium.org/p/project-zero/issues/detail?id=1559

[toc] | [prev] | [next] | [standalone]

#5413

On Thu, May 3, 2018 at 4:53 PM, richard lucassen wrote:

> There is also an big increase in time before random is initialized:
...
> One of the consequences is that openntpd (or a program like
> rdate) hangs until the crng is initialized.

What do these two programs require entropy for?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

[toc] | [prev] | [next] | [standalone]

#5414

On Fri, 4 May 2018 10:06:58 +0800
Paul Wise <pabs@debian.org> wrote:

> > One of the consequences is that openntpd (or a program like
> > rdate) hangs until the crng is initialized.
> 
> What do these two programs require entropy for?

That's the question. The only thing I saw that these two programs
normally send 123/UDP packets to query the configured timeservers, but
apparently these packets are blocked until crng is initialized.
At least "rdate" uses "getrandom", that's what you see rdate is waiting
for when you "strace -p <pid rdate>"

-- 
___________________________________________________________________
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+------------------------------------------------------------------+
| Richard Lucassen, Utrecht                                        |
+------------------------------------------------------------------+

[toc] | [prev] | [next] | [standalone]

#5415

On 04/05/2018 04:06, Paul Wise wrote:
> On Thu, May 3, 2018 at 4:53 PM, richard lucassen wrote:
> 
>> There is also an big increase in time before random is initialized:
> ...
>> One of the consequences is that openntpd (or a program like
>> rdate) hangs until the crng is initialized.
> 
> What do these two programs require entropy for?

security:

Integrates the latest secure API advances from OpenBSD such as 
getentropy(2), arc4random(3) (a fail-safe CSRNG that works in chroot 
environments), and reallocarray(3) (an integer overflow-checking 
malloc/calloc/realloc replacement).[1]

you can read more detail on NTP RFC[2]

Ciao
Davide

[1] http://www.openntpd.org/features.html
[2] https://www.ietf.org/rfc/rfc1305.txt
     https://www.ietf.org/rfc/rfc5905.txt

[toc] | [prev] | [next] | [standalone]

#5416

On Fri, 04 May 2018, Davide Prina wrote:
> On 04/05/2018 04:06, Paul Wise wrote:
> > On Thu, May 3, 2018 at 4:53 PM, richard lucassen wrote:
> > 
> > > There is also an big increase in time before random is initialized:
> > ...
> > > One of the consequences is that openntpd (or a program like
> > > rdate) hangs until the crng is initialized.
> > 
> > What do these two programs require entropy for?
> 
> security:
> 
> Integrates the latest secure API advances from OpenBSD such as
> getentropy(2), arc4random(3) (a fail-safe CSRNG that works in chroot
> environments), and reallocarray(3) (an integer overflow-checking
> malloc/calloc/realloc replacement).[1]
> 
> you can read more detail on NTP RFC[2]

Well, it is false security if it depends on a RNG with too little
entropy, and unless you have hardware assistance, that also means you
need to delay their start until the RNG is properly seeded.

Maybe we should have a systemd target/sysvinit facility that can be used
properly for "crng available" (and use the !@#$ one for clock sync'd as
well, related to ntp...  dnssec *really* depends on never enabling its
secure mode before you sync'd the clock, for example.  But lots of other
stuff would like to start providing service only after the local clock
has been made realtively accurate by ntp/sntp/whatever).

-- 
  Henrique Holschuh

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.security

csiph-web