[gentoo-user] Dirty COW bug

[gentoo-user] Dirty COW bug

[Mick]

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

https://github.com/dirtycow/dirtycow.github.io/wiki/VulnerabilityDetails

Are we patched?  I'm running 4.4.21-gentoo


-- 
Regards,
Mick

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

Re: [gentoo-user] Dirty COW bug

[Rich Freeman]

On Fri, Oct 21, 2016 at 10:49 AM, Mick <michaelkintzios@gmail.com> wrote:
> https://github.com/dirtycow/dirtycow.github.io/wiki/VulnerabilityDetails
>
> Are we patched?  I'm running 4.4.21-gentoo
>

Not yet:
https://bugs.gentoo.org/show_bug.cgi?id=597624

You're probably going to want to update to 4.4.26.  It has been
released, though it doesn't look like it is packaged in Gentoo yet.
I've been running upstream's git for a while (currently on 4.4.26).

-- 
Rich

Re: [gentoo-user] Dirty COW bug

[Andy Mender]

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

On 21 October 2016 at 17:04, Rich Freeman <rich0@gentoo.org> wrote:

> On Fri, Oct 21, 2016 at 10:49 AM, Mick <michaelkintzios@gmail.com> wrote:
> > https://github.com/dirtycow/dirtycow.github.io/wiki/VulnerabilityDetails
> >
> > Are we patched?  I'm running 4.4.21-gentoo
> >
>
> Not yet:
> https://bugs.gentoo.org/show_bug.cgi?id=597624
>
> You're probably going to want to update to 4.4.26.  It has been
> released, though it doesn't look like it is packaged in Gentoo yet.
> I've been running upstream's git for a while (currently on 4.4.26).
>
> --
> Rich
>
> Would a Gentoo .config work with the upstream "vanilla" 4.4.26 kernel?
I know Gentoo does some patching to the upstream sources and menuconfig has
 additional features thereby.

~ Andy

