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

Groups > linux.debian.user > #190647 > unrolled thread

CVE-2017-5754 - ETA?

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

Contents

  CVE-2017-5754 - ETA? francis picabia <fpicabia@gmail.com> - 2018-01-04 15:00 +0100
    Re: CVE-2017-5754 - ETA? Don Armstrong <don@debian.org> - 2018-01-04 21:50 +0100
      Re: CVE-2017-5754 - ETA? francis picabia <fpicabia@gmail.com> - 2018-01-08 16:40 +0100
        Re: CVE-2017-5754 - ETA? Jeroen Mathon <jeroenmathonmac@gmail.com> - 2018-01-08 17:20 +0100
        Re: CVE-2017-5754 - ETA? Tixy <tixy@yxit.co.uk> - 2018-01-08 18:10 +0100
          Re: CVE-2017-5754 - ETA? Sven Joachim <svenjoac@gmx.de> - 2018-01-08 18:40 +0100
        Re: CVE-2017-5754 - ETA? Richard Hector <richard@walnut.gen.nz> - 2018-01-08 22:30 +0100
          Re: CVE-2017-5754 - ETA? francis picabia <fpicabia@gmail.com> - 2018-01-10 13:50 +0100
      Re: CVE-2017-5754 - ETA? Vincent Lefevre <vincent@vinc17.net> - 2018-01-12 14:40 +0100
        Re: CVE-2017-5754 - ETA? bw <bwtnguy@yahoo.com> - 2018-01-12 16:10 +0100
          Re: CVE-2017-5754 - ETA? Jack Dangler <tdldev@gmail.com> - 2018-01-12 17:00 +0100
            Re: CVE-2017-5754 - ETA? Roberto C. Sánchez <roberto@debian.org> - 2018-01-12 17:00 +0100
          Re: CVE-2017-5754 - ETA? Vincent Lefevre <vincent@vinc17.net> - 2018-01-12 22:10 +0100
            Re: CVE-2017-5754 - ETA? Roberto C. Sánchez <roberto@debian.org> - 2018-01-12 22:20 +0100
              Re: CVE-2017-5754 - ETA? Vincent Lefevre <vincent@vinc17.net> - 2018-01-12 22:20 +0100
            Re: CVE-2017-5754 - ETA? Nick <debuser@acrasis.net> - 2018-01-12 22:30 +0100
              Re: CVE-2017-5754 - ETA? Vincent Lefevre <vincent@vinc17.net> - 2018-01-12 22:50 +0100
                Re: CVE-2017-5754 - XEN silent_disable? bw <bwtnguy@yahoo.com> - 2018-01-13 02:10 +0100
                  Re: CVE-2017-5754 - XEN silent_disable? <tomas@tuxteam.de> - 2018-01-13 08:30 +0100
                    Re: CVE-2017-5754 - XEN silent_disable? Vincent Lefevre <vincent@vinc17.net> - 2018-01-13 10:50 +0100
                      Re: CVE-2017-5754 - XEN silent_disable? <tomas@tuxteam.de> - 2018-01-13 12:30 +0100
                Re: CVE-2017-5754 - ETA? Tixy <tixy@yxit.co.uk> - 2018-01-13 09:10 +0100
                  Re: CVE-2017-5754 - ETA? Tixy <tixy@yxit.co.uk> - 2018-01-13 09:50 +0100

Page 1 of 2  [1] 2  Next page →

#190647 — CVE-2017-5754 - ETA?

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

Redhat, Ubuntu and others have kernel updates available today
for this kernel patch that has been worked on since November.
Normally Debian has been quick out of the gate with security measures.

Is there an ETA when Debian will update kernel packages?

https://security-tracker.debian.org/tracker/CVE-2017-5754

Isn't showing any release with the fix at this time.

[toc] | [next] | [standalone]

#190669

On Thu, 04 Jan 2018, francis picabia wrote:
> Redhat, Ubuntu and others have kernel updates available today for this
> kernel patch that has been worked on since November. Normally Debian
> has been quick out of the gate with security measures.
> 
> Is there an ETA when Debian will update kernel packages?

