Latest Linux Security News & Information

denial of serviceopen-sourcememory leak

How Memory Leaks Affect System Stability and Security

A process with a stable workload shouldn't keep growing its resident memory. When it does, the first question isn't how much RAM is available. It's where the allocations stopped being released. On Linux, that answer isn't always obvious because the kernel, allocator, and application all influence what memory usage looks like from the outside. . Separating normal allocation behavior from an actual leak takes more than watching top or container metrics. Heap growth, allocator caches, mapped regions, and process lifetime all change the picture. A steadily increasing RSS may indicate a leak. It may also reflect fragmentation, caching, or memory the allocator hasn't returned to the kernel. The useful evidence comes from understanding how Linux manages process memory and from using the right profiling tools to follow allocations back to their source. That's where the investigation starts. What a memory leak is, at the OS level A memory leak happens when a program asks an allocator for memory through malloc() and never releases it through free(). The allocator keeps that block marked as allocated, and the kernel has no way to know it’s functionally dead once the application loses track of it. Understanding why requires a quick look at how Linux handles virtual memory underneath malloc(). The request goes to an allocator, usually glibc ’s implementation derived from ptmalloc, though latency-sensitive services often swap in jemalloc or tcmalloc instead, each using a different strategy for the same underlying problem. With glibc, small and medium allocations come from heap arenas backed by brk()/sbrk(), while large allocations are typically served through anonymous mmap() regions, with the cutoff tunable and, in modern glibc, dynamically adjusted rather than fixed. Either way, the kernel maps virtual addresses first and delays committing physical RAM until first touch, through a page fault. From the kernel’s point of view, the process still owns that virtual address range regardless ofwhether anything still needs it. Whether a page stays resident, gets swapped out, or gets reclaimed follows normal virtual memory rules and current pressure, not whether the application still holds a pointer to it. With a valid pointer, the program can release the allocation through free() or munmap(). Without one, the allocation is effectively unrecoverable until the process exits. That distinction explains a pattern every Linux administrator runs into in top or htop: the gap between VIRT and RES. VIRT is the total virtual address space a process has mapped, useful for spotting address-space growth or mmap() leaks, but not physical pressure. RES is the resident set size, the actual RAM backing that mapping. A process whose RES keeps climbing over hours or days, well past where its workload should have settled, is the most basic signature of a leak on Linux. Where leaks come from in Linux server software Leaks come from a handful of recurring patterns, and most Linux server software runs into at least one of them: Malloc/free mismatches in error paths : The most common source in C and C++ services: a function allocates a buffer, hits an early return on failure, and skips the cleanup that only runs on the success path. The leak only shows up under conditions that exercise that failure path, which makes it easy to miss in testing. File descriptor leaks : A socket or file opened without a matching close() eventually hits the per-process limit set by ulimit -n, but the cost starts well before that. Each open descriptor keeps kernel-side structures allocated behind it: socket buffers, dentry and inode references, epoll registrations. mmap()-based leaks : A process maps a file or shared memory segment and never calls munmap(). If the mapping is never touched again, VIRT grows without a matching jump in RES, which trips people up when they assume RES tells the whole story. JVM reference retention : Common in Kafka, Elasticsearch, or Cassandra deployments. Objects stay reachable throughreferences left in static collections, listeners that never get removed, or classloaders that accumulate across repeated redeploys. The garbage collector is doing what it’s designed to do: keeping alive everything still reachable, even when “reachable” only happens because of a bug. Leaks inside managed runtimes : Garbage collection doesn’t make a language immune. In Python, C extensions like numpy or pandas manage memory outside the reach of Python’s own collector, so a leak inside the extension is invisible to gc.collect(). In Go, a goroutine blocked forever on a channel that never receives anything holds onto every variable it captured for as long as the program runs. Connection pool exhaustion : A database connection checked out and never returned drains the pool over time, and each connection still in use holds buffers, prepared statement caches, and protocol state behind it. Detecting and diagnosing memory leaks on Linux Diagnosing a leak on Linux moves through four stages: spotting the trend, ruling out look-alikes, finding the responsible code, and confirming what happened after the fact. Spotting the trend top or htop sorted by memory is the first signal, followed by ps aux --sort=-%mem to confirm which process is climbing. /proc/[pid]/status gives quick indicators like VmRSS and VmHWM for trend-spotting. For mapping-level accuracy, especially when shared pages matter, use /proc/[pid]/smaps or smaps_rollup, which show memory by individual mapping and help separate a heap leak from one in a mapped file or shared library. On hosts running many copies of similar daemons, plain RSS double-counts shared pages, which is where smem earns its place, reporting proportional set size (PSS) for a more honest per-process picture. Ruling out look-alikes Not every upward RSS trend is a true lost-allocation leak. Allocator fragmentation, unbounded caches, per-thread arenas, and garbage-collected heaps that don’t return memory to the OS all produce leak-like graphs. The fixdiffers: a true leak needs corrected ownership and lifetime, while bloat needs cache limits, heap sizing, or allocator tuning. Finding the responsible code Once a leak is confirmed, the next step is finding it in the code. Valgrind’s memcheck , run with --leak-check=full, classifies leaks as “definitely lost” or “possibly lost,” tied to the allocating call stack, though the overhead makes it mostly a staging tool rather than something run against live traffic. AddressSanitizer and LeakSanitizer, built into gcc and clang, are lighter and more common in CI pipelines instead, though the specific behavior depends on compiler, platform, and sanitizer configuration. For a process already running in production, where attaching a heavily instrumented build isn’t an option, eBPF-based tools have become the standard: memleak.py from the BCC toolkit , or the bpftrace equivalent, hooks into malloc and free on a live process with much lower overhead than Valgrind, though overhead still depends on allocation rate, sampling settings, and workload. It reports outstanding allocations without requiring a restart. For JVM workloads, jmap pulls a heap dump that Eclipse Memory Analyzer or VisualVM can open to find which objects are holding the most memory and why they’re still reachable. Go ships its own answer in the standard library’s pprof heap profiler. Kernel-space leaks are rarer, usually inside drivers rather than core subsystems. The kernel’s built-in kmemleak detector exists because user-space tools can’t see kernel memory, and slabtop offers a lighter way to watch slab cache growth without it. Confirming it after the fact When none of this happens in time, the OOM killer’s own logs become the diagnostic tool of last resort. dmesg | grep -i oom or journalctl -k usually shows which process was holding the most memory at the moment it got killed, useful retroactively even if it would have helped more a few hours earlier. The stability impact, from RSS growth to the OOM killer The kernel’s response to memory pressure follows a general pattern, though the exact path depends on workload, kernel settings, cgroups, and available swap. Under pressure, Linux attempts to reclaim in stages: page cache, reclaimable slab, and, depending on configuration, anonymous memory through swap. As a process’s RSS grows, the kernel typically starts with page cache, the clean, easily-recreated pages backing recently read files, reclaimed through kswapd running in the background. This is why low free memory on a Linux box often isn’t a problem: page cache is supposed to fill unused RAM and gets evicted painlessly under pressure. The trouble starts once page cache has little left to give and the kernel has to consider reclaiming anonymous memory, the heap and stack pages behind running processes, including whatever a leak has accumulated. vm.swappiness shapes how aggressively the kernel prefers swapping anonymous memory over reclaiming file-backed cache, but it doesn’t guarantee heap and stack pages get swapped before anything is killed, since that depends on how much swap exists and how fast pressure builds. This is the stretch where a leaking service feels sluggish rather than broken, right up until reclaim can’t keep pace. Once reclaim and swap can’t satisfy demand, the OOM killer picks a victim based on oom_score, adjustable per process through /proc/[pid]/oom_score_adj. This matters operationally: a leak in one service can get an unrelated process killed instead, if that process has a less negative oom_score_adj when the kernel goes looking for a victim. vm.overcommit_memory controls commit accounting and affects whether large allocations fail early, but it doesn’t control this later reclaim-and-OOM sequence once real pressure exists. Containers and orchestrated environments Inside a container, the same leak plays out differently because memory is bounded by a cgroup rather than the whole host. Cgroup v1 enforces this through memory.limit_in_bytes; cgroup v2 through memory.max.A leaking process usually hits that ceiling well before it affects the rest of the node, and gets killed by the kernel’s per-cgroup OOM handling. In Kubernetes, this surfaces as a pod entering the OOMKilled state, visible in kubectl describe pod. The restart policy that makes containers resilient also makes leaks harder to notice. Kubernetes brings the container back up automatically, RSS resets to baseline, and the leak resumes from zero until it grows back to the limit, and the cycle repeats. Without memory metrics tracked over time, through Prometheus scraping cAdvisor or kube-state-metrics and graphed in something like Grafana, this pattern looks like an intermittent crash. It’s a deterministic leak on a timer set by request rate and the configured memory limit. Sidecars complicate this further. Kubernetes memory limits are usually specified per container, so a leak in a logging sidecar or service mesh proxy gets killed independently of the main application, without eating into its limit directly. Newer clusters can also define pod-level resource limits, now beta and enabled by default, giving the whole pod a shared memory ceiling instead. Either way, a sidecar with no limit set can still consume from the node’s general pool, putting unrelated pods at risk of eviction. The security implications go deeper than data exposure Leaks create three kinds of security exposure: denial of service, a more specific data-exposure risk than is often assumed, and a quieter risk to the security tooling running alongside the leak. 1. Denial of service The most direct risk is denial of service. Leak-driven DoS is a recognized attack class, formally classified as CWE-401 , “Missing Release of Memory after Effective Lifetime,” not just an unfortunate side effect of sloppy code. An attacker who finds a request pattern that reliably triggers a code path missing a free() call can repeat it to drive a service toward its memory limit on purpose. The recently disclosed HTTP/2 Bomb attack is betterframed as resource-amplification denial of service than a classic leak, but the result is similar: a small amount of attacker-controlled input forces disproportionate server-side resource consumption, and the outcome looks identical to an organic crash unless someone is watching for it. 2. Data exposure A second risk is data exposure, though the mechanism is more specific than it’s often assumed to be. A true memory leak and a failure to clear sensitive data before releasing it are related but distinct problems. The practical risk with leaks specifically is duration: a buffer holding a credential, a session token, or a request body that should have lived for milliseconds instead stays resident for hours or days, simply because nothing freed it. That extended lifetime widens the window during which an unrelated bug, an out-of-bounds read, a crash that writes a core dump, a swap file persisted to disk, can expose data that a properly managed allocation would never have stuck around long enough to leak. 3. Quieter risk to the security tooling A third, quieter risk involves the security tooling on the same host. auditd, intrusion detection agents, and log shippers compete for the same memory as everything else, and get throttled or killed under the same pressure a leak creates, unless their oom_score_adj is specifically protected. The moment a host is under the most pressure, often because something is leaking, is also the moment its own defenses are least likely to be running normally. Open source software and the kernel itself Widely deployed open source daemons, Redis, Nginx, PostgreSQL, and Apache, have all had real memory leak issues tied to specific configurations or malformed input, documented in changelogs and bug trackers. Being open source means these get found and patched quickly once flagged. It also means the affected versions are public, making patch prioritization a real operational task rather than a guessing game, since anyone, including an attacker, can read the same changelog. “Linux memory leak” sometimes refers to something happening inside the kernel itself, typically in a driver rather than a core subsystem. These leaks are harder to see because user-space diagnostic tools have no visibility into kernel memory, which is the gap kmemleak was built to fill. slabtop offers a lighter way to watch slab cache growth without its full instrumentation. Preventing leaks before they ship Preventing leaks comes down to ownership discipline paired with guardrails specific to the runtime in use: C and C++: RAII and smart pointers where possible, explicit cleanup on every error branch, and sanitizers wired into CI rather than run only when something looks wrong. Go: context. Context cancellation to bound goroutine lifetimes, avoiding unbounded goroutine creation in handlers, and routine profiling with pprof. JVM services: bounded caches, deregistered listeners, and no static registries retaining request-scoped objects. Python: context managers, explicit closes instead of relying on GC timing, and tracemalloc for Python-level allocations, with native extension memory watched separately since tracemalloc can’t see it. Watching for leaks before they become incidents The most useful signal is a trend, not a threshold. A single memory number rarely tells you anything; the slope of that number over hours and days tells you almost everything. Worth alerting on: A sustained positive RSS slope after warm-up. Climbing cgroup memory usage independent of request volume. Repeated container restarts or OOMKilled events on the same workload. A growing file descriptor count. Divergence between an app’s own heap metrics and total process or container RSS. That last one tends to catch native extensions and off-heap leaks that a runtime’s own instrumentation never sees. A practical troubleshooting flow When something looks like a leak, the order of operations matters: Confirm the trend using RSS, cgroup memory, or process metrics overtime, not a single snapshot. Separate heap growth from mapping growth using smaps or smaps_rollup. Check file descriptor counts through /proc/[pid]/fd or lsof to rule out an fd leak. Match the tool to the runtime: Valgrind or a sanitizer build for C and C++, a heap dump for JVM, pprof for Go, tracemalloc for Python. Check OOM evidence through journalctl -k, dmesg, or Kubernetes pod events to confirm which process was responsible. A quick note for desktop systems Anyone running into this on their own Mac, rather than a fleet of servers, can usually resolve the issue by identifying the application consuming memory and closing or restarting it before the system becomes unresponsive. In most cases, this can be done through Activity Monitor without using the Terminal or other profiling tools. Anyone running into this on their own Mac, rather than a fleet of servers, can follow a troubleshooting guide to identify the responsible application and recover without losing unsaved work, no profiler or terminal required. Treating memory as a first-class metric The teams that catch leaks early are usually the ones already graphing RSS over time for their long-running services, the same way they graph CPU and disk. A leak announces itself on that chart as a line that never comes back down between deploys, well before it becomes an incident. Memory tends to get treated as a fixed quantity that’s either fine or not, rather than a trend worth watching, and long-running Linux infrastructure punishes that assumption eventually, usually at the worst possible time. . Explore how memory leaks impact Linux system stability, security and performance, including detection techniques and prevention strategies.. Memory Leak Linux, System Stability, Security Implications, Open Source Applications. . MaK Ulac

