andi- changed the topic of #nixos-security to: Vulnerability Roundup Issues: + | Currently supported releases: unstable (master), 20.09, 20.03 (until 27th of November)
rajivr has joined #nixos-security
ris has quit [Ping timeout: 240 seconds]
justan0theruser has joined #nixos-security
justanotheruser has quit [Ping timeout: 272 seconds]
star_cloud has quit [Remote host closed the connection]
MichaelRaskin has quit [Quit: MichaelRaskin]
FRidh has joined #nixos-security
star_cloud has joined #nixos-security
star_cloud has quit [Remote host closed the connection]
star_cloud has joined #nixos-security
star_cloud has quit [Remote host closed the connection]
star_cloud has joined #nixos-security
FRidh has quit [Ping timeout: 240 seconds]
FRidh has joined #nixos-security
star_cloud has quit [Remote host closed the connection]
star_cloud has joined #nixos-security
sphalerite has quit [Quit: reboot time!]
sphalerite has joined #nixos-security
star_cloud has quit [Remote host closed the connection]
star_cloud has joined #nixos-security
Ox4A6F has quit [Quit: Bridge terminating on SIGTERM]
aanderse has quit [Quit: Bridge terminating on SIGTERM]
bbigras has quit [Quit: Bridge terminating on SIGTERM]
thefloweringash has quit [Quit: Bridge terminating on SIGTERM]
Yakulu[m] has quit [Quit: Bridge terminating on SIGTERM]
colemickens has quit [Quit: Bridge terminating on SIGTERM]
danielrf[m] has quit [Quit: Bridge terminating on SIGTERM]
blitzclone[m] has quit [Quit: Bridge terminating on SIGTERM]
dstzd has quit [Quit: ZNC -]
dstzd has joined #nixos-security
JJJollyjim has joined #nixos-security
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]> but I also have no way to test it
<red[evilred]> so ...
<hexa-> the patch is from the glibc upstream?
<red[evilred]> yes
<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
<{^_^}> (by vcunat, 5 weeks ago, open): glibc: 2.32 -> 2.32-10
<red[evilred]> by vcunat
<hexa-> glibc-2.32-10-g0b9460d22e
<red[evilred]> who pointed me at his for me to copy
<red[evilred]> Oh - nm then
<hexa-> that's glibc-2.32 + 10 commits
<red[evilred]> that'll learn me
<red[evilred]> :-)
<hexa-> git describe :)
<red[evilred]> ahhh
<red[evilred]> another new command.
<hexa-> so still some semblance of upstream versioning
<red[evilred]> I swear to $deity - if I could shadow someone for a day I'd learn more in that day than I have in the last 4 years
<andi-> Especially since we have to create matching patch files whenever we touch that
<red[evilred]> andi- (IRC): #104685
<{^_^}> (by redvers, 22 seconds ago, open): Update glibc 2.31 cve 2020 6096
<red[evilred]> WTF
<red[evilred]> ignore that - something's wrong
<red[evilred]> I apparently gained some other patches from other people
<red[evilred]> trying to work out why
<red[evilred]> okay got it
<red[evilred]> sorry about that
<andi-> you are targeting the wrong branch
<andi-> those commits are already in staging-20.09 but your PR is against release-20.09
<andi-> red[evilred]: first line of the commit message should be more like: glibc: fix CVE-2020-6096
<andi-> second line: This fixes CVE-2020-6096 by including patches A and B from upstream.
<andi-> a & B schound point to the upstream repo
<red[evilred]> k, thx
<hexa-> maybe the best of both worlds :)
<hexa-> CVE-2020-13584 … arbitrary code execution due to use after free in webkitgtk <3
FRidh has quit [Ping timeout: 240 seconds]
<andi-> as usual most of those that were released today were fixed by apple two weeks ago :/
<andi-> I really do not like using webkitgtk as long as that trend continues
<andi-> "just" look at safari updates to see what will come up on webkit 2 weeks later
<hexa-> yep
<hexa-> I'll do the thing
<red[evilred]> hexa- (IRC): How does that commit message look now?
* red[evilred] finally puts hexa and mweinelt together in his mind.
<red[evilred]> I'm glad I've done nothing but said nice things about the reviews that I've gotten over time :-)
<hexa-> I would gladly use hexa on github, but alas its taken
<red[evilred]> yeah... I don't doubt it
rajivr has quit [Quit: Connection closed for inactivity]
<red[evilred]> My name full first name is my github id and is fairly unique
<red[evilred]> but I go by "red" everywhere
<red[evilred]> so ... that's usually taken
justan0theruser has quit [Ping timeout: 260 seconds]
<andi-> vim has been built on that branch, ship it! :D
justan0theruser has joined #nixos-security
<hexa-> ship it till it breaks!
FRidh has joined #nixos-security
<hexa-> hah, downstream patches <3
<hexa-> James Henstridge discovered that an Ubuntu-specific patch caused
<hexa-> PulseAudio to incorrectly handle snap client connections. An attacker
<hexa-> could possibly use this to expose sensitive information.
<hexa-> </USN-4260-1>
ris has joined #nixos-security
{^_^} has quit [Excess Flood]
{^_^} has joined #nixos-security
FRidh has quit [Quit: Konversation terminated!]
<hexa-> #104692
<{^_^}> (by mweinelt, 3 hours ago, open): webkitgtk: 2.30.2 -> 2.30.3
* andi- thinks about pipewire downstream patches...
* flokli hides
justan0theruser has quit [Ping timeout: 264 seconds]
justan0theruser has joined #nixos-security