Episode 238

Ubuntu Security Podcast

Player FM - Internet Radio Done Right

149 subscribers

اضافه شده در seven سال پیش

محتوای ارائه شده توسط Alex Murray and Ubuntu Security Team. تمام محتوای پادکست شامل قسمت‌ها، گرافیک‌ها و توضیحات پادکست مستقیماً توسط Alex Murray and Ubuntu Security Team یا شریک پلتفرم پادکست آن‌ها آپلود و ارائه می‌شوند. اگر فکر می‌کنید شخصی بدون اجازه شما از اثر دارای حق نسخه‌برداری شما استفاده می‌کند، می‌توانید روندی که در اینجا شرح داده شده است را دنبال کنید.https://fa.player.fm/legal

In Her Ellement

1
Navigating Career Pivots and Grit with Milo’s Avni Patel Thompson 26:18

26 روز پیش26:18

پخش در آینده

لیست ها

پسندیدن

دوست داشته شد

26:18

How do you know when it’s time to make your next big career move? With International Women’s Day around the corner, we are excited to feature Avni Patel Thompson, Founder and CEO of Milo. Avni is building technology that directly supports the often overlooked emotional and logistical labor that falls on parents—especially women. Milo is an AI assistant designed to help families manage that invisible load more efficiently. In this episode, Avni shares her journey from studying chemistry to holding leadership roles at global brands like Adidas and Starbucks, to launching her own ventures. She discusses how she approaches career transitions, the importance of unpleasant experiences, and why she’s focused on making everyday life easier for parents. [01:26] Avni's University Days and Early Career [04:36] Non-Linear Career Paths [05:16] Pursuing Steep Learning Curves [11:51] Entrepreneurship and Safety Nets [15:22] Lived Experiences and Milo [19:55] Avni’s In Her Ellement Moment [20:03] Reflections Links: Avni Patel Thompson on LinkedIn Suchi Srinivasan on LinkedIn Kamila Rakhimova on LinkedIn Ipsos report on the future of parenting About In Her Ellement: In Her Ellement highlights the women and allies leading the charge in digital, business, and technology innovation. Through engaging conversations, the podcast explores their journeys—celebrating successes and acknowledging the balance between work and family. Most importantly, it asks: when was the moment you realized you hadn’t just arrived—you were truly in your element? About The Hosts: Suchi Srinivasan is an expert in AI and digital transformation. Originally from India, her career includes roles at trailblazing organizations like Bell Labs and Microsoft. In 2011, she co-founded the Cleanweb Hackathon, a global initiative driving IT-powered climate solutions with over 10,000 members across 25+ countries. She also advises Women in Cloud, aiming to create $1B in economic opportunities for women entrepreneurs by 2030. Kamila Rakhimova is a fintech leader whose journey took her from Tajikistan to the U.S., where she built a career on her own terms. Leveraging her English proficiency and international relations expertise, she discovered the power of microfinance and moved to the U.S., eventually leading Amazon's Alexa Fund to support underrepresented founders. Subscribe to In Her Ellement on your podcast app of choice to hear meaningful conversations with women in digital, business, and technology.…

حدود یک سال پیش 31:39

MP3•خانه قسمت

Overview

For the first in a 3-part series for Cybersecurity Awareness month, Luci Stanescu joins Alex to discuss the recent CUPS vulnerabilities as well as the evolution of cybersecurity since the origin of the internet.

Get in contact

248 قسمت

#Alex Murray #Ubuntu Security Team #Linux #Tech #Operating Systems #Alex and Joe #Security #Software Development

Episode 238

Ubuntu Security Podcast

149 subscribers

published حدود یک سال پیش

اشتراک گذاری

MP3•خانه قسمت

Overview

Get in contact

248 قسمت

#Alex Murray #Ubuntu Security Team #Linux #Tech #Operating Systems #Alex and Joe #Security #Software Development

همه قسمت ها

1
Episode 243 24:00

14 weeks پیش24:00

24:00

Overview It’s the end of the year for official duties for the Ubuntu Security team so we take a look back on the security highlights of 2024 for Ubuntu and predict what is coming in 2025. 2024 Year in Review for Ubuntu Security (00:55) full-disclosure necromancy with zombie CVEs full-disclosure spammed with zombie CVEs from Episode 217 Development of unprivileged user namespace restrictions for Ubuntu 24.04 LTS Updates for unprivileged user namespace restrictions in Ubuntu 24.04 LTS from Episode 218 Linux kernel becomes a CNA Linux kernel becomes a CNA from Episode 219 Follow up to Linux kernel CNA from Episode 220 Ubuntu participates in Pwn2Own Vancouver Summary of Pwn2Own Vancouver 2024 results against Ubuntu 23.10 from Episode 223 xz-utils / SSH backdoor supply-chain attack xz-utils backdoor and Ubuntu from Episode 224 Update on xz-utils from Episode 225 Linux Security Summit NA and EU Linux Security Summit NA 2024 from Episode 226 Linux Security Summit Europe 2024 from Episode 237 Release of Ubuntu 24.04 LTS Ubuntu 24.04 LTS (Noble Numbat) released from Episode 227 regreSSHion remote unauthenticated code execution vulnerability in OpenSSH Deep-dive into regreSSHion - Remote Unauthenticated Code Execution Vulnerablity in OpenSSH from Episode 232 Various other high profile vulnerabilities Discussion of CVE-2024-5290 in wpa_supplicant from Episode 234 Deep dive into needrestart local privilege escalation vulnerabilities from Episode 242 Ubuntu/Windows Dual-boot regression Reports of dual-boot Linux/Windows machines failing to boot from Episode 235 AppArmor-based snap file prompting experimental feature Ubuntu Security Center with snapd-based AppArmor home file access prompting preview from Episode 236 Official announcement of Permissions Prompting in Ubuntu 24.10 from Episode 237 Predictions for 2025 (14:35) Increased use of AI to both spam projects with hallucinated CVEs (e.g. curl ) but also to “aid” in dealing with that spam as the shine wears of AI likely expect OSS projects to ban contributions generated with the aid of AI - whether CVE reports or code but also expect companies to try and prove the worth of AI by finding novel vulns - e.g. apparent first 0-day discovered with AI doing vuln research https://googleprojectzero.blogspot.com/2024/06/project-naptime.html also more expected uses of AI like automating tasks used in the process of security-related SW dev - automatically generating fuzz targets and then improving the fuzz targets via AI as well https://security.googleblog.com/2024/11/leveling-up-fuzzing-finding-more.html More malware targeting Linux didn’t mention it earlier but we covered a number of Linux malware teardowns this year and expect that trend to increase as Linux keeps growing in popularity Full LSM stacking still won’t make it into the upstream Linux kernel Integrity of code and data will play more of a role both in terms of software supply chain and integrity of distro repos etc, but also efforts to try and guarantee the integrity of a Linux system itself - whether via new IPE LSM or other mechanisms - mainstream distros will start to care about integrity more More collaboration across distros to aid in efforts to collectively handle deluge of CVEs More efforts to try and fund OSS to learn from lessons of Heartbleed and xz-utils some more and less successful More interesting vulns in more software During 2024 Qualys have done some of the most interesting vuln research on Linux - expect more from them and from others (whether aided by AI or not) Get in contact security@ubuntu.com #ubuntu-security on the Libera.Chat IRC network ubuntu-hardened mailing list Security section on discourse.ubuntu.com @ubuntusecurity@fosstodon.org , @ubuntu_sec on twitter…

1
Episode 242 19:40

17 weeks پیش19:40

19:40

Overview This week we dive into the details of a number of local privilege escalation vulnerablities discovered by Qualys in the needrestart package, covering topics from confused deputies to the inner workings of the /proc filesystem and responsible disclosure as well. Deep dive into needrestart local privilege escalation vulnerabilities https://blog.qualys.com/vulnerabilities-threat-research/2024/11/19/qualys-tru-uncovers-five-local-privilege-escalation-vulnerabilities-in-needrestart https://www.qualys.com/2024/11/19/needrestart/needrestart.txt https://www.bleepingcomputer.com/news/security/ubuntu-linux-impacted-by-decade-old-needrestart-flaw-that-gives-root/ Qualys contacted security@ubuntu.com on [2024-10-04 Fri] to notify of 3 different local privilege escalation vulnerablities in needrestart needrestart is system service, written in Perl, to automatically restart system services if one of the libraries or the service itself was updated installed by default on Ubuntu Server since 21.04 - so anyone using 22.04 LTS (jammy) or 24.04 LTS (noble) would be affected - and is integrated into apt so that it runs at the end of an apt install/upgrade/remove or via unattended-upgrades (which again is installed by default to install security updates automatically every 24 hours) since it runs via apt it runs as root so if an unprivileged user can influence it to execute code of their chosing, can achieve local privilege escalation the next time it runs Initially described these as: trick needrestart into running the Python interpreter with an attacker controlled PYTHONPATH environment variable win a race condition with needrestart to trick it into running with attacker controlled Python interpreter instead of the system-installed one perl-related vuln in the ScanDeps module where would open a filename containing a pipe - which in turn causes Perl to execute a shell pipeline with the filename as input and hence code execution needrestart is written in Perl so why is Python relevant? basic functionality of needrestart is to look at the shared objects mapped into memory of each process and match these against newly updated/installed packages - if it sees that one of the shared objects for a given process got updated it will then be restarted back in 2014 introduced support for scanning files of interpreted languages for Java, Perl, Python and Ruby uses /proc/self/exe to first identify the interpreter as say python then looks at /proc/self/cmdline to determine the primary file being run by the interpreter and from that looks at import statements to determine which files are likely being used uses similar approaches for the other interpreters Interestingly it seems Qualys discovered this by accident - noticed the message “Scanning processes…” whilst doing and apt upgrade and wondered what that was - and if they controlled a process, whether they could then influence the behaviour of it For PYTHONPATH CVE, needrestart needs to replicate the behaviour of the Python interpreter when it imports files PYTHONPATH env var allows to specify a custom path to import from - so needrestart looks this up from /proc/pid/environ and executes the Python interpreter with this same value to get it to resolve the imports to files on disk But the unprivileged user is in control of this environment variable for their process - classic case of a Confused Deputy - lower privileged application is able to trick a higher privileged application into misusing its authority on the system - so can set their own PYTHONPATH, and since Python will happy load any __init__.so files from that path, the attacker controlled shared object is then executed by Python running as root via needrestart Initially Qualys suggested the Ruby implementation (which uses the RUBYLIB env var) may also be affected and subsequently confirmed this to be the case The second aforementioned vuln is also related to Python but instead of the PYTHONPATH used by the interpreter, is about the interpreter binary itself Before we said needrestart identified a process as using say Python by looking at its /proc/pid/exe entry - matches this against a regex like /usr/bin/python - back in 2022 Jakub Wilk discovered a vuln where the regex was not anchored, so if a process was running via a attacker controlled interpreter ( /home/amurray/usr/bin/python ) this would match and needrestart would execute that interpreter directly as root - CVE-2022-30688 Hoewever, it turns out needrestart reads the processes /proc/pid/exe twice - once early on when collecting info on all processes, and then a second time to determine if it is say a Python application - but when needrestart goes and executes this interpreter to do the PYTHONPATH lookups etc, it uses the original value that it collected at the start of its run Classic TOCTOU issue So a malicious process can run with say its own malicious Python interpreter at startup, then wait for needrestart to probe that (using say inotify to be notified when it is accessed) and then quickly exec() the real system Python interpreter and hence change its /proc/self/exe to trick needrestart - which will then go and execute its original malicious interpreter binary Since had found issues in Python and Ruby parts of needrestart, Qualys went looking at the Perl parts since needrestart is written in Perl though it doesn’t have to execute a Perl interpreter to resolve “imports” etc instead uses a Perl library (ScanDeps) which analyses Perl scripts directly Found this module was vulnerable to a very old Perl foot-gun, Pesky Pipe (coined in 1999 by rain.forest.puppy in Phrack ) Perl has a feature where you can call open with a string that ends in a pipe ( | ) and it will instead execute that string as a shell command ScanDeps did exactly this - called open on any files that it finds along the way in its analysis - and since these filenames are controlled by the unprivileged attacker, can create a file which ends in a pipe character (e.g. /home/amurray/bin/pwned| ) and Perl will then just execute that script directly Also found cases in ScanDeps where it would call eval() on contents from these files as well - directly executing whatever strings found as Perl code Mark Esler on our team then liased with Qualys and got the upstream needrestart developer involved to coordinate on writing fixes and disclosing the issue - first to other distros via the distros mailing list and then eventually publicly via oss-security Patches to fix went through a number of revisions before being finalised To fix these, a number of changes were made: ScanDeps was fixed to use an explicit call to open() to avoid Perl executing the argument as code and the uses of eval replaced with safer parsing needrestart removed the use of ScanDeps entirely and instead replaced this with its own regex based parsing of perl files to look for use directives needrestart modified to not set PYTHONPATH when running the Python interpreter and instead look inside the specified PYTHONPATH manually (to avoid having the Python interpreter possibly load untrusted shared objects from that path) - similarly for RUBYLIB needrestart modified to use the original /proc/pid/exe path to match against when looking for interpreted processes to remove the TOCTOU race Unfortunately, testing for the patches upstream wasn’t complete and a minor regression was introduced in the original update which caused needrestart to misidentify processes within a container as being on the host and so would inadvertently kill them Sudhakar Verma (who handled the technical side of testing proposed patches plus preparing and releasing the final updates) liased with upstream to help get a fix developed and deployed as a regression fix for Ubuntu Interesting to consider, the info needrestart was using comes from /proc filesystem - this is a virtual filesystem managed by the kernel, representing information about processes in userspace Easy to assume the data it presents is trusted as it is populated by the kernel - and generally file permissions are read-only for these files - so a process can’t just directly write to them to modify them - BUT these values all come from the userspace process itself originally perhaps needrestart could look at dropping privileges to those of the process in question before doing the evaluation as well - although this is tricky to do correctly - we’ve seen bugs in a number of applications which try and follow this pattern like snap-confine or apport which turn out to cause security issues as they don’t drop privileges completely etc Ryan Lee is looking to create an AppArmor profile for needrestart to help confine it to hopefully limit the damage any other similar bugs may cause [ USN-7117-1 ] needrestart and Module::ScanDeps vulnerabilities 5 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS), 24.10 2 medium priority CVE(s) 3 high priority CVE(s) [ USN-7117-2 ] needrestart regression 5 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS), 24.10 2 medium priority CVE(s) 3 high priority CVE(s) Get in contact security@ubuntu.com #ubuntu-security on the Libera.Chat IRC network ubuntu-hardened mailing list Security section on discourse.ubuntu.com @ubuntusecurity@fosstodon.org , @ubuntu_sec on twitter…

1
Episode 241 18:16

19 weeks پیش18:16

18:16

