| === JanC is now known as Guest7641 | ||
| === JanC_ is now known as JanC | ||
| 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:42 |
|---|---|---|
| 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:43 |
| ahasenack | or can it be just /usr/lib/foo/bar.py? | 12:44 |
| 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" | 12:59 |
| 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:00 |
| 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:45 |
| appxprt | this simple shell script can lpe to root with full updates/pgrades: https://github.com/OllaPapito/gameoverlay | 13:47 |
| 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:48 |
| 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:49 |
| appxprt | still works, checking for further updates after reboot | 13:53 |
| appxprt | nothing | 13:54 |
| appxprt | still vulnerable | 13:54 |
| mdeslaur | let me check | 13:54 |
| 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:55 |
| appxprt | pretty sure I'm compromised | 13:56 |
| 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:57 |
| appxprt | ahhhh yea Permission denied, the id threw me off uid=0 | 13:58 |
| appxprt | ok thanks, you rock | 13:58 |
| mdeslaur | cool, np! | 13:58 |
| 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:29 | |
| 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:31 |
| teward | s/stupid stuff/undisclosed tweaks/ | 14:32 |
| teward | also https://my.f5.com/manage/s/article/K000137106 to the tracker (security advisory from F5 who owns nginx now) | 14:35 |
| 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> | 15:17 | |
| === 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 | ||
| 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:20 |
| 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:32 |
| 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:34 |
| Habbie | ack :) | 16:35 |
| 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:13 |
| 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:18 |
| ahasenack | and using common sense | 17:19 |
| mdeslaur | teward: Habbie: I've added the CVE to our tracker now, thanks | 17:39 |
| Habbie | some caching going on it appears | 17:40 |
| 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:41 |
| 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:42 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:58 |
| 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) | 17:59 |
| mdeslaur | ack, thanks | 18:22 |
| Habbie | mdeslaur, https://github.com/nghttp2/nghttp2/pull/1961 | 18:52 |
| -ubottu:#ubuntu-security- Pull 1961 in nghttp2/nghttp2 "Rework session management" [Merged] | 18:52 | |
| mdeslaur | Habbie: yeah, I just added it, thanks | 18:53 |
| Habbie | yw :) | 18:53 |
| Habbie | good news, i have a patch for h2o. bad news, ABI. | 19:00 |
| Habbie | mdeslaur, nghttp2 isn't showing up for me yet | 21:26 |
| 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:05 | |
| Habbie | it is now for me too | 22:06 |
| Habbie | more caching than i expected there :) | 22:06 |
| 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 | 22:07 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!