Jun 26, 2026 •

MaK Ulac Server Security

security advisoryUbuntuimportant

Ubuntu 18.04 EOL: Understanding Security Management and Risks

Linux security depends heavily on whether a system is still inside its support window. When that window closes, the system keeps running, and nothing on the surface changes, but the updates stop immediately. From that point forward, the release no longer tracks the changes happening in the rest of the environment. The gap isn’t evident from uptime or basic monitoring, but it affects how well the system withstands new security pressures. . In a mixed environment, the pattern becomes clear. Systems that still receive updates stay aligned with current fixes, and the ones outside support don’t, so their exposure shifts away from the rest of the fleet. Operations can keep older workloads stable, but stability doesn’t mean the system is protected to the same degree. The kernel introduces another timing layer because it follows its own lifecycle, and that schedule doesn’t always align with the base OS. Ubuntu 18.04 is a straightforward example since its lifecycle is well documented and common in production, making the transitions easy to observe. What follows is a breakdown of how Ubuntu’s lifecycle is structured, what the 18.04 timeline shows in practice, how the kernel’s lifecycle fits into that picture, why these transitions matter for Linux security, and the steps needed to keep systems operating inside supported windows. The systems continue to function normally, but once support ends, they stop receiving updates that keep them aligned with current security needs. Understanding the Ubuntu Linux Support Lifecycle (Standard Support, LTS, ESM, and EOL) Ubuntu’s support lifecycle sets the pace for how long a system can stay aligned with current Linux security expectations. Each LTS release moves through the same sequence of phases: Standard Support, a quieter Maintenance window, Extended Security Maintenance, and finally EOL. The sequence is predictable, and that predictability gives long-lived systems a clear update path as they age. Once a release stops tracking upstreamchanges, its security posture holds still while the rest of the environment keeps moving. The lifecycle policies published by Canonical describe the early stage where full kernel and userland maintenance is still routine. Standard Support brings broad updates, but the rhythm shifts as the release matures and the stream narrows toward security-focused patches. That tightening creates the hinge between Maintenance and ESM, the point where the release moves away from general upkeep and into targeted fixes. Extended Security Maintenance keeps those patches available for Ubuntu Pro users, giving the system a controlled tail period even as the broader ecosystem moves forward. The 18.04 LTS documentation reflects this exact progression, ending in the phase where vendor updates stop entirely and the system holds whatever protections it had at EOL. The OS continues to run without issue, but its defense surface no longer evolves with new threats or upstream corrections. The lifecycle works exactly as designed, and that stable pattern is what makes its support boundaries so important when evaluating long-term security posture. For reference, Ubuntu 18.04’s Standard Support ended on 31 May 2023, and ESM coverage remains available through April 2028 for Ubuntu Pro users. Ubuntu 18.04 Lifecycle Explained: From Standard Support to ESM Ubuntu 18.04 makes a steady case study because its lifecycle was predictable from day one, and the release saw wide use across cloud and enterprise stacks. The transition from Standard Support into ESM followed the schedule exactly as published. That consistency matters, since it shows how a release can operate normally while its support window quietly narrows beneath it. The lifecycle breaks into four clear stages, each with a different security implication: Ubuntu 18.04 Lifecycle Phases Phase What It Included Security Implication Standard Support Full kernel and userland updates System trackscurrent fixes and stays aligned with active development Maintenance Security-focused updates become the primary stream The update surface begins to narrow as broader maintenance winds down. ESM (Ubuntu Pro) Continued security fixes for subscribers Critical patches persist, but only for ESM-enabled systems EOL No further vendor updates System runs, but protection no longer evolves with the environment When Ubuntu 18.04 moved fully to ESM, Ubuntu Pro users continued receiving targeted patches, while non-ESM systems remained operational but no longer gained new protections. That’s the lifecycle principle in plain form: functionality continues, but security alignment halts the moment a release crosses its final support boundary. Linux Kernel LTS Lifecycle and EOL: What Administrators Need to Know The kernel runs on its own support cycle, separate from any distribution, and that cycle determines how long a system can keep gaining new security capabilities. The upstream schedule in the kernel.org LTS table rarely matches a distro’s timeline, which means OS support and kernel support don’t expire at the same time. That split matters because the kernel sets the ceiling for how far its protections can evolve. How the Kernel Lifecycle Works Kernel.org publishes the LTS timeline that decides how long upstream work continues. Each branch receives hardening improvements, mitigation updates, and subsystem refinements until its upstream EOL. Once that date passes, the branch is fixed at its last upstream commit, even if a distribution keeps shipping it. What Changes at Upstream EOL The kernel keeps running, but upstream development stops, so new defenses no longer land. Vendors can still backport CVE fixes, but backports only patch specific issues; they don’t deliver broader changes like stack-hardening updates, memory-isolation improvements, or reworked subsystembehavior. Newer kernel lines continue advancing while the EOL branch stays static, widening the security gap over time. Why This Matters for Long-Lived Releases A release such as Ubuntu 18.04 carries a kernel line whose upstream lifecycle determines which mitigations it can support. Even if the OS remains fully supported, the kernel’s protections stop evolving once its upstream EOL arrives. Both timelines have to be monitored since the distro controls patch flow and the upstream kernel controls the protection ceiling. The Practical Takeaway for Administrators A system can be inside its OS support window while its kernel has already aged out of upstream development, leaving it with a fixed set of defenses. Every distribution inherits this behavior because the upstream kernel sets the boundary, not the vendor. How Lifecycle Boundaries Impact Linux Security Outcomes When a system moves outside its support window, its security posture changes immediately, even though nothing on the surface looks different. The OS keeps running, but it no longer receives the security inputs that matter — advisories, patches, kernel improvements. Supported environments continue to shift with each update cycle, and an unsupported system stays tied to its last known state. What Stops at the Support Boundary New security advisories no longer arrive for that release. Vendor patches stop, leaving exposed systems that continue to be vulnerable. Kernel-level updates end, so no new mitigations or hardening improvements arrive. Vulnerabilities accumulate because the system is no longer part of the active update stream. Components such as systemd, compilers, logging tools, and container runtimes continue to advance across supported stacks, while the unsupported system remains fixed. Ubuntu 18.04 shows this clearly: Standard Support closed on schedule, and from that point forward, only ESM systems continued receiving targeted fixes. Systems running 18.04 without ESM stayedfunctional but could no longer take on the protections needed to match current baselines. Unsupported nodes don’t fall behind all at once; they simply stop moving while everything around them continues to progress. Tracking the latest Linux News makes this visible over time, as supported releases keep gaining updates and older ones drop out of the advisory flow entirely. How to Manage Linux Support Lifecycles (Actionable Steps for Security Teams) Lifecycle timing has a direct impact on Linux security, and the only reliable way to stay aligned is to treat those dates as operational boundaries, not background information. Once the schedule is clear, planning becomes predictable instead of reactive. Track Lifecycle Dates Proactively Use Canonical’s lifecycle pages along with the kernel.org LTS tables so that both support clocks stay in view. One governs distribution updates, the other governs upstream hardening work. Missing either one leads to surprises later. Inventory Systems by Lifecycle Stage Sort machines into Standard Support, Maintenance, ESM, and EOL. It shows which systems still have full coverage and which don’t. Nodes still running Ubuntu 18.04 without ESM usually stand out immediately. This is the point where patch behavior and long-term protection diverge. Apply Updates Before Lifecycle Transitions Apply updates while the release is still in Standard Support, since that’s when the full set of fixes is still available. Once the release moves into later phases, the update stream narrows and coverage drops. Doing the work before that shift avoids the scramble that usually follows. Migrate Workloads Before Deadlines Test on Ubuntu 20.04 or 22.04 early so the move doesn’t collide with other changes. Configuration management tools such as Ansible, Chef, and Puppet drop support for EOL systems, and once that happens, automation degrades quickly. Keeping workloads on supported releases maintains automation. If Ubuntu 18.04 Must Remain Temporarily, ReduceExposure Tighten network access first, keep privileges minimal, and freeze configuration state to avoid drift. These controls reduce the surface while you plan the replacement path. Once CM tools stop supporting Ubuntu 18.04 post-EOL, expect more manual handling for anything not already scripted. Monitor Active Advisories Compare the update activity of supported releases to what your older branches receive. The difference becomes visible fast when unsupported systems fall out of the advisory flow. The Ubuntu advisories page is a practical way to track that gap as it opens. Takeaway: Treat Lifecycle Awareness as a Core Linux Security Practice Lifecycle awareness sits at the center of modern Linux security work because a system’s protection level follows its support stage, not how healthy it appears. Ubuntu 18.04 shows this clearly; it moved through each phase as documented, gaining new defenses while supported and holding steady once that window closed. Supported systems continue to evolve with current protections, and unsupported systems remain fixed at whatever update level they held on the final day. Lifecycle deadlines should be treated as security deadlines. They mark the point where a system can no longer keep pace with the environment around it. Broader operational issues—such as system drift in Linux —often begin from the same condition: a system that stops moving while everything else keeps going. Staying inside defined support windows is the most reliable way to prevent that drift from taking hold. . Understand the implications of Ubuntu 18.04 EOL on security and how to manage risks effectively.. Ubuntu Security, LTS Support, Linux Lifecycle Management, EOL Risks. . MaK Ulac