The DSA has been (will be shortly?) released for stable. Unstable,
testing, and likely oldstable will probably follow soon.
https://security-tracker.debian.org/tracker/DSA-4078-1

-- 
Don Armstrong                      https://www.donarmstrong.com

There is no mechanical problem so difficult that it cannot be solved
by brute strength and ignorance.
 -- William's Law

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

#190803

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

On Thu, Jan 4, 2018 at 4:47 PM, Don Armstrong <don@debian.org> wrote:

> On Thu, 04 Jan 2018, francis picabia wrote:
> > Redhat, Ubuntu and others have kernel updates available today for this
> > kernel patch that has been worked on since November. Normally Debian
> > has been quick out of the gate with security measures.
> >
> > Is there an ETA when Debian will update kernel packages?
>
> The DSA has been (will be shortly?) released for stable. Unstable,
> testing, and likely oldstable will probably follow soon.
> https://security-tracker.debian.org/tracker/DSA-4078-1
>
>
>
Thanks for the response.  I'm looking now and I see stretch and wheezy are
addressed, but not jessie.  Odd.  Why would old-stable be a challenge?

I'm concerned because we run a system for students to do programming, and
there
is typically one in the crowd who will try out any script kiddies in the
news.  For
the time being I've blocked access to the system, but faculty expect it
will be available for use in a week or so.  I have the option to install
the stretch kernel and run in a hybrid version for awhile, but I'm not sure
if there will be problems with that workaround.

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

#190805

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

Can't you clone the disk to another machine, then test the stretch
kernel and then run hybrid for a while?

The kernel is just the intermediate between the hardware and userspace,
shoulnd not cause too much trouble, if not you can always test it that way.


On 01/08/2018 04:36 PM, francis picabia wrote:
> On Thu, Jan 4, 2018 at 4:47 PM, Don Armstrong <don@debian.org
> <mailto:don@debian.org>> wrote:
>
>     On Thu, 04 Jan 2018, francis picabia wrote:
>     > Redhat, Ubuntu and others have kernel updates available today
>     for this
>     > kernel patch that has been worked on since November. Normally Debian
>     > has been quick out of the gate with security measures.
>     >
>     > Is there an ETA when Debian will update kernel packages?
>
>     The DSA has been (will be shortly?) released for stable. Unstable,
>     testing, and likely oldstable will probably follow soon.
>     https://security-tracker.debian.org/tracker/DSA-4078-1
>     <https://security-tracker.debian.org/tracker/DSA-4078-1>
>
>
>
> Thanks for the response.  I'm looking now and I see stretch and wheezy are
> addressed, but not jessie.  Odd.  Why would old-stable be a challenge?
>
> I'm concerned because we run a system for students to do programming,
> and there
> is typically one in the crowd who will try out any script kiddies in
> the news.  For
> the time being I've blocked access to the system, but faculty expect it
> will be available for use in a week or so.  I have the option to install
> the stretch kernel and run in a hybrid version for awhile, but I'm not
> sure
> if there will be problems with that workaround.
>
>

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

#190807

On Mon, 2018-01-08 at 11:36 -0400, francis picabia wrote:
> > The DSA has been (will be shortly?) released for stable. Unstable,
> > testing, and likely oldstable will probably follow soon.
> > https://security-tracker.debian.org/tracker/DSA-4078-1
> >
> >
> >
> Thanks for the response.  I'm looking now and I see stretch and wheezy
> are
> addressed, but not jessie.  Odd.  Why would old-stable be a challenge?

It's a major set of changes that needs to be ported and tested. Perhaps
there we're more companies and distro's working on the 3.2 kernel in
Wheezy compared to 3.16 as used in Jessie. Or perhaps the latter port
hit problems, who knows.

-- 
Tixy

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

#190813

On 2018-01-08 17:04 +0000, Tixy wrote:

> On Mon, 2018-01-08 at 11:36 -0400, francis picabia wrote:
>> > The DSA has been (will be shortly?) released for stable. Unstable,
>> > testing, and likely oldstable will probably follow soon.
>> > https://security-tracker.debian.org/tracker/DSA-4078-1
>> >
>> >
>> >
>> Thanks for the response.  I'm looking now and I see stretch and wheezy
>> are
>> addressed, but not jessie.  Odd.  Why would old-stable be a challenge?
>
> It's a major set of changes that needs to be ported and tested. Perhaps
> there we're more companies and distro's working on the 3.2 kernel in
> Wheezy compared to 3.16 as used in Jessie.