[-- Attachment #2: Type: text/html, Size: 1569 bytes --]

Re: [gentoo-user] Dirty COW bug

[Alexander Kapshuk]

On Fri, Oct 21, 2016 at 6:42 PM, Andy Mender <andymenderunix@gmail.com> wrote:
> On 21 October 2016 at 17:04, Rich Freeman <rich0@gentoo.org> wrote:
>>
>> On Fri, Oct 21, 2016 at 10:49 AM, Mick <michaelkintzios@gmail.com> wrote:
>> > https://github.com/dirtycow/dirtycow.github.io/wiki/VulnerabilityDetails
>> >
>> > Are we patched?  I'm running 4.4.21-gentoo
>> >
>>
>> Not yet:
>> https://bugs.gentoo.org/show_bug.cgi?id=597624
>>
>> You're probably going to want to update to 4.4.26.  It has been
>> released, though it doesn't look like it is packaged in Gentoo yet.
>> I've been running upstream's git for a while (currently on 4.4.26).
>>
>> --
>> Rich
>>
> Would a Gentoo .config work with the upstream "vanilla" 4.4.26 kernel?
> I know Gentoo does some patching to the upstream sources and menuconfig has
>  additional features thereby.
>
> ~ Andy

Running 'make oldconfig' within the sources directory by default uses
whatever config-x.y.z is the highest version available in /boot.
Otherwise, copying the config file desired to the sources directory
followed by running 'make oldconfig' will generate a new one based on
the config file copied.
You could than run the diff on the gentoo config file and the vanilla
one and take it from there.

Re: [gentoo-user] Dirty COW bug

[Rich Freeman]

On Fri, Oct 21, 2016 at 12:22 PM, Alexander Kapshuk
<alexander.kapshuk@gmail.com> wrote:
> On Fri, Oct 21, 2016 at 6:42 PM, Andy Mender <andymenderunix@gmail.com> wrote:
>
>> Would a Gentoo .config work with the upstream "vanilla" 4.4.26 kernel?
>> I know Gentoo does some patching to the upstream sources and menuconfig has
>>  additional features thereby.
>
> Running 'make oldconfig' within the sources directory by default uses
> whatever config-x.y.z is the highest version available in /boot.
> Otherwise, copying the config file desired to the sources directory
> followed by running 'make oldconfig' will generate a new one based on
> the config file copied.
> You could than run the diff on the gentoo config file and the vanilla
> one and take it from there.

Correct.  I'm pretty confident (having done this a bunch of times)
that it is just going to drop any config items it doesn't recognize
including the Gentoo ones (removal of config items is normal anyway).
Since the Gentoo ones just pull in other pre-reqs, and the way the
config file works is that the pre-reqs also get written into the
config file, you'll still have all the settings that actually matter.
For example, systemd support probably turns on multiple pts support,
and even if you get rid of the gentoo systemd option the multiple pts
support option will remain selected.

So, if you're staying in the same kernel series (4.4) you should just
be able to run make oldconfig and that's it.  You can take a look but
I'd be shocked if you're either prompted for any new settings or if
anything doesn't work exactly as before.  You might just be missing a
random patch or two (gentoo-sources doesn't have that many of them).

Going between kernel series is going to be the same as always, you'll
be asked a dozen questions for new options.

Now, the one thing you'll lose without the Gentoo options is that if
an openrc/systemd/udev/whatever requirement changes it won't just
automatically get pulled in.  You'll need to find out about it and
manually update your config.  Honestly, I think that option wouldn't
be a bad one to merge upstream, though it obviously does cross the
userspace/kernelspace boundary.  Also, having end-users manipulate
kernel config options is something very few distros do these days, I'm
not sure if any of the well-known distros encourage it.

-- 
Rich

Re: [gentoo-user] Dirty COW bug

[Mick]

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

On Friday 21 Oct 2016 13:39:54 Rich Freeman wrote:
> On Fri, Oct 21, 2016 at 12:22 PM, Alexander Kapshuk
> 
> <alexander.kapshuk@gmail.com> wrote:
> > On Fri, Oct 21, 2016 at 6:42 PM, Andy Mender <andymenderunix@gmail.com> 
wrote:
> >> Would a Gentoo .config work with the upstream "vanilla" 4.4.26 kernel?
> >> I know Gentoo does some patching to the upstream sources and menuconfig
> >> has
> >> 
> >>  additional features thereby.
> > 
> > Running 'make oldconfig' within the sources directory by default uses
> > whatever config-x.y.z is the highest version available in /boot.
> > Otherwise, copying the config file desired to the sources directory
> > followed by running 'make oldconfig' will generate a new one based on
> > the config file copied.
> > You could than run the diff on the gentoo config file and the vanilla
> > one and take it from there.
> 
> Correct.  I'm pretty confident (having done this a bunch of times)
> that it is just going to drop any config items it doesn't recognize
> including the Gentoo ones (removal of config items is normal anyway).
> Since the Gentoo ones just pull in other pre-reqs, and the way the
> config file works is that the pre-reqs also get written into the
> config file, you'll still have all the settings that actually matter.
> For example, systemd support probably turns on multiple pts support,
> and even if you get rid of the gentoo systemd option the multiple pts
> support option will remain selected.
> 
> So, if you're staying in the same kernel series (4.4) you should just
> be able to run make oldconfig and that's it.  You can take a look but
> I'd be shocked if you're either prompted for any new settings or if
> anything doesn't work exactly as before.  You might just be missing a
> random patch or two (gentoo-sources doesn't have that many of them).
> 
> Going between kernel series is going to be the same as always, you'll
> be asked a dozen questions for new options.
> 
> Now, the one thing you'll lose without the Gentoo options is that if
> an openrc/systemd/udev/whatever requirement changes it won't just
> automatically get pulled in.  You'll need to find out about it and
> manually update your config.  Honestly, I think that option wouldn't
> be a bad one to merge upstream, though it obviously does cross the
> userspace/kernelspace boundary.  Also, having end-users manipulate
> kernel config options is something very few distros do these days, I'm
> not sure if any of the well-known distros encourage it.

I haven't looked into exploits for this.  At a practical level, what will it 
take to compromise a PC? 

-- 
Regards,
Mick

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

Re: [gentoo-user] Dirty COW bug

[Rich Freeman]

On Fri, Oct 21, 2016 at 2:02 PM, Mick <michaelkintzios@gmail.com> wrote:
>
> I haven't looked into exploits for this.  At a practical level, what will it
> take to compromise a PC?
>

You need to be able to run arbitrary code as a non-privileged user
that has read-access to a file whose modification would allow
elevation of privileges, on a read-write mounted filesystem.

For example, somebody with shell access to your system could edit a
SUID binary to obtain a root shell.  Or they could edit any number of
config files in /etc to cause code to be run as root, and so on.

In general it is pretty easy to exploit in any multi-user scenario.
It is a privilege escalation vulnerability, so somebody needs to
already be running non-privileged code on your host.  On some more
"exotic" configurations like android where all the suid and
configuration stuff is mounted read-only and even read access tends to
be limited cross-user the opportunity for attacks is much smaller.

I'm not sure how hardening like SELinux interacts with this.  I'm not
sure if it would prevent modification of the files.  It could limit
some of the impact of execution of those files, since you'd probably
be running as root in a more limited security context.  I suspect that
containers wouldn't help a great deal, since you could get root inside
the container, and if you have root inside the container then you can
probably get whatever user that is equivalent to outside the
container, and if that isn't root on the host you could use the same
attack to obtain root on the host.

Note, I'm not an expert on such matters, but this is probably not far
off the mark.

-- 
Rich

Re: [gentoo-user] Dirty COW bug

[Nils Freydank]

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

On Fri, Oct 21, 2016 at 13:39:54 CEST wrote Rich Freeman:
> On Fri, Oct 21, 2016 at 12:22 PM, Alexander Kapshuk
> [...]
> 
> So, if you're staying in the same kernel series (4.4) you should just
> be able to run make oldconfig and that's it.  You can take a look but
> I'd be shocked if you're either prompted for any new settings or if
> anything doesn't work exactly as before.  You might just be missing a
> random patch or two (gentoo-sources doesn't have that many of them).
> 
> Going between kernel series is going to be the same as always, you'll
> be asked a dozen questions for new options.
> 
> Now, the one thing you'll lose without the Gentoo options is that if
> an openrc/systemd/udev/whatever requirement changes it won't just
> automatically get pulled in.  You'll need to find out about it and
> manually update your config. 
Regarding this matter I’d like to share my usage here, hoping it would help to 
avoid the missing-config-entries issue (in short: I patch vanilla upstream 
myself):

I run vanilla upstream kernels and just pick the patches from genpatches/
gentoo-sources I think I need. Currently mine are:
 1500_XATTR_USER_PREFIX.patch
 1510_fs-enable-link-security-restrictions-by-default.patch
 2900_dev-root-proc-mount-fix.patch
 4567_distro-Gentoo-Kconfig.patch
 5010_enable-additional-cpu-optimizations-for-gcc.patch

My workflow for kernel upgrades there for is
- downloading the kernel, checking with GPG signatures
- extraction to /usr/src/
- patching the new kernel
- copy the old .config
- run make nconfig, maybe change something if needed, save and quit
- run make and install the rest as usual (maybe create initramfs and other 
things)

Or in short: "cd /usr/src/<fancy-new-kernel>/ && patch -p1 < ../patches/
patches-<kernel-major>/* && cp ../usr/src/<last-used-kernel>/.config .config && 
make nconfig"

That way I have full control over the patches I use and can use *my* config 
from minor release to minor release without running into any trouble.

Maybe I`ll put that stuff into an ebuild…someday.. :P
> [...]

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

Re: [gentoo-user] Dirty COW bug

[J. Roeleveld]

On Friday, October 21, 2016 11:04:19 AM Rich Freeman wrote:
> On Fri, Oct 21, 2016 at 10:49 AM, Mick <michaelkintzios@gmail.com> wrote:
> > https://github.com/dirtycow/dirtycow.github.io/wiki/VulnerabilityDetails
> > 
> > Are we patched?  I'm running 4.4.21-gentoo
> 
> Not yet:
> https://bugs.gentoo.org/show_bug.cgi?id=597624
> 
> You're probably going to want to update to 4.4.26.  It has been
> released, though it doesn't look like it is packaged in Gentoo yet.
> I've been running upstream's git for a while (currently on 4.4.26).

4.4.26 is in the tree. You just need to unmask (~amd64/...)  it.
Both as gentoo-sources and as vanilla-sources.

--
Joost

Re: [gentoo-user] Dirty COW bug

[Rich Freeman]

On Sat, Oct 22, 2016 at 4:04 AM, J. Roeleveld <joost@antarean.org> wrote:
> On Friday, October 21, 2016 11:04:19 AM Rich Freeman wrote:
>> On Fri, Oct 21, 2016 at 10:49 AM, Mick <michaelkintzios@gmail.com> wrote:
>> > https://github.com/dirtycow/dirtycow.github.io/wiki/VulnerabilityDetails
>> >
>> > Are we patched?  I'm running 4.4.21-gentoo
>>
>> Not yet:
>> https://bugs.gentoo.org/show_bug.cgi?id=597624
>>
>> You're probably going to want to update to 4.4.26.  It has been
>> released, though it doesn't look like it is packaged in Gentoo yet.
>> I've been running upstream's git for a while (currently on 4.4.26).
>
> 4.4.26 is in the tree. You just need to unmask (~amd64/...)  it.
> Both as gentoo-sources and as vanilla-sources.
>

It is marked stable now on amd64/x86.  I imagine that all archs that
the bug applies to will follow quickly.

And upstream just released 4.4.27.  I'd have to check the history but
this feels like 4 kernel updates in about a week.

-- 
Rich