Nov 20, 2025 •

MaK Ulac Server Security

security riskpythonsoftware transition

Navigating Legacy Infrastructure Amidst Python 2 Sunset Phase

The Python 2 EOL is coming and will have some serious implications for legacy systems. . If you're a developer, you know that once a language reaches EOL, it won't get any new features or bug fixes. That means if you're using Python 2, there will be no more support from the creators of the language. Plus, plenty of projects still use versions of Python 2 that haven't been updated since 2014—so they're likely vulnerable to hacking and other attacks. But what if your company has legacy code that doesn't support newer languages like Python 3? How can you manage this transition? I found the article linked below helpful in understanding how to deal with this issue, how long it takes to make the switch, how much it costs, and what kinds of things could go wrong during the process. Check it out! If you have additional questions, please connect with me on X @lnxsec - I'd love to help! The link for this article located at Security Boulevard is no longer available. . As Python 2 nears end-of-life, developers face migration challenges and security issues that need addressing effectively.. Python End Of Life, Legacy System Challenges, Software Transition, Code Migration. . LinuxSecurity.com Team

Dec 17, 2023 •

LinuxSecurity.com Team Security Projects

security advisoryIntelsecurity risk

Intel Alder Lake BIOS Code Leak: Security Risks and Hidden Features

Source code for the BIOS used with Intel's 12th-gen Core processors has been leaked online, possibly including details of undocumented model-specific registers (MSRs) and even the private signing key for Intel's Boot Guard security technology. . The source code was apparently shared via 4chan and GitHub, in a file containing tools and code for generating and optimizing BIOS/UEFI firmware images, plus related documentation. Word quickly spread to Twitter at the weekend, Alder Lake being the code-name for the x86 giant's 12th-gen desktop processors. The source code may reveal exploitable vulnerabilities in the firmware that miscreants could abuse in future on people's PCs. . Uncover the exposed Intel Alder Lake firmware source code, highlighting possible vulnerabilities and hidden functionalities.. Intel BIOS Leak, Alder Lake Security Threats, Firmware Exploits. . LinuxSecurity.com Team