I doubt that, both 3.2 and 3.16 are maintained by Ben Hutchings and are
not used by any major distro except Debian AFAIK.

> Or perhaps the latter port hit problems, who knows.

Definitely, both Ben and testers/reviewers hit showstopper bugs
including failure to boot at all.  See the thread on the stable@vger
list at https://www.spinics.net/lists/stable/index.html#209049.

Cheers,
       Sven

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

#190822

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

On 09/01/18 04:36, francis picabia wrote:
> I have the option to install
> the stretch kernel and run in a hybrid version for awhile, but I'm not sure
> if there will be problems with that workaround.

The jessie-backports kernel has been updated, I believe.

Richard

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

#190890

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

On Mon, Jan 8, 2018 at 5:20 PM, Richard Hector <richard@walnut.gen.nz>
wrote:

> On 09/01/18 04:36, francis picabia wrote:
> > I have the option to install
> > the stretch kernel and run in a hybrid version for awhile, but I'm not
> sure
> > if there will be problems with that workaround.
>
> The jessie-backports kernel has been updated, I believe.
>
>
The jessie-backports did work, as well as using stretch as the repo for
install.

There is now a 3.16.51-3+deb8u1 released for jessie, so this is now
fixed without using a kernel from 4.* series.

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

#190980

On 2018-01-04 12:47:42 -0800, Don Armstrong wrote:
> On Thu, 04 Jan 2018, francis picabia wrote:
> > Redhat, Ubuntu and others have kernel updates available today for this
> > kernel patch that has been worked on since November. Normally Debian
> > has been quick out of the gate with security measures.
> > 
> > Is there an ETA when Debian will update kernel packages?
> 
> The DSA has been (will be shortly?) released for stable. Unstable,
> testing, and likely oldstable will probably follow soon.
> https://security-tracker.debian.org/tracker/DSA-4078-1

According to answers on

  https://security.stackexchange.com/questions/176624/how-do-i-check-if-kpti-is-enabled-on-linux/176654

linux-image-4.9.0-5-amd64 4.9.65-3+deb9u2 is still vulnerable as shown
below:

# dmesg | grep -i isolation
# cat /sys/kernel/debug/x86/pti_enabled
cat: /sys/kernel/debug/x86/pti_enabled: No such file or directory

The command line is:

  root=UUID=... ro console=ttyS0 console=hvc0 nomce loglevel=5 net.ifnames=0

thus KPTI is not disabled via the command line.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

#190988

On Fri, 12 Jan 2018, Vincent Lefevre wrote:

> 
> According to answers on
> 
>   https://security.stackexchange.com/questions/176624/how-do-i-check-if-kpti-is-enabled-on-linux/176654
> 
> linux-image-4.9.0-5-amd64 4.9.65-3+deb9u2 is still vulnerable as shown
> below:
> 
> # dmesg | grep -i isolation

You should get either

[    0.000000] Kernel/User page tables isolation: enabled
or
[    0.000000] Kernel/User page tables isolation: disabled

Search with dmesg | less it's about two pages down for me,

$ uname -a
Linux debian 4.9.0-5-amd64 #1 SMP Debian 4.9.65-3+deb9u2 (2018-01-04) 
x86_64 GNU/Linux

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

#190991

On 01/12/2018 10:00 AM, bw wrote:
>
> On Fri, 12 Jan 2018, Vincent Lefevre wrote:
>
>> According to answers on
>>
>>    https://security.stackexchange.com/questions/176624/how-do-i-check-if-kpti-is-enabled-on-linux/176654
>>
>> linux-image-4.9.0-5-amd64 4.9.65-3+deb9u2 is still vulnerable as shown
>> below:
>>
>> # dmesg | grep -i isolation
> You should get either
>
> [    0.000000] Kernel/User page tables isolation: enabled
> or
> [    0.000000] Kernel/User page tables isolation: disabled
>
> Search with dmesg | less it's about two pages down for me,
>
> $ uname -a
> Linux debian 4.9.0-5-amd64 #1 SMP Debian 4.9.65-3+deb9u2 (2018-01-04)
> x86_64 GNU/Linux
>
>
I tried this on my Ubu workstation and didnt get anything back...
$ dmesg | grep -i isolation
$
$ uname -a
Linux 4.10.0-40-generic #44~16.04.1-Ubuntu SMP Thu Nov 9 15:37:44 UTC 
2017 x86_64 x86_64 x86_64 GNU/Linux

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

