[gentoo-user] CoreOS vulnerability inherited from Gentoo?

[gentoo-user] CoreOS vulnerability inherited from Gentoo?

[James]

 Here is an interesting read::

Security brief: CoreOS Linux Alpha remote SSH issue
May 19, 2016 · By Matthew Garrett 

<snippets>

Gentoo defaults to ending the PAM configuration with an optional pam_permit.

This meant that failing both pam_unix and pam_sss on CoreOS systems would
surprisingly result in authentication succeeding, and access being granted.

The operator user was not used by CoreOS, but existed because it exists in
the Gentoo Portage system from which CoreOS is derived.  
<end/snippets>

Full read [1]. It kinda shows that CoreOS is derived from Gentoo 
and not ChromeOS; at least when time to blame a security lapse elsewhere....


enjoy,
James

[1] https://coreos.com/blog/

Re: [gentoo-user] CoreOS vulnerability inherited from Gentoo?

[Mick]

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

On Tuesday 31 May 2016 16:30:27 James wrote:
>  Here is an interesting read::
> 
> Security brief: CoreOS Linux Alpha remote SSH issue
> May 19, 2016 · By Matthew Garrett
> 
> <snippets>
> 
> Gentoo defaults to ending the PAM configuration with an optional pam_permit.
> 
> This meant that failing both pam_unix and pam_sss on CoreOS systems would
> surprisingly result in authentication succeeding, and access being granted.
> 
> The operator user was not used by CoreOS, but existed because it exists in
> the Gentoo Portage system from which CoreOS is derived.
> <end/snippets>
> 
> Full read [1]. It kinda shows that CoreOS is derived from Gentoo
> and not ChromeOS; at least when time to blame a security lapse elsewhere....
> 
> 
> enjoy,
> James
> 
> [1] https://coreos.com/blog/

Does this mean we need to do anything to improve the security of our systems?
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-user] CoreOS vulnerability inherited from Gentoo?

[Michael Cook]

On 05/31/2016 01:44 PM, Mick wrote:
> On Tuesday 31 May 2016 16:30:27 James wrote:
>>  Here is an interesting read::
>>
>> Security brief: CoreOS Linux Alpha remote SSH issue
>> May 19, 2016 · By Matthew Garrett
>>
>> <snippets>
>>
>> Gentoo defaults to ending the PAM configuration with an optional pam_permit.
>>
>> This meant that failing both pam_unix and pam_sss on CoreOS systems would
>> surprisingly result in authentication succeeding, and access being granted.
>>
>> The operator user was not used by CoreOS, but existed because it exists in
>> the Gentoo Portage system from which CoreOS is derived.
>> <end/snippets>
>>
>> Full read [1]. It kinda shows that CoreOS is derived from Gentoo
>> and not ChromeOS; at least when time to blame a security lapse elsewhere....
>>
>>
>> enjoy,
>> James
>>
>> [1] https://coreos.com/blog/
>
> Does this mean we need to do anything to improve the security of our systems?
>
I tried logging in as operator with any password, it did not work for 
me. Unsure if that's because of my SSH set up or not though. The blog 
post does however mention reverting their SSSD change did fix the issue, 
so I assume if you set up SSSD the same way they did you would have 
issues. With that being said, maybe it would be a good idea for the 
gentoo pam team to set up pambase to support SSSD and not cause issues. 
(Currently if you want to set up SSSD you are left to do it manually)

[gentoo-user] Re: CoreOS vulnerability inherited from Gentoo?

[James]

Michael Cook <mcook <at> mackal.net> writes:


> >> [1] https://coreos.com/blog/

> > Does this mean we need to do anything to improve the security of our
systems?


It's going to depend, but surely a wide audience needs to poke at this...

> I tried logging in as operator with any password, it did not work for 
> me. Unsure if that's because of my SSH set up or not though. The blog 
> post does however mention reverting their SSSD change did fix the issue, 
> so I assume if you set up SSSD the same way they did you would have 
> issues. With that being said, maybe it would be a good idea for the 
> gentoo pam team to set up pambase to support SSSD and not cause issues. 
> (Currently if you want to set up SSSD you are left to do it manually)