Overview This week we take a deep dive into the latest Linux malware, GoblinRAT to look at how malware is evolving to stay stealthy and evade detection and how malware authors are learning from modern software development along the way. GoblinRAT Linux Malware teardown https://rt-solar.ru/solar-4rays/blog/4861/ Solar 4RAYS team (Cyber Threat Research Center at SOLAR - Russian Cybersecurity firm) describes a new piece of Linux malware which they name GoblinRAT (RAT = Remote Access Trojan) 2023 when contacted by an IT company which provides services to (presumably) Russian government agencies - noticed system logs being deleted off one of their servers and a utility being downloaded to steal account passwords from a domain controller Found this malware masquerading as a legitimate process which takes quite careful steps to avoid detection - in fact most of the functionality within the malware is devoted to hiding its presence on the target system Doesn’t include automatic persistence but instead appears to be manually “installed” by the attackers with a unique name for each target where it would be named after an existing legitimate process on the target system - similarly even the names of its files and libraries were also unique per-system as well to avoid detection e.g. in one case where zabbix was running, the malware named itself zabbix_agent and setup a new systemd service to launch itself at boot which looks identical to the real zabbix agent (except the real one is zabbix_agentd ) and then once running it edits its own command-line arguments after startup to insert standard parameters expected by the real zabbix_agentd so that on a ps aux or similar output it appears basically identical to the real zabbix_agentd in another case it named itself rhsmd to mimic the Red Hat subscription manager service again using systemd as the launcher, whilst for others as memcached using cron to launch C2 uses DDNS (Dynamic DNS) and legitimate hacked sites to hide in noise of “normal” traffic - using DDNS attackers would use specifically named C2 machines per target host - in one case where it was named chrony_debug to mimic the chronyd time synchronisation service, it would connect to C2 a machine named chronyd.tftpd.net - attackers clearly went to a lot of work to hide this in plain sight Automatically deletes itself off the system if does not get pinged by the C2 operator after a certain period of time - and when it deletes itself it shreds itself to reduce the chance of being detected later via disk forensics etc Has 2 versions - a “server” and “client” - the server uses port-knocking to watching incoming connection requests on a given network interface and then only actually allowing a connection if the expected sequence of port numbers was tried - this allows the controller of the malware to connect into it without the malware actively listening on a given port and hence reduces the chance it is detected accidentally Client instead connects back to its specific C2 server Logs collected by 4RAYS team appear to show the commands executed by the malware were quite manual looking - invoking bash and then later invoking commands like systemctl to stop and replace an existing service, where the time lag between commands is in the order of seconds - minutes and so would seem like these were manually typed command rather than automatically driven by scripts Malware itself is implemented in Go and includes the ability to execute single commands as well as providing an interactive shell; also includes support for listing / copying / moving files including with compression; also works as a SOCKS5 proxy to allow it to proxy traffic to/from other hosts that may be behind more restrictive firewalls etc; and as detailed above the ability to mimic existing processes on the system to avoid detection To try and frustrate reverse engineering Gobfuscate was used to obfuscate the compiled code - odd choice though since this project was seemingly abandonded 3 years ago and nowadays garble seems to be the go-to tool for this (no pun intended)- but perhaps this is evidence of the time of the campaign since these samples were all found back in 2020 which this project was more active… Encrypts its configuration using AES-GCM and the config contains details like the shell to invoke, kill-switch delay and secret value to use to disable it, alternate process name to use plus the TLS certificate and keys to use when communicating with the C2 server Uses the yamux Go connection multiplexing library then to multiplex the single TLS connection to/from the C2 server Can then be instructed to perform the various actions like running commands / launching a shell / list files in a directory / reading files etc as discussed before Other interesting part is the kill switch / self-destruct functionality - if kill switch delay is specified in the encrypted configuration malware will automatically delete itself by invoking dd to overwrite itself with input from /dev/urandom 8 times; once more with 0 bytes and finally then removing the file from disk Overall 4 organisations were found to have been hacked with this and in each it was running with full admin rights - with some running for over 3 years - and various binaries show compilation dates and golang toolchain versions indicating this was developed since at least 2020 But unlike other malware that we have covered, it does not appear to be a more widespread campaign since “other information security companies with global sensor networks” couldn’t find any similar samples in their own collections No clear evidence of origin - Solar 4RAYS asking for other cybersecurity companies to help contribute to their evidence to identify the attackers Interesting to see the evolution of malware mirrors that of normal software development - no longer using C/C++ etc but more modern languages like Go which provide exactly the sorts of functionality you want in your malware - systems-level programming functionality with built-in concurrency and memory safety - also Go binaries are statically linked so no need to worry about dependencies on the target system Get in contact #ubuntu-security on the Libera.Chat IRC network ubuntu-hardened mailing list Security section on discourse.ubuntu.com @ubuntusecurity@fosstodon.org , @ubuntu_sec on twitter…

1
Episode 240 36:22

21 weeks پیش36:22

36:22

Overview For the third and final part in our series for Cybersecurity Awareness Month, Alex is again joined by Luci as well as Diogo Sousa to discuss future trends in cybersecurity and the likely threats of the future. Get in contact security@ubuntu.com #ubuntu-security on the Libera.Chat IRC network ubuntu-hardened mailing list Security section on discourse.ubuntu.com @ubuntusecurity@fosstodon.org , @ubuntu_sec on twitter…

1
Episode 239 39:16

23 weeks پیش39:16

39:16

Overview In the second part of our series for Cybersecurity Awareness Month, Luci is back with Alex, along with Eduardo Barretto to discuss our top cybersecurity best practices. Get in contact security@ubuntu.com #ubuntu-security on the Libera.Chat IRC network ubuntu-hardened mailing list Security section on discourse.ubuntu.com @ubuntusecurity@fosstodon.org , @ubuntu_sec on twitter…

1
Episode 238 31:39

25 weeks پیش31:39

31:39

Overview For the first in a 3-part series for Cybersecurity Awareness month, Luci Stanescu joins Alex to discuss the recent CUPS vulnerabilities as well as the evolution of cybersecurity since the origin of the internet. Get in contact security@ubuntu.com #ubuntu-security on the Libera.Chat IRC network ubuntu-hardened mailing list Security section on discourse.ubuntu.com @ubuntusecurity@fosstodon.org , @ubuntu_sec on twitter…

1
Episode 237 16:16

27 weeks پیش16:16

16:16

Overview John and Maximé have been talking about Ubuntu’s AppArmor user namespace restrictions at the the Linux Security Summit in Europe this past week, plus we cover some more details from the official announcement of permission prompting in Ubuntu 24.10, a new release of Intel TDX for Ubuntu 24.04 LTS and more. This week in Ubuntu Security Updates (01:11) 613 unique CVEs addressed in the past fortnight [ USN-6989-1 ] OpenStack vulnerability 1 CVEs addressed in Jammy (22.04 LTS), Noble (24.04 LTS) CVE-2024-44082 [ USN-6990-1 ] znc vulnerability 1 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS) CVE-2024-39844 [ USN-6992-1 ] Firefox vulnerabilities 8 CVEs addressed in Focal (20.04 LTS) CVE-2024-8385 CVE-2024-8384 CVE-2024-8381 CVE-2024-8389 CVE-2024-8387 CVE-2024-8386 CVE-2024-8383 CVE-2024-8382 [ USN-6993-1 ] Vim vulnerabilities 2 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS) CVE-2024-43374 CVE-2024-41957 [ USN-6991-1 ] AIOHTTP vulnerability 1 CVEs addressed in Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS) CVE-2024-23334 [ USN-6995-1 ] Thunderbird vulnerabilities 10 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS) CVE-2024-8384 CVE-2024-8381 CVE-2024-7525 CVE-2024-7522 CVE-2024-7519 CVE-2024-8382 CVE-2024-7529 CVE-2024-7527 CVE-2024-7526 CVE-2024-7521 [ USN-6996-1 ] WebKitGTK vulnerabilities 6 CVEs addressed in Jammy (22.04 LTS), Noble (24.04 LTS) CVE-2024-4558 CVE-2024-40789 CVE-2024-40782 CVE-2024-40780 CVE-2024-40779 CVE-2024-40776 [ USN-6841-2 ] PHP vulnerability 1 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM) CVE-2024-5458 [ USN-6997-1 , USN-6997-2 ] LibTIFF vulnerability 1 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS) CVE-2024-7006 [ USN-6994-1 ] Netty vulnerabilities 2 CVEs addressed in Jammy (22.04 LTS) CVE-2023-44487 CVE-2023-34462 HTTP/2 DoS, seen exploited in the wild and listen on the CISA KEV [ USN-6998-1 ] Unbound vulnerabilities 2 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS) CVE-2024-43168 CVE-2024-43167 [ USN-6999-1 ] Linux kernel vulnerabilities 220 CVEs addressed in Noble (24.04 LTS) Full CVE list elided - see USN for details [ USN-7003-1 , USN-7003-2 , USN-7003-3 ] Linux kernel vulnerabilities 85 CVEs addressed in Bionic ESM (18.04 ESM), Focal (20.04 LTS) Full CVE list elided - see USN for details [ USN-7004-1 ] Linux kernel vulnerabilities 221 CVEs addressed in Noble (24.04 LTS) Full CVE list elided - see USN for details [ USN-7005-1 , USN-7005-2 ] Linux kernel vulnerabilities 219 CVEs addressed in Jammy (22.04 LTS), Noble (24.04 LTS) Full CVE list elided - see USN for details [ USN-7006-1 ] Linux kernel vulnerabilities 94 CVEs addressed in Focal (20.04 LTS) Full CVE list elided - see USN for details [ USN-7007-1 ] Linux kernel vulnerabilities 219 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS) Full CVE list elided - see USN for details [ USN-7008-1 ] Linux kernel vulnerabilities 222 CVEs addressed in Jammy (22.04 LTS) Full CVE list elided - see USN for details [ USN-7009-1 ] Linux kernel vulnerabilities 219 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS) Full CVE list elided - see USN for details [ USN-7019-1 ] Linux kernel vulnerabilities 429 CVEs addressed in Jammy (22.04 LTS) Full CVE list elided - see USN for details [ USN-7002-1 ] Setuptools vulnerability 1 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS) CVE-2024-6345 [ USN-7000-1 , USN-7000-2 ] Expat vulnerabilities 3 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS) CVE-2024-45492 CVE-2024-45491 CVE-2024-45490 [ USN-7001-1 , USN-7001-2 ] xmltok library vulnerabilities 2 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS) CVE-2024-45491 CVE-2024-45490 [ USN-6560-3 ] OpenSSH vulnerability 1 CVEs addressed in Xenial ESM (16.04 ESM) CVE-2023-51385 [ USN-7011-1 , USN-7011-2 ] ClamAV vulnerabilities 2 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS) CVE-2024-20506 CVE-2024-20505 [ USN-7012-1 ] curl vulnerability 1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS) CVE-2024-8096 [ USN-7013-1 ] Dovecot vulnerabilities 2 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS) CVE-2024-23185 CVE-2024-23184 [ USN-7014-1 ] nginx vulnerability 1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS) CVE-2024-7347 [ USN-7015-1 ] Python vulnerabilities 5 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS) CVE-2024-8088 CVE-2024-7592 CVE-2024-6923 CVE-2024-6232 CVE-2023-27043 [ USN-7010-1 ] DCMTK vulnerabilities 9 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS) CVE-2024-34509 CVE-2024-34508 CVE-2024-28130 CVE-2022-43272 CVE-2022-2121 CVE-2021-41690 CVE-2021-41689 CVE-2021-41688 CVE-2021-41687 [ USN-7016-1 ] FRR vulnerability 1 CVEs addressed in Jammy (22.04 LTS), Noble (24.04 LTS) CVE-2024-44070 [ USN-7017-1 ] Quagga vulnerability 1 CVEs addressed in Focal (20.04 LTS) CVE-2024-44070 [ USN-7018-1 ] OpenSSL vulnerabilities 6 CVEs addressed in Trusty ESM (14.04 ESM) CVE-2024-0727 CVE-2023-3446 CVE-2022-2068 CVE-2022-1292 CVE-2021-23840 CVE-2020-1968 Goings on in Ubuntu Security Community Linux Security Summit Europe 2024 (03:44) https://events.linuxfoundation.org/linux-security-summit-europe/program/schedule/ Sep 16-17 - Vienna, Austria John Johansen and Maxime Bélair from AppArmor team presented “Restricting Unprivileged User Namespaces in Ubuntu” https://youtu.be/yCHGmdXpylA?t=1053 https://static.sched.com/hosted_files/lsseu2024/ed/Restricting%20Unprivileged%20User%20Namespaces%20In%20Ubuntu.pdf Other talks Deep-dive into xz-utils supply chain attack Internals of the SLUB memory allocator for exploit developers Landlock update - including details of new IOCTL restrictions etc systemd and TPM2 update Official announcement of Permissions Prompting in Ubuntu 24.10 (09:00) https://discourse.ubuntu.com/t/ubuntu-desktop-s-24-10-dev-cycle-part-5-introducing-permissions-prompting/47963 Ubuntu Security Center with snapd-based AppArmor home file access prompting preview in episode 236 Even works for command-line applications etc - not just graphical Covers future developments as well: Better default response suggestions based on user feedback. Shell integration of the prompting pop-ups (eg full screen takeovers) Improved rule management summaries and better messaging of overlapping or redundant prompts. Expansion of the prompting system to cover additional snap interfaces such as camera and microphone access. Smarter client side analysis of prompts, recommending additional options if multiple similar prompts are detected. Version 2.1 of IntelⓇ TDX on Ubuntu 24.04 LTS Released (11:46) https://discourse.ubuntu.com/t/version-2-1-of-intel-tdx-on-ubuntu-24-04-lts-released/47918/1 Confidential computing - using TDX to run VMs in confidential mode - runs workloads (VMs) in hardware-backed isolated execution environments (Trust Domains). VM memory isolation via encryption in hardware so can’t be accessed by the hypervisor, remote attestation etc ( Confidential Computing with Ijlal Loutfi and Karen Horovitz from Episode 230 ) https://discourse.ubuntu.com/t/intel-tdx-1-0-technology-preview-available-on-ubuntu-23-10/40698 Scripting to setup the required elements to use TDX on Ubuntu 24.04 host and then setup guest VMs to run in confidential mode Install server image, run scripts, enable TDX in BIOS, create VM images etc Can also configure remote attestation of VM too See full changes at https://github.com/canonical/tdx/releases/tag/2.1 Ubuntu 22.04.5 LTS released (13:45) https://discourse.ubuntu.com/t/jammy-jellyfish-point-release-changes/29835/8 Only covers changes in main and restricted, doesn’t list security updates either https://discourse.ubuntu.com/t/jammy-jellyfish-release-notes/24668 AppArmor security update for CVE-2016-1585 published (14:23) Upcoming AppArmor Security update for CVE-2016-1585 from Episode 226 https://discourse.ubuntu.com/t/upcoming-apparmor-security-update-for-cve-2016-1585/44268/3 Now published to -updates pocket for 20.04 LTS and 22.04 LTS Will be published to -security pocket next week Get in contact security@ubuntu.com #ubuntu-security on the Libera.Chat IRC network ubuntu-hardened mailing list Security section on discourse.ubuntu.com @ubuntusecurity@fosstodon.org , @ubuntu_sec on twitter…

1
Episode 236 18:23

29 weeks پیش18:23

18:23