#190992

On Fri, Jan 12, 2018 at 10:51:34AM -0500, Jack Dangler wrote:
> I tried this on my Ubu workstation and didnt get anything back...
> $ dmesg | grep -i isolation
> $
> $ uname -a
> Linux 4.10.0-40-generic #44~16.04.1-Ubuntu SMP Thu Nov 9 15:37:44 UTC 2017
                                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
> x86_64 x86_64 x86_64 GNU/Linux
> 

Your kernel was built prior to the vulnerbilities being made public.
The patches had not yet made their way into Linux at that point.

Regards,

-Roberto
-- 
Roberto C. Sánchez

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

#191007

On 2018-01-12 10:00:03 -0500, bw wrote:
> On Fri, 12 Jan 2018, Vincent Lefevre wrote:
> > According to answers on
> > 
> >   https://security.stackexchange.com/questions/176624/how-do-i-check-if-kpti-is-enabled-on-linux/176654
> > 
> > linux-image-4.9.0-5-amd64 4.9.65-3+deb9u2 is still vulnerable as shown
> > below:
> > 
> > # dmesg | grep -i isolation
> 
> You should get either
> 
> [    0.000000] Kernel/User page tables isolation: enabled
> or
> [    0.000000] Kernel/User page tables isolation: disabled

I get neither.

> Search with dmesg | less it's about two pages down for me,

If I search for isolation I get:

Pattern not found  (press RETURN)

> $ uname -a
> Linux debian 4.9.0-5-amd64 #1 SMP Debian 4.9.65-3+deb9u2 (2018-01-04) 
> x86_64 GNU/Linux

$ uname -a
Linux joooj 4.9.0-5-amd64 #1 SMP Debian 4.9.65-3+deb9u2 (2018-01-04) x86_64 GNU/Linux

There seems to be something really wrong. I'll report a bug.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

#191008

On Fri, Jan 12, 2018 at 09:59:20PM +0100, Vincent Lefevre wrote:
> 
> $ uname -a
> Linux joooj 4.9.0-5-amd64 #1 SMP Debian 4.9.65-3+deb9u2 (2018-01-04) x86_64 GNU/Linux
> 
> There seems to be something really wrong. I'll report a bug.
> 
What is the output of `grep vendor_id /proc/cpuinfo` on your machine?

Regards,

-Roberto

-- 
Roberto C. Sánchez

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

#191010

On 2018-01-12 16:10:40 -0500, Roberto C. Sánchez wrote:
> On Fri, Jan 12, 2018 at 09:59:20PM +0100, Vincent Lefevre wrote:
> > $ uname -a
> > Linux joooj 4.9.0-5-amd64 #1 SMP Debian 4.9.65-3+deb9u2 (2018-01-04) x86_64 GNU/Linux
> > 
> > There seems to be something really wrong. I'll report a bug.
> > 
> What is the output of `grep vendor_id /proc/cpuinfo` on your machine?

$ grep vendor_id /proc/cpuinfo
vendor_id       : GenuineIntel

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

#191011

On 2018-01-12 21:09 GMT, Vincent Lefevre wrote:
> On 2018-01-12 10:00:03 -0500, bw wrote:
> > On Fri, 12 Jan 2018, Vincent Lefevre wrote:
> > > # dmesg | grep -i isolation
> > 
> > You should get either
> > 
> > [    0.000000] Kernel/User page tables isolation: enabled
> > or
> > [    0.000000] Kernel/User page tables isolation: disabled
> 
> I get neither.

> There seems to be something really wrong. I'll report a bug.