I simple went looking for a pam<*>.conf file to make a simple edit and 
then test. It took me on a journey, so I posted here, figuring one
of the others had already ferreted out the details....


Oddly, I was looking at DPI (deep packet inspection) tools readily 
available for gentoo, to test some protocols, including ssh*.


I found nDPI and libndpi in overlays and suricata, which purports to
be able to perform deep packet inspections and is Netfilter compatible.
Since dpi can be a big drain on resources (of a single host), I was
hoping somebody had already migrated a dpi family of codes to a gentoo
cluster of some sort. Naddah. Ziltchen. Verboten! Since much of routing and
network engines have move to clusters (sdn, nvf, etc) dpi is king
of the hill for hot analytics.....


Those folks deeply into penetration (professional assessment types) means
are the best source for understanding dpi semantics. Every thing I have
found where folks are migrating dpi to clusters, these companies, projects
and experts are being snapped up by large corps,  agencies and otherwise
going 'off grid'. I'm not too sure what to make of all of this, but the pam
issue is only the tip of the berg.....ymmv.



hth,
James

Re: [gentoo-user] CoreOS vulnerability inherited from Gentoo?

[Max R.D. Parmer]

On Tue, May 31, 2016, at 10:44, Mick wrote:
> On Tuesday 31 May 2016 16:30:27 James wrote:
> >  Here is an interesting read::
> > 
> > Security brief: CoreOS Linux Alpha remote SSH issue
> > May 19, 2016 · By Matthew Garrett
> > 
> > <snippets>
> > 
> > Gentoo defaults to ending the PAM configuration with an optional pam_permit.
> > 
> > This meant that failing both pam_unix and pam_sss on CoreOS systems would
> > surprisingly result in authentication succeeding, and access being granted.
> > 
> > The operator user was not used by CoreOS, but existed because it exists in
> > the Gentoo Portage system from which CoreOS is derived.
> > <end/snippets>
> > 
> > Full read [1]. It kinda shows that CoreOS is derived from Gentoo
> > and not ChromeOS; at least when time to blame a security lapse elsewhere....
> > 
> > 
> > enjoy,
> > James
> > 
> > [1] https://coreos.com/blog/
> 
> Does this mean we need to do anything to improve the security of our
> systems?

The interaction seems to be problematic when SSSD is introduced to the
mix, as the SSSD documentation seems to assume a fallthrough to
pam_permit.so. With a merely empty user password, I cannot trigger this
issue. I will have to try with an expired account and a locked account
later.

the pam_permit.so line was introduced here:
https://gitweb.gentoo.org/proj/pambase.git/commit/?id=ac9023eecfe3c13d212c548bb9d5d1b42a4e044b

At the very least, it does seem like it ought to be pam_deny.so instead.

I wonder if this issue is still even relevant for Kerberos users?
https://bugs.gentoo.org/show_bug.cgi?id=333393 

Re: [gentoo-user] CoreOS vulnerability inherited from Gentoo?

[Max R.D. Parmer]

On Tue, May 31, 2016, at 11:07, Max R.D. Parmer wrote:
> On Tue, May 31, 2016, at 10:44, Mick wrote:
> > On Tuesday 31 May 2016 16:30:27 James wrote:
> > >  Here is an interesting read::
> > > 
> > > Security brief: CoreOS Linux Alpha remote SSH issue
> > > May 19, 2016 · By Matthew Garrett
> > > 
> > > <snippets>
> > > 
> > > Gentoo defaults to ending the PAM configuration with an optional pam_permit.
> > > 
> > > This meant that failing both pam_unix and pam_sss on CoreOS systems would
> > > surprisingly result in authentication succeeding, and access being granted.
> > > 
> > > The operator user was not used by CoreOS, but existed because it exists in
> > > the Gentoo Portage system from which CoreOS is derived.
> > > <end/snippets>
> > > 
> > > Full read [1]. It kinda shows that CoreOS is derived from Gentoo
> > > and not ChromeOS; at least when time to blame a security lapse elsewhere....
> > > 
> > > 
> > > enjoy,
> > > James
> > > 
> > > [1] https://coreos.com/blog/
> > 
> > Does this mean we need to do anything to improve the security of our
> > systems?
> 
> The interaction seems to be problematic when SSSD is introduced to the
> mix, as the SSSD documentation seems to assume a fallthrough to
> pam_permit.so. With a merely empty user password, I cannot trigger this
> issue. I will have to try with an expired account and a locked account
> later.
> 
> the pam_permit.so line was introduced here:
> https://gitweb.gentoo.org/proj/pambase.git/commit/?id=ac9023eecfe3c13d212c548bb9d5d1b42a4e044b
> 
> At the very least, it does seem like it ought to be pam_deny.so instead.
> 
> I wonder if this issue is still even relevant for Kerberos users?
> https://bugs.gentoo.org/show_bug.cgi?id=333393 
> 