Overview The long awaited preview of snapd-based AppArmor file prompting is finally seeing the light of day, plus we cover the recent 24.04.1 LTS release and the podcast officially moves to a fortnightly cycle. This week in Ubuntu Security Updates 45 unique CVEs addressed [ USN-6972-4 ] Linux kernel (Oracle) vulnerabilities 18 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM) CVE-2023-52470 CVE-2024-26687 CVE-2024-36901 CVE-2024-26654 CVE-2024-26679 CVE-2024-39484 CVE-2023-52806 CVE-2023-52760 CVE-2024-35955 CVE-2023-52629 CVE-2024-26600 CVE-2024-36940 CVE-2024-39292 CVE-2023-52644 CVE-2024-35835 CVE-2024-26903 CVE-2024-24860 CVE-2024-22099 [ USN-6982-1 ] Dovecot vulnerabilities 2 CVEs addressed in Noble (24.04 LTS) CVE-2024-23185 CVE-2024-23184 [ USN-6983-1 ] FFmpeg vulnerability 1 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS) CVE-2024-32230 [ USN-6984-1 ] WebOb vulnerability 1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS) CVE-2024-42353 [ USN-6973-4 ] Linux kernel (Raspberry Pi) vulnerabilities 9 CVEs addressed in Bionic ESM (18.04 ESM) CVE-2023-52760 CVE-2023-52629 CVE-2021-46926 CVE-2024-26921 CVE-2024-26929 CVE-2024-36901 CVE-2024-39484 CVE-2024-26830 CVE-2024-24860 [ USN-6981-2 ] Drupal vulnerabilities 3 CVEs addressed in Trusty ESM (14.04 ESM) CVE-2020-28949 CVE-2020-28948 CVE-2020-13671 2 of these are in the CISA KEV - Discussion of CISA KEV from Episode 231 [ USN-6986-1 ] OpenSSL vulnerability 1 CVEs addressed in Jammy (22.04 LTS), Noble (24.04 LTS) CVE-2024-6119 [ USN-6987-1 ] Django vulnerabilities 2 CVEs addressed in Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS) CVE-2024-45231 CVE-2024-45230 [ USN-6988-1 ] Twisted vulnerabilities 2 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS) CVE-2024-41810 CVE-2024-41671 [ USN-6985-1 ] ImageMagick vulnerabilities 11 CVEs addressed in Trusty ESM (14.04 ESM) CVE-2019-12979 CVE-2019-12978 CVE-2019-12976 CVE-2019-12975 CVE-2019-12974 CVE-2019-11598 CVE-2019-11597 CVE-2019-11472 CVE-2019-11470 CVE-2019-10650 CVE-2019-10131 Goings on in Ubuntu Security Community Ubuntu 24.04.1 LTS released (02:55) On 29th August - https://lists.ubuntu.com/archives/ubuntu-announce/2024-August/000304.html https://discourse.ubuntu.com/t/ubuntu-24-04-lts-noble-numbat-release-notes/39890 Discussed high level features previously in Ubuntu 24.04 LTS (Noble Numbat) released from Episode 227 New security features / improvements: Unprivileged user namespace restrictions Binary hardening AppArmor 4 Disabling of old TLS versions Upstream Kernel Security Features Intel shadow stack support Secure virtualisation with AMD SEV-SNP and Intel TDX Strict compile-time bounds checking Initially offered upgrades from 22.04 but this has been pulled just recently due to reports of a critical bug in the ubuntu-release-upgrader package and its interaction with the apt solver - essentially resulting in packages like linux-headers being in an broken state since it would remove some packages that were seen as obsolete but which were still required due to other packages depending on them likely will not be fixed until early next week Ubuntu Security Center with snapd-based AppArmor home file access prompting preview (05:45) https://news.itsfoss.com/ubuntu-security-center-near-stable/ Details the new Desktop Security Center application Written by the Ubuntu Desktop team - new application built using Flutter + Dart etc and published a snap Eventually this will allow to manage various security related things like full-disk encryption, enabling/usage of Ubuntu Pro, Firewall control and finally for snap permission prompting this last feature is the only one currently supported - has a single toggle which is to enable “snaps to ask for system permissions” - aka. snapd-based AppArmor prompting and then once this is enabled, allows the specific permissions to be futher fine-tuned What is AppArmor? AppArmor policies - and MAC systems in general are static - policy defined by sysadmin etc Not well suited for dynamic applications that are controlled by a user - like desktop / CLI etc - can’t know in advance every possible file a user may want to open in say Firefox so have to grant access to all files in home directory just in case Ideally system would only allow files that the user explicitly chooses - number of ways this can be done, XDG Portals one such way - using Powerbox concept pioneered in tools from the object-capability based security community like CapDesk/Polaris and Plash (principle of least-authority shell) - access is mediated by a privileged component that acts with the users whole authority to then delegate some of that authority to the application - seen say in the file-chooser dialog with portals - this runs outside of the scope of the application itself and so has the full, unrestricted access to the system to allow a file to be chosen - then the application is then just given a file-descriptor to the file to grant it the access (or similar) This only works in the case of applications that open files interactively - can’t allow the user to explicitly grant access to the configuration file that gets loaded from a well-known path at startup in a server application etc One way to handle that case is to alert the user and explicitly prompt them for that access - and this is currently how this new prompting feature works When the feature is enabled, the usual broad-based access rules for the home interface in snapd get tagged with a prompt attribute - any access then which would normally be allowed is instead delegated to a trusted helper application which displays a dialog to the user asking them to explicitly allow such access since this happens directly in the system-call path within the kernel, the application itself is unaware that this is happening - but is just suspended whilst waiting for the users response - and then assuming they grant the access it proceeds as normal (or if they deny then the application gets a permission denied error) Completely transparent to the application and supports any kind of file-access regardless of which API might be used (unlike portals which only support the regular file-chooser scenario) Allows tighter control of what files a snap is granted access to - and can be managed by the user in the Security Center later to revoke any such permission that they granted Has been in development for a long time, and is certainly not a new concept - seccomp has supported this via the seccomp_unotify interface - allows to delegate seccomp decisions to userspace in a very similar manner - existed since the 5.5 kernel released in January 2020 Even before that, prototype LSMs existed which implemented this kind of functionality ( https://sourceforge.net/projects/pulse-lsm/ / https://crpit.scem.westernsydney.edu.au/confpapers/CRPITV81Murray.pdf ) Can test this now on an up-to-date 24.04 or 24.10 install Need to use snapd from the latest/edge channel and then install both the desktop-security-center snap as well as the prompting-client snap Launch Security Center and toggle the option Note this is experimental but has undergone a fair amount of internal testing Very exciting to see this finally available in this pre-release stage - has been talked about since at least 2018 Give it a spin and provide feedback - I would suggest to use the link in the security center application itself for this but it is not working currently - instead report via a Github issue on the desktop-security-center project Get in contact security@ubuntu.com #ubuntu-security on the Libera.Chat IRC network ubuntu-hardened mailing list Security section on discourse.ubuntu.com @ubuntusecurity@fosstodon.org , @ubuntu_sec on twitter…

1
Episode 235 17:40

31 weeks پیش17:40

17:40

Overview A recent Microsoft Windows update breaks Linux dual-boot - or does it? This week we look into reports of the recent Windows patch-Tuesday update breaking dual-boot, including a deep-dive into the technical details of Secure Boot, SBAT, grub, shim and more, plus we look at a vulnerability in GNOME Shell and the handling of captive portals as well. This week in Ubuntu Security Updates 135 unique CVEs addressed [ USN-6960-1 ] RMagick vulnerability 1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS) CVE-2023-5349 [ USN-6951-2 ] Linux kernel (Azure) vulnerabilities 83 CVEs addressed in Focal (20.04 LTS) CVE-2022-48674 CVE-2024-39471 CVE-2024-39292 CVE-2024-36270 CVE-2024-36904 CVE-2024-38618 CVE-2024-36014 CVE-2024-36941 CVE-2024-38637 CVE-2024-38613 CVE-2024-36286 CVE-2024-36902 CVE-2024-38599 CVE-2024-39301 CVE-2024-39475 CVE-2024-36954 CVE-2024-33621 CVE-2024-38552 CVE-2024-36950 CVE-2024-38582 CVE-2024-36015 CVE-2023-52434 CVE-2024-38659 CVE-2024-36940 CVE-2024-38607 CVE-2024-39480 CVE-2024-38583 CVE-2023-52882 CVE-2024-39467 CVE-2024-39489 CVE-2024-38601 CVE-2024-27019 CVE-2023-52752 CVE-2024-36960 CVE-2024-38549 CVE-2024-38567 CVE-2024-38587 CVE-2024-38635 CVE-2024-38598 CVE-2024-38612 CVE-2024-38579 CVE-2024-27401 CVE-2024-36946 CVE-2024-36017 CVE-2022-48772 CVE-2024-36905 CVE-2024-35947 CVE-2024-38381 CVE-2024-38565 CVE-2024-38589 CVE-2024-36939 CVE-2024-38661 CVE-2024-39488 CVE-2024-36883 CVE-2024-38621 CVE-2024-37353 CVE-2024-38780 CVE-2024-36964 CVE-2024-38627 CVE-2024-36971 CVE-2024-38615 CVE-2024-38559 CVE-2024-31076 CVE-2024-26886 CVE-2024-39493 CVE-2024-27398 CVE-2024-36886 CVE-2024-38633 CVE-2024-36959 CVE-2024-38634 CVE-2024-38560 CVE-2024-38558 CVE-2023-52585 CVE-2024-37356 CVE-2024-35976 CVE-2024-36919 CVE-2024-36933 CVE-2024-38596 CVE-2024-39276 CVE-2024-27399 CVE-2024-38600 CVE-2024-38578 CVE-2024-36934 [ USN-6961-1 ] BusyBox vulnerabilities 4 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS) CVE-2023-42365 CVE-2023-42364 CVE-2023-42363 CVE-2022-48174 [ USN-6962-1 ] LibreOffice vulnerability 1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS) CVE-2024-6472 [ USN-6963-1 ] GNOME Shell vulnerability (01:03) 1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS) CVE-2024-36472 Captive portal detection would spawn an embedded webkit browser automatically to allow user to login etc But the page the user gets directed to is controlled by the attacker and can contain arbitrary javascript etc Upstream bug report claimed could then get a reverse shell etc - not clear this is the case since would still be constrained by the webkitgtk browser so would also need a sandbox escape etc. This update then includes a change to both not automatically open the captive portal page (instead it will show a notification and the user needs to click that) BUT to also disable the use of the webkitgtk-based embedded browser and instead use the users regular browser [ USN-6909-3 ] Bind vulnerabilities 2 CVEs addressed in Xenial ESM (16.04 ESM) CVE-2024-1975 CVE-2024-1737 [ USN-6964-1 ] ORC vulnerability 1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS) CVE-2024-40897 [ USN-6837-2 ] Rack vulnerabilitie 3 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS) CVE-2024-26146 CVE-2024-26141 CVE-2024-25126 [ USN-6966-1 ] Firefox vulnerabilities 13 CVEs addressed in Focal (20.04 LTS) CVE-2024-7525 CVE-2024-7522 CVE-2024-7520 CVE-2024-7519 CVE-2024-7531 CVE-2024-7530 CVE-2024-7529 CVE-2024-7528 CVE-2024-7527 CVE-2024-7526 CVE-2024-7524 CVE-2024-7521 CVE-2024-7518 [ USN-6966-2 ] Firefox regressions 13 CVEs addressed in Focal (20.04 LTS) CVE-2024-7525 CVE-2024-7522 CVE-2024-7520 CVE-2024-7519 CVE-2024-7531 CVE-2024-7530 CVE-2024-7529 CVE-2024-7528 CVE-2024-7527 CVE-2024-7526 CVE-2024-7524 CVE-2024-7521 CVE-2024-7518 [ USN-6951-3 ] Linux kernel (Azure) vulnerabilities 83 CVEs addressed in Bionic ESM (18.04 ESM) CVE-2022-48674 CVE-2024-39471 CVE-2024-39292 CVE-2024-36270 CVE-2024-36904 CVE-2024-38618 CVE-2024-36014 CVE-2024-36941 CVE-2024-38637 CVE-2024-38613 CVE-2024-36286 CVE-2024-36902 CVE-2024-38599 CVE-2024-39301 CVE-2024-39475 CVE-2024-36954 CVE-2024-33621 CVE-2024-38552 CVE-2024-36950 CVE-2024-38582 CVE-2024-36015 CVE-2023-52434 CVE-2024-38659 CVE-2024-36940 CVE-2024-38607 CVE-2024-39480 CVE-2024-38583 CVE-2023-52882 CVE-2024-39467 CVE-2024-39489 CVE-2024-38601 CVE-2024-27019 CVE-2023-52752 CVE-2024-36960 CVE-2024-38549 CVE-2024-38567 CVE-2024-38587 CVE-2024-38635 CVE-2024-38598 CVE-2024-38612 CVE-2024-38579 CVE-2024-27401 CVE-2024-36946 CVE-2024-36017 CVE-2022-48772 CVE-2024-36905 CVE-2024-35947 CVE-2024-38381 CVE-2024-38565 CVE-2024-38589 CVE-2024-36939 CVE-2024-38661 CVE-2024-39488 CVE-2024-36883 CVE-2024-38621 CVE-2024-37353 CVE-2024-38780 CVE-2024-36964 CVE-2024-38627 CVE-2024-36971 CVE-2024-38615 CVE-2024-38559 CVE-2024-31076 CVE-2024-26886 CVE-2024-39493 CVE-2024-27398 CVE-2024-36886 CVE-2024-38633 CVE-2024-36959 CVE-2024-38634 CVE-2024-38560 CVE-2024-38558 CVE-2023-52585 CVE-2024-37356 CVE-2024-35976 CVE-2024-36919 CVE-2024-36933 CVE-2024-38596 CVE-2024-39276 CVE-2024-27399 CVE-2024-38600 CVE-2024-38578 CVE-2024-36934 [ USN-6968-1 ] PostgreSQL vulnerability 1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS) CVE-2024-7348 [ USN-6967-1 ] Intel Microcode vulnerabilities 5 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS) CVE-2024-25939 CVE-2024-24980 CVE-2024-24853 CVE-2023-49141 CVE-2023-42667 [ LSN-0106-1 ] Linux kernel vulnerability 3 CVEs addressed in CVE-2024-36016 CVE-2024-26585 CVE-2023-52620 [ USN-6969-1 ] Cacti vulnerabilities 10 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS) CVE-2024-34340 CVE-2024-34360 CVE-2024-31460 CVE-2024-31459 CVE-2024-31458 CVE-2024-31445 CVE-2024-31444 CVE-2024-31443 CVE-2024-29894 CVE-2024-25641 [ USN-6970-1 ] exfatprogs vulnerability 1 CVEs addressed in Jammy (22.04 LTS) CVE-2023-45897 [ USN-6944-2 ] curl vulnerability 1 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM) CVE-2024-7264 [ USN-6965-1 ] Vim vulnerabilities 5 CVEs addressed in Trusty ESM (14.04 ESM) CVE-2021-4069 CVE-2021-4019 CVE-2021-3984 CVE-2021-3974 CVE-2021-3973 Goings on in Ubuntu Security Community Reports of dual-boot Linux/Windows machines failing to boot (04:30) https://arstechnica.com/security/2024/08/a-patch-microsoft-spent-2-years-preparing-is-making-a-mess-for-some-linux-users/ https://msrc.microsoft.com/update-guide/en-US/advisory/CVE-2022-2601 https://discourse.ubuntu.com/t/sbat-self-check-failed-mitigating-the-impact-of-shim-15-7-revocation-on-the-ubuntu-boot-process-for-devices-running-windows/47378 Microsoft released an update for Windows on 13th August 2024 - revoking old versions of grub that were susceptible to CVE-2022-2601 How do you revoke grub? Secure Boot relies on each component in the boot chain verifying that the next component is signed with a valid signature before it is then loaded UEFI BIOS validates shim shim validates grub grub validates kernel kernel validates kernel modules etc UEFI specification has effectively a CRL - list of hashes of binaries which shouldn’t be trusted BUT there is only limited space in the UEFI storage - after the original BootHole vulnerabilities revoked a huge number of grub binaries from many different distros, some devices failed to boot as the NVRAM was too full Microsoft and Red Hat and other maintainers of shim decided on a new scheme, called SBAT - Secure Boot Advanced Targeting maintains a generation number for each component in the boot chain when say shim or grub gets updated to fix a bunch more security vulnerabilities, upstream bumps the generation number shim/grub then embeds the generation number within itself Signed UEFI variable then lists which generation numbers are acceptable shim checks the generation number of a binary (grub/fwupd etc) against this list and if it is too old refuses to load it In Ubuntu this was patched back in Jan 2023 and was documented on the Ubuntu Discourse - in this case we updated shim to a newer version which itself revoked an older grub, grub,1 Now Microsoft’s update revokes grub,2 , ie sets the minimum generation number for grub to 3 You can inspect the SBAT policy by either directly reading the associated EFI variable or using mokutil --list-sbat-revocations cat /sys/firmware/efi/efivars/SbatLevelRT-605dab50-e046-4300-abb6-3dd810dd8b23 mokutil --list-sbat-revocations sbat,1,2023012900 shim,2 grub,3 grub.debian,4 objdump -j .sbat -s /boot/efi/EFI/ubuntu/grubx64.efi | xxd -r sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md grub,4,Free Software Foundation,grub,2.12,https://www.gnu.org/software/grub/ grub.ubuntu,2,Ubuntu,grub2,2.12-5ubuntu4,https://www.ubuntu.com/ grub.peimage,2,Canonical,grub2,2.12-5ubuntu4,https://salsa.debian.org/grub-team/grub/-/blob/master/debian/patches/secure-boot/efi-use-peimage-shim.patch rm -rf grub2-signed mkdir grub2-signed pushd grub2-signed >/dev/null || exit for rel in focal jammy noble; do mkdir $rel pushd $rel >/dev/null || exit pull-lp-debs grub2-signed $rel-security 1>/dev/null 2>/dev/null || pull-lp-debs grub2-signed $rel-release 1>/dev/null 2>/dev/null dpkg-deb -x grub-efi-amd64-signed*.deb grub2-signed echo $rel echo ----- find . -name grubx64.efi.signed -exec objdump -j .sbat -s {} \; | tail -n +5 | xxd -r popd >/dev/null || exit done popd >/dev/null focal ----- sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md grub,4,Free Software Foundation,grub,2.06,https://www.gnu.org/software/grub/ grub.ubuntu,1,Ubuntu,grub2,2.06-2ubuntu14.4,https://www.ubuntu.com/ jammy ----- sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md grub,4,Free Software Foundation,grub,2.06,https://www.gnu.org/software/grub/ grub.ubuntu,1,Ubuntu,grub2,2.06-2ubuntu14.4,https://www.ubuntu.com/ noble ----- sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md grub,4,Free Software Foundation,grub,2.12,https://www.gnu.org/software/grub/ grub.ubuntu,2,Ubuntu,grub2,2.12-1ubuntu7,https://www.ubuntu.com/ grub.peimage,2,Canonical,grub2,2.12-1ubuntu7,https://salsa.debian.org/grub-team/grub/-/blob/master/debian/patches/secure-boot/efi-use-peimage-shim.patch So if all the current LTS releases have a grub with a generation number higher than this, why are so many machines failing to boot? It is not just grub that is the issue - shim itself also got revoked in the same update https://msrc.microsoft.com/update-guide/en-US/advisory/CVE-2023-40547 - so shim 15.8 (ie. 4th SBAT generation of shim) is now required Unfortunately, the related updates for this shim in Ubuntu are still in the process of being released - https://bugs.launchpad.net/ubuntu/+source/shim/+bug/2051151 rm -rf shim-signed mkdir shim-signed pushd shim-signed >/dev/null || exit for rel in focal jammy noble; do mkdir $rel pushd $rel >/dev/null || exit pull-lp-debs shim-signed $rel-security 1>/dev/null 2>/dev/null || pull-lp-debs shim-signed $rel-release 1>/dev/null 2>/dev/null dpkg-deb -x shim-signed*.deb shim-signed echo $rel echo ----- find . -name shimx64.efi.signed.latest -exec objdump -j .sbat -s {} \; | tail -n +5 | xxd -r popd >/dev/null || exit done popd >/dev/null focal ----- sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md shim,3,UEFI shim,shim,1,https://github.com/rhboot/shim shim.ubuntu,1,Ubuntu,shim,15.7-0ubuntu1,https://www.ubuntu.com/ jammy ----- sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md shim,3,UEFI shim,shim,1,https://github.com/rhboot/shim shim.ubuntu,1,Ubuntu,shim,15.7-0ubuntu1,https://www.ubuntu.com/ noble ----- sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md shim,4,UEFI shim,shim,1,https://github.com/rhboot/shim shim.ubuntu,1,Ubuntu,shim,15.8-0ubuntu1,https://www.ubuntu.com/ only noble has a new-enough shim in the security/release pocket - both focal and jammy have the older one - but the new 4th generation shim is currently undergoing testing in the -proposed pocket and will be released next week until then, if affected, need to disable secure boot in BIOS then can either wait until the new shim is released OR just reboot twice in this mode and shim will automoatically reset the SBAT policy to the previous version, allowing the older shim to still be used then can re-enable Secure Boot in BIOS Once new shim is released it will reinstall the new SBAT policy to revoke its older version One other thing, this also means the old ISOs won’t boot either 24.04.1 will be released on 29th August upcoming 22.04.5 release will also have this new shim too no further ISO spins planned for 20.04 - so if you really want to install this release on new hardware, would need to disable secure boot first, do the install, then install updates to get the new shim, and re-enable secure boot Get in contact security@ubuntu.com #ubuntu-security on the Libera.Chat IRC network ubuntu-hardened mailing list Security section on discourse.ubuntu.com @ubuntusecurity@fosstodon.org , @ubuntu_sec on twitter…

