With the recent discovery of a significant Chrome vulnerability tagged as CVE-2025-0762 , Google Chrome has again come under fire. This new threat, found in the DevTools function of the browser, is a use-after-free memory issue. It could enable attackers to execute code and take over your computer to hijack your critical Linux systems for malicious purposes. Given Chrome’s ubiquitous presence across various platforms, the urgency to update Chrome to version 132.0.6834.159 cannot be overstated. . Implementing this crucial update immediately is imperative to safeguard against this medium-severity threat. By verifying the Chrome version running on your systems and guiding your teams through the necessary update processes, you can effectively mitigate risks associated with this vulnerability. Staying ahead of such security challenges fortifies your infrastructure and reinforces best practices for maintaining robust cybersecurity hygiene across your organization. Let's take a closer look at this flaw, its repercussions, and how to update Chrome to protect against exploits. Understanding This Chrome Vulnerability The recent CVE-2025-0762 Chrome vulnerability is a use-after-free flaw, a type of security issue that happens when a program uses memory after it has been freed. When a browser like Chrome inadvertently permits access to no longer valid memory, it risks allowing attackers to manipulate this gap to execute arbitrary code and hijack your computer. This vulnerability can have widespread implications, potentially affecting all users interacting with compromised sites. Given that Chrome's DevTools are an integral part of web development and debugging, any flaw here can impact developers and end-users alike, making it a prime target for exploitation. Examining Other Recent Flaws Fixed in Chrome 132 Just recently, Google released a critical Chrome update to address some serious security vulnerabilities discovered before CVE-2025-0762. Specifically, these issues were found in the V8JavaScript engine, which affects users across various operating systems, including Android, Linux, macOS, and Windows. The two vulnerabilities, identified as CVE-2025-0611 and CVE-2025-0612 , pose significant threats. CVE-2025-0611 is a heap-based overflow that can cause memory corruption, potentially allowing attackers to run arbitrary code on your system and take over your computer or device. CVE-2025-0612 involves out-of-bounds memory access, enabling attackers to read or write data outside of allocated memory areas, which can also lead to arbitrary code execution. The impact of these vulnerabilities is quite severe, as they can let attackers take control of your browser and potentially the entire system. Users must update Chrome to the latest version as soon as possible to safeguard their systems against these bugs. Why This Update Matters The discovery of a flaw like CVE-2025-0762 reminds us of the importance of regular and immediate updates. In environments with high browser usage, the potential entry points for attacks multiply, making it essential to address such vulnerabilities quickly. Google has released version 132.0.6834.159 of Chrome , which patches this medium-severity flaw, urging security teams to ensure this update is applied across all impacted systems. Failing to update could expose systems, leading to critical breaches that could compromise sensitive information and disrupt organizational operations. Debian , Fedora , openSUSE , and SUSE have released security advisory updates in response to this flaw, urging users to update to version 132.0.6834.159 immediately. Guiding Your Organization Through the Update Process Ensuring that systems are updated promptly requires a methodical approach. As Chrome typically updates automatically, users may assume their systems are always protected, but this update should not be left to chance. Admins should proactively check current browser versions, guide the manual update process where necessary, and verify that allinstances of Chrome are running the latest patched version. Navigating the update process is straightforward: users should open Chrome, navigate to the settings menu, and select "About Google Chrome." The browser will check for updates and automatically download any available patches. After this process, restarting the browser to apply the changes is crucial. Administrators should confirm that Chrome reflects version 132.0.6834.159. Communicating the Importance of Regular Updates For systems where uptime and reliability are paramount, unplanned security breaches can lead to significant downtime and resource strain. Therefore, regular software updates are a vital first line of defense. The threat posed by CVE-2025-0762 reinforces the need for a culture of vigilance where security updates are part of routine practice rather than reactive measures taken only following a security incident. Encouraging transparency and communication within your organization about potential risks and the steps taken to avert them can foster a more informed and engaged workforce. Security updates should be regarded not only as a technical requirement but as an essential component of risk management strategies that protect both digital assets and the broader organization. Looking Forward: Maintaining a Secure Environment As threats evolve, so too should security measures. While the immediate priority is mitigating the present risk posed by this particular vulnerability, longer-term strategies should focus on continuous improvements in security protocols. Regular audits , user training, and simulated security incidents can enhance an organization’s preparedness for future threats. Moreover, maintaining partnerships with software vendors and staying informed through trusted security advisories will empower you with the knowledge needed to stay ahead of the curve. Evaluating Chrome Security & Secure Web Browser Alternatives for Linux Users Chrome has been a go-to browser for many due to its speed,reliability, and extensive ecosystem. However, like any software, it's not immune to security vulnerabilities. Google has a robust security team working to patch these flaws as they arise. They also have a strong bug bounty program encouraging external researchers to report vulnerabilities. This proactive approach generally keeps Chrome users protected, but it also means that staying updated is crucial. Regular updates ensure you have the latest security fixes, minimizing the risk of exploitation. For security-conscious Linux admins seeking alternative web browser options, a few browsers stand out. Mozilla Firefox is often praised for its commitment to user privacy and security. Firefox is open-source, which allows for extensive scrutiny by the global security community, and it regularly rolls out updates to address any discovered vulnerabilities. Additionally, Firefox includes various built-in privacy tools, like enhanced tracking protection, to keep your browsing more secure. Another key consideration is Brave . Built on the same Chromium engine as Chrome, Brave offers Chrome’s speed but adds several privacy features like built-in ad blockers and fingerprinting protection. Due to its focus on privacy, it’s gaining popularity among users who want a more secure and private browsing experience. Firefox and Brave are solid alternatives, especially for administrators keen on boosting their Linux system's security posture. Our Final Thoughts on Mitigating This Chrome DevTools Flaw The revelation of the CVE-2025-0762 vulnerability in Google Chrome is a stark reminder of the ongoing challenges Linux security admins face. Rapidly deploying the recommended update is critical to mitigating risk and protecting the broader enterprise infrastructure from potential exploitation. By understanding the intricacies of this vulnerability, ensuring prompt updates, and fostering an environment committed to continuous security consciousness, admins and organizations can navigate current challenges while buildinga robust defense against future vulnerabilities. Safeguarding your systems is ongoing but achievable with vigilant management and strategic foresight. . Applying this essential patch without delay is vital to protect against this moderate-level vulnerability in Chrome.. Chrome Update, Use After Free, Browser Security, Linux Security, Cyber Threats. . Brittany Day
Multiple high-impact network security issues have been discovered in Thunderbird, which could result in Denial of Service (DoS) attacks in network security that lead to server crashes, access restrictions, arbitrary code execution, and spoofing breaches. These findings include a vulnerability that involves incorrect code generation during JIT compilation (CVE-2023-25751) and high-severity memory safety bugs, both of which were present in Thunderbird 102.8 (CVE-2023-28176). . Thunderbird 102.9.0 has been released as a security and bug fix update and the latest stable version of the open-source email client. This article will cover the cybersecurity vulnerabilities recently found in Thunderbird and fixed in version 102.9.0 to equip you with the information you need to protect against potential downtime and system compromise that could result from bugs exploiting your company. Thunderbird 102.9.0 Security Fixes Thunderbird 102.9.0 fixes six moderate-to-high network security issues in email programs. The cybersecurity vulnerabilities addressed in version 102.9.0 include: CVE-2023-25751: Incorrect code generation during JIT compilation could lead to a potentially exploitable cra sh (high severity rating) CVE-2023-28164: URL being dragged from a removed cross-origin iframe into the same tab triggered navigation, potentially leading to user confusion and website spoofing attacks (moderate severity rating) CVE-2023-28162: Invalid downcast in Worklets could lead to a potentially exploitable crash (moderate severity rating) CVE-2023-25752: Potential out-of-bounds when accessing throttled streams may have led future code to be incorrect and vulnerable (moderate severity rating) CVE-2023-28163: Windows Save As dialog resolved environment variables in the context of the current user (moderate severity rating) CVE-2023-28176: Memory safety bugs present in Thunderbird 102.8 showed evidence of memory corruption and could potentially be exploited to run arbitrary code (highseverity rating) The release also includes the following non-security fixes: Notification about a sender's changed OpenPGP key was not immediately visible TLS Certificate Override dialog did not appear when retrieving messages via IMAP using "Get Messages" context menu Spellcheck dictionaries were missing from localized Thunderbird builds that should have included them Tooltips for "Show/Hide" calendar toggle did not display Upgrade to Thunderbird 102.9.0 Now! In order to protect against dangerous exploits in cybersecurity, it is critical that all impacted users upgrade immediately. Existing Thunderbird installations should receive the update automatically as long as the automatic updates functionality has not been disabled by the administrator. For users who prefer to update manually, this can be done by selecting “Help → About Thunderbird,” or by selecting the Settings icon in the new sidebar on the left. Thunderbird displays the installed version in a small overlay window in the interface. The email client performs an update check and will download and install updates that it finds during the check. To stay on top of important updates released by the open-source programs and applications you use, be sure to register as a LinuxSecurity user . Subscribe to our Linux Advisory Watch newsletter and customize your advisories for the distro(s) you use. This will enable you to stay up-to-date on the latest, most significant cybersecurity vulnerabilities impacting the data and network security of your systems. Follow @LS_Advisories on X for real-time updates on advisories for your distro(s). . Uncover pivotal enhancements and patches in Thunderbird 102.9.0 to protect your emails and networks from looming vulnerabilities.. Thunderbird 102.9.0, Email Client Security, Denial of Service, Code Execution Flaws. . Brittany Day
Openwall recently announced the release of LKRG (Linux Kernel Runtime Guard) 0.9.0, featuring a host of major changes and improvements, as well as fixes for multiple security bugs. LKRG is a kernel module that performs runtime integrity checking of the Linux kernel and detection of security vulnerability exploits against the kernel. . In an email sent to the LKRG Users List announcing the release of LKRG 0.9.0, Openwall Founder Alexander Peslyak (known by many as “Solar Designer” ) outlines the major changes that have been made between LKRG 0.8.1 and 0.9.0, and explains the significance of these updates: *) Support new mainline kernel versions 5.8 to 5.12 (inclusive) and new stable kernels 5.4.87+ (which include some back-ports from 5.8+) *) Support new RHEL kernels up to RHEL 8.4's (inclusive) *) Support building LKRG in the kernel tree (not only as a standalone module), as a module or linking into the kernel image (see scripts/copy-builtin.sh) *) Support CONFIG_FUNCTION_TRACER with or without CONFIG_DYNAMIC_FTRACE *) Support various CONFIG_OPTPROBES configurations *) Support loading overlayfs[2] after LKRG (e.g., by Docker; previously, the overlayfs[2] module had to be loaded before LKRG for Docker to work) *) "Support" CONFIG_GCC_PLUGIN_RANDSTRUCT (don't monitor SELinux if enabled) *) Explicitly do not support RT kernels *) Fix support for 32-bit x86 (was unintentionally broken in LKRG for ages, but could mostly work on many pre-5.7 kernel and LKRG builds by "luck") *) Fix detection of process user/group ID corruption to cover any unexpected changes (previously, only numerically lower new IDs, as exploits normally use, would be detected - a limitation left over from early LKRG testing) *) Fix logging of WP/SMEP/SMAP violations on systems with SMAP in the "log and accept" mode (previously, one such violation could mute logging of others) *) Add detection of ADDR_LIMIT corruption attacks *) Remove validation of waking-up tasks (drop pint_validate=2) *) Replace execve(2) hooks (instead hook security_bprm_committing_creds and security_bprm_committed_creds, which shortens the race window for exploits) *) Replace ptrace(2) hooks (instead hook security_ptrace_access) *) Simplify UMH blocking and make it compatible with CPA-protected pages *) Simplify and speed up do_exit hook (no need to validate a dying process) *) Many other changes under the hood to make LKRG easier to maintain and debug *) Integrate LKRG with out-of-tree (a tool to assist kernel module testing) *) Integrate LKRG with mkosi (systemd's tool for generating a test boot image) *) Continuous Integration setup: boot tests on GitHub Actions using mkosi (with Ubuntu's release kernels and their daily builds of mainline kernels) As you can see, we had to make changes to support Linux kernels newer than those available at the time of previous release. Almost every major kernel release, and some back-ports too, broke compatibility with LKRG. Since we did not make new LKRG releases, people with those newer kernels were advised (on the LKRG homepage and otherwise) to use our latest code off GitHub, which we tried to keep in a stable state (lately in part through use of Continuous Integration). We also preserved support for all of the old kernels we supported previously (RHEL7, etc.) LKRG 0.8.1 was already smaller than 0.8, and with 0.9 the LKRG source code became a bit smaller again (at least in terms of line count) due to the simplifications we made, despite of significant additions: $ git diff --shortstat v0.8.1..v0.9.0 126 files changed, 3919 insertions(+), 4375 deletions(-) Also, perhaps in part due to our move to GitHub, we started to receive more direct contributions to LKRG development (GitHub pull requests). The fulllist of direct contributors to this release is: $ git shortlog -sn v0.8.1..v0.9.0 67 Adam 'pi3' Zabrocki 15 Solar Designer 12 Mariusz Zaborski 7 Vladimir D. Seleznev 5 0xC0ncord 5 RageLtMan 5 Vitaly Chikunov 2 F0x1fy 1 William 1 disrupttheflow I'd like to specifically highlight the contribution of support for building LKRG in-tree (scripts/copy-builtin.sh and related testing) by RageLtMan and the contribution of mkosi integration and Continuous Integration setup by Vitaly Chikunov. I'd also like to highlight Mikhail Klementev's offer to use his out-of-tree framework, which Adam eventually added the integration for. The announcement also mentions various Linux kernel issues that LKRG principal developer Adam 'pi3' Zabrocki discovered in the development and testing of LKRG: During LKRG development and testing I've found 7 Linux kernel bugs, 4 of them have CVE numbers (however, 1 CVE number covers 2 bugs): CVE-2021-3411 - Linux kernel: broken KRETPROBES and OPTIMIZER CVE-2020-27825 - Linux kernel: Use-After-Free in the ftrace ring buffer resizing logic due to a race condition CVE-2020-25220 - Linux kernel Use-After-Free in backported patch for CVE-2020-14356 (affected kernels: 4.9.x before 4.9.233, 4.14.x before 4.14.194, and 4.19.x before 4.19.140) CVE-2020-14356 - Linux kernel Use-After-Free in cgroup BPF component (affected kernels: since 4.5+ up to 5.7.10) I've also found 2 other issues related to the ftrace UAF bug (CVE-2020-27825): - Deadlock issue which was not really addressed and devs said they will take a look and there are not many updates on that. - Problem with the code related to hwlatdkernel thread - it is incorrectly synchronizing with launcher / killer of it. You can have WARN in kernels all the time. CVE-2021-3411 refers to 2 different type of bugs: - Broken KRETPROBE (recently reported) - Incompatibility of KPROBE optimizer with the latest changes in the linker. Additionally, I've also found a bug with the kernel signal handling in dying process: CVE-2020-12826 - Linux kernel prior to 5.6.5 does not sufficiently restrict exit signals However, I don't remember if I found it during my work related to LKRG so I'm not counting it here (otherwise it would be total 8 bugs while 5 of them would have CVE). That's pretty bad stats... However, it might be an interesting story to say during LKRG announcement of the new version. It could be also interesting talk for a conference. The kretprobes and ftrace issues here are of questionable security relevance (this functionality is not exposed for attack under most reasonable threat models), but all of these are interesting bugs. Peslyak welcomes any feedback on this release. In a recent email exchange with LinuxSecurity.com security researchers, Peslyak summarizes the main benefits that LKRG offers users, “LKRG offers best-effort protection against kernel vulnerability exploits with little effort on behalf of the user - no need to configure a policy, etc. - making it especially beneficial for systems that are not expected to be consistently kept up-to-date.” You can download LKRG 0.9.0 lkrg . Are you using LKRG to help secure your Linux system? Have you downloaded LKRG 0.9.0? What are your thoughts? We want to hear! Connect with us on social media: Twitter | Facebook . Openwall unveils LKRG 0.9.0, featuring major updates and essential security patches aimed at bolstering kernel security and overall integrity.. LKRG, Runtime Integrity Guard, Openwall, Linux Kernel, SecurityImprovements. . Brittany Day
On April 12, 2021, the Apache SpamAssassin Project announced the release of Apache SpamAssassin Version 3.4.6 mitigating two small but potentially annoying bugs introduced in Version 3.4.5, which was created to fix a few security vulnerabilities just a few weeks ago. . A Quick Introduction to Apache SpamAssassin Apache SpamAssassin is a mature, widely-deployed open-source project that serves as a mail filter to identify spam. SpamAssassin leverages a combination of mail header and text analysis, Bayesian filtering, DNS blocklists, and collaborative filtering databases. SpamAssassin’s flexible modular architecture makes the framework compatible with a wide array of other technologies Apache SpamAssassin typically runs on a server, classifying and labeling spam before it reaches your mailbox, while allowing other components of a mail system to act on its results. Portability, robustness and facilitated maintenance are among the key benefits that Apache SpamAssassin offers. What’s New in Apache SpamAssassin Version 3.4.6? While the release of Apache SpamAssassin doesn’t include any groundbreaking new features, configuration options or Internal changes, it does feature mitigations for two minor - but potentially aggravating - bugs introduced in Version 3.4.5. Sidney Markowitz, Apache SpamAssassin PMC Chair, stated in a recent announcement email: Apache SpamAssassin 3.4.6 fixes two small but potentially annoying bugs in 3.4.5 *** On March 1, 2020, we stopped publishing rulesets with SHA-1 signatures. If you do not update to 3.4.2 or later, you will be stuck at the last ruleset with SHA-1 signatures. Such an upgrade should be to 3.4.6 to obtain the contained security fixes *** *** Ongoing development on the 3.4 branch has ceased. All future releases and bug fixes will be on the 4.0 series, unless a new security issue is found that necessitates a 3.4.7 release. *** Many thanks to the committers, contributors, ruletesters, mass checkers, and code testers who have made this release possible. Notable changes --------------- This release includes fixes for the following: - Fixed URIDNSBL not triggering meta rules - Fix false positive in T_KAM_HTML_FONT_INVALID on CSS color !important Downloading and availability ---------------------------- Downloads are available from: spamassassin.apache.org/downloads.cgi The Bottom Line The release of Apache SpamAssassin Version 3.4.6 is fairly mundane when it comes to features, improvements and optimizations. That being said, the release does introduce fixes for two small but potentially annoying security bugs introduced in Version 3.4.5. Upgrading is quick, easy and free and stands to make your SpamAssassin user experience more pleasant and hassle-free. All in all, it seems like the logical decision to make the switch to Apache SpamAssassin Version 3.4.6. . Update to Apache SpamAssassin 3.4.6 to fix two small issues from version 3.4.5 for improved functionality.. Apache SpamAssassin Update,Bug Fix,Mail Filtering,Open Source Project. . Brittany Day
Patching and upgrading software requires more than running a few commands. Having a patch recovery plan, communicating with developers on that server, and knowing who to contact in case of a botched patch job is critical.. I wonder what goes through Jay. F.'s head when I send another patch update with a few dozen servers to patch. Patch Management can be a headache, especially in a large network environment. It can also be disastrous if someone doesn't read the documentation that comes with patches or types the wrong command to upgrade a software package. Consequently, knowing how to back out of a botched patch job is just as important as knowing how to apply the patch. Don't apply multiple patches at once. Apply patches in increments, it makes recovering from a problem with one patch a whole lot easier. Patching will require you to know the functionality of services running and the current security settings. Some patches may disable security settings, overwrite a configuration file or may start services that were shut down or weren't even previously enabled. Backup configuration files for a software package before applying a patch to it. Also, run the following commands to see if something was started or disabled after the patch was applied. /bin/ps -ef > before-patches-ps.txt and /bin/netstat -an > before-patches-netstat.txt. Then after the patches run: /bin/ps -ef > after-patches-ps.txt and /bin/netstat -an > after-patches-netstat.txt Run diff or sdiff on the those files to see if anything has changed. /usr/bin/sdiff before-patches-ps.txt after-patches-ps.txt Also, check your file-integrity program to see what changes were made to the system. File-integrity programs have more uses than just looking for intruders. Many vendors have a patch management program that will check your system against the most recent software versions available and download or send an email with the latest available versions. It isrecommended to only allow these automated programs to alert you when there are new packages available . Others have mailing list and some vendors publish updates on Bugtraq. Before you patch your systems: Know who to contact before applying a patch, in case something goes wrong. Write down the current version of the software to be patched. Have that version on standby in case something goes wrong. Write down the version to be updated. Read the documentation about the patch before applying it. Check the website's mailing lists, if any, to see if others have had a problem with that patch. Take a deep breath and apply it. Before patching, talk to the programmers and others who use the system about what is going to be done. If patching will break an existing service, for sure, then monitor that service more closely and document (GASP!! THE "D" WORD) why the service can't be patched and give a copy to your supervisor. Last, but not least, email the software's developers and explain that the patch didn't work properly. Case example K.D. was upgrading packages on his Linux server and he ran the commands: /bin/rpm -Uhv *.rpm and /sbin/reboot The server rebooted but his Linux installation didn't boot. His system was hosed and had to reinstall the whole system. After reinstalling, applying updates, and restoring from backups, a half a day had gone by and this was a critical server. The error in K.D.'s case was that the latest kernel was within the rpms that he upgraded. He didn't know that the kernel should be installed with the command: /bin/rpm -ihv kernel-version.rpm instead of: /bin/rpm -Uvh kernel-version.rpm The switches, " ivh " installs the new kernel and modules and keeps the original kernel and modules. The switches " Uhv " removes the current kernel and modules and installs the new kernel and modules. He also didn't edit the boot loader configuration file to point to the new kernel. K.D. had backups but nopatch management recovery plan. K.D. was in an organization where he could have had a plan written up and reviewed by others. If K.D. had a recovery plan and communicated with the right people he could have gone into rescue mode, edited the boot loader configuration file, and rebooted with the new kernel with minimal down time. Managers, require your admins to provide you a written patch management plan. The plan should include: Sites, mailing lists, and other sources to monitor for each service running on the servers they maintain. The primary and backup person to apply patches and their contact information. Contact information for any developers, programmers, or other admins running mission critical programs on that system. What is to be done if a patch breaks soemthing eg. what is the backup procedure and who to contact. What system to test patches on. Some organizations may not have the luxury of having test systems. That shouldn't be a problem because there are many operating system emulators available An investment in VMWare may be worth pennies compared to a day of lost revenue because a single patch broke your companies credit-card processing system. There is also the excellent GPL'd program User-mode Linux which emulates a Linux environment. With either program you can setup your production servers same software configuration and apply patches and see if it causes any problems. Having a patch management disaster recovery plan, good communication, and cooperation will make patch management a seamless process. Also, Managers we need your support. Duane Dunston is a Computer Security Analyst at STG Inc. for the National Climatic Data Center in Asheville, NC. He received his B.A. and M.S. degrees from Pfeiff er University and he has his GSEC certification from SANS. He hangs out at Old Europe Cafe, Early Girl's eatery, Annton y's, and any place with good tea and hot chocolate. Duane has been working in security for 5 years and wishes he had thefunding for a "Basic Security Tour" so he could provide the world with hands-on training on how to implement the security recommendations from the Sans Top 20 List of the most common vulnerabilities. He knows that applying these recommendations to any network can minimize the most com mon types of attacks. Not only does he enjoy his work in computer security, he also likes to get involved in its ever-g rowing technologies. Duane says, "Security is one of those jobs where you have to stay abreast of new technologies and new ways that attackers are compromising computer systems. Security keeps evolving and the industry has to keep up w ith it, that is why we need well-trained, evolving security professionals supportive managers to help us with this ongo ing process". . I wonder what goes through Jay. F.'s head when I send another patch update with a few dozen servers . patching, upgrading, software, requires, running, commands, having, patch, recovery. . Duane Dunston
Get the latest Linux and open source security news straight to your inbox.