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

[Henrique de Moraes Holschuh]

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

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

[Davide Prina]

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

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

[Richard Lucassen]

On Fri, 4 May 2018 10:06:58 +0800
Paul Wise  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 "

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

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

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

[Paul Wise]

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

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

[Konstantin Khomoutov]

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

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

[richard lucassen]

On Thu, 03 May 2018 01:44:06 +0100
Ben Hutchings  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/

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

[Ben Hutchings]

On Thu, 2018-05-03 at 00:06 +0100, Dominic Hargreaves wrote:
> On Tue, May 01, 2018 at 05:12:02PM +, Ben Hutchings wrote:
> > -
> > Debian Security Advisory DSA-4187-1   secur...@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-104
> >  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

signature.asc
Description: This is a digitally signed message part

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

[Dominic Hargreaves]

On Tue, May 01, 2018 at 05:12:02PM +, Ben Hutchings wrote:
> -
> Debian Security Advisory DSA-4187-1   secur...@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-104
>  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.