1
Episode 234 29:11

33 weeks پیش29:11

29:11

Overview This week we take a deep dive behind-the-scenes look into how the team handled a recent report from Snyk’s Security Lab of a local privilege escalation vulnerability in wpa_supplicant plus we cover security updates in Prometheus Alertmanager, OpenSSL, Exim, snapd, Gross, curl and more. This week in Ubuntu Security Updates 185 unique CVEs addressed [ USN-6935-1 ] Prometheus Alertmanager vulnerability (01:08) 1 CVEs addressed in Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS) CVE-2023-40577 Stored XSS via the Alertmanager UI - alerts API allows to specify a URL which should be able to be called interactively by the user from the UI - an attacker instead could POST to this with arbitrary JavaScript which would then get included in the generated HTML and hence run on users when viewing the UI Fixed to validate this field is actually a URL before including in the generated UI page [ USN-6938-1 ] Linux kernel vulnerabilities (02:05) 31 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM) CVE-2024-35978 CVE-2024-35984 CVE-2024-35997 CVE-2024-26840 CVE-2024-27020 CVE-2023-52752 CVE-2021-47194 CVE-2021-46960 CVE-2024-26884 CVE-2024-36016 CVE-2023-52436 CVE-2024-36902 CVE-2024-26886 CVE-2023-52469 CVE-2024-26923 CVE-2023-52444 CVE-2023-52620 CVE-2021-46933 CVE-2024-35982 CVE-2023-52449 CVE-2024-26934 CVE-2024-26882 CVE-2024-26857 CVE-2021-46932 CVE-2024-26901 CVE-2024-25739 CVE-2024-24859 CVE-2024-24858 CVE-2024-24857 CVE-2023-46343 CVE-2022-48619 4.4 - generic, AWS, KVM, Low Latency, Virtual [ USN-6922-2 ] Linux kernel vulnerabilities 4 CVEs addressed in Jammy (22.04 LTS) CVE-2024-25739 CVE-2024-24859 CVE-2024-24858 CVE-2024-24857 6.5 lowlatency [ USN-6926-2 ] Linux kernel vulnerabilities 30 CVEs addressed in Trusty ESM (14.04 ESM), Bionic ESM (18.04 ESM) CVE-2023-52620 CVE-2023-52444 CVE-2024-26901 CVE-2023-52449 CVE-2024-27013 CVE-2024-26934 CVE-2024-35978 CVE-2024-27020 CVE-2023-52469 CVE-2024-35982 CVE-2024-35997 CVE-2023-52443 CVE-2024-36902 CVE-2024-26857 CVE-2024-36016 CVE-2023-52436 CVE-2023-52752 CVE-2024-26886 CVE-2024-35984 CVE-2023-52435 CVE-2024-26840 CVE-2024-26923 CVE-2024-26882 CVE-2024-26884 CVE-2024-25744 CVE-2024-25739 CVE-2024-24859 CVE-2024-24858 CVE-2024-24857 CVE-2023-46343 4.15 Azure [ USN-6895-4 ] Linux kernel vulnerabilities 100 CVEs addressed in Jammy (22.04 LTS) CVE-2024-26802 CVE-2024-26664 CVE-2023-52880 CVE-2024-26695 CVE-2024-27416 CVE-2024-26714 CVE-2024-26603 CVE-2024-26920 CVE-2024-26736 CVE-2024-26593 CVE-2024-26922 CVE-2024-26600 CVE-2024-26702 CVE-2024-26782 CVE-2024-26685 CVE-2024-26691 CVE-2024-26734 CVE-2024-26822 CVE-2024-35833 CVE-2024-26792 CVE-2024-26674 CVE-2024-26889 CVE-2024-26712 CVE-2024-26917 CVE-2024-26919 CVE-2023-52637 CVE-2024-26700 CVE-2024-26661 CVE-2024-26926 CVE-2023-52631 CVE-2024-26679 CVE-2024-26798 CVE-2024-26667 CVE-2024-26689 CVE-2024-26681 CVE-2024-26910 CVE-2024-26828 CVE-2024-26790 CVE-2024-26606 CVE-2024-26825 CVE-2024-26677 CVE-2024-26722 CVE-2024-26923 CVE-2024-26803 CVE-2024-26898 CVE-2023-52642 CVE-2024-26660 CVE-2024-26716 CVE-2023-52645 CVE-2024-26602 CVE-2024-26711 CVE-2024-26826 CVE-2024-26601 CVE-2024-26890 CVE-2024-26698 CVE-2024-26693 CVE-2024-26665 CVE-2024-26676 CVE-2024-26824 CVE-2024-26838 CVE-2024-26720 CVE-2024-26666 CVE-2024-26718 CVE-2024-26723 CVE-2024-26675 CVE-2024-26680 CVE-2024-26642 CVE-2024-26710 CVE-2024-26696 CVE-2024-26748 CVE-2024-26717 CVE-2024-26735 CVE-2024-26916 CVE-2024-26697 CVE-2024-26829 CVE-2024-26715 CVE-2024-26694 CVE-2024-26830 CVE-2024-26726 CVE-2024-26719 CVE-2024-26820 CVE-2024-26707 CVE-2024-26818 CVE-2024-26733 CVE-2024-26688 CVE-2023-52643 CVE-2024-26703 CVE-2024-26831 CVE-2024-26789 CVE-2024-26662 CVE-2024-26663 CVE-2024-26708 CVE-2024-26659 CVE-2024-26684 CVE-2023-52638 CVE-2024-24861 CVE-2024-23307 CVE-2024-1151 CVE-2024-0841 CVE-2023-6270 6.5 OEM [ USN-6937-1 ] OpenSSL vulnerabilities (03:04) 4 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS) CVE-2024-5535 CVE-2024-4741 CVE-2024-4603 CVE-2024-2511 Four low priority issues Possible UAF in SSL_free_buffers API - requires an application to directly call this function - across the entire Ubuntu package ecosystem there doesn’t appear to be any packages that do this so highly unlikely to be an issue in practice Similarly, in another rarely used function SSL_select_next_proto - if called with an empty buffer list would read other private memory - ie OOB read - and potentially then either crash or return private data but again this is not expected to occur in practice CPU-based DoS when validating long / crafted DSA keys simply check if using to large a modulus and error in that case If had set the SSL_OP_NO_TICKET option would possibly get into a state where the session cache would not be flushed and so would grow unbounded - memory based DoS [ USN-6913-2 ] phpCAS vulnerability (04:51) 1 CVEs addressed in Xenial ESM (16.04 ESM) CVE-2022-39369 [USN-6913-1] phpCAS vulnerability from Episode 233 [ USN-6936-1 ] Apache Commons Collections vulnerability (05:03) 1 CVEs addressed in Trusty ESM (14.04 ESM) CVE-2015-4852 Unsafe deserialisation - could allow to overwrite an object with an attacker controlled version containing code to be executed - RCE [ USN-6939-1 ] Exim vulnerability (05:31) 1 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS) CVE-2024-39929 Mishandles multiline filename header and so a crafted value could bypass the MIME type extension blocking mechanism - allowing executables etc to be delivered to users [ USN-6933-1 ] ClickHouse vulnerabilities (06:00) 5 CVEs addressed in Focal (20.04 LTS) CVE-2021-42388 CVE-2021-43305 CVE-2021-43304 CVE-2021-42387 real-time analytics DBMS Mostly written in C++ so not surprisingly has various memory safety issues All in the the LZ4 compression codec - uses an attacker controlled 16-bit unsiged value as the offset to read from the compressed data - then this value is also used when copying the data but there is no check on the upper bound so could index outside of the data Also a heap buffer overflow during this same data copy since doesn’t verify the size of the destination either [ USN-6940-1 ] snapd vulnerabilities (06:55) 3 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS) CVE-2024-29069 CVE-2024-29068 CVE-2024-1724 2 quite similar issues discovered by one of the engineers on the snapd team - Zeyad Gouda snaps are squashfs images - in general they are just mounted but certain files from the squashfs get extracted by snapd and placed on the regular file-system (ie. desktop files and icons for launchers etc) - as such, snapd would read the contents of these files and then write them out - if the file was actually a named pipe, snapd would block forever - DoS similarly, if the file was a symlink that pointed to an existing file on the file-system, when opening that file (which is a symlink) snapd would read the contents of the other file and write it out - recall these are desktop files etc so they get written to /usr/share/applications which is world-readable - so if the symlink pointed to /etc/shadow then you would get a copy of this written out as world-readable - so an unprivileged user on the system could then possibly escalate their privileges 3rd issue was AppArmor sandbox home interface allows snaps to read/write to your home directory On Ubuntu, if the bin directory exists, it gets automatically added to your PATH AppArmor policy for snapd took this into account and would stop snaps from writing files into this directory (and hence say creating a shell script that you would then execute later, outside of the snap sandbox) BUT it did not prevent a snap from creating this directory if it didn’t already exist [ USN-6941-1 ] Python vulnerability (11:15) 1 CVEs addressed in Noble (24.04 LTS) CVE-2024-4032 [USN-6928-1] Python vulnerabilities from Episode 233 [ USN-6909-2 ] Bind vulnerabilities (11:30) 2 CVEs addressed in Bionic ESM (18.04 ESM) CVE-2024-1975 CVE-2024-1737 2 different CPU-based DoS Didn’t restrict the number of resource records for a given hostname - if an attacker could arrange so a large number of RRs then could degrade the performace of bind due to it having to perform expensive lookups across all the records introduce a limit of 100 RRs for a given name Removed support DNSSEC SIG(0) transaction signatures since they could be abused to perform a CPU-based DoS [ USN-6943-1 ] Tomcat vulnerabilities (12:26) 5 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS) CVE-2022-29885 CVE-2022-23181 CVE-2021-41079 CVE-2021-25122 CVE-2020-9484 [ USN-6942-1 ] Gross vulnerability (12:33) 1 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS) CVE-2023-52159 greylisting server used in MTA setup to minimise spam - uses DNS block lists to tag mails which come from these domains as possible spam stack buffer overflow through the use of strncat() during logging would concatenate a list of parameters as string into a fixed size buffer on the stack but would pass the entire buffer size as the length argument rather than accounting for the remaining space in the buffer as these parameters can be controlled by an attacker can be used to either crash grossd or get RCE [ USN-6944-1 ] curl vulnerability (13:55) 1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS) CVE-2024-7264 Possible OOB read through crafted ASN.1 Generalized Time field when parsing TLS certificate chain - would potentially use a negative length value and hence try calculate the length of a string but pointing to the wrong memory region - crash / info leak Need to specifically use the https://curl.se/libcurl/c/CURLINFO_CERTINFO.html option though to be vulnerable [ USN-6200-2 ] ImageMagick vulnerabilities (14:52) 20 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS) CVE-2023-34151 CVE-2023-3195 CVE-2023-1289 CVE-2023-3428 CVE-2023-1906 CVE-2021-3610 CVE-2022-32547 CVE-2022-32546 CVE-2022-32545 CVE-2022-28463 CVE-2021-39212 CVE-2021-20313 CVE-2021-20312 CVE-2021-20246 CVE-2021-20309 CVE-2021-20244 CVE-2021-20243 CVE-2021-20241 CVE-2021-20224 CVE-2020-29599 [USN-6200-1] ImageMagick vulnerabilities from Episode 202 [ USN-6946-1 ] Django vulnerabilities (15:04) 4 CVEs addressed in Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS) CVE-2024-42005 CVE-2024-41991 CVE-2024-41990 CVE-2024-41989 SQL injection via crafted JSON in methods on the QuerySet class, and various DoS - one via very large inputs of Unicode characters in certain input fields, another through floatformat template filter - would use a large amount of memory if given a number in scientific notation with a large exponent [ USN-6945-1 ] wpa_supplicant and hostapd vulnerability (15:42) 1 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS) CVE-2024-5290 Possible privilege escalation through abuse of DBus method to get wpa_supplicant to load an attacker controlled shared object into memory Goings on in Ubuntu Security Community Discussion of CVE-2024-5290 in wpa_supplicant (16:10) Reported privately to us by Rory McNamara from Snyk as part of a larger disclosure of various security issues they had found Issue specific to Debian and Ubuntu - includes patch to the dbus policy for wpa_supplicant to allow various methods to be called by users in the netdev group historical hangover before we had network manager etc to do this nowadays, Network Manager allows the user who is logged in to control access to wireless networks etc historically though, Debian had the netdev group instead - so you would add your user to this group to allow them to configure network settings etc so makes sense to allow that group to control wpa_supplicant via its dbus interface DBus API includes a method called CreateInterface takes an argument called ConfigFile which specifies the path to a configuration file using the format of wpa_supplicant.conf config file includes a parameter for opensc_engine_path or similarly PKCS11 engine and module paths these are shared object which then get dynamically loaded into memory by wpa_supplicant hence could overwrite existing functions and therefore get code execution as root - since wpa_supplicant runs as root upstream actually includes a patch to hard-code these values at compile-time and not allow them to be specified in the config file BUT we don’t use this in Ubuntu since it was only introduced recently (so not all Ubuntu releases include it) but regardless, we want to support setups where these modules may live in different locations Discussed how to possibly fix this in LP: #2067613 Is not an issue for upstream since the upstream policy only allows root to use this dbus method so there is no privilege escalation Could allow-list various paths but was not clear which ones to use Lukas from Foundations team (and maintainer of Netplan) tried searching for any users of these config parameters but couldn’t find anything in the archive However, users may still be configuring things so don’t want to break their setups Or could tighten up the DBus policy for the netdev group to NOT include access to this method - but this may break existing things that are using the netdev group and this method Marc from our team then tried looking for anything in Ubuntu which used the wpa_supplicant DBus interface - none appear to make use of the netdev group Considered dropping support entirely for this feature which allows the netdev group access since in general this should be done with NetworkManager or netplan nowadays anyway But this is such a long-standing piece of functionality it wasn’t clear what the possible regression potential would be Or we could patch wpa_supplicant to check that the specified module was owned by root - this should then stop an unprivileged user from creating their own module and specifying it as it wouldn’t be owned by root This looked promising and a patch was drafted and tested against the proof-of-concept and was able to block it However, Rory came back with some excellent research showing it could be bypassed by some quite creative use of a crafted FUSE filesystem in combination with overlayfs inside an unprivileged user namespace (ie. unpriv userns strikes again) create a FUSE which lies about the uid of a file to say it is 0 (root) mount this as an unprivileged user create a new user and mount namespace through unshare within that (since you are “root”) mount an overlay filesystem using the FUSE fs Specify the path to this file using the special root link inside the proc filesystem - which points to the actual root directory of that process - and since the FUSE fs lies about the UID it looks like root owned So at this point we were running out of ideas - Luci from our team suggested manually walking the path to the specified file akin to how realpath works (which should block the ability to read it via the proc symlink) but this was considered too complicated and possibly prone to a TOCTOU race Finally Marc proposed to simply allow-list anything under /usr/lib - since anything installed from the archive would live here - in this case we simply call realpath() directly on the provided path name and if it doesn’t start with /usr/lib then deny loading of the module No way to race against this and would seem to have the least chance of regression Yes if using a non-standard location like /opt would now fail BUT if you can write to /opt then you can write to somewhere in /usr/lib - so is easy to fix as well Was tested significantly both with a dummy PKCS11 provider as well as a real one to ensure works as expected (both to prevent the exploit but also to work as intended) Eventual solution then was both secure but also would appear to minimise the chance of regressions None reported so far anyway ;) Demonstrates the careful balance between security and possible regressions Also the team effort of both the security team and other Ubuntu teams Thanks to Marc, Luci, Mark E, and Sudhakar on our side, and Lukas from Foundations, but most importantly to Rory from Snyk for both reporting the vuln but also in their help evaluating the various proposed solutions Get in contact security@ubuntu.com #ubuntu-security on the Libera.Chat IRC network ubuntu-hardened mailing list Security section on discourse.ubuntu.com @ubuntusecurity@fosstodon.org , @ubuntu_sec on twitter…

