=== JanC is now known as Guest7641
=== JanC_ is now known as JanC
[12:42] <ahasenack> I have a systemd service unit that starts a process, oneshot (not a daemon). It's python, so it's called like "ExecStart=/usr/bin/python3 /usr/lib/foo/bar.py". How would I apparmor it? Perhaps use systemd's AppArmorProfile= setting? Otherwise, since it's not executing the python script directly, but via /usr/bin/python3 in the cmdline, what would the apparmor profile be called?
[12:43] <ahasenack> thinking about the autoattach feature on exec (if that's what it's called)
[12:43] <ahasenack> it can't be /usr/bin/python3, as that would confine all python apps, and it calso can't be just /usr/lib/foo/bar.py, as that's not the executable being called (it doesn't even have the +x bit)
[12:44] <ahasenack> or can it be just /usr/lib/foo/bar.py?
[12:59] <georgiag> ahasenack: you could use the not-path-based option "profile bar {}". make sure the profile is loaded, and in the systemd file reference it as "AppArmorProfile=bar"
[13:00] <ahasenack> right, it's what I'm testing now
[13:00] <ahasenack> but it won't attach the profile if someone calls it manually via python3 /usr/lib/foo/bar.py
[13:00] <ahasenack> right?
[13:00] <georgiag> correct, unfortunately
[13:00] <ahasenack> ok
[13:45] <appxprt> How is this not patched by latest updates? https://ubuntu.com/security/CVE-2023-32629 >
[13:45] -ubottu:#ubuntu-security- Local privilege escalation vulnerability in Ubuntu Kernels overlayfs ovl_copy_up_meta_inode_data skip permission checks when calling ovl_do_setxattr on Ubuntu kernels <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-32629>
[13:45] <appxprt> ?
[13:47] <appxprt> this simple shell script can lpe to root with full updates/pgrades: https://github.com/OllaPapito/gameoverlay
[13:48] <appxprt> is this patched in some other Ubuntu repo?
[13:48] <mdeslaur> appxprt: what release and which kernel are you running?
[13:48] <mdeslaur> appxprt: did you reboot after updating the kernel?
[13:49] <appxprt> oh wow, I thought I was on 23.04, but it's apparently 22.04.3 LTS 6.2.0-34-generic #34~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC
[13:49] <appxprt> rebooting real quick and will recheck
[13:49] <appxprt> brb
[13:53] <appxprt> still works, checking for further updates after reboot
[13:54] <appxprt> nothing
[13:54] <appxprt> still vulnerable
[13:54] <mdeslaur> let me check
[13:55] <appxprt> what is latest kernel for 23.04.3 and I thought there was .4 out?
[13:55] <appxprt> errr 22.04.3 LTS
[13:55] <appxprt> I thought there was 22.04.4 or 6 or something by now
[13:56] <appxprt> pretty sure I'm compromised
[13:57] <mdeslaur> doesn't work for me...while I appear to become root, I'm not, I'm just in a namespace
[13:57] <mdeslaur> try "cat /etc/shadow"
[13:58] <appxprt> ahhhh yea Permission denied, the id threw me off uid=0
[13:58] <appxprt> ok thanks, you rock
[13:58] <mdeslaur> cool, np!
[14:29] <teward> has the security team triaged/processed CVE-2023-44487 yet?  If not, mark nginx affected because as of the disclosure today/yesterday I'm seeing that nginx and *all* known HTTP/2 implementations are affected.  Except maybe CloudFlare's because they have done some stupid stuff behind the scenes
[14:29] -ubottu:#ubuntu-security- The HTTP/2 protocol allows a denial of service (server resource consumption) because request cancellation can reset many streams quickly, as exploited in the wild in August through October 2023. <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-44487>
[14:31] <teward> some information links to add to the tracker - https://www.nginx.com/blog/http-2-rapid-reset-attack-impacting-f5-nginx-products/ - https://blog.cloudflare.com/zero-day-rapid-reset-http2-record-breaking-ddos-attack/ - https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/ (the Cloudflare blog posts give a nice overview of the scope of how hard it was being exploited yesterday and a deep technical deep-dive)
[14:31] <teward> (and the nginx one is for the reference that nginx is affected
[14:31] <teward> eslerm: or mdeslaur if you're bored: ^
[14:31] <teward> (since nginx is in main)
[14:32] <teward> s/stupid stuff/undisclosed tweaks/
[14:35] <teward> also https://my.f5.com/manage/s/article/K000137106 to the tracker (security advisory from F5 who owns nginx now)
[15:17] <teward> also, can you update https://ubuntu.com/security/CVE-2017-6519 for upstream to indicate Upstream fixed this with Avahi version 0.8?  (see https://github.com/lathiat/avahi/releases/tag/v0.8) So that the one or two users confused by things on Ask Ubuntu can have a better understanding of things.
[15:17] -ubottu:#ubuntu-security- avahi-daemon in Avahi through 0.6.32 and 0.7 inadvertently responds to IPv6 unicast queries with source addresses that are not on-link, which allows remote attackers to cause a denial of service (traffic amplification) and may cause information leakage by obtaining potentially sensitive information from the responding device via port-5353 UDP packets. NOTE: this may... <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-6519>
=== ChanServ changed the topic of #ubuntu-security to: Twitter: @ubuntu_sec || https://usn.ubuntu.com || https://wiki.ubuntu.com/SecurityTeam || https://wiki.ubuntu.com/Security/Features || Community: leosilva
[16:20] <Habbie> hello! I see ubuntu doesn't have entries for https://security-tracker.debian.org/tracker/CVE-2023-44487 yet
[16:20] -ubottu:#ubuntu-security- The HTTP/2 protocol allows a denial of service (server resource consumption) because request cancellation can reset many streams quickly, as exploited in the wild in August through October 2023. <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-44487>
[16:20] <Habbie> is that coming?
[16:20] <Habbie> if so, please know that the debian list is missing libh2o
[16:20] <Habbie> (i have also let them know)
[16:32] <teward> Habbie: i already poked them the tracker has a triage list
[16:32] <teward> and i noted some things for them during their triage process
[16:32] <Habbie> great, thanks
[16:32] <Habbie> is this triage list visible somewhere? just curious
[16:34] <teward> don't think so, and it has to be looked at / triaged in the system before they can poke it into the list, it's also automated so it might not have picked it up yet since that was only published *today* and not yet in the autosync list
[16:35] <Habbie> ack :)
[17:13] <ahasenack> hi security, is there something like aa-logprof to help with restricting systemd service units, and help decide which security isolation features to apply to a unit? From the list that `systemd-analyze security <unit>` gives
[17:13] <ahasenack> stuff like CapabilityBoundingSet, SystemCallFilter, etc
[17:13] <ahasenack> or should someone just go one by one, with knowledge of that the app should be able to do, and experiment? 
[17:18] <sbeattie> ahasenack: hrm, good question. I'm not aware of one, but I haven't looked for one, either.
[17:18] <ahasenack> ok, I'm doing the usual (googling) :)
[17:19] <ahasenack> and using common sense
[17:39] <mdeslaur> teward: Habbie: I've added the CVE to our tracker now, thanks
[17:40] <Habbie> some caching going on it appears
[17:41] <mdeslaur> takes a while to get published to the interwebz
[17:41] <Habbie> ack
[17:41] <Habbie> i'll wait :)
[17:41] <Habbie> thanks
[17:42] <teward> mdeslaur: ack, thanks for poking it, i know it's one of those odd "Huh it's not here or we have to look at it" cases but it's a major 0-day that hit yesterday so
[17:48] <mdeslaur> teward: "We do not consider nginx to be affected by this issue." - https://mailman.nginx.org/pipermail/nginx-devel/2023-October/S36Q5HBXR7CAIMPLLPRSSSYR4PCMWILK.html
[17:49] <teward> mdeslaur: is that dated today or prior to the F5 notice?
[17:49] <teward> becuase the F5 notice says "not fixed" but mentions that exact workaround
[17:49] <mdeslaur> click on it?
[17:49] <teward> and i do say *workaround* because the proposed patch for secondary limits wasn't in the commit list yet
[17:50] <teward> mdeslaur: "Nevertheless, we've decided to implemented some additional mitigations which will help nginx to detect such attacks and drop connections with misbehaving clients faster.  Hence the patch."
[17:50] <teward> mdeslaur: those mitigations are in the dev tree but not a release yet
[17:51] <teward> so i take Maxim's claim as a grain of salt because "while some mitigations exist, additional mitigations are on the way"
[17:51] <mdeslaur> right, not affected, but the patch still improves things
[17:51] <teward> mdeslaur: if i'm dissecting the technical details on this though
[17:52] <teward> Prior to version 1.19.10, the default value was 100.  <-- for keepalive requests this alone wasn't actually *ENOUGH* to protect the infrastructure (CF uses a modified NGINX)
[17:52] <teward> and is why this is a 0-day notice
[17:53] <teward> i'll have to reread the CF dissection but it was my understanding that this wasn't enough
[17:53] <mdeslaur> the default of 100 is better than the current default of 1000
[17:53] <mdeslaur> it's not enough if someone uses a bigger value than 1000
[17:54] <mdeslaur> "However, if NGINX is configured with a keepalive that is substantially higher than the default and recommended setting, the attack may deplete system resources."
[17:58] <teward> mdeslaur: agreed, but I would argue that in the strictest interpretation of CVEs, "mitigations exist in default configurations" is not enough to say "we are not affected"
[17:58] <teward> (and i just emailed the nginx-devel list with this question/statement)
[17:59] <mdeslaur> teward: I'll let the developers know you disagree with their statements :)
[17:59] <teward> i already did ;)
[17:59] <teward> (nginx-devel is a public list xD)
[17:59] <mdeslaur> we will release an update with the improved patch, but it's not a world-burning issue atm
[17:59] <teward> yep, just wanted ito make sure the CVE was on the radar though
[17:59] <teward> and whatever other HTTP/2 implementations are in Universe, etc. are almost definitely affected (unless Apache wrote in protections intentionally)
[18:22] <mdeslaur> ack, thanks
[18:52] <Habbie> mdeslaur, https://github.com/nghttp2/nghttp2/pull/1961
[18:52] -ubottu:#ubuntu-security- Pull 1961 in nghttp2/nghttp2 "Rework session management" [Merged]
[18:53] <mdeslaur> Habbie: yeah, I just added it, thanks
[18:53] <Habbie> yw :)
[19:00] <Habbie> good news, i have a patch for h2o. bad news, ABI.
[21:26] <Habbie> mdeslaur, nghttp2 isn't showing up for me yet
[22:05] <mdeslaur> Habbie: hrm, it does for me https://ubuntu.com/security/cves?q=CVE-2023-44487
[22:05] -ubottu:#ubuntu-security- The HTTP/2 protocol allows a denial of service (server resource consumption) because request cancellation can reset many streams quickly, as exploited in the wild in August through October 2023.
[22:06] <Habbie> it is now for me too
[22:06] <Habbie> more caching than i expected there :)
[22:07] <mdeslaur> yeah, it's complicated, a script pulls from our CVE tracker git tree, then gets consumed by a cluster of hamsters running around in wheels. Sometimes the hamsters go on strike.
[22:07] <Habbie> right