Oct 14, 2022 •

LinuxSecurity.com Team Hacks/Cracks

cyber threatssecurity riskattack methods

Malware Delivery Risks in Linux Systems Require Vigilance Against Threats

Linux systems are a popular delivery mechanism for malware. While they’re not the most popular – that distinction goes to HTML and Javascript – don’t think you can ignore them. Linux-based attacks are very much still happening. . When bad actors identify a vulnerability they can exploit, their next move is typically to spread malware to achieve their objectives. When deciding what platforms to employ, hackers have a variety of ways to get malware into systems without attracting attention. This is known as the “hacker’s choice.” And they can also find ways to remain in those systems even longer without being noticed, which is what we’re seeing with advanced persistent crime (APC). Our researchers have observed that over the previous six months, HTML has been the most common method of malware delivery, with a difference of about 10% between it and Javascript. HTML hit a new high in May. . Operating systems like Linux can still pose vulnerabilities for malware infiltration, underscoring the necessity of continuous protective protocols against potential dangers.. Malware Delivery, Linux Systems, Cyber Threat Awareness, Security Practices. . Brittany Day

Sep 30, 2022 •

Brittany Day Security Trends

security riskgnomelinux systems

GNOME's New Feature to Alert on Secure Boot Risks in UEFI Systems

GNOME is planning to protect insecure hardware by notifying users more about their firmware security status. . When you install Linux on your UEFI-enabled computer, you have to disable Secure Boot because the live USB will refuse to boot with the option enabled. Some mainstream Linux distributions support Secure Boot, but it is still challenging to set up for many other distributions (and with Nvidia hardware onboard). While things may not have improved over the years, Secure Boot is an essential protection feature in general. . Explore GNOME's initiatives aimed at alerting users about their firmware security conditions in relation to Secure Boot vulnerabilities.. Secure Boot, GNOME Notifications, UEFI Security, Firmware Status, Linux Hardware Risks. . Brittany Day