1
Episode 233 24:07

34 weeks پیش24:07

24:07

Overview This week we take a look at the recent Crowdstrike outage and what we can learn from it compared to the testing and release process for security updates in Ubuntu, plus we cover details of vulnerabilities in poppler, phpCAS, EDK II, Python, OpenJDK and one package with over 300 CVE fixes in a single update. This week in Ubuntu Security Updates 462 unique CVEs addressed [ USN-6915-1 ] poppler vulnerability (01:35) 1 CVEs addressed in Jammy (22.04 LTS), Noble (24.04 LTS) CVE-2024-6239 Installed by default in Ubuntu due to use by cups PDF document format describes a Catalog which has a tree of destinations - essentially hyperlinks within the document. These can be either a page number etc or a named location within the document. If open a crafted document with a missing name property for a destination - name would then be NULL and would trigger a NULL ptr deref -> crash -> DoS [ USN-6913-1 ] phpCAS vulnerability (02:26) 1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS) CVE-2022-39369 Authentication library for PHP to allow PHP applications to authenticates users against a Central Authentication Server (ie. SSO). When used for SSO, a client who is trying to use a web application gets directed to the CAS. The CAS then authenticates the user and returns a service ticket - the client then needs to validate this ticket with the CAS since it could have possibly been injected via the application. To do this, pass the ticket along with its own service identifier to CAS - and if this succeeds is provided with the details of which user was authenticated etc. For clients, previously would use HTTP headers to determine where the CAS server was to authenticate the ticket. Since these can be manipulated by a malicious application, could essentially redirect the client to send the ticket to the attacker who could then use that to impersonate the client and login as the user. Fix requires a refactor to include an additional API parameter which specifies either a fixed CAS server for the client to use, or a mechanism to auto-discover this in a secure way - either way, applications using phpCAS now need to be updated. [ USN-6914-1 ] OCS Inventory vulnerability 1 CVEs addressed in Jammy (22.04 LTS) CVE-2022-39369 Same as above since has an embedded copy of phpCAS [ USN-6916-1 ] Lua vulnerabilities (04:44) 2 CVEs addressed in Jammy (22.04 LTS) CVE-2022-33099 CVE-2022-28805 Heap buffer over-read and a possible heap buffer over-flow via recursive error handling - looks like both require to be interpreting malicious code [ USN-6920-1 ] EDK II vulnerabilities (05:04) 5 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM) CVE-2019-0160 CVE-2018-3613 CVE-2018-12183 CVE-2018-12182 CVE-2017-5731 UEFI firmware implementation in qemu etc Various missing bounds checks -> stack and heap buffer overflows -> DoS or code execution in BIOS context -> privilege escalation within VM [ USN-6928-1 ] Python vulnerabilities (05:49) 2 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS) CVE-2024-4032 CVE-2024-0397 Memory race in the ssl module - can call into various functions to get certificate information at the same time as certs are loaded if happening to be doing a TLS handshake with a certificate directory configured - all via different threads. Python would then possibly return inconsistent results leading to various issues Occurs since ssl module is implemented in C to interface with openssl and did not properly lock access to the certificate store [ USN-6929-1 , USN-6930-1 ] OpenJDK 8 and OpenJDK 11 vulnerabilities (06:52) 6 CVEs addressed in Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS) CVE-2024-21147 CVE-2024-21145 CVE-2024-21144 CVE-2024-21140 CVE-2024-21138 CVE-2024-21131 Latest upstream releases of OpenJDK 8 and 11 8u422-b05-1, 11.0.24+8 Fixes various issues in the Hotspot and Concurrency components [ USN-6931-1 , USN-6932-1 ] OpenJDK 17 and OpenJDK 21 vulnerabilities (07:11) 5 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS) CVE-2024-21147 CVE-2024-21145 CVE-2024-21140 CVE-2024-21138 CVE-2024-21131 Latest upstream releases of OpenJDK 17 and 21 17.0.12+7, 21.0.4+7 Fixes the same issues in the Hotspot component [ USN-6934-1 ] MySQL vulnerabilities (07:29) 15 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS) CVE-2024-21185 CVE-2024-21179 CVE-2024-21177 CVE-2024-21173 CVE-2024-21171 CVE-2024-21165 CVE-2024-21163 CVE-2024-21162 CVE-2024-21142 CVE-2024-21134 CVE-2024-21130 CVE-2024-21129 CVE-2024-21127 CVE-2024-21125 CVE-2024-20996 Also latest upstream release 8.0.39 Bug fixes, possible new features and incompatible changes - consult release notes: https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-38.html https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-39.html https://www.oracle.com/security-alerts/cpujul2024.html [ USN-6917-1 ] Linux kernel vulnerabilities (07:57) 156 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS) CVE-2024-35933 CVE-2024-35910 CVE-2024-27393 CVE-2024-27004 CVE-2024-27396 CVE-2024-36029 CVE-2024-26955 CVE-2024-35976 CVE-2024-26966 CVE-2024-26811 CVE-2024-35871 CVE-2023-52699 CVE-2024-35796 CVE-2024-35851 CVE-2024-35885 CVE-2024-35813 CVE-2024-35789 CVE-2024-35825 CVE-2024-26994 CVE-2024-35815 CVE-2024-27395 CVE-2024-26981 CVE-2024-35886 CVE-2024-26931 CVE-2024-35791 CVE-2024-35849 CVE-2024-35978 CVE-2024-35895 CVE-2024-35918 CVE-2024-35902 CVE-2024-26926 CVE-2024-35934 CVE-2024-35807 CVE-2024-35805 CVE-2024-36008 CVE-2024-26950 CVE-2024-26973 CVE-2024-35898 CVE-2024-35955 CVE-2024-36004 CVE-2024-36006 CVE-2024-35990 CVE-2024-35944 CVE-2024-36007 CVE-2024-35896 CVE-2024-35819 CVE-2024-26988 CVE-2024-35872 CVE-2024-36025 CVE-2024-26957 CVE-2024-35897 CVE-2024-27016 CVE-2024-35806 CVE-2024-35927 CVE-2022-48808 CVE-2024-35960 CVE-2024-27001 CVE-2024-35970 CVE-2024-35988 CVE-2024-36005 CVE-2024-35821 CVE-2024-35925 CVE-2024-26961 CVE-2024-35817 CVE-2024-26922 CVE-2024-26976 CVE-2024-35899 CVE-2024-35984 CVE-2024-26929 CVE-2024-27018 CVE-2024-35907 CVE-2024-35884 CVE-2023-52488 CVE-2024-35982 CVE-2024-26934 CVE-2024-26935 CVE-2024-35973 CVE-2024-26958 CVE-2024-27008 CVE-2024-35809 CVE-2024-26951 CVE-2024-35900 CVE-2024-35888 CVE-2024-26965 CVE-2024-26828 CVE-2024-35935 CVE-2024-35857 CVE-2024-26642 CVE-2024-26989 CVE-2024-35893 CVE-2024-35877 CVE-2024-27009 CVE-2024-35785 CVE-2024-35905 CVE-2024-27020 CVE-2024-35901 CVE-2024-26956 CVE-2024-26977 CVE-2024-26969 CVE-2024-26810 CVE-2024-26813 CVE-2024-35930 CVE-2024-26970 CVE-2024-26687 CVE-2024-27015 CVE-2024-35847 CVE-2024-26999 CVE-2024-35940 CVE-2024-35890 CVE-2024-26814 CVE-2024-35958 CVE-2024-35804 CVE-2024-26629 CVE-2024-26974 CVE-2023-52880 CVE-2024-26937 CVE-2024-35922 CVE-2024-35854 CVE-2024-27013 CVE-2024-35853 CVE-2024-27000 CVE-2024-35989 CVE-2024-35852 CVE-2024-35823 CVE-2024-36020 CVE-2024-36031 CVE-2024-26923 CVE-2024-26654 CVE-2024-26925 CVE-2024-35855 CVE-2024-35997 CVE-2024-35822 CVE-2024-27019 CVE-2024-35938 CVE-2024-35915 CVE-2024-35912 CVE-2024-35936 CVE-2024-35969 CVE-2024-27059 CVE-2024-26964 CVE-2024-27437 CVE-2024-26960 CVE-2024-35950 CVE-2024-26817 CVE-2024-26984 CVE-2024-26812 CVE-2024-35879 CVE-2024-26996 CVE-2024-26993 CVE-2024-25739 CVE-2024-24861 CVE-2024-24859 CVE-2024-24858 CVE-2024-24857 CVE-2024-23307 CVE-2022-38096 5.15 - Azure + FDE (CVM) [ USN-6918-1 ] Linux kernel vulnerabilities 180 CVEs addressed in Noble (24.04 LTS) CVE-2024-24859 CVE-2024-24858 CVE-2024-24857 CVE-2024-35932 CVE-2024-35937 CVE-2024-27006 CVE-2024-35960 CVE-2024-27011 CVE-2024-35924 CVE-2024-35946 CVE-2024-35942 CVE-2024-35921 CVE-2024-35908 CVE-2024-26811 CVE-2024-27008 CVE-2024-35871 CVE-2024-36019 CVE-2024-35965 CVE-2024-35973 CVE-2024-26981 CVE-2024-27009 CVE-2024-27019 CVE-2024-36022 CVE-2024-35910 CVE-2024-35907 CVE-2024-35860 CVE-2024-35951 CVE-2024-26924 CVE-2024-26921 CVE-2024-35901 CVE-2024-35972 CVE-2024-35889 CVE-2024-27017 CVE-2024-35913 CVE-2024-35936 CVE-2024-36025 CVE-2024-35961 CVE-2024-35977 CVE-2024-35902 CVE-2024-26817 CVE-2024-26994 CVE-2023-52699 CVE-2024-35868 CVE-2024-35899 CVE-2024-35888 CVE-2024-26995 CVE-2024-35865 CVE-2024-26993 CVE-2024-35863 CVE-2024-35970 CVE-2024-35943 CVE-2024-35875 CVE-2024-35978 CVE-2024-27005 CVE-2024-35909 CVE-2024-35957 CVE-2024-35950 CVE-2024-26986 CVE-2024-36020 CVE-2024-35952 CVE-2024-26928 CVE-2024-35878 CVE-2024-35954 CVE-2024-26998 CVE-2024-36024 CVE-2024-26936 CVE-2024-27018 CVE-2024-35900 CVE-2024-35940 CVE-2024-35985 CVE-2024-35944 CVE-2024-35958 CVE-2024-35864 CVE-2024-35975 CVE-2024-27002 CVE-2024-36018 CVE-2024-35974 CVE-2024-26926 CVE-2024-35877 CVE-2024-35916 CVE-2024-35934 CVE-2024-35930 CVE-2024-35898 CVE-2024-35893 CVE-2024-35887 CVE-2024-35929 CVE-2024-26923 CVE-2024-35911 CVE-2024-35919 CVE-2024-26984 CVE-2024-27016 CVE-2024-35926 CVE-2024-35872 CVE-2024-35922 CVE-2024-27007 CVE-2024-35931 CVE-2024-36021 CVE-2024-35953 CVE-2024-27004 CVE-2024-27001 CVE-2024-27014 CVE-2024-35866 CVE-2024-27021 CVE-2024-35870 CVE-2024-35925 CVE-2024-35891 CVE-2024-26982 CVE-2024-35879 CVE-2024-35979 CVE-2024-35912 CVE-2024-35982 CVE-2024-27015 CVE-2024-26985 CVE-2024-35861 CVE-2024-35939 CVE-2024-27003 CVE-2024-35945 CVE-2024-35967 CVE-2024-35966 CVE-2024-26983 CVE-2024-35894 CVE-2024-35896 CVE-2024-36027 CVE-2024-35895 CVE-2024-26987 CVE-2024-35873 CVE-2024-26996 CVE-2024-26991 CVE-2024-27013 CVE-2024-36026 CVE-2024-26922 CVE-2024-35897 CVE-2024-35917 CVE-2024-35968 CVE-2024-35890 CVE-2024-35904 CVE-2024-35867 CVE-2024-35933 CVE-2024-35918 CVE-2024-35920 CVE-2024-26997 CVE-2024-35981 CVE-2024-35963 CVE-2024-26989 CVE-2024-26999 CVE-2024-35892 CVE-2024-27010 CVE-2024-26992 CVE-2024-35935 CVE-2024-27022 CVE-2024-35971 CVE-2024-35956 CVE-2024-35862 CVE-2024-35969 CVE-2024-27012 CVE-2024-26990 CVE-2024-35885 CVE-2024-26925 CVE-2024-35905 CVE-2024-35914 CVE-2024-35884 CVE-2024-35927 CVE-2024-35882 CVE-2024-26980 CVE-2024-35964 CVE-2024-35955 CVE-2024-27020 CVE-2024-35980 CVE-2024-35903 CVE-2024-35976 CVE-2024-35886 CVE-2024-35883 CVE-2024-35959 CVE-2024-35915 CVE-2024-35880 CVE-2024-27000 CVE-2024-35938 CVE-2024-35869 CVE-2024-36023 CVE-2024-26988 6.8 - Oracle [ USN-6919-1 ] Linux kernel vulnerabilities 304 CVEs addressed in Jammy (22.04 LTS) CVE-2024-35976 CVE-2023-52880 CVE-2024-35849 CVE-2024-27073 CVE-2024-35934 CVE-2024-27038 CVE-2024-26973 CVE-2024-35853 CVE-2024-27047 CVE-2024-36007 CVE-2024-27024 CVE-2024-26750 CVE-2024-26833 CVE-2024-26960 CVE-2024-26929 CVE-2023-52488 CVE-2024-27417 CVE-2024-26922 CVE-2024-26863 CVE-2024-35890 CVE-2024-27015 CVE-2024-27395 CVE-2024-26779 CVE-2024-27419 CVE-2024-27013 CVE-2024-26981 CVE-2024-26798 CVE-2024-26895 CVE-2024-35922 CVE-2023-52699 CVE-2024-26883 CVE-2024-35871 CVE-2024-27410 CVE-2024-26884 CVE-2024-26885 CVE-2024-27074 CVE-2024-26751 CVE-2024-26857 CVE-2024-26848 CVE-2024-26901 CVE-2024-35844 CVE-2024-35809 CVE-2024-26687 CVE-2024-35988 CVE-2024-26835 CVE-2024-26764 CVE-2024-27020 CVE-2024-35907 CVE-2024-35886 CVE-2024-27077 CVE-2024-26787 CVE-2024-26950 CVE-2024-26974 CVE-2024-35905 CVE-2024-27008 CVE-2024-26744 CVE-2024-35935 CVE-2024-26988 CVE-2024-26748 CVE-2024-26776 CVE-2024-26907 CVE-2024-27053 CVE-2024-35970 CVE-2024-35950 CVE-2024-35854 CVE-2024-35822 CVE-2024-26961 CVE-2024-26733 CVE-2024-26773 CVE-2024-27390 CVE-2024-35888 CVE-2024-36029 CVE-2024-26643 CVE-2024-35821 CVE-2024-35819 CVE-2024-26809 CVE-2024-35984 CVE-2024-26851 CVE-2024-35940 CVE-2024-26654 CVE-2024-35910 CVE-2024-26891 CVE-2024-26793 CVE-2024-35938 CVE-2024-26736 CVE-2024-26583 CVE-2024-26870 CVE-2024-35828 CVE-2024-35885 CVE-2024-35958 CVE-2024-26889 CVE-2024-35899 CVE-2024-26839 CVE-2024-26894 CVE-2024-26937 CVE-2024-35925 CVE-2024-35933 CVE-2024-26771 CVE-2024-26923 CVE-2024-26852 CVE-2024-26924 CVE-2024-26872 CVE-2024-26774 CVE-2024-35930 CVE-2024-27065 CVE-2024-26993 CVE-2024-27034 CVE-2024-36020 CVE-2024-26802 CVE-2024-26976 CVE-2022-48808 CVE-2024-35847 CVE-2024-26996 CVE-2024-36025 CVE-2023-52652 CVE-2024-27403 CVE-2023-52447 CVE-2024-27037 CVE-2024-27413 CVE-2024-26749 CVE-2024-26956 CVE-2024-26958 CVE-2024-26754 CVE-2024-26812 CVE-2024-26772 CVE-2024-27436 CVE-2024-27437 CVE-2024-35912 CVE-2024-35805 CVE-2024-26845 CVE-2024-35990 CVE-2024-35791 CVE-2024-26906 CVE-2024-27039 CVE-2024-26915 CVE-2024-26970 CVE-2024-26782 CVE-2024-26813 CVE-2023-52645 CVE-2024-26935 CVE-2024-27076 CVE-2024-35823 CVE-2024-26743 CVE-2024-26846 CVE-2024-26811 CVE-2024-26989 CVE-2024-26642 CVE-2024-26659 CVE-2024-26766 CVE-2024-27393 CVE-2024-26859 CVE-2024-35898 CVE-2024-35893 CVE-2023-52640 CVE-2024-26795 CVE-2024-27009 CVE-2024-26791 CVE-2024-27043 CVE-2024-26934 CVE-2024-27051 CVE-2024-26804 CVE-2024-26878 CVE-2024-27030 CVE-2024-27000 CVE-2024-26777 CVE-2024-35825 CVE-2024-27415 CVE-2024-27001 CVE-2024-27004 CVE-2024-26769 CVE-2024-26816 CVE-2024-35807 CVE-2024-35900 CVE-2024-35851 CVE-2024-27052 CVE-2024-26805 CVE-2024-35804 CVE-2024-35944 CVE-2024-35895 CVE-2024-26897 CVE-2024-27045 CVE-2024-26814 CVE-2024-26801 CVE-2024-26874 CVE-2024-35982 CVE-2024-35915 CVE-2024-26820 CVE-2024-26603 CVE-2024-35997 CVE-2024-26688 CVE-2024-27054 CVE-2024-26828 CVE-2024-35857 CVE-2023-52662 CVE-2024-35989 CVE-2024-36005 CVE-2024-35785 CVE-2024-27396 CVE-2024-35884 CVE-2023-52650 CVE-2024-26882 CVE-2024-26879 CVE-2024-26898 CVE-2024-27388 CVE-2024-35879 CVE-2024-35918 CVE-2024-35978 CVE-2024-26585 CVE-2024-35872 CVE-2023-52497 CVE-2024-26778 CVE-2024-26999 CVE-2024-27046 CVE-2023-52434 CVE-2024-26862 CVE-2024-26810 CVE-2024-35796 CVE-2024-35960 CVE-2024-35969 CVE-2024-26966 CVE-2024-26856 CVE-2024-35936 CVE-2024-35955 CVE-2024-26763 CVE-2024-35806 CVE-2024-27059 CVE-2024-35855 CVE-2024-36008 CVE-2024-27075 CVE-2023-52620 CVE-2024-26931 CVE-2024-35813 CVE-2024-26788 CVE-2024-27412 CVE-2024-26861 CVE-2024-36004 CVE-2024-26951 CVE-2024-26903 CVE-2024-26584 CVE-2024-35877 CVE-2024-26792 CVE-2024-27416 CVE-2024-27432 CVE-2024-26651 CVE-2024-35852 CVE-2024-35973 CVE-2023-52656 CVE-2024-26965 CVE-2024-26969 CVE-2024-26840 CVE-2024-26817 CVE-2024-27028 CVE-2024-26752 CVE-2024-27016 CVE-2023-52641 CVE-2024-35789 CVE-2024-27078 CVE-2024-26994 CVE-2024-26629 CVE-2024-26803 CVE-2024-26977 CVE-2024-35830 CVE-2024-27019 CVE-2024-26957 CVE-2024-36006 CVE-2024-35817 CVE-2024-26601 CVE-2024-35845 CVE-2024-35897 CVE-2024-27414 CVE-2024-26855 CVE-2024-26877 CVE-2024-35829 CVE-2024-35896 CVE-2024-26875 CVE-2024-27405 CVE-2024-26747 CVE-2023-52644 CVE-2024-26881 CVE-2024-26735 CVE-2024-26843 CVE-2024-26926 CVE-2024-26880 CVE-2024-26964 CVE-2024-27044 CVE-2024-26737 CVE-2024-27431 CVE-2024-26955 CVE-2024-26790 CVE-2024-26925 CVE-2024-26838 CVE-2024-26984 CVE-2024-25739 CVE-2024-24861 CVE-2024-24859 CVE-2024-24858 CVE-2024-24857 CVE-2024-23307 CVE-2024-22099 CVE-2024-21823 CVE-2024-0841 CVE-2023-7042 CVE-2023-6270 CVE-2022-38096 5.15 - Raspi [ USN-6922-1 ] Linux kernel vulnerabilities 4 CVEs addressed in Jammy (22.04 LTS) CVE-2024-25739 CVE-2024-24859 CVE-2024-24858 CVE-2024-24857 6.5 - NVIDIA [ USN-6923-1 , USN-6923-2 ] Linux kernel vulnerabilities 6 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS) CVE-2024-36016 CVE-2024-27017 CVE-2023-52752 CVE-2024-26952 CVE-2024-26886 CVE-2024-25742 5.15 - generic, AWS, GCP, GKE, HWE, Intel-IOTG, KVM, LowLatency, NVIDIA, Oracle, IBM, Raspi [ USN-6921-1 , USN-6921-2 ] Linux kernel vulnerabilities 7 CVEs addressed in Noble (24.04 LTS) CVE-2024-36016 CVE-2024-36008 CVE-2024-35984 CVE-2024-35992 CVE-2024-35997 CVE-2024-35990 CVE-2024-25742 6.8 - generic, AWS, GCP, GKE, IBM, NVIDIA, OEM, Raspi, LowLatency [ USN-6924-1 , USN-6924-2 ] Linux kernel vulnerabilities 7 CVEs addressed in Bionic ESM (18.04 ESM), Focal (20.04 LTS) CVE-2024-26583 CVE-2022-48655 CVE-2024-26907 CVE-2021-47131 CVE-2024-26585 CVE-2024-36016 CVE-2024-26584 5.4 - generic, AWS, Azure, Bluefield, GCP, GKE, HWE, IBM, IOT, KVM, Raspi, Xilinx-ZynqMP [ USN-6925-1 ] Linux kernel vulnerability 1 CVEs addressed in Trusty ESM (14.04 ESM) CVE-2024-26882 3.13 - generic, lowlatency, server, virtual [ USN-6926-1 ] Linux kernel vulnerabilities 30 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM) CVE-2023-52752 CVE-2023-52444 CVE-2024-26882 CVE-2023-52449 CVE-2024-26934 CVE-2024-26840 CVE-2024-36016 CVE-2024-27020 CVE-2023-52443 CVE-2024-26923 CVE-2024-26857 CVE-2024-36902 CVE-2024-35982 CVE-2024-26886 CVE-2024-35978 CVE-2023-52469 CVE-2024-26901 CVE-2024-26884 CVE-2023-52436 CVE-2024-35997 CVE-2023-52620 CVE-2024-35984 CVE-2024-27013 CVE-2023-52435 CVE-2024-25744 CVE-2024-25739 CVE-2024-24859 CVE-2024-24858 CVE-2024-24857 CVE-2023-46343 4.15 - generic, AWS, HWE, GCP, KVM, Oracle [ USN-6927-1 ] Linux kernel vulnerabilities 161 CVEs addressed in Focal (20.04 LTS) CVE-2024-27008 CVE-2024-26951 CVE-2024-26970 CVE-2024-35815 CVE-2024-26828 CVE-2024-35898 CVE-2024-26999 CVE-2024-35938 CVE-2024-27016 CVE-2024-35825 CVE-2024-35950 CVE-2024-26969 CVE-2024-26643 CVE-2024-26924 CVE-2024-36025 CVE-2023-52752 CVE-2024-35936 CVE-2024-35847 CVE-2024-26964 CVE-2024-35857 CVE-2024-35854 CVE-2024-27437 CVE-2024-35851 CVE-2024-26654 CVE-2024-26629 CVE-2024-26988 CVE-2024-27001 CVE-2024-26956 CVE-2024-35990 CVE-2024-27020 CVE-2024-26996 CVE-2024-35817 CVE-2024-26950 CVE-2024-26810 CVE-2024-35893 CVE-2024-35852 CVE-2024-35895 CVE-2024-27009 CVE-2024-26687 CVE-2024-35821 CVE-2024-35944 CVE-2024-27015 CVE-2024-35822 CVE-2024-35823 CVE-2024-35890 CVE-2024-35973 CVE-2024-27013 CVE-2024-35912 CVE-2024-26817 CVE-2024-35935 CVE-2024-26989 CVE-2024-35877 CVE-2024-26926 CVE-2024-35849 CVE-2024-26993 CVE-2024-26974 CVE-2024-35791 CVE-2024-35910 CVE-2024-36008 CVE-2024-35988 CVE-2024-26813 CVE-2024-36006 CVE-2024-35879 CVE-2024-35789 CVE-2024-35969 CVE-2024-35925 CVE-2024-26984 CVE-2024-35871 CVE-2024-35853 CVE-2024-27004 CVE-2024-35899 CVE-2024-26931 CVE-2024-35934 CVE-2024-35796 CVE-2024-36020 CVE-2023-52699 CVE-2024-35930 CVE-2024-26957 CVE-2024-35804 CVE-2024-26922 CVE-2024-26814 CVE-2024-35900 CVE-2024-27395 CVE-2024-26642 CVE-2024-26960 CVE-2024-26935 CVE-2024-36005 CVE-2024-26981 CVE-2024-26934 CVE-2024-26976 CVE-2024-35806 CVE-2024-35915 CVE-2024-35922 CVE-2022-48808 CVE-2024-26973 CVE-2024-35933 CVE-2024-35785 CVE-2024-26937 CVE-2024-35918 CVE-2024-27000 CVE-2024-26977 CVE-2024-27393 CVE-2024-35984 CVE-2024-35970 CVE-2024-27019 CVE-2024-26955 CVE-2024-35888 CVE-2024-35976 CVE-2024-35982 CVE-2024-35805 CVE-2024-35960 CVE-2024-26812 CVE-2024-27017 CVE-2024-26966 CVE-2023-52880 CVE-2024-27396 CVE-2024-35809 CVE-2024-35997 CVE-2024-26958 CVE-2024-26961 CVE-2024-26923 CVE-2024-26811 CVE-2024-35813 CVE-2024-36029 CVE-2024-35896 CVE-2024-26965 CVE-2024-35885 CVE-2024-35855 CVE-2024-36007 CVE-2024-26929 CVE-2024-35897 CVE-2024-35905 CVE-2024-27018 CVE-2024-26886 CVE-2024-35884 CVE-2023-52488 CVE-2024-36016 CVE-2024-35872 CVE-2024-35819 CVE-2024-35907 CVE-2024-26952 CVE-2024-35940 CVE-2024-35989 CVE-2024-27059 CVE-2024-26925 CVE-2024-35955 CVE-2024-36004 CVE-2024-26994 CVE-2024-35807 CVE-2024-35886 CVE-2024-35978 CVE-2024-35958 CVE-2024-35902 CVE-2024-25742 CVE-2024-25739 CVE-2024-24861 CVE-2024-24859 CVE-2024-24858 CVE-2024-24857 CVE-2024-23307 CVE-2022-38096 5.15 - GCP Goings on in Ubuntu Security Community Discussion of testing for security updates in light of CrowdStrike (11:20) Recent outage of over 8 million Windows machines running CrowdStrike Falcon https://www.crowdstrike.com/falcon-content-update-remediation-and-guidance-hub/ Initially very little information on what happened - CS have now released more details about the apparent testing that was done but clearly were never actually testing the combination of Windows + Falcon + Rapid Response Content otherwise would have observed this failure immediately Also clearly didn’t have any kind of staged/phased update process in place either If you want to read a good analysis of the response from CS, https://verse.systems/blog/post/2024-07-25-parsing-crowdstrikes-post/ Toby Murray (full disclosure, my brother) - Associate Professor and Co-Lead of Computer Science Research Group at School of Computing and Information Systems, University of Melbourne, Director, Defence Science Institute (Vic & Tas) Future plans from CS now include gradual deployment of rules with “canaries” etc and then increased testing: Local dev testing, content update testing, stress, fuzz, fault-injection, stability and interface testing Toby (not surprisingly as an expert in formal software verification) advocates for a formal approach to validating rules and in-kernel code etc What can we learn from this for Ubuntu? Formal methods might be tractable for a large company like CS who is developing a single, specific product like Falcon (particularly if they can reduce the size of their kernel module), this is not the case for a Linux distribution like Ubuntu which collates over 30,000 different open source software projects over 4TB of source code across the various releases Instead have to take the pragmatic approach of thorough testing For regular SRUs - detailed review by SRU team including a thorough test plan, cross-package testing via Autopkgtest plus a minimum 7 day “soak” testing in the proposed pocket of the release before being pushed into the -updates pocket Once in -updates, Phased Updates implements the gradual deployment model - you can check the progress of various updates at https://ubuntu-archive-team.ubuntu.com/phased-updates.html Watches for increased error reports via errors.ubuntu.com (captured via apport/whoopsie) and if detected stops the release of the package to users Compare that to the process for Security updates Separate -security pocket in the archive which packages get published to immediately No standardised review by separate team instead adhoc reviews within the security team No documented test plan per update instead thorough test procedures including: checking for any changes in the build log (e.g. new compiler warnings/errors) and comparing the difference between the generated binaries (e.g. new / changed / missing symbols - ABI breaks) testing of the patched code including stepping through it with a debugger running any existing PoC or creating one if none exists and is feasible running any existing unit/integration tests within the package (including dep8/autopkgtests) test apt upgrade of the package is smooth QA regression testing scripts - maintained by the security team, implement various regression tests and system-level tests for different packages to exercise them in various different configurations Cross-package testing via security-britney - instance of the autopkgtest infrastructure that runs against the public Ubuntu Security Proposed PPA (and we have a similar internal instance for the different private PPAs we use for embargoed updates or ESM etc) No phased updates - instead immediate updates via specific security.ubuntu.com archive, combined with unattended-upgrades designed to deliver security updates as soon as possible to remediate issues In general, I would argue that the process we have in place results in more thorough testing for security updates - particularly checking for anything anomalous like new compiler warnings / symbols / unexpected changes in binaries etc as well as more thorough, standardised testing for packages through the QA Regression Testing repo scripts However, the lack of phased/progressive updates combined with the separate security.ubuntu.com archive and unattended-upgrades on by default, means any security update is delivered to Ubuntu users within 24 hours (on average) - BUT then any regression is also rolled out to all users in 24 hours as well As such, kicking off discussions around possible changes to our deployment strategy to potentially introduce some more guard rails on the deployment side If you have any thoughts, please let us know Get in contact security@ubuntu.com #ubuntu-security on the Libera.Chat IRC network ubuntu-hardened mailing list Security section on discourse.ubuntu.com @ubuntusecurity@fosstodon.org , @ubuntu_sec on twitter…

