dstzd has quit [Read error: Connection reset by peer]
dstzd has joined #nixos-security
dstzd has quit [Client Quit]
dstzd has joined #nixos-security
blitzclone[m] has joined #nixos-security
thefloweringash has joined #nixos-security
colemickens has joined #nixos-security
danielrf[m] has joined #nixos-security
Ox4A6F has joined #nixos-security
Yakulu[m] has joined #nixos-security
bbigras has joined #nixos-security
aanderse has joined #nixos-security
FRidh has quit [Ping timeout: 240 seconds]
FRidh has joined #nixos-security
FRidh has quit [Ping timeout: 268 seconds]
FRidh has joined #nixos-security
tilpner has quit [Quit: tilpner]
tilpner has joined #nixos-security
ehmry_ has joined #nixos-security
ehmry_ is now known as ehmry
FRidh has quit [Ping timeout: 256 seconds]
FRidh has joined #nixos-security
FRidh has quit [Ping timeout: 260 seconds]
FRidh has joined #nixos-security
red[evilred] has joined #nixos-security
<red[evilred]>
So - looking at the glibc vuln that's in the issues list.
<red[evilred]>
Cherry-picking the next glibc version breaks a whole lot of stuff so we don't want to do that
<red[evilred]>
so looking at the situation - we can add the three patches to glibc to fix & test it
<red[evilred]>
but in examining the patches, I noticed that this affects arm7 only
<hexa->
name the CVE to make this more concrete
<red[evilred]>
CVE-2020-6096
<red[evilred]>
So, the question really becomes.
<hexa->
> An exploitable signed comparison vulnerability exists in the ARMv7 memcpy() implementation of GNU glibc 2.30.9000. Calling memcpy() (on ARMv7 targets that utilize the GNU glibc implementation) with a negative value for the 'num' parameter results in a signed comparison vulnerability. If an attacker underflows the 'num' parameter to memcpy(), this vulnerability could lead to undefined
<{^_^}>
error: syntax error, unexpected IN, expecting ')', at (string):434:55
<hexa->
behavior such as writing to out-of-bounds memory and potentially remote code execution. Furthermore, this memcpy() implementation allows for program execution to continue in scenarios where a segmentation fault or crash should have occurred. The dangers occur in that subsequent execution and iterations of this code will be executed with this corrupted data.
<red[evilred]>
There certainly is a risk (probably low) to include these patches in the glibc package
<hexa->
pretty sure that memcpy is used quite often and that cases exist where user supplied input might be mixed in
<hexa->
fwiw: you could try to add the patches for armv7 only
<red[evilred]>
the question is - how do we balance a vuln against arm7 (afaik, no PoC - but potentially serious) against the potential of breaking more archs on stable?
<hexa->
do you have any indication it would break other archs?
<red[evilred]>
Other than my lack of confidence in my ability to not screw it up - no :-)
<red[evilred]>
being nervous around glibc isn't a bad thing
<hexa->
so let's just trust them not to screw this up
<hexa->
well, start being worried when the patch doesn't apply cleanly and you have to mangle it
<red[evilred]>
Okay - so I can trust you to review this for me then? :-)
<hexa->
well, we can't really
<andi->
make sure to target staging
<hexa->
glibc is a mass rebuild
<red[evilred]>
staging-20.09
<hexa->
master is not affected?
<andi->
staging, then staging-20.09, then staging-20.03
<andi->
If you open that PR ping me and I'll start a nixos test jobset on my hydra
<hexa->
andi-++
<{^_^}>
andi-'s karma got increased to 45
<red[evilred]>
thanks andi
<red[evilred]>
I just want to tread really carefully here
<gchristensen>
I wouldn't apply it to staging-20.03 tbh
<gchristensen>
and just go right for release-20.03
<gchristensen>
almost no chance a staging merge for 20.03 will happen
<andi->
we can do that?
<red[evilred]>
rgr
<hexa->
yeah, the last time I applied a patch for staging-20.03 it was the only one
<gchristensen>
I mean we could
<gchristensen>
we could do it, yes
<hexa->
it was openldap
<andi->
I've done that in the past.. Just stage them in the staging branch in case other important (smaller) fixes come out in the mean time.
<gchristensen>
but we'll need to stay on it to make sure it merges
<red[evilred]>
only 4 days to go before that door slams shut
<red[evilred]>
I will confess I am surprised by one decision that the glibc maintainers made
<red[evilred]>
7b5f02dc2a
<red[evilred]>
They started by writing a test for the CVE
<red[evilred]>
fixed it
<red[evilred]>
then removed the test
<red[evilred]>
I guess I don't understand why you'd remove it
<red[evilred]>
Okay - got the patches in place
<red[evilred]>
question: do I make them arm7 specific?
<red[evilred]>
what is the norm ?
<andi->
if possible always apply patches everywhere
<andi->
that avoid silent "bit rod" of patches for arches we seldomly build
<andi->
e.g. if you have a package that has darwin patches (that also work on linux) just include them as it makes it less likely for them to silenty break.
<red[evilred]>
Okay - coolio
<red[evilred]>
there are some patches in there already which are optional based on host and build platforms
<red[evilred]>
but they both seem functional as opposed to security-based
<red[evilred]>
and the files the patches touch are both assembly so ...
<red[evilred]>
do I still bump the glibc rev? If so - what's our format for version?
<red[evilred]>
2.31-1
<red[evilred]>
?
<hexa->
no, we don't do downstream versions
<red[evilred]>
do don't bump the version
<red[evilred]>
?
<andi->
there is no point in doing that
<andi->
we already have the hash of a derivation
<hexa->
red[evilred]: other distros do that so their version comparison detects a newer version
<red[evilred]>
k, thx
<andi->
usually other distributions just do that to trigger an update of package
<red[evilred]>
ahhh
<red[evilred]>
I wonder if it would be useful to have a metadata field that listed CVEs that we've patched
<red[evilred]>
(I know - not another metadata field) ;-)
<andi->
It will never be a complete list of fixed issues
<andi->
You wont go back and add CVEs that were implicitly fixed by some version upgrade.
<andi->
Also the CVE might not be completly fixed
<red[evilred]>
yeah - you're right
<red[evilred]>
so andi- (IRC) - you want my branch that I push right? you don't want me to open a PR yet right?
<andi->
Just open a PR against staging and link it
<red[evilred]>
okay - incoming
<andi->
that will serve as sign for others that someone is working on it.
<red[evilred]>
the PR title format? glibc: update 2.31 -> 2.31 patches cve-2020-6096
<andi->
sounds good enough
<hexa->
no version bump
<hexa->
2.31 -> 2.31 = noop
<andi->
ah right yes
<red[evilred]>
so
<red[evilred]>
glibc: patch cve-2020-6096
<red[evilred]>
?
<hexa->
also the update is misplaced either way
<hexa->
CVE, but yes
<andi->
yes
<andi->
and please ensure that this also matches the commit message
<red[evilred]>
I'm in the commit message now - hence the question :-)
<red[evilred]>
perfect
<hexa->
also I usually like to add
<hexa->
Fixes: CVE-2020-6096
<red[evilred]>
that works
<red[evilred]>
btw - the reason I asked about the 2.31-1 is because of this: #100813