Aug 02, 2022 •

Brittany Day Desktop Security

remote accessmalwaresecurity risk

Rising Malware Threats in Windows Subsystem for Linux (WSL)

The number of malware strains targeting WSL is growing. . Windows Subsystem for Linux (WSL) is becoming a breeding ground for malware , cybersecurity researchers are saying. While WSL-based malware is not particularly new (spotted as early as September 2021), it’s been rising in popularity among cybercriminals of late. Speaking to BleepingComputer, cybersecurity researchers from Lumen Technologies said they’ve managed to track more than 100 samples since then. The samples vary in complexity, as well as features on offer. While some are relatively simple, others enable threat actors to remotely access devices, run arbitrary code, steal authentication cookies from specific browsers , or download files. . The Windows Subsystem for Linux (WSL) is increasingly viewed as a potential hotspot for malicious software, prompting alarm bells to ring amongst cybersecurity professionals.. Windows Subsystem for Linux, Malware Threats, Cybersecurity Risks, Remote Access Issues. . LinuxSecurity.com Team

Jun 01, 2022 •

LinuxSecurity.com Team Hacks/Cracks

patch managementsecurity riskvulnerability management

Critical Linux Patching Delays Lead to Increased Cybersecurity Incidents

Computer security only happens when software is kept up to date. That should be a basic tenet for business users and IT departments. Apparently, it isn’t. At least for some Linux users who ignore installing patches, critical or otherwise. A recent survey sponsored by TuxCare , a vendor-neutral enterprise support system for commercial Linux, shows companies fail to protect themselves against cyberattacks even when patches exist. . Results reveal that some 55 percent of respondents had a cybersecurity incident because an available patch was not applied. In fact, once a critical or high priority vulnerability was found, 56 percent took five weeks to one year on average to patch the vulnerability. The goal of the study was to understand how organizations are managing security and stability in the Linux suite of products. Sponsored by TuxCare, the Ponemon Institute in March surveyed 564 IT staffers and security practitioners in 16 different industries in the United States. . Research indicates that 55% experienced security breaches stemming from outdated software; discover efficient methods for applying updates.. Cybersecurity Incidents, Linux Patching, IT Management, Software Security, Linux Study. . Brittany Day