1
Episode 232 29:20

38 weeks پیش29:20

29:20

Overview This week we deep-dive into one of the best vulnerabilities we’ve seen in a long time regreSSHion - an unauthenticated, remote, root code-execution vulnerability in OpenSSH. Plus we cover updates for Plasma Workspace, Ruby, Netplan, FontForge, OpenVPN and a whole lot more. This week in Ubuntu Security Updates 39 unique CVEs addressed [ USN-6843-1 ] Plasma Workspace vulnerability (01:23) 1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Mantic (23.10), Noble (24.04 LTS) CVE-2024-36041 KDE Session Manager - used for restoring previously running applications at next boot Provides ability to clients to connect to it via Inter-Client Exchange (ICE) protocol - protocol within X for allowing X clients to interact with one-another Since X supports remote clients, is important to authenticate connections - in this case KDE SM would authenticate to ensure the connection was coming from the local machine - but this could then allow any local user to connect to another users SM and hence use the session management features to set some arbitrary application to be run when the session is restored - as that other user [ USN-6852-1 , USN-6852-2 ] Wget vulnerability (02:42) 1 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Mantic (23.10), Noble (24.04 LTS) CVE-2024-38428 mishandled semicolons in userinfo of a URL - this is the user@host:port combination - so would possibly then use a different hostname than the one the user expected [ USN-6853-1 ] Ruby vulnerability (03:12) 1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Mantic (23.10) CVE-2024-27280 Provides methods ungetbyte()/ungetc() to push-back characters on an IO stream - would possibly read beyond the end of the buffer - OOB read [ USN-6851-1 ] Netplan vulnerabilities (03:37) 1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Mantic (23.10), Noble (24.04 LTS) CVE-2022-4968 Two different issues When configuring a Wireguard interface, would write the wireguard private key into the netplan interface configuration - but would then leave this with world-readable permissions This can either be specified as the filename to the private key OR the private key itself - so if had chosen to specify the actual private key, this is now world-readable to any other user Fixed to use restrictive permissions on the generated configuration files and to fixup any existing ones as well Failed to escape control characters in various backend files - a malicious application that is able to create a netplan configuration could then abuse this to get code execution as netplan [ USN-6851-2 ] Netplan regression Affecting Focal (20.04 LTS), Jammy (22.04 LTS), Mantic (23.10), Noble (24.04 LTS) Failed to properly do the permissions fixup on already existing files [ USN-6854-1 ] OpenSSL vulnerability (05:10) 1 CVEs addressed in Jammy (22.04 LTS) CVE-2022-40735 Related to a historical vulnerability - https://dheatattack.gitlab.io/ - CVE-2002-20001 DoS against Diffie-Hellman key exchange protocol - during key negotiation a client can trigger expensive CPU calculations -> CPU-based DoS [ USN-6856-1 ] FontForge vulnerabilities (05:50) 2 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Mantic (23.10) CVE-2024-25082 CVE-2024-25081 Uses various external utilities to do things like decompress archive files etc However, would do this via the system() system-call - which spawns a shell - so if a filename contained any shell metacharacters, could then just easily get arbitrary code execution Changed to use the utility functions from glib that do not spawn a shell and instead just exec() the expected command directly [ USN-6857-1 ] Squid vulnerabilities (06:48) 6 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM) CVE-2024-25617 CVE-2023-50269 CVE-2023-49286 CVE-2023-49285 CVE-2022-41318 CVE-2021-28651 [ USN-6566-2 ] SQLite vulnerability 1 CVEs addressed in Bionic ESM (18.04 ESM) CVE-2023-7104 [ USN-5615-3 ] SQLite vulnerability 3 CVEs addressed in Trusty ESM (14.04 ESM) CVE-2021-20223 CVE-2020-35527 CVE-2020-35525 [ USN-6855-1 ] libcdio vulnerability (06:58) 1 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Mantic (23.10), Noble (24.04 LTS) CVE-2024-36600 ISO file parser - used strcpy() instead of strncpy() so could be made to quite easily achieve buffer overflow and hence possible code-execution [ USN-6858-1 ] eSpeak NG vulnerabilities (07:33) 5 CVEs addressed in Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Mantic (23.10) CVE-2023-49994 CVE-2023-49993 CVE-2023-49992 CVE-2023-49991 CVE-2023-49990 speech synthesiser - pass file to it and it will read it aloud various buffer overflows when parsing different formats - found by a researcher via fuzzing [ USN-6844-2 ] CUPS regression (07:51) Affecting Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Mantic (23.10), Noble (24.04 LTS) [USN-6844-1] CUPS vulnerability from Episode 231 [ USN-6860-1 ] OpenVPN vulnerabilities (07:57) 2 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Mantic (23.10), Noble (24.04 LTS) CVE-2024-5594 CVE-2024-28882 Client was able to keep the session alive even when the server had been instructed to disconnect the client Client was able to send junk/non-printable characters in the control channel since would then get logged and possibly allow to corrupt the log file or cause high CPU load [ USN-6862-1 ] Firefox vulnerabilities (08:27) 13 CVEs addressed in Focal (20.04 LTS) CVE-2024-5696 CVE-2024-5695 CVE-2024-5694 CVE-2024-5688 CVE-2024-5701 CVE-2024-5700 CVE-2024-5699 CVE-2024-5698 CVE-2024-5697 CVE-2024-5693 CVE-2024-5691 CVE-2024-5690 CVE-2024-5689 127.0.2 [ USN-6859-1 ] OpenSSH vulnerability 1 CVEs addressed in Jammy (22.04 LTS), Mantic (23.10), Noble (24.04 LTS) CVE-2024-6387 Goings on in Ubuntu Security Community Deep-dive into regreSSHion - Remote Unauthenticated Code Execution Vulnerablity in OpenSSH https://blog.qualys.com/vulnerabilities-threat-research/2024/07/01/regresshion-remote-unauthenticated-code-execution-vulnerability-in-openssh-server https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion.txt https://ubuntu.com/blog/ubuntu-regresshion-security-fix First notified late last week by Qualys of a pending update for OpenSSH which fixes a newly discovered unauthenticated remote code execution vulnerability - as root - this is about as bad as it can get Exactly the kind of thing that “Jia Tan” spent all that time working on in xz-utils to try and achieve ( xz-utils backdoor and Ubuntu from Episode 224 ) Qualys are quite specific to note that this only affects OpenSSH on glibc (so distros which use say musl are not affected) - due to the intricacies of the vulnerablity and how they exploit it Also OpenSSH is quite carefully designed - employs privilege separation to try keep the privileged part as minimal as possible - but in this case, the vuln is in this privielged part, hence why code execution as root OpenSSH developers released 9.8p1 on Monday this week which has some quite significant refactoring to help address this vuln - in particular it includes functionality similar to fail2ban to penalise clients that appear to be malicious AND it employs even more privilege separation than before Qualys are quite careful to say that they think OpenSSH is one of the most secure pieces of software in the world “near-flawless implementation” with inspirational defense-in-depth - but clearly bugs still slip through In this case is a signal handler race condition Diversion - what are signals? signal (7) simple, asynchronous form of IPC which allows sending a single piece of information - the type of signal many different types - e.g. SIGSEGV for invalid memory access, or SIGFPE for a math error - or can be sent by other processes - SIGTERM / SIGKILL / SIGINT process can then set itself up so that a particular signal handler function of its choosing is invoked for a given signal when a signal is sent to a process, it is queued up and then delivered to a process the next time the kernel returns from kernel space to that process - ie. when returning from a system-call or scheduling of that process to deliver it, kernel constructs an entirely new stack frame and passes execution to the signal handler function - this runs and then eventually returns control back to the original thread of the process Signal handlers are special - since they run on their own special stack and outside of the normal thread of execution of the process, they can potentially cause issues if they do things which modify the global state of the process - many regular functions are off-limits within signal handlers since they can inadvertently modify such global state only some functions are hence async-signal-safe (7) list contains a lot of functions BUT many which might ordinarily get used are not included - in particular malloc()/free() This vuln was caused then by use of one of these async unsafe functions OpenSSH has a functionality called LoginGraceTime which allows an admin to configure how long OpenSSH will allow a client to take to login - if they don’t log in in that time then it closes the connection Since this code is all single-threaded, can’t just have the code which is listening to the client connection bail out easily - so instead this is implemented via the SIGALARM signal - used by the alarm (2) system call to configure the SIGALARM signal to be delivered to a process some number of seconds later Unfortunately in the signal handler function for this SIGALARM, OpenSSH can end up calling syslog() when trying to which is one of those unsafe functions in glibc syslog() will potentially call malloc()/free() which as we mentioned earlier is not async safe it is possible that the original thread may be in the middle of a call to malloc() / free() and then SIGALARM signal is delivered (since malloc()/free() calls brk (2) system call under the hood and so a pending signal SIGALARM may be delivered on return from brk() ) both the original thread and the signal handler are then calling malloc() at the same time - corrupting the global state of the heap etc as we know, if can corrupt the heap state ‘correctly’ can get code execution but requires the ability to win this race In fact, this is a reoccurrence of historical CVE-2006-5051 - discovered by Mark Dowd but subsequently fixed code in question was refactored in October 2020 and released in OpenSSH 8.5p1 which would then call syslog() during the SIGALARM signal handler To exploit this, Qualys take inspiration from a 2001 paper by Michal Zalewski (aka lcamtuf previously Director of Information Security Engineering at Google and now VP Security Engineering at Snap (ie Snapchat etc)) Even so, it is an incredibly difficult path to get to a working exploit - both since this is a race-condition so it is very hard to get the right timing conditions and second due to defence-in-depth measures like ASLR First develop an exploit for the original 2006 CVE against a couple older versions OpenSSH 3.4p1 on Debian Woody even on i386 which has much worse ASLR than amd64, takes 10,000 tries to win the race - even then with 10 concurrent connections and each with a LoginGraceTime of 5 minutes - ~1week to get a remote root shell OpenSSH 4.2p1 on Ubuntu 6.06 (Dapper Drake) - first LTS version of Ubuntu - this vuln was patched during the lifetime of 6.06 release but original install media still contains the unpatched version Similarly, takes ~10,000 tries to win the race - with LoginGraceTime of only 2 minutes can reduce the time to get a remote root shell to 1-2 days Finally, OpenSSH 9.2p1 from current Debian stable on i386 10,000 tries - now 100 connections with 2 minutes grace time - in practice still ~6-8 hours since still have to guess the address used by glibc and due to ASLR is only 50% accurate All of these are lab conditions - VMs with quite stable network - and only on i386 - but Qualys say they were starting on an exploit even for amd64 but didn’t continue after they noticed a related bug report about this async-unsafe signal handling - so decided that may draw attention to the issue and others may discover the vuln and start exploiting it - so best to disclose it in its current state For Ubuntu, since this only affects version since 8.5p1, only 22.04 LTS onwards were affected - we released patches on Monday - unattended-upgrades is enabled by default on all relases since 16.04 LTS anyway - checks for and installs security updates every 24 hours - so any affected Ubuntu users would likely have been automatically patched within ~24 of the vuln becoming public (and the restart logic in OpenSSH would have restarted the service when it got upgraded as well) Other thing which is more internal for Ubuntu is that Qualys explicitly called out OpenSSH in 24.04 LTS as having a deficiency in the enablement of ASLR - since we are using systemd socket activation we disable reexec support for OpenSSH - so it never reexecutes itself for its child processes - so they never get the benefit of ASLR - BUT by chance it also makes this unexploitable since it changes the use of syslog() within OpenSSH so that syslog() gets called early on in the use of OpenSSH and so then when it gets called in the SIGALARM signal handler it doesn’t do the same memory allocation and hence can’t be used to corrupt memory and get code execution Get in contact security@ubuntu.com #ubuntu-security on the Libera.Chat IRC network ubuntu-hardened mailing list Security section on discourse.ubuntu.com @ubuntusecurity@fosstodon.org , @ubuntu_sec on twitter…

