=== chris14_ is now known as chris14 [04:58] morning [06:08] Hello, I have a question related to apparmor. So basically I have a k8s pod that has a host mount to /etc/apparmor.d , and that pod is responsible for generating and enforcing profiles using "apparmor_parser" from within, and then it gets enforced on the host. But for some reason the profile seems to block pods that tries to access the K8s API. [06:08] even though all network is allowed in the profile [06:08] type=AVC msg=audit(1713956546.682:24729): apparmor="DENIED" operation="create" profile="kubearmor-default" pid=41265 comm="kubearmor" family="inet" sock_type="stream" protocol=0 requested_mask="create" denied_mask="create" [06:10] to fix this, I again have to run "apparmor_parser" on the host instead of inside that pod, and now it works as it should. [07:02] https://ubuntu.com//blog/whats-new-in-security-for-ubuntu-24-04-lts - thanks for this post, amurray . Is the unprivileged namespace hardening the reason why I can't run docker in a nesting-enabled lxc or lxd container using the noble nightlies? Is there a way around that, if that's the case? [19:40] mdeslaur: sarnold: because it came up on Ask Ubuntu (https://askubuntu.com/questions/1511606/pci-audit-openssh-authentication-bypass-vulnerability-cve-2023-51767), I'm poking regarding CVE-2023-51767. Is only openssh-ssh1 affected? Or are all openssh servers (and yes it's possible to enforce newer SSH versions if I remember right!) impacted? The question came up because of PCI/DSS compliance. [19:40] -ubottu:#ubuntu-security- OpenSSH through 9.6, when common types of DRAM are used, might allow row hammer attacks (for authentication bypass) because the integer value of authenticated in mm_answer_authpassword does not resist flips of a single bit. NOTE: this is applicable to a certain threat model of attacker-victim co-location in which the attacker has user privileges. [19:59] mdeslaur: could we also annotate the bug with https://bugzilla.mindrot.org/show_bug.cgi?id=3656 which states this: "This attack was not demonstrated against stock OpenSSH, but instead against a modified sshd that had extra synchronisation added to make the attack easier. AFAIK achieving the timing required to successfully exploit is close to impossible in the real world. See section 9 of their paper [19:59] https://arxiv.org/pdf/2309.02545.pdf They don't mention it, but any kind of ASLR would increase the difficulty of attack by several orders of magnitude. Nobody has demonstrated this attack against a configuration remotely approximating real-world conditions. We consider rowhammer mitigation to the job of the platform, not userspace software." [19:59] -ubottu:#ubuntu-security- bugzilla.mindrot.org bug 3656 in Portable OpenSSH "How to fix row hammer attacks？" [Security, New] [19:59] s/annotate the bug/annotate the CVE/ [20:00] because it looks like the paper on this exploit is not possible in Real World Implementations [20:04] so basically this is only relevant if you still use Ubuntu from before 2005? [20:05] JanC: from what i'm reading even latest OpenSSH in 24.04 is impacted, but upon additional diving into the linked CVE and its papers on arxiv and other documentation, it requires very specific circumstances to happen [20:06] and by very specific I mean modified sshd and a configuration that wouldn't be sane in the real world [20:10] and when people change their sshd that's not Ubuntu's responsibility [20:11] correct [20:11] also, I'd expect this to be mostly a problem on servers, but those would use ECC in most cases... [20:12] the core problem however is PCI/DSS compliance scans are stupid and don't take into account when these CVEs have very VERY specific *theoretical only* cases of exploit [20:12] hence the only reason i'm poking xD [20:12] and I think ECC would prevent this exploit too? [20:14] or at least make it much harder too [20:14] yeah that's the point any kind of implementation of ASLR makes it difficult, and Linux has had that since 2005 so [20:15] it makes it several orders of magnitude more difficult, and there's no real-world conditions approximated config nor stock OpenSSH confirmed affected by this, especially when we dig into the paper [20:15] this CVE probably should've been marked as an experimental or theory-only case and not a CVCSS 7.0 IMO [20:18] the paper specifically calls out that ECC isn't a good defense: `in 2019 showed that the ECC countermeasure is not secure either` [20:20] it might not be a full defence, but if your system suddenly gets a million ECC errors that would probably make the admins suspicious? :) [20:27] JanC: yeah that's also my understanding, I just wanted to mention that's no silver bullet unfortunately. HW is hard (too) it seems :) [20:53] sdeziel: we also have to keep in mind that there's a lot of mitigations that just *naturally* work and sane defaults tend to mitigate the risk by orders of magnitude [20:54] so default kernel ASLR and such, sane configis for a real-world setup, etc. seem to be the proper mitigations, and nobody's proposed or shown a *real world* usable exploit that isn't a shared-neighbor type local-only attack vector with user creds [20:58] teward: I didn't read the paper but a quick look at it showed it talks about password auth which is indeed not a sane config [20:58] yeah i glanced it [21:06] teward: sure, I'll add the upstream bug to it tomorrow [21:07] mdeslaur: thank you kindly [21:07] btw, pretty much everything is vulnerable to rowhammer issues and there's nothing we can do about it except stop using computers [21:07] every year someone comes out with a new practical attack [21:07] mdeslaur: true. the problem is PCI/DSS compliance checks flag that as a problem [21:07] that isn't my problem :) [21:07] despite veryone KNOWING rowhammer is still a vulnerability [21:07] nope [21:08] I will add more details to the CVE tomorrow, I'll take another look at it [21:08] but as long as we annotate the bug with notes, etc. so people can JUSTIFY why it can't be fixed (there is no solution for rowhammer attacks!) things're better [21:08] cool cool mdeslaur thanks,