May 09, 2022 •

Brittany Day Security Trends

Community Poll

More Polls

Stay Ahead With Linux Security News

Refine news

Get the latest News and Insights

Community Poll

Is continuous patching actually viable?

Trending News

Misuse of Cron Jobs for Long-Term Access in Linux Environments

MXDR Provider Selection for Linux Environments and Security Services

Risks of GitHub Repo Breach on Linux Supply Chain Security

After Years of Supply Chain Attacks, npm Is Finally Closing the Door on Auto-Scripts

Explore Latest Linux Security news

How Memory Leaks Affect System Stability and Security

Ubuntu 18.04 EOL: Understanding Security Management and Risks

Navigating Legacy Infrastructure Amidst Python 2 Sunset Phase

Intel Alder Lake BIOS Code Leak: Security Risks and Hidden Features

Malware Delivery Risks in Linux Systems Require Vigilance Against Threats

GNOME's New Feature to Alert on Secure Boot Risks in UEFI Systems

Rising Malware Threats in Windows Subsystem for Linux (WSL)

Critical Linux Patching Delays Lead to Increased Cybersecurity Incidents

Get the latest News and Insights

Community Poll

Is continuous patching actually viable?

Trending News

Misuse of Cron Jobs for Long-Term Access in Linux Environments

MXDR Provider Selection for Linux Environments and Security Services

Risks of GitHub Repo Breach on Linux Supply Chain Security

After Years of Supply Chain Attacks, npm Is Finally Closing the Door on Auto-Scripts

Powered By

Linux Security - Your source for Top Linux News, Advisories, HOWTOs and Feature Releases

QUICK LINKS

subscribe to newsletters!

Stay Ahead With Linux Security News

Refine news

Topics

Category

Authors

Published Date

Get the latest News and Insights

Community Poll

Is continuous patching actually viable?

Trending News

Explore Latest Linux Security news

Get the latest News and Insights

Community Poll

Is continuous patching actually viable?

Trending News

Search Topics

Powered By

Linux Security - Your source for Top Linux News, Advisories, HOWTOs and Feature Releases

QUICK LINKS

subscribe to newsletters!