<ekleog> tbh it'd be great if we managed to have a bsd-nixos
<ekleog> would exercise lots of stuff and likely discover hidden assumptions
<ekleog> but it won't happen with systemd
<gchristensen> that assumes nixos's "hidden assumptions" are a bad thing
<pie_> im just getting real tired of this shit. can you be jaded at 23?
<gchristensen> yes
<gchristensen> security work is jading
<pie_> my complaining isnt even fair because 1) its not helping 2) i dont have the software engineering experience to shit on other peoples work
<gchristensen> 3) brilliant people write security-buggy softwr
<pie_> but its the same old problems again and again (disclaimer: have not read vuln report)
<pie_> (i bet its C related memory corruption though?)
<gchristensen> that reveals it is a systemic problem,
<pie_> and so i scream use better languages / constructs into the air, without substance
<pie_> why has the haskell ecosystem not gotten more engineering investment before rust became a thing
<pie_> inb4 noone cares
<pie_> man if i was drunk id at least have an excuse
<pie_> for appropriate value of "noone"
<gchristensen> failure at all costs
<pie_> alternatively im preaching to the choir but
<pie_> > cycle "a"
<{^_^}> undefined variable 'cycle' at (string):215:1
<pie_> I scream into the void.
<gchristensen> lol
<ekleog> pie_: this case isn't C-specific
<ekleog> it's another instance of stack clash, ie. jumping the guard page of the stack by a big alloca to write into the head
<ekleog> heap*
<pie_> alternatively: all you hear these days is systemd vuln this systemd vuln that
<gchristensen> ekleog: would rust have avoided this?
<ekleog> no
<gchristensen> no way, pie_
<pie_> ekleog, i thought that was a solved problem?
<gchristensen> there havebeen a zillion CVEs issued between every systemd one
<gchristensen> everything is broken
erictapen has quit [Ping timeout: 244 seconds]
<pie_> gchristensen, ok fine your right, its just *another* systemd vuln, but systemd is big, so its just a big umbrella over a bunch of stuff
<ekleog> well… technically stable rust would have avoided this, I think, but only because it doesn't support big allocas yet (IIRC)
<ekleog> it's an architectural vuln
<gchristensen> ah
<pie_> reinforcement learning: keep hearing systemd vuln being repeated
<gchristensen> systemd haters amplify systemd vulns
<pie_> guilty as charged i guess
<ekleog> somedays I wonder why the stack isn't placed *below* the heap, then in the absence of memory vulnerability and of overflows there wouldn't be any way of saving stuff
<pie_> its a meme
<ekleog> gchristensen: systemd is the source of most of the CVEs I have to patch on my server, I think
<gchristensen> systemd has incredible features to make software more secure by default
<pie_> so, how could this vuln have been avoided with foresight?
<ekleog> (or at least most of those I'm aware of)
<gchristensen> 00:26 <gchristensen> systemd haters amplify systemd vulns
<ekleog> on desktop firefox clearly wins
<gchristensen> also, systemd is a widely researched target
<ekleog> well, I'm following oss-security, so it's not only not hearing about other ones
<pie_> theo de raadt seems pretty caustic but he is very against additional attack surface and doesnt seem very wrong about it...though isolation features certanly are convenient
<ekleog> it totally is, that's why I'm speaking in terms of source of CVEs I have to patch and not in terms of currently opened vulns
<gchristensen> or unknown vulns
<ekleog> I included unknown vulns in “currently opened vulns”, sorry if it wasn't clear (let's say I quite hope known vulns have a CVE and are announced on oss-sec, as I run only oss stuff on my server)
<ekleog> oh wait maybe the linux kernel competes with systemd actually
<pie_> ok id love to stay and have an honest chat but i need to force myself to sleep, ive managed to sleep properly for two days. maybe thisll help someone else feel better about the above too :P https://www.youtube.com/watch?v=c7VlkvW0Lio
<pie_> i was serious about the foresight question though, im all about categorically fixing things
<gchristensen> I don't know what large allocations really means, so I have no idea
<ekleog> stack clash is basically “actually segmentation was nice, paging is meh”
<ekleog> we'd need segregated address spaces to properly handle it
<ekleog> but we don't have usable segregated address spaces since quite long, so the only solution is to probe everywhere, hence that gcc flag
<ekleog> s/since/for/
<pie_> ekleog, does riscv
LnL has quit [Ping timeout: 268 seconds]
<ekleog> “large allocations” is basically “enough to jump from a stack address to a heap address”, which is something like from 0xc94d033c to 0x018f4260 on a quick test with `int main() { int a; printf("%016x %016x\n", &a, malloc(1)); }`
<ekleog> -> about 3G on this test
<ekleog> pie_: apparently RISC-V “provides simplified segmentation where just a single base address and limit are specified for the memory accessible to the application” (source https://courses.cs.washington.edu/courses/cse599w/16sp/projects/riscv.pdf ), so… maybe, idk
<gchristensen> how about Mill? :)
* ekleog too tired to read about a new arch
<ekleog> (btw, about the 3G on my test, there are ways to reduce the allocation, that's more of a higher bound than a lower bound, and the case I'm considering is the simplest one for stack clash)
tilpner has quit [Ping timeout: 250 seconds]
pie_ has quit [Remote host closed the connection]
pie_ has joined #nixos-security
labancle has joined #nixos-security
labancle has left #nixos-security ["ERC (IRC client for Emacs 25.2.2)"]
periklis has joined #nixos-security
__Sander__ has joined #nixos-security
__Sander__ has quit [Ping timeout: 258 seconds]
__Sander__ has joined #nixos-security
<zimbatm> looks like journald has a hole :)
<andi-> Yeah, was discussed yesterday evening :) (our timezone)
labancle has joined #nixos-security
erictapen has joined #nixos-security
periklis has quit [Ping timeout: 272 seconds]
periklis has joined #nixos-security
periklis has quit [Ping timeout: 240 seconds]
erictapen has quit [Ping timeout: 258 seconds]
LnL has joined #nixos-security
__Sander__ has quit [Ping timeout: 246 seconds]
__Sander__ has joined #nixos-security
pie_ has quit [Remote host closed the connection]
pie_ has joined #nixos-security
pietranera has joined #nixos-security
<pietranera> re https://www.qualys.com/2019/01/09/system-down/system-down.txt does NixOS build with hardening flags (e.g. -fstack-clash-protection)?
<gchristensen> I don't believe so, IIRC it didn't build with that option at some point and we weren't able to fix it then
<gchristensen> but, we could/should obviously yes do that
<pietranera> maybe they can be turned on incrementally? E.g. with systemd-* stuff?... or when you say "it didn't build with that option" you are actually referring to systemd-*?
<globin> fpletz is working on this
<globin> it needs gcc8
<pietranera> thanks for the pointers!
<gchristensen> fpletz++
<{^_^}> fpletz's karma got increased to 1
<gchristensen> :O
<pietranera> whooo...
<pietranera> gchristensen++
<{^_^}> gchristensen's karma got increased to 60
tilpner has joined #nixos-security
__Sander__ has quit [Quit: Konversation terminated!]
periklis has joined #nixos-security
pie_ has quit [Remote host closed the connection]
pie_ has joined #nixos-security
periklis has quit [Ping timeout: 258 seconds]
<fpletz> could somebody please verify that I modified the last commit on https://github.com/NixOS/systemd/commits/nixos-v239-security correctly so that is applies to our systemd 239?
<fpletz> specifically, I picked the relevant fixes for the CVEs from https://github.com/systemd/systemd/pull/11374
<{^_^}> systemd/systemd#11374 (by keszybz, 18 hours ago, merged): Journal/journal-remote/coredump fixes
<fpletz> andi-: have you got some time maybe? :)
<gchristensen> or aszlig
<fpletz> yeah! he isn't here though, I'll ping him
<gchristensen> fpletz: do you need a big fat nixos machine to work with?
<fpletz> that would be great :)
<gchristensen> fpletz: https://www.packet.com/cloud/servers/ pick your favorite
<fpletz> I'm right now compiling on our hardware but if you got a juicy packet.net box, it would be faster :>
<fpletz> hmm :)
<andi-> fpletz: on my way to a concert.. Earliest around 11pm or later
<gchristensen> the c2.medium.x86 is pretty nice -- turbos to 3.0ghz
<fpletz> hard to decide, but the epyc does indeed look nice
<fpletz> yeah, the c2.medium.x86 would be awesome
<fpletz> how long could we get that? I would use that for the gcc8 and hardening stuff, no more than a few days probably
<gchristensen> let's go to PM for some details
<fpletz> thanks!
Synthetica has joined #nixos-security
rain1 has joined #nixos-security
<fpletz> andi-: awesome :)
<fpletz> aszlig is also going to take a look
<pie_> ekleog, re riscv iiuc that means you have hardware a hardware enforced memory range?
<pie_> ekleog, that *sounds* sufficient
lassulus has joined #nixos-security
<ekleog> pie_: the issue is that one hardware-enforced memory range is not enough (otherwise regular pagination does it too)
<ekleog> you need a separate hardware-enforced memory range for at least the stack and the heap (and ideally one different per heap item but for that I know of no architecture that'd provide this)
<ekleog> and not just “here are two ranges you can access”, you'd need to have each memory access be “I want address X in the stack”
<pie_> ekleog, i mean i figured you could do that
<pie_> two memory ranges that is
<pie_> but ok im not very knoelwdgeable about this yet
<ekleog> I didn't understand that (hear: the “I want address X in stack” that would check X is actually in the stack)and not in the heap even if the heap is accessible too) as possible from the short read I did
<ekleog> but I may very well have missed the place where it's stated as possible :)
gchristensen is now known as c
c is now known as gchristensen
erictapen has joined #nixos-security
erictapen has quit [Ping timeout: 252 seconds]
<gchristensen> fpletz: whats the word?
tilpner has quit [Ping timeout: 268 seconds]
labancle has left #nixos-security ["ERC (IRC client for Emacs 25.2.2)"]