It might have aged out of the buffer that dmesg reports on. I don't
see it in my dmesg either but in /var/log/kern.log.1 there is

  Kernel/User page tables isolation: enabled

Try a grep in /var/log ?
-- 
Nick

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

#191012

On 2018-01-12 21:21:06 +0000, Nick wrote:
> It might have aged out of the buffer that dmesg reports on.

No, there's the beginning of the dmesg output:

[    0.000000] Linux version 4.9.0-5-amd64 (debian-kernel@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.65-3+deb9u2 (2018-01-04)

But I think I've found the reason:

In arch/x86/mm/kaiser.c:

void __init kaiser_check_boottime_disable(void)
{
[...]
        if (boot_cpu_has(X86_FEATURE_XENPV))
                goto silent_disable;
[...]
disable:
        pr_info("disabled\n");

silent_disable:
        kaiser_enabled = 0;
        setup_clear_cpu_cap(X86_FEATURE_KAISER);
}

I must be in the "silent_disable" case (this is a Xen guest).

It's unfortunate that no-one mentions this case!

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

#191017 — Re: CVE-2017-5754 - XEN silent_disable?

On Fri, 12 Jan 2018, Vincent Lefevre wrote:

> But I think I've found the reason:
> 
> In arch/x86/mm/kaiser.c:
> 
> void __init kaiser_check_boottime_disable(void)
> {
> [...]
>         if (boot_cpu_has(X86_FEATURE_XENPV))
>                 goto silent_disable;
> [...]
> disable:
>         pr_info("disabled\n");
> 
> silent_disable:
>         kaiser_enabled = 0;
>         setup_clear_cpu_cap(X86_FEATURE_KAISER);
> }
> 
> I must be in the "silent_disable" case (this is a Xen guest).
> 
> It's unfortunate that no-one mentions this case!
> 

It is an unfortunate situation all around, no doubt!  I did a quick 
websearch and found contrary opinions about whether Xen paravirtualization 
is affected or not, whether a patched server and a patched guest is 
necessary, and to what degree patching one or the other protects either, 
and from whom.

Very unfortunate. 

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

#191023 — Re: CVE-2017-5754 - XEN silent_disable?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, Jan 12, 2018 at 08:08:17PM -0500, bw wrote:
> 
> 
> On Fri, 12 Jan 2018, Vincent Lefevre wrote:
> 
> > But I think I've found the reason:
> > 
> > In arch/x86/mm/kaiser.c:
> > 
> > void __init kaiser_check_boottime_disable(void)
> > {
> > [...]
> >         if (boot_cpu_has(X86_FEATURE_XENPV))
> >                 goto silent_disable;
> > [...]
> > disable:
> >         pr_info("disabled\n");
> > 
> > silent_disable:
> >         kaiser_enabled = 0;
> >         setup_clear_cpu_cap(X86_FEATURE_KAISER);
> > }
> > 
> > I must be in the "silent_disable" case (this is a Xen guest).
> > 
> > It's unfortunate that no-one mentions this case!
> > 
> 
> It is an unfortunate situation all around, no doubt!  I did a quick 
> websearch and found contrary opinions about whether Xen paravirtualization 
> is affected or not, whether a patched server and a patched guest is 
> necessary, and to what degree patching one or the other protects either, 
> and from whom.

FWIW, this is the patch which brought it about:

  http://lists-archives.com/linux-kernel/29009008-kaiser-disabled-on-xen-pv.html

I'm not very happy with the "silent" part either.

Cheers
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlpZtIEACgkQBcgs9XrR2kbNwACfRovUdRTiZR7U1TIfbspdk14b
WXgAnRhSFGayMn18nREAE0hb1h2CkzqV
=GNHh
-----END PGP SIGNATURE-----

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

#191026 — Re: CVE-2017-5754 - XEN silent_disable?

On 2018-01-13 08:25:53 +0100, tomas@tuxteam.de wrote:
> FWIW, this is the patch which brought it about:
> 
>   http://lists-archives.com/linux-kernel/29009008-kaiser-disabled-on-xen-pv.html
> 
> I'm not very happy with the "silent" part either.

For the "silent" part, I've reported a wishlist bug here:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887061

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web