1
Episode 231 19:00

39 weeks پیش19:00

19:00

Overview A look into CISA’s Known Exploited Vulnerability Catalogue is on our minds this week, plus we look at vulnerability updates for gdb, Ansible, CUPS, libheif, Roundcube, the Linux kernel and more. This week in Ubuntu Security Updates 175 unique CVEs addressed [ USN-6842-1 ] gdb vulnerabilities (01:10) 6 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS) CVE-2023-39130 CVE-2023-39129 CVE-2023-39128 CVE-2023-1972 CVE-2022-4285 CVE-2020-16599 a couple of these are inherited from binutils as they share that code - parsing of crafted ELF executables -> NULL ptr deref or possible heap based buffer overflow -> DoS/RCE other stack and heap buffer overflows as well - parsing of crafted ada files and crafted debug info files as well -> DoS/RCE [ USN-6845-1 ] Hibernate vulnerability (02:12) 1 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS) CVE-2020-25638 Object relational-mapping (ORM) library for Java SQL injection in the JPA Criteria API implementation - could allow unvalidated literals when they are used in the SQL comments of a query when logging is enabled - fixed by properly escaping comments in this case [ USN-6846-1 ] Ansible vulnerabilities (02:46) 2 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS) CVE-2023-5764 CVE-2022-3697 Possibly would leak the password into log file when using the AWS EC2 module since failed to validate the tower_callback (nowadays is called aap_callback - Ansible Automation Platform) parameter appropriately Allows to mark variables as unsafe - in that they may come from an external, untrusted source - won’t get evaluated/expanded when used to avoid possible info leaks etc - various issues where ansible would fail to respect this and essentially forget they were tagged as unsafe and end up exposing secrets as a result [ USN-6844-1 ] CUPS vulnerability (04:08) 1 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Mantic (23.10), Noble (24.04 LTS) CVE-2024-35235 When starting, cups would arbitrarily chmod the socket specified as the Listen parameter to make it world-writable - if this was a symlink, would then make the target of the symlink world-readable - in general the cups config file is only writable by root so requires some other vuln to be able to exploit it where you can get write access to the config file to exploit it OR be able to replace the regular cups socket path with a user-controlled symlink - but if you can, then you can even change the cups config itself to be world-writable and hence modify other parameters like the user and group that cups should run as, as well as a crafted FoomaticRIPCommandLine then can run arbitrary commands as root [ USN-6849-1 ] Salt vulnerabilities (06:20) 2 CVEs addressed in Trusty ESM (14.04 ESM) CVE-2020-11652 CVE-2020-11651 Failed to properly validate paths in some methods and also failed to restrict access to other methods, allowing them to be used without authentication - could then either allow arbitrary directory access or the ability to retrieve tokens from the master or run arbitrary commands on minions [ USN-6746-2 ] Google Guest Agent and Google OS Config Agent vulnerability (06:44) 1 CVEs addressed in Noble (24.04 LTS) CVE-2024-24786 A vuln in the embedded golang protobuf module - when parsing JSON could end up in an infinite loop -> DoS [ USN-6850-1 ] OpenVPN vulnerability (07:04) 1 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM) CVE-2022-0547 [USN-5347-1] OpenVPN vulnerability from Episode 155 - possibly gets confused when using multiple authentication plugins and deferred authentication [ USN-6847-1 ] libheif vulnerabilities (07:36) 8 CVEs addressed in Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Mantic (23.10) CVE-2023-49464 CVE-2023-49463 CVE-2023-49462 CVE-2023-49460 CVE-2023-29659 CVE-2023-0996 CVE-2020-23109 CVE-2019-11471 First time to mention libheif on the podcast - High Efficiency Image File Format - part of the MPEG-H standard - container format used to store images or sequences of images Commonly seen due to its use by Apple for images on iPhone C++ - usual types of issues UAF, buffer overflows, floating point exception etc most found through fuzzing [ USN-6848-1 ] Roundcube vulnerabilities (08:21) 4 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Mantic (23.10) CVE-2024-37384 CVE-2024-37383 CVE-2023-47272 CVE-2023-5631 webmail front-end for IMAP 2 different possible XSS issues due to mishandling of SVG - email containing an SVG could embed JS that then gets loaded when the email is viewed Also possible XSS through a crafted user preference value - similarly through a crafted Content-Type/Content-Disposition header which can be used for attachment preview/download [ USN-6819-4 ] Linux kernel (Oracle) vulnerabilities (09:21) 149 CVEs addressed in Jammy (22.04 LTS) CVE-2024-26631 CVE-2023-52694 CVE-2023-52685 CVE-2023-52682 CVE-2024-35835 CVE-2023-52446 CVE-2023-52487 CVE-2023-52619 CVE-2023-52627 CVE-2023-52674 CVE-2024-26598 CVE-2023-52679 CVE-2023-52455 CVE-2024-26671 CVE-2023-52444 CVE-2023-52683 CVE-2023-52690 CVE-2024-35842 CVE-2023-52610 CVE-2024-26607 CVE-2023-52445 CVE-2023-52497 CVE-2023-52488 CVE-2024-26623 CVE-2023-52607 CVE-2023-52677 CVE-2023-52457 CVE-2024-26673 CVE-2024-26594 CVE-2024-26638 CVE-2023-52621 CVE-2023-52594 CVE-2023-52468 CVE-2024-26647 CVE-2023-52492 CVE-2023-52452 CVE-2024-26615 CVE-2023-52448 CVE-2023-52698 CVE-2023-52443 CVE-2023-52614 CVE-2023-52494 CVE-2024-35837 CVE-2024-26582 CVE-2023-52632 CVE-2023-52680 CVE-2023-52595 CVE-2023-52626 CVE-2023-52495 CVE-2023-52451 CVE-2023-52583 CVE-2023-52469 CVE-2023-52584 CVE-2023-52450 CVE-2024-26608 CVE-2023-52609 CVE-2023-52464 CVE-2023-52591 CVE-2024-26645 CVE-2024-35838 CVE-2023-52470 CVE-2023-52456 CVE-2023-52589 CVE-2024-26585 CVE-2023-52696 CVE-2023-52633 CVE-2023-52462 CVE-2023-52597 CVE-2023-52587 CVE-2024-26584 CVE-2024-26636 CVE-2023-52491 CVE-2023-52493 CVE-2024-26627 CVE-2023-52465 CVE-2023-52687 CVE-2023-52593 CVE-2024-26595 CVE-2024-26629 CVE-2024-35840 CVE-2023-52666 CVE-2024-26633 CVE-2023-52686 CVE-2023-52467 CVE-2023-52667 CVE-2023-52449 CVE-2023-52473 CVE-2023-52670 CVE-2024-26649 CVE-2023-52498 CVE-2023-52693 CVE-2024-26583 CVE-2023-52678 CVE-2023-52675 CVE-2023-52489 CVE-2024-26640 CVE-2024-26618 CVE-2023-52599 CVE-2024-26634 CVE-2023-52608 CVE-2024-26625 CVE-2023-52486 CVE-2024-26632 CVE-2023-52669 CVE-2023-52676 CVE-2023-52635 CVE-2023-52664 CVE-2024-35841 CVE-2023-52598 CVE-2023-52458 CVE-2024-26644 CVE-2023-52697 CVE-2023-52617 CVE-2024-26612 CVE-2023-52672 CVE-2023-52490 CVE-2024-35839 CVE-2024-26610 CVE-2024-26616 CVE-2023-52588 CVE-2023-52623 CVE-2024-26669 CVE-2023-52692 CVE-2024-26620 CVE-2023-52606 CVE-2024-26592 CVE-2023-52616 CVE-2024-26641 CVE-2023-52622 CVE-2023-52611 CVE-2023-52453 CVE-2023-52681 CVE-2024-26586 CVE-2023-52472 CVE-2024-26646 CVE-2024-26670 CVE-2023-52454 CVE-2024-26668 CVE-2023-52447 CVE-2023-52463 CVE-2023-52618 CVE-2023-52691 CVE-2024-26808 CVE-2023-52612 CVE-2024-24860 CVE-2024-23849 CVE-2023-6536 CVE-2023-6535 CVE-2023-6356 Of all these CVEs, 6 had a high priority rating many are due to bugs in the async handling of cryto operations in the in-kernel TLS implementation CVE-2024-26582 and CVE-2024-26584 - both reported by Google kernelCTF program (talked about back in [USN-6766-2] Linux kernel vulnerabilities from Episode 228 ) first is UAF in TLS handling of scattter/gather arrays second is UAF when crypto requests get backlogged and the underlying crypto engine can’t process them all in time - can then end up having the async callback invoked twice CVE-2024-26585 very similar - UAF in handling of crypto operations from TLS - thread which handles the socket could close this before all the operations had been scheduled CVE-2024-26583 - similarly, race between async notify event and socket close -> UAF UAF in BPF and a UAF in netfilter - also reported via Google kernelCTF - both able to be triggered via an unpriv userns Goings on in Ubuntu Security Community Discussion of CISA KEV US Gov Cybersecurity & Infrastructure Security Agency “America’s Cyber Defense Agency” National Coordinator for Critical Infrastructure Security and Resilience Publish various guidance for organisations around topics of cybersecurity for instance, recently published a report “Exploring Memory Safety in Critical Open Source Projects” Joint guidance (FBI, ASD / ACSC & Candadian CSC) Builds on the previous case for memory safe roadmaps by looking at the prevalence of memory unsafe languages in various critical open source projects Also maintain the KEV - Known Exploitable Vulnerabilities Catalog “authoritative source of vulnerabilities that have been exploited in the wild” Mandates for federal civilian agencies in the US to remediate KEV vulns within various timeframes Also recommend that anyone else monitors this list and immediately addresses these vulns as part of the vuln remediation plan List of vilns that are causing immediate harm based on observed adversarial activity Various requirements to be listed in the KEV: CVE ID assigned Evidence it has been or is being actively exploited reliable evidence that execution of malicious code was performed on a system by an unauthorised actor also includes both attempted and successful exploitation (e.g. includes honeypots as well as real systems) Clear remediation guidelines An update is available and should be applied OR Vulnerable component should be removed from networks etc if it is EOL and cannot be updated available as CSV or JSON Currently lists 1126 CVEs including: Accellion File Transfer Appliances Adobe Reader, Flash Player Apache HTTP Server, Struts (Solarwinds), Log4j Huge number of Apple iOS etc (WebKit and more) Atlassian Confluence Citrix Gateways Exim Fortinet Gitlab Google Chromium ImageMagick Microsoft Windows and Exchange Mozilla Firefox Ivanti Pulse Connect Security SaltStack VMWare WordPress Oldest CVEs are 2 against Windows from 2002 and 2004 Newest include 26 2024 CVEs - various Chromium, Windows, Android Pixel, Ivanti and more interestingly includes ARM Mali GPU Driver CVE-2024-4610 - this affects the Bifrost and Valhall drivers - in Ubuntu we only ship the related Midgard driver back in bionic and focal so not affected by this one but as you may have noticed, lots that we potentially are affected by Apache HTTP Server, Exim, Firefox, Thunderbird - plus OpenJDK, GNU C Library, Bash, Roundcube (mentioned earlier but not this particular vuln), WinRAR (unrar), not to mention a number against the Linux kernel all for Linux kernel are privesc - most against either netfilter or various other systems like perf, AF_PACKET , tty, ptrace, futex and others For Ubuntu, not surprisingly, we prioritise these vulnerabilities in our patching process Get in contact security@ubuntu.com #ubuntu-security on the Libera.Chat IRC network ubuntu-hardened mailing list Security section on discourse.ubuntu.com @ubuntusecurity@fosstodon.org , @ubuntu_sec on twitter…