Yeah -- doesn't work with a locked or expired account either.

Re: [gentoo-user] CoreOS vulnerability inherited from Gentoo?

[Neil Bothwick]

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

On Tue, 31 May 2016 18:44:10 +0100, Mick wrote:

> > The operator user was not used by CoreOS, but existed because it
> > exists in the Gentoo Portage system from which CoreOS is derived.
> > <end/snippets>
> > 
> > Full read [1]. It kinda shows that CoreOS is derived from Gentoo
> > and not ChromeOS; at least when time to blame a security lapse
> > elsewhere....

ChromeOS is based on Gentoo, so if CoreOS is based no ChromeOS it is a
second generation Gentoo derivative.

> Does this mean we need to do anything to improve the security of our
> systems?

The report seems to be saying that the problem is caused by using the
Gentoo default config, which assumes a Gentoo environment. So  it's fine
on Gentoo. But it won't hurt to run glsa-check from time to time (my sync
script does it every time and mails me if there's a problem).


-- 
Neil Bothwick

Everything else being equal, fat people use more soap.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[gentoo-user] Re: CoreOS vulnerability inherited from Gentoo?

[James]

Neil Bothwick <neil <at> digimed.co.uk> writes:


> > Does this mean we need to do anything to improve the security of our
> > systems?

> The report seems to be saying that the problem is caused by using the
> Gentoo default config, which assumes a Gentoo environment. So  it's fine
> on Gentoo. But it won't hurt to run glsa-check from time to time (my sync
> script does it every time and mails me if there's a problem).

Which file contains the purported malaised default configration?
I just want to manually inspect it and verify for myself.


curiously,
James

Re: [gentoo-user] Re: CoreOS vulnerability inherited from Gentoo?

[Max R.D. Parmer]

On Thu, Jun 2, 2016, at 06:44, James wrote:
> Neil Bothwick <neil <at> digimed.co.uk> writes:
> 
> 
> > > Does this mean we need to do anything to improve the security of our
> > > systems?
> 
> > The report seems to be saying that the problem is caused by using the
> > Gentoo default config, which assumes a Gentoo environment. So  it's fine
> > on Gentoo. But it won't hurt to run glsa-check from time to time (my sync
> > script does it every time and mails me if there's a problem).
> 
> Which file contains the purported malaised default configration?
> I just want to manually inspect it and verify for myself.

/etc/pam.d/system-auth which is provided by pambase:
https://gitweb.gentoo.org/proj/pambase.git/

[gentoo-user] Re: CoreOS vulnerability inherited from Gentoo?

[James]

Max R.D. Parmer <maxp <at> trystero.is> writes:


> > Which file contains the purported malaised default configration?
> > I just want to manually inspect it and verify for myself.

> /etc/pam.d/system-auth which is provided by pambase:
> https://gitweb.gentoo.org/proj/pambase.git/


Huh. I looked at that and concluded it could not possibly be the problem.

I went a bit deeper at coreOS and found that they are using 

pambase-20101024 from 2010. Double_huh. I had heard they were behind
on updating may ebuilds, but that is ridiculous.  Here are the details
should anyone be interested::

https://github.com/coreos/coreos-overlay/commit/
048faeb3b1b1a693dec3bdb47b127b8d71c48c13

I (previously) had high regards for CoreOS, but not keeping things current
is usually the largest source of problems and sploits, imho.


thx,
James