1
Episode 230 21:12

40 weeks پیش21:12

21:12

Overview This week we bring you a special edition of the podcast, featuring an interview between Ijlal Loutfi and Karen Horovitz who deep-dive into Confidential Computing. Ranging from a high-level discussion of the need for and the features provided by confidential computing, through to the specifics of how this is implemented in Ubuntu and a look at similar future security technologies that are on the horizon. Confidential Computing with Ijlal Loutfi and Karen Horovitz (01:17) Get in contact security@ubuntu.com #ubuntu-security on the Libera.Chat IRC network ubuntu-hardened mailing list Security section on discourse.ubuntu.com @ubuntusecurity@fosstodon.org , @ubuntu_sec on twitter…

1
Episode 229 13:22

43 weeks پیش13:22

13:22

Overview As the podcast winds down for a break over the next month, this week we talk about RSA timing side-channel attacks and the recently announced DNSBomb vulnerability as we cover security updates in VLC, OpenSSL, Netatalk, WebKitGTK, amavisd-new, Unbound, Intel Microcode and more. This week in Ubuntu Security Updates 152 unique CVEs addressed [ USN-6783-1 ] VLC vulnerabilities (00:54) 2 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Mantic (23.10) CVE-2023-47360 CVE-2023-47359 integer underflow and a heap buffer overflow -> RCE [ USN-6663-3 ] OpenSSL update (01:40) Affecting Noble (24.04 LTS) [USN-6663-1] OpenSSL update from Episode 220 - hardening improvement to return deterministic random bytes instead of an error when an incorrect padding length is detected during PKCS#1 v1.5 RSA to avoid this being used for possible Bleichenbacher timing attacks [ USN-6673-3 ] python-cryptography vulnerability (02:32) 1 CVEs addressed in Noble (24.04 LTS) CVE-2024-26130 [USN-6673-1] python-cryptography vulnerabilities from Episode 220 - counterpart to the OpenSSL update mentioned earlier [ USN-6736-2 ] klibc vulnerabilities (02:43) 4 CVEs addressed in Noble (24.04 LTS) CVE-2022-37434 CVE-2018-25032 CVE-2016-9841 CVE-2016-9840 [USN-6736-1] klibc vulnerabilities from Episode 228 [ USN-6784-1 ] cJSON vulnerabilities (02:58) 3 CVEs addressed in Jammy (22.04 LTS), Mantic (23.10), Noble (24.04 LTS) CVE-2024-31755 CVE-2023-50472 CVE-2023-50471 2 different researchers fuzzing cJSON APIs all different NULL ptr deref - requires particular / “incorrect” or possible misuse use of the APIs (like passing in purposefully corrupted values) so unlikely to be an issue in practice [ USN-6785-1 ] GNOME Remote Desktop vulnerability (03:52) 1 CVEs addressed in Noble (24.04 LTS) CVE-2024-5148 Discovered by a member of the SUSE security team when reviewing g-r-d Exposed various DBus services that were able to be called by any unprivileged user which would then return the SSL private key used to encrypt the connection - so could allow a local user to possibly spy on the sessions of other users remotely connected to the system [ USN-6786-1 ] Netatalk vulnerabilities (04:45) 1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS) CVE-2022-22995 Apple file sharing implementation for Linux If the same path was shared via both AFP and SMB then a remote attacker could combine various operations through both file-systems (like creating a crafted symlink, which would then be followed during a second operation where a file is renamed) to allow them to overwrite arbirary files and hence achieve arbitrary code execution on the host [ USN-6788-1 ] WebKitGTK vulnerabilities (05:48) 1 CVEs addressed in Jammy (22.04 LTS), Mantic (23.10), Noble (24.04 LTS) CVE-2024-27834 Possible pointer authentication bypass - used on arm64 in particular - demonstrated at Pwn2Own earlier this year by Manfred Paul - $60k [ USN-6789-1 ] LibreOffice vulnerability (06:28) 1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Mantic (23.10), Noble (24.04 LTS) CVE-2024-3044 Unchecked script execution triggered when clicking on a graphic - allows to run arbitrary scripts without the usual prompt [ USN-6790-1 ] amavisd-new vulnerability (07:09) 1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Mantic (23.10), Noble (24.04 LTS) CVE-2024-28054 MTA / AV interface - often used in conjunction with Postfix, not just for AV but also can be used to do DKIM verification and integration with spamassassin etc Misinterpreted MIME message boundaries in emails, allowing email parts to possibly bypass usual checks [ USN-6791-1 ] Unbound vulnerability (07:46) 1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Mantic (23.10), Noble (24.04 LTS) CVE-2024-33655 DNSBomb attack announced recently at IEEE S&P - affecting multiple different DNS implementations including BIND, Unbound, PowerDNS, Knot, DNSMasq and others Unbound itself was not necessarily vulnerable to such an attack specifically, but could be used to generate such an attack against others - in particular Unbound had the highest amplification factor of ~22k times - next highest was DNSMasq at ~3k times Fix involves introducing a number of timeout parameters for various operations and discarding operations if they take longer than this to avoid the ability to “store up” responses to be released at a later time [ USN-6793-1 ] Git vulnerabilities (09:31) 5 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Mantic (23.10), Noble (24.04 LTS) CVE-2024-32465 CVE-2024-32021 CVE-2024-32020 CVE-2024-32004 CVE-2024-32002 [ USN-6792-1 ] Flask-Security vulnerability 1 CVEs addressed in Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS) CVE-2021-23385 [ USN-6794-1 ] FRR vulnerabilities 4 CVEs addressed in Jammy (22.04 LTS), Mantic (23.10), Noble (24.04 LTS) CVE-2024-34088 CVE-2024-31951 CVE-2024-31950 CVE-2024-31948 [ USN-6777-4 ] Linux kernel (HWE) vulnerabilities (09:40) 17 CVEs addressed in Xenial ESM (16.04 ESM) CVE-2023-52583 CVE-2024-26801 CVE-2024-26805 CVE-2024-26735 CVE-2024-26622 CVE-2021-46981 CVE-2023-52566 CVE-2023-52604 CVE-2024-26704 CVE-2024-26614 CVE-2023-52602 CVE-2024-26635 CVE-2023-52439 CVE-2023-52601 CVE-2023-52530 CVE-2023-52524 CVE-2023-47233 [USN-6777-1] Linux kernel vulnerabilities from Episode 228 AWS HWE kernel (4.15) [ USN-6795-1 ] Linux kernel (Intel IoTG) vulnerabilities (10:00) 95 CVEs addressed in Jammy (22.04 LTS) CVE-2023-52588 CVE-2023-52622 CVE-2024-26920 CVE-2023-52607 CVE-2023-52530 CVE-2023-52435 CVE-2023-52615 CVE-2024-26684 CVE-2024-26829 CVE-2024-26614 CVE-2023-52489 CVE-2023-52642 CVE-2023-52583 CVE-2024-26696 CVE-2024-26627 CVE-2024-26636 CVE-2024-26663 CVE-2024-26702 CVE-2024-26685 CVE-2024-26715 CVE-2024-26668 CVE-2023-52492 CVE-2023-52498 CVE-2024-26825 CVE-2023-52587 CVE-2024-26615 CVE-2023-52608 CVE-2024-26660 CVE-2023-52601 CVE-2024-26910 CVE-2024-26676 CVE-2023-52493 CVE-2024-26673 CVE-2024-26707 CVE-2024-26698 CVE-2024-26641 CVE-2023-52494 CVE-2023-52595 CVE-2024-26697 CVE-2023-52617 CVE-2024-26675 CVE-2024-26610 CVE-2024-26606 CVE-2023-52614 CVE-2024-26712 CVE-2023-52635 CVE-2024-26689 CVE-2024-26916 CVE-2024-26665 CVE-2023-52623 CVE-2024-26635 CVE-2024-26602 CVE-2023-52597 CVE-2023-52619 CVE-2024-26808 CVE-2024-26600 CVE-2024-26826 CVE-2024-26644 CVE-2024-26695 CVE-2023-52604 CVE-2024-26625 CVE-2023-52618 CVE-2024-26664 CVE-2024-26593 CVE-2023-52633 CVE-2023-52606 CVE-2024-26640 CVE-2023-52486 CVE-2023-52631 CVE-2024-26720 CVE-2023-52599 CVE-2024-26671 CVE-2024-26722 CVE-2023-52602 CVE-2024-26645 CVE-2023-52637 CVE-2024-26704 CVE-2023-52638 CVE-2024-26717 CVE-2024-26592 CVE-2023-52491 CVE-2023-52627 CVE-2023-52598 CVE-2024-26594 CVE-2023-52643 CVE-2024-26622 CVE-2023-52594 CVE-2024-26608 CVE-2024-26679 CVE-2023-52616 CVE-2024-23849 CVE-2024-2201 CVE-2022-0001 CVE-2024-1151 CVE-2023-47233 Very similar to [USN-6766-2] Linux kernel vulnerabilities from Episode 228 5.15 Intel IOTG - optimisations for various Intel IOT platforms like NUCs and Atom-based devices - low power x86 [ USN-6779-2 ] Firefox regressions (10:30) 14 CVEs addressed in Focal (20.04 LTS) CVE-2024-4770 CVE-2024-4367 CVE-2024-4764 CVE-2024-4778 CVE-2024-4777 CVE-2024-4776 CVE-2024-4775 CVE-2024-4774 CVE-2024-4773 CVE-2024-4772 CVE-2024-4771 CVE-2024-4769 CVE-2024-4768 CVE-2024-4767 126.0.1 - drag-and-drop was broken in 126.0 [ USN-6787-1 ] Jinja2 vulnerability (10:48) 1 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Mantic (23.10), Noble (24.04 LTS) CVE-2024-34064 Incorrect handling of various HTML attributes - attacker could then possibly inject arbitrary HTML attrs/values and hence inject JS code to peform XSS attacks etc [ USN-6797-1 ] Intel Microcode vulnerabilities (11:22) 9 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Mantic (23.10), Noble (24.04 LTS) CVE-2023-46103 CVE-2023-47855 CVE-2023-45745 CVE-2023-45733 CVE-2023-43490 CVE-2023-39368 CVE-2023-38575 CVE-2023-28746 CVE-2023-22655 Latest release from upstream - mitigates against various hardware vulns A couple issues in SGX/TDX on different Intel Xeon processors: Invalid restrictions -> local root -> super-privesc Invalid input on TDX -> local root -> super-privesc Invalid SGX base key calculation -> info leak Transient execution attacks to read privileged information DoS through bus lock mishandling or through invalid instruction sequences Get in contact security@ubuntu.com #ubuntu-security on the Libera.Chat IRC network ubuntu-hardened mailing list Security section on discourse.ubuntu.com @ubuntusecurity@fosstodon.org , @ubuntu_sec on twitter…

به Player FM خوش آمدید!

Player FM در سراسر وب را برای یافتن پادکست های با کیفیت اسکن می کند تا همین الان لذت ببرید. این بهترین برنامه ی پادکست است که در اندروید، آیفون و وب کار می کند. ثبت نام کنید تا اشتراک های شما در بین دستگاه های مختلف همگام سازی شود.