Jump to content

Search the Community

Showing results for tags 'linux kernel'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Site Related
    • News & Updates
    • Site / Forum Feedback
    • Member Introduction
  • News
    • General News
    • FileSharing News
    • Mobile News
    • Software News
    • Security & Privacy News
    • Technology News
  • Downloads
    • nsane.down
  • General Discussions & Support
    • Filesharing Chat
    • Security & Privacy Center
    • Software Chat
    • Mobile Mania
    • Technology Talk
    • Entertainment Exchange
    • Guides & Tutorials
  • Off-Topic Chat
    • The Chat Bar
    • Jokes & Funny Stuff
    • Polling Station

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Found 19 results

  1. Google Project Zero scolds Samsung and other vendors for adding features that undermine Android security. Samsung's attempt to prevent attacks on Galaxy phones by modifying kernel code ended up exposing it to more security bugs, according to Google Project Zero (GPZ). Not only are smartphone makers like Samsung creating more vulnerabilities by adding downstream custom drivers for direct hardware access to Android's Linux kernel, vendors would be better off using security features that already exist in the Linux kernel, according to GPZ researcher Jann Horn. It was this type of mistake that Horn found in the Android kernel on the Samsung Galaxy A50. But as he notes, what Samsung did is pretty common among all smartphone vendors. That is, adding code to the Linux kernel code downstream that upstream kernel developers haven't reviewed. Even when these downstream customizations are meant to add security to a device, they also introduce security bugs. Samsung's intended kernel security mitigations introduced a memory corruption bug that Google reported to Samsung in November. It was patched in Samsung's just-released February update for Galaxy phones. The issue affects Samsung's extra security subsystem called PROCA or Process Authenticator. Samsung describes the bug, SVE-2019-16132, as a moderate issue consisting of use-after-free and double-free vulnerabilities in PROCA that allow "possible arbitrary code execution" on some Galaxy devices running Android 9.0 and 10.0. Incidentally, the February update also includes a patch for critical flaw in "TEEGRIS devices", referring to Trusted Execution Environment (TEE) on newer Galaxy phones that contain Samsung's proprietary TEE operating system. The Galaxy S10 is among TEEGRIS devices. But Horn's new blogpost is focused on efforts in Android to reduce the security impact of vendors adding unique code to the kernel. "Android has been reducing the security impact of such code by locking down which processes have access to device drivers, which are often vendor-specific," explains Horn. An example is that newer Android phones access hardware through dedicated helper processes, collectively known as the Hardware Abstraction Layer (HAL) in Android. But Horn says vendors modifying how core parts of the Linux kernel work undermines efforts to "lock down the attack surface". Instead, he suggests handset makers use direct hardware access features already supported in Linux, rather than customizing Linux kernel code. Horn says some of the custom features that Samsung added are "unnecessary" and wouldn't affect the device if they were removed. He speculated that PROCA is meant to restrict an attacker who has already gained read and write access on the kernel. But he reckons Samsung could be more efficient by directing engineering resources to preventing an attacker from getting this access in the first place. "I believe that device-specific kernel modifications would be better off either being upstreamed or moved into userspace drivers, where they can be implemented in safer programming languages and/or sandboxed, and at the same time won't complicate updates to newer kernel releases," explained Horn. Source
  2. Google outlines plans for mainline Linux kernel support in Android Google wants less forking, more modularization for Android's Linux kernel. First image of article image gallery. Please visit the source link to see all images. It seems like Google is working hard to update and upstream the Linux kernel that sits at the heart of every Android phone. The company was a big participant in this year's Linux Plumbers Conference, a yearly meeting of the top Linux developers, and Google spent a lot of time talking about getting Android to work with a generic Linux kernel instead of the highly-customized version it uses now. It even showed an Android phone running a mainline Linux kernel. But first, some background on Android's current kernel mess.Currently, three major forks happen in between the "mainline" Linux kernel and a shipping Android device (note that "mainline" here has no relation to Google's own "Project Mainline"). First, Google takes the an LTS (Long Term Support) Linux kernel and turns it into the "Android Common kernel"—the Linux kernel with all the Android OS-specific patches applied. Android Common is shipped to the SoC vendor (usually Qualcomm) where it gets its first round of hardware-specific additions, first focusing on a particular model of SoC. This "SoC Kernel" then gets sent to a device manufacturer for even more hardware-specific code that supports every other piece of hardware, like the display, camera, speakers, usb ports, and any extra hardware. This is the "Device Kernel," and it's what actually ships on a device. This is an extremely long journey that results in every device shipping millions of lines of out-of-tree kernel code. Every shipping device kernel is different and device specific—basically no device kernel from one phone will work on another phone. The mainline kernel version for a device is locked in at the beginning of an SoC's initial development, so it's typical for a brand-new device to ship with a Linux kernel that is two years old. Even Google's latest and, uh, greatest device, the Pixel 4, shipped in October 2019 with Linux kernel 4.14, an LTS release from November 2017. It will be stuck on kernel 4.14 forever, too. Android devices do not get kernel updates, probably thanks to the incredible amount of work needed to produce just a single device kernel, and the chain of companies that would need to cooperate to do it. Thanks to kernel updates never happening, this means every new release of Android usually has to support the last three years of LTS kernel releases (the minimum for Android 10 is 4.9, a 2016 release). Google's commitments to support older versions of Android with security patches means the company is still supporting kernel 3.18, which is five years old now. Google's band-aid solution for this so far has been to team up with the Linux community and support mainline Linux LTS releases for longer, and they're now up to six years of support. Last year, at Linux Plumbers Conference 2018, Google announced its initial investigation into bringing the Android kernel closer to mainline Linux. This year it shared a bit more detail on its progress so far, but it's definitely still a work in progress. "Today, we don't know what it takes to be added to the kernel to run on a [specific] Android device," Android Kernel Team lead Sandeep Patil told the group at LPC 2019. "We know what it takes to run Android but not necessarily on any given hardware. So our goal is to basically find all of that out, then upstream it and try to be as close to mainline as possible." Google says that "compared to [Linux] LTS (4.14.0), the Android common kernel has 355 changes, 32,266 insertions, and 1,546 deletions (as of February 2018)." Progress is being made here every year, but keep in mind there are still two more forks after this. Google While there is still work to be done for getting the wider Android ecosystem and myriad device configurations on board, for specific models of device, things seem to be progressing well. Tom Gall, the director of the Linaro Consumer Group, showed off a Xiaomi Poco F1 actually running the mainline Linux kernel under the usual Android OS. Gall told the audience "There are major, major props to be given to the Google Kernel Team in particular for getting their code upstream so that we can boot devices with a mainline kernel." Along with the plan to upstream as much kernel code as possible, Google is also looking to replicate its earlier work at modularizing Android, Project Treble. Just as Treble created a stable interface between the Android OS and the device HALs (Hardware Abstraction Layers), Google's proposal for bringing Android closer to mainline Linux (How is there not a silly "project" name for this yet?) involves stabilizing Linux's in-kernel ABI and having a stable interface for the Linux kernel and hardware vendors to write to. Google wants to decouple the Linux kernel from its hardware support. The Linux community has been against the idea of a stable interface for some time, with the suggestion that if you want the ability to quickly update a kernel, open source your drivers and get them in the main kernel tree, where any changes will be taken care of for you. Open sourcing drivers is an absolute deal breaker for many hardware companies, though, and no amount of advocacy or product degradation is going to change that. The fact that Google is stuck supporting five-year-old versions of Linux shows this model isn't working. Enlarge / Instead of a bunch of forks, Google imagines the new kernel as a series of modules. Matthias Männich Matthias Männich, a senior software engineer at Google, displayed a diagram labeled "Android Next Generation" that showed what this proposed kernel architecture would look like. Google would ship a "Generic Kernel Image (GKI)" along with several "GKI Modules" that would expose this stable API/ABI in the kernel. The hardware-specific drivers (probably closed source drivers) would be loaded as kernel modules. So instead of forks on top of forks, everything gets modularized into additive packages. For now, Google is only proposing that the in-kernel ABI be stable for a single LTS version. So this wouldn't allow devices to upgrade from one version of the Linux kernel to another—it would just allow for a single generalized kernel image to work across multiple devices, instead of the device-specific kernel forks we have today. It would definitely allow for easier security updates, and hopefully it would get new LTS releases to market faster. We would be premature if we said this is a change that is definitely coming to Android and the Linux kernel. There are still tons of problems to solve (both technically and politically, I would imagine), and some of these talks were more like public brainstorming sessions between the Google presenters and the Linux engineers (many of which were also Googlers!) in the audience. This is the second year in a row Google has showed up to LPC and pitched the idea of using the mainline Linux kernel in Android, though, and with Android being of the biggest Linux sort-of-distros on Earth, it makes sense for everyone to work together, right? "We have miles to go, and we know that, but we've come along from where we started," Patil told the crowd. "Last year, I talked it into existence. This time, we actually have problems to discuss." Listing image by Eric Adeleye / Flickr Source: Google outlines plans for mainline Linux kernel support in Android (Ars Technica) (To view the article's image gallery, please visit the above link)
  3. Linux, the most important software program in the world, has a major weak point: Poor testing. That's changing, and one big sign of that is KernelCI, an automated testing framework for the Linux kernel, is now a Linux Foundation project. At the recent Linux Kernel Plumbers get-together in Lisbon, Portugal, one of the hottest topics was how to bring better and automated testing to the Linux kernel. There, the top Linux developers united their efforts behind one testing framework: KernelCI. Now, at Open Source Summit Europe in Lyon, France, to help give KernelCI the resources it needs to be successful, it became a Linux Foundation project. Here's how it works: As you probably know the Linux kernel is developed by a large, collaborative open-source community, which works through the Linux Kernel Mailing List (LKML). You can't argue with the method. But Linux kernel testing is fragmented -- since it is largely done in private silos without enough collaboration on the testing software or methodologies. Part of the problem is how patches are done with Linux's mailing lists. Russell Currey, a Linux kernel developer, recently explained: "[Unlike a project based solely on GitHub or GitLab] where a pull request contains all of the information needed to merge a group of changes; an email containing, say, patch 7/10 lacks that context. It is nearly impossible to tell from an email message whether a patch series has been merged, rejected, or superseded. In general, mailing lists simply do not carry the same level of metadata as contemporary project-hosting sites, and that makes the CI [Continuous Integration] problem harder." The specific problem? KernelCI was designed in the beginning to address testing Linux on a wide variety of hardware. Until now, when Linux patches were tested, they were done on developers' own machines. That meant you could be sure Linux would run as expected on mainstream hardware. But if your hardware wasn't that popular… Well, chances are it wasn't tested. As Greg Kroah-Hartman, the maintainer of the Linux stable branch, explained: "Linux runs everywhere and on so many different pieces of hardware and but the testing on that hardware was very minimal. Most people, were just testing on the few things that they cared about. So we want to test it on as much hardware as we could to make sure that we're actually supporting all the hardware that we claim we're supporting." Going forward, though, KernelCI will do more than just far more than just hardware testing. Kevin Hilman, KernelCI's co-founder, and a senior engineer at BayLibre, explained in his Open Source Summit Europe keynote: "We got together at Linux Plumbers. One of the big problems that we have now is we have six or seven different code testing projects that were sending kernel developers and maintainers reports This was getting really annoying so we came together and said, 'pick one and use it as a framework' and so we've agreed on KernelCI so, we're all gonna work together, not to duplicate our efforts and results." By consolidating these testing projects and seeking common ground, the new KernelCI will also help address the problem of dealing with patches within the LKML. So, while there will still be many Linux testing suites, no longer will they stand alone without any real coordination between them. KernelCI's goal going forward will be not just to test a wider variety of devices but to unify all upstream Linux kernel testing efforts. Together, this will provide a single place to store, view, compare and track testing results. "Provided how crucial Linux has become to society, achieving comprehensive test coverage of the Linux kernel is essential. By applying the open-source philosophy to testing, the KernelCI distributed architecture enables the whole kernel community to collaborate around a single upstream CI system," said Guy Lunardi, VP of business development at open-source consultancy and KernelCI contributor Collabora. Put it all together, and KernelCI will improve Linux Long Term Support (LTS) kernel testing and validation; consolidate existing testing initiatives; improve Linux's overall security; and increase the pool of tested hardware. This, in turn, will improve the quality, stability. and long-term maintenance of the Linux kernel. And, that is a very good thing. Source
  4. New Linux kernel "lockdown" module to limit high-privileged users -- even root -- from tampering with some kernel functionality. After years of countless reviews, discussions, and code rewrites, Linus Torvalds approved on Saturday a new security feature for the Linux kernel, named "lockdown." The new feature will ship as a LSM (Linux Security Module) in the soon-to-be-released Linux kernel 5.4 branch, where it will be turned off by default; usage being optional due to the risk of breaking existing systems. Putting a leash on the root account The new feature's primary function will be to strengthen the divide between userland processes and kernel code by preventing even the root account from interacting with kernel code -- something that it's been able to do, by design, until now. When enabled, the new "lockdown" feature will restrict some kernel functionality, even for the root user, making it harder for compromised root accounts to compromise the rest of the OS. "The lockdown module is intended to allow for kernels to be locked down early in [the] boot [process]," said Matthew Garrett, the Google engineer who proposed the feature a few years back. "When enabled, various pieces of kernel functionality are restricted," said Linus Torvalds, Linux kernel creator, and the one who put the final stamp of approval on the module yesterday. This includes restricting access to kernel features that may allow arbitrary code execution via code supplied by userland processes; blocking processes from writing or reading /dev/mem and /dev/kmem memory; block access to opening /dev/port to prevent raw port access; enforcing kernel module signatures; and many more others, detailed here. Two lockdown modes The new module will support two lockdown modes, namely "integrity" and "confidentiality." Each is unique, and restricts access to different kernel functionality. "If set to integrity, kernel features that allow userland to modify the running kernel are disabled," said Torvalds. "If set to confidentiality, kernel features that allow userland to extract confidential information from the kernel are also disabled." If necessary, additional lockdown modes can also be added on top, but this will require an external patch, on top of the lockdown LSM. A long time coming Work on the kernel lockdown feature started in the early 2010s, and was spearheaded by now-Google engineer, Matthew Garrett. The idea behind the kernel lockdown feature was to create a security mechanism to prevent users with elevetated permissions -- even the vaunted "root" account -- from tampering with the kernel's code. Back then, even if Linux systems were employing secure boot mechanisms, there were still ways that malware could abuse drivers, root accounts, and user accounts with special elevated privileges to tamper with the kernel's code, and by doing so, gain boot persistence and a permanent foothold on infected systems. Many security experts have asked across the years that the Linux kernel support a more potent way to restrict the root account and improve kernel security. The main opposition came from Torvalds, who was one of the feature's most ardent critics, especially in its early days. As a result, many Linux distros, such as Red Hat, developed their own Linux kernel patches that added a lockdown feature on top of the mainline kernel. However, the two parties reached a middleground in 2018, and work progressed on the lockdown feature this year. "The majority of mainstream distributions have been carrying variants of this patchset for many years now, so there's value in providing a doesn't meet every distribution requirement, but gets us much closer to not requiring external patches," Torvalds said yesterday. "Applications that rely on low-level access to either hardware or the kernel may cease working as a result - therefore this should not be enabled without appropriate evaluation beforehand." The news that a kernel lockdown module has been finally approved has been greeted positively in the Linux and cyber-security communities. Source
  5. 5 ways Linux changed our lives and we didn’t even know it Aug. 25, 1991, a 21-year-old Finnish student named Linus Torvalds announced to the internet that he was working on a project he said was “just a hobby, won’t be big and professional.” Less than one month later, Torvalds released the Linux kernel to the public. The world hasn’t been the same since. From how we interact with one another on a daily basis to preparing for the future of the human race, Linux is integral to our technological development. To commemorate the nearly 30 years that Linux has been available, we compiled a shortlist of ways Linux has fundamentally changed our lives. Linux and the internet It’s hard to imagine life without the internet. It’s how we communicate, how we learn, and how we hear about the outside world. Needless to say, the internet is one of the single most important inventions in human history, and today it is mostly powered by Linux. Linux-based operating systems are the number-one choice for servers around the world. Servers are computers that keep an individual’s or a company’s digital services, products, and websites connected to the internet. Whether its Google, Twitter, Facebook, Amazon, or even Apple, most companies choose to use some form of Linux to run their businesses. It’s hard to pin down exactly how many servers run Linux. As of 2015, web analytics and market share company W3Cook estimated that as many as 96.4% of all servers ran Linux or one of its derivatives. No matter the exact number, it’s safe to say that the kernel nearly powers the entire web. The computer in your pocket, on your wrist, and in your TV Not only is the internet essentially powered by Linux, but it changed how we most often access the internet: our Android smartphones. Founded in Oct. 2003, a team of developers forked Android from Linux to run on digital cameras. Nearly 16 years later, it’s the single most popular operating system in the world, running on more than 2 billion devices. Even Chrome OS, Android TV, and Wear OS are all forked from Linux. Google isn’t the only one to do this either. Samsung’s own in-house operating system, Tizen, is forked from Linux as well, and it’s is even backed by The Linux Foundation. It is incredibly likely that at least one of the devices you use everyday runs some form of Linux. So, the next time you think how amazing your new Samsung Galaxy Note 10 or OnePlus 7 Pro is, thank Linux it exists. Linux and the automotive industry Smartphones and similar devices have been commonplace for some time now. Unlike them, electric and smart cars are newer to the consumer electronics industry. Just like other devices, most of these offerings run Linux, and I’m not just talking about Android Auto. Tesla uses Linux as the software in every one of its products. In 2018, ZDNet reported that Tesla even began releasing that code to the public, as is custom for all open-source software. Tesla isn’t alone in this either. Many major car companies like Honda, Mazda, Volkswagen, and Mercedes-Benz rely on Automotive Grade Linux to deliver their connected car functionality to customers. Wide adoption of standardized connected functionality would be nearly impossible without the kernel, making it the future of the industry. Supercomputers and other research tools Supercomputers date all the way back to 1960. But, no matter how long they have been around, supercomputers are more powerful now than ever before, and nearly all of them use Linux. Supercomputers are the most powerful technological devices on the planet. Scientists use them to study quantum mechanics, weather forecasting, and molecular research. And, as of 2017, every one of the top 500 supercomputers in the world runs on Linux. Alongside these supercomputers, companies like CERN, a European nuclear research organization, run Linux for its research. In 2009, CERN launched the world’s largest and most powerful particle accelerator. This Linux powered machine is called the Large Hadron Collider, and CERN uses it to study matter, energy, and how the universe began. NASA and SpaceX Linux has even changed how we study the universe at large. For similar reasons cars and supercomputers use Linux, NASA uses it for most of the computers aboard the International Space Station. Astronauts use these computers to carry out research and perform tasks related to their assignments. But NASA isn’t the only galaxy studying organization using Linux. The privately-owned SpaceX also uses Linux for many of its projects. In 2017, SpaceX sent a Linux-powered supercomputer developed by HP to space and, according to an AMA on Reddit, even the Dragon and Falcon 9 run Linux. In the end, the kernel has changed us more than we will ever know. It is crucial to our communication, scientific research, and technological development. And it does all of that while simultaneously allowing the internet to provide us an infinite amount of dank memes. Without it, there would be no science or social human development, and we would all still be cave-people. So thank you, Linux, for bringing us together both physically and digitally over the last 28 years. We look forward to the future and how you will change our lives even more. Source
  6. Currently, at release candidate 3, the Linux 5.2 kernel is coming soon and promises to offer quite a host of impressive new features and improvements. Let’s take a look at some of the highlights. New Features Fieldbus Subsystem One of the new features that should excite anyone who deals with automated industrial systems is the introduction of the new Fieldbus Subsystem. Fieldbus is crucial in connecting different systems in industrial environments, and with this addition, the Linux kernel can now natively communicate with field instruments (such as those used in manufacturing plants) as a part of a control system. U2F Zero Driver Two-Factor authentication will be getting a bump in the 5.2 kernel, thanks to the new U2F Zero driver. This new drive will add support for USB-based U2F tokens, which can work with online 2-Factor Authentication. The U2F driver will also provide hardware-based Random Number Generator (RNG) capability. NVIDIA “AltMode” A new open-source NVIDIA driver is coming that handles VirtualLink devices that make use of the USB-C connector-based RTX Turing graphics cards. As for the VirtualLink devices, there is no certainty as to which device might first be supported, but (according to Phoronix) Valve might possibly be among the first VR Head Mounted Display to be supported. Generic Counter Interface Although not as sexy as some of the other new features coming to the kernel, there’s a new Generic Counter Interface that will allow counter devices and drivers to reuse common code (rather than having to use redundant code for each driver). What is a Counter Device? According to the diff for generic-counter.rst: Counter devices are prevalent within a diverse spectrum of industries. The ubiquitous presence of these devices necessitates a common interface and standard of interaction and exposure. This driver API attempts to resolve the issue of duplicate code found among existing counter device drivers by introducing a generic counter interface for consumption. The Generic Counter interface enables drivers to support and expose a common set of components and functionality present in counter devices. Null TTY Driver The NULL TTY driver is necessary when a console driver is needed, but not available. When this occurs, the NULL TTY driver will provide a dummy console so that all writes are simply discarded. One practical application for such a driver would be embedded controllers. Daktronics Drivers Daktronics is a global manufacturer of massive displays (such as those used for scoreboards). These particular drivers have been out of the Linux tree since the 2.x days, but are finally making their way back. Once these drivers return, they will be cleaned up for production usage. Anyone who works with Daktronics displays should be quite excited about this niche-y news. Intel Comet Lake Intel Comet Lake is the successor to Coffee Lake and is rumored to top out at 10 physical cores. These new processors should see a mid-year launch and (according to rumors, might require a new motherboard/socket). Comet Lake should be well supported in kernel 5.2. Improvements There are a number of improvements coming to 5.2. Let’s take a look at some of these highlights. Logitech Wireless Devices If you own any sort of Logitech wireless device (such as a keyboard or mouse), you will see significant improvement, such as better battery monitoring and per-device key-mapping. Previous iterations of the kernel supported Logitech wireless devices via generic HID emulation, but with 5.2 the per-device keymapping will make it possible to better support individual wireless devices. EXT4 Case-Insensitive Filenames/Folders Linux has, since inception, been case sensitive. However, with 5.2, the EXT4 filesystem will allow, on a per-directory basis, the support of case-insensitive files and folders. These patches have been in development and it seems they are finally ready for mainline support. AMD Ryzen Laptop Improvement For those with laptops that use AMD Ryzen chips, you should see significant improvement with touchscreens and touchpads. AMDGPU Alex Deucher (of AMD) has been working on replacement code to clean up/improve: Power profiles for PowerPlay Dx display bandwidth RAS support with Vega 20 Plane handling with the DC code FreeSync X86 Memory Management Thanks to VMware’s Nadav Amit, the 5.2 kernel should see a 3% performance increase, by reworking a portion of the kernel’s x86 Translation Lookaside Buffer (TLB)/memory management code. Other Improvements/Features Kernel 5.2 should see a number of other improvements for the likes of: Intel Icelake ARM Mali graphics hardware Fixes for the Nouveau open source graphics driver Improved Thunderbolt support (for older Apple hardware) Intel i40e Dynamic Device personalization ASpeed AST2500 SoC driver Zap shader support for Qualcomm Adreno 600 GCC 9 live-patching Be on the Lookout When the 5.2 kernel releases, there should be serious improvements for nearly any type of user. The release date has not been set, but kernel 5.2 should find its way into the wild sometime in late 2019 or early 2020. Be on the lookout for this to hit your systems in the coming months. Source
  7. As suggested by Thomas Gleixner and signed off by Waiman Long in a proposed Linux kernel patch, a new bit will be introduced to toggle off Speculative Store Bypass Disable (SSBD) for programs that do not require the extra protection against the Spectre Variant 4 security issue. This vulnerability was disclosed during May 2018 and mitigated in the Linux kernel with the SSBD bit added to the IA32_SPEC_CTRL Model-Specific Register (MSR) of x86 processors and introduced via an intel-microcode omnibus update on August 27, 2018. SSBD mitigates the effects of the CVE-2018-3639 (aka Variant 4 or SpectreNG or Speculative Store Bypass or SSB) hardware security vulnerability which can be exploited by would-be attackers using "speculative execution and cache based side channel methods to bypass security measures and access privileged memory." SSB is closely related to the Meltdown and Spectre issues, and it affects a wide range of modern microprocessors, from AMD, Intel, and ARM, to IBM, POWER8, and POWER9. According to the suggested Linux kernel patch: Only certain class of applications (like Java) that can run on behalf of multiple users on a single thread will require disabling speculative store bypass for security purposes. Those applications will call prctl(2) at startup time to disable SSB. They won't rely on the fact the SSB might have been disabled. Other applications that don't need SSBD will just move on without checking if SSBD has been turned on or not. The fact that the TIF_SSBD is inherited across execve(2) boundary will cause performance of applications that don't need SSBD but their predecessors have SSBD on to be unwittingly impacted especially if they write to memory a lot. To be more exact, the unnecessary performance decrease caused by SSBD to programs unaffected by SSB stems from the inheritance of the TIF_SSBD bit when new tasks are either forked or cloned, leading to the bit still being kept active "when a new program is execve'ed". To fix this problem, the new changes to the kernel will add a PR_SPEC_DISABLE_NOEXEC argument for the PR_SET_SPECULATION_CTRL option of prctl(2) which will enable allow applications to specify that the SSBD feature bit should be cleared whenever a new program is being executed. Using this argument will allow Linux programs that do not need protection against the Speculative Store Bypass issue to run without a performance hit. It is also important to mention that, as explained by Red Hat's Jon Masters, system administrators who want "to globally disable the Speculative Store Buffer Bypassing can do so quickly and easily through the new “spec_store_bypass_disable” kernel parameter." Source
  8. It was just several years ago that the open-source ecosystem began supporting the x32 ABI, but already kernel developers are talking of potentially deprecating the support and for it to be ultimately removed. The Linux x32 ABI as a reminder requires x86_64 processors and is engineered to support the modern x86_64 features but with using 32-bit pointers rather than 64-bit pointers. The x32 ABI allows for making use of the additional registers and other features of x86_64 but with just 32-bit pointers in order to provide faster performance when 64-bit pointers are unnecessary. While the x32 support was plumbed through the Linux landscape, it really hasn't been used much. Kernel developers are now discussing the future of the x32 ABI due to the maintenance cost involved in still supporting this code but with minimal users. Linus Torvalds is in favor of sunsetting x32 and many other upstream contributors in favor of seeing it deprecated and removed. However, there are some users still of this port although no known enterprise users, so we'll see what ends up happening with Linux x32. Source
  9. This is on by default? 'Yikes' says Chipzilla techie Linux supremo Linus Torvalds has voiced support for a kernel patch that limits a previously deployed defense against Spectre Variant 2, a data-leaking vulnerability in modern processors. Specifically, the proposed patch disables a particular Spectre V2 defense mechanism by default, rather than switching it on automatically. And here's the reason for that suggested change: code runs up to 50 per cent slower on Intel CPUs that use Hyper-Threading with the security defense enabled. For those not in the know, Hyper-Threading is Chipzilla's implementation of simultaneous multi-threading (SMT), which splits individual CPU cores into two hardware threads. Thus, each core can mostly run two strands of software at the same time. That means a, say, 12-core processor would have 24 hardware threads, effectively presenting itself as a 24-core chip to the operating system and software. Some applications benefit from SMT, and some suffer, depending on what they're trying to achieve and how. It's been known, and mitigated for a while, that code running in one hardware thread can potentially snoop on another app running on its sibling thread within their shared CPU core. The Spectre family of vulnerabilities has reopened this Pandora's box of security headaches, though, in that SMT and some Spectre kernel mitigations don't mix well, resulting in a performance hit. STIBP THBIS NONBSEPNSE The specific Spectre V2 mitigation in this case was added to Linux 4.20 and backported to Linux 4.19.2. It's called STIBP (Single Thread Indirect Branch Predictors), and prevents the processor's branch prediction engine from being exploited by malware on a computer to steal passwords, encryption keys, and other secrets out of memory it shouldn't have access to. The defense mechanism turns out to be such a drag on performance that Torvalds believes it should not be enabled by default in all cases. "When performance goes down by 50 per cent on some loads, people need to start asking themselves whether it was worth it," Torvalds wrote in a message to the Linux kernel mailing list on Sunday. "It's apparently better to just disable SMT entirely, which is what security-conscious people do anyway." In response to a suggestion by Jiri Kosina, director of the Core Kernel team at SUSE Labs, that a practical Spectre Variant 2 attack might involve JavaScript in one browser tab targeting private data in a separate tab, Torvalds expressed skepticism, arguing that's far more theoretical than the Meltdown vulnerability. For one thing, browsers have built in their own defenses against tabs using Spectre to steal information, and to date, there's no word on malware or spyware in the wild exploiting the processor flaws. "Have you seen any actual realistic attacks for normal human users?" he asked. "Things where the *kernel* should actually care? The JavaScript thing is for the browser to fix up, not for the kernel to say 'now everything should run up to 50 per cent slower.'" Not everyone characterizes the impact of STIBP as seriously. Tim Chen, an engineer at Intel's Open Source Technology Center, said that running perlbench with STIBP using the SpecInt Rate 2006 test suite shows a 21 per cent reduction in throughput. Your mileage may vary – real-world slowdown metrics depend on the workload and hardware involved. Torvalds doesn't see the need to undo the patch that enabled STIBP, but agrees with others that the default behavior should not be to enable it unconditionally in all cases because STIBP "was clearly way more expensive than people were told." So a patch in progress will allow admins to turn on STIBP if needed, but not by default. Students of the Linux leader's ways may yet recall that in January, Torvalds – before he repudiated tantrums – was apoplectic about the quality of Intel's initial Spectre and Meltdown patches. Arjan van de Ven, an Intel Fellow and Linux kernel dev, added his voice to the mix of people opposed to enabling STIBP by default. "In the documentation, AMD officially recommends against this by default, and I can speak for Intel that our position is that as well: this really must not be on by default," he said. "...Using these tools much more surgically is fine, if a paranoid task wants it for example, or when you know you are doing a hard core security transition. But always on? Yikes." PS: A reminder that OpenBSD recommends disabling Intel Hyper-Threading for security reasons. Source
  10. Torvalds has published the first Release Candidate for Linux 4.19, two weeks after the Linux 4.18 kernel series was launched. Linux 4.19 has been an interesting cycle and was fairly eventful but some problematic pull requests led Linus Torvalds to calling it a horrible merge window From our original reporting over the past two weeks, highlights of the Linux 4.19 kernel include: Display / Graphics: - The VKMS DRM driver was merged for virtual kernel mode-setting and may be of use moving forward to some headless systems. - The USB Type-C display mode alternate driver was merged to the mainline kernel for stepping up the DP Type-C support, but more work on integrating with the DRM drivers is still being tackled. - Initial support for the Qualcomm Adreno 600 series hardware. - Continued work on bringing up the Intel Icelake "Gen 11" graphics. - Raven Ridge "stutter mode" support, JPEG VCN engine support, GFXOFF, and AMDKFD compute driver support for these latest AMD Zen+GFX9 APUs. - Armada atomic mode-setting. - Deferred console takeover support for FBDEV. - Various other DRM improvements. Processors: - AMD Threadripper 2 temperature monitoring is now correct and this should also be back-ported to stable kernel series. - The lazy TLB mode is lazier for some small possible performance enhancements. - A kernel build-time option to indicate if you trust the CPU's hardware random number generator but by default will assume your CPU HWRNG is not trustworthy. - Various crypto updates. - The RISC-V code is beginning to work with user-space bits though this open-source processor ISA still has a long road ahead. - Some minor work on OpenRISC. - Many x86 KVM improvements. - More Spectre mitigation work for IBM POWER processors as well as continued x86 Spectre updates and even some for IBM s390 too. - "A bunch of good stuff" for 64-bit ARM. - Improved NUMA emulation. - Intel Icelake LPSS support. Storage / File-Systems: - The EROFS file-system is added to the staging tree. This is a read-only file-system developed by Huawei for possible use in future Android mobile devices. EROFS is still missing an open-source user-space. - Faster SMB3/CIFS performance. - Low-level Btrfs improvements. - Other routine file-system changes. - F2FS discard is finally enabled by default. - OverlayFS support for stack file operations and metadata-only copy-up. Other Hardware: - Initial support for 802.11ax wireless as well as initial Intel 802.11ax support in IWLWIFI. - Creative Recon3D sound cards are finally supported along with other new sound hardware support. - Support for the Nintendo Wii guitar and drum attachments to the Wiimote. - ThinkPad calculator key support and more tablet touchscreens being supported. - A Raspberry Pi voltage driver in mainline for supporting under-voltage situations and more. Other Big Additions - An in-kernel GPS subsystem was added to the kernel... Yes, only in 2018 is there a formal GPS/GNSS subsystem in the mainline kernel. - ChromeOS EC CEC driver addition for HDMI CEC support with some Chromebooks. USB charging support was also added to the ChromeOS EC driver. - Google's Gasket Driver Framework was merged - the Google ASIC Software, Kernel Extensions, and Tools. GASKET allows developing thin kernel drivers while shifting the rest of the driver logic to user-space code. GASKET is initially being used for the Google Apex chip. - An idle injection framework and the never-ending work on Linux power management. - The STACKLEAK GCC plug-in was merged for preventing some possible stack attacks on the kernel. This is based upon earlier work by PaX/GrSecurity. - Continued Y2038 preparations and other work. - Linux 4.19 now requires GCC 4.6 or newer for building with support from GCC 4.5 through GCC 3.2 finally being dropped. Onwards now to begin benchmarking the Linux 4.19 kernel. Source: [Phoronix]
  11. A security vulnerability in a driver leading to local privilege escalation in the latest Linux Kernel version was introduced 8 years ago, Check Point reveals. The security flaw provides a local user with access to a vulnerable privileged driver with the possibility to read from and write to sensitive kernel memory. Tracked as CVE 2018-8781, the vulnerability could be exploited to escalate local privileges, Check Point's researchers say. The bug impacts the internal mmap() function defined in the fb_helper file operations of the “udl” driver of “DisplayLink” and was discovered using a simple search. Because drivers commonly implement their own version of file operation functions, they are prone to implementation errors, and the discovery of this vulnerability is proof of that. In fact, there are various common vulnerabilities impacting drivers where the mmap() handler is used, such as lack of input validations and Integer-Overflows. A classic driver, the researchers explain, holds an internal buffer representing the shared memory region with the peripheral device, and should only let the user access memory ranges inside this buffer. The prototype of the mmap() function includes numerous fields that an attacker can control and developers should perform a series of checks and to avoid possible Integer-Overflows to eliminate issues. According to Check Point, there are three checks that should be performed: Region start: 0 <= offset < buffer’s end; Region end: buffer’s start <= offset + length <= buffer’s end; and Region start <= Region End. “In actual fact, the last check can be spared since the Linux kernel will sanitize the supplied length, making it practically impossible to pass the first two checks while still passing the third check,” Check Point says. The researchers discovered the security flaw while taking a closer look at remap_pfn_range(), a function of high importance, because it maps physical memory pages to the user. “The video/drm module in the kernel defines a default mmap() wrapper that calls that real mmap() handler defined by the specific driver,” the security researchers note. The bug is a classic example for an Integer-Overflow: there’s an unsigned offset, thus the first check is skipped, and the calculation “offset + size,” however, can bypass the second check while still using an illegal “offset” value. As there are only 48 bits of accessible memory on 64-bit machines, the use of a huge “offset” to bypass the check requires making sure that “info->fix.smem_start + offset” will wrap-around to a valid mappable physical address, Check Point also notes. The vulnerability was verified on an Ubuntu 64-bit virtual machine where a simulated vulnerable driver was uploaded. The driver’s mmap() handler included the implementation to check in each test. Two consecutive calls to mmap() on the vulnerable driver were made by user-mode code, namely a sanity check and a vulnerability check. Setting the buffer’s address at the page-aligned physical address of the kernel’s /dev/urandom implementation results in the output providing the correct physical page and the previous physical page, respectively. Additional checks revealed that it is possible for the user to read and write from/to the mapped pages. Thus, an attacker could eventually trigger code execution in kernel space, the researchers explain. “While the vulnerability was found using a simple search, it was introduced to the kernel eight years ago. This fact can teach us that even on a popular open source project as the Linux Kernel, you could always hope to find vulnerabilities if you know where to search,” Check Point concludes. The vulnerability was disclosed to the Linux Kernel on March 18 and a patch was issued the same day. After the patch was verified, the official Linux patch was issued for CVE 2018-8781 on March 21 and was integrated to the Linux Kernel the same day. Source
  12. Linux 4.14 to Be the Next LTS Kernel Series, Supported for at Least 2 Years Development could start in mid-September 2017 Development of the Linux 4.14 kernel series did not even start, as the version that's being developed these days is Linux 4.12, which should be promoted to stable early next month. Two weeks after the release of Linux kernel 4.12, development of the Linux 4.13 kernel branch will begin. As the first Release Candidate (RC) milestone of Linux kernel 4.13 could hit the streets in mid-July or a week later on the 23rd, we're looking at a final release of the series in early September, so only two weeks after that, the development of the Linux 4.14 kernel will commence, around mid-September. Linux kernel 4.14 to be supported for two years If everything goes well, and Linux 4.14's development starts in mid-September (based on a development cycle of seven RCs for Linux kernels 4.12 and 4.13), we're looking at a final release of the long-term supported kernel branch in early November, but it can take longer if the previous kernels have eight RCs each one. Greg Kroah-Hartman promises to support the Linux 4.14 kernel series for at least two years after its release in November 2017, until November 2019, according to the Google+ post: "As no one seemed to make 4.9 blow up too badly, let's try this again! 4.14 == next LTS kernel I support for at least 2 years. Any objections?" According to kernel.org, the currently maintained LTS (Long Term Support) kernel branches are Linux 4.9 (most advanced one), Linux 4.4, Linux 4.1, Linux 3.16, Linux 3.10, Linux 3.4, and Linux 3.2. So in about three months from now, Linux 4.14 will be the most advanced LTS kernel branch that you can install on your Linux OS. Source
  13. Canonical Launches Its Linux Kernel Livepatch Service for Ubuntu 14.04 LTS Users You won't have to reboot your PC when installing new kernels Until today, Canonical's Kernel Livepatch service was available only for those running the Ubuntu 16.04 LTS (Xenial Xerus) operating system series, providing them with rebootless kernel upgrades. Starting today, you can use the Canonical Kernel Livepatch service on Ubuntu 14.04 LTS too. As usual, Canonical lets users to install its Kernel Livepatch service on up to three (3) computers for free, but only on systems running 64-bit Intel or AMD processors. Those who want to enable Canonical Kernel Livepatch on more than 3 machines will have to purchase the Ubuntu Advantage support package. "We are pleased to announce that we have extended our Canonical Kernel Livepatch Service to users running Ubuntu 14.04 LTS," reads the announcement. "The Canonical Kernel Livepatch Service enables runtime correction of critical security vulnerabilities in the kernel without the need to reboot." Here's how to enable Canonical Kernel Livepatch on Ubuntu 14.04 LTS Installing the Canonical Kernel Livepatch service on Ubuntu 14.04 LTS (Trusty Tahr) operating systems is possible because the Snapd 2.20 release announced in December 2016 brought support for this long-term supported version of Ubuntu Linux. And it's super easy to install both Snapd and Canonical Kernel Livepatch. First, you'll have to make sure that you're running the Linux 4.4 kernel. Then, open the Terminal app and paste the command listed below to install the Snapd daemon, which enables installation of Snap packages on Ubuntu 14.04 LTS. Access https://ubuntu.com/livepatch and get your free kernel livepatch token. sudo apt update && sudo apt install snapd The token should look like this [d3b07384d213edec49eaa6238ad5ff00] so make sure you keep it safe somewhere. To install and enable the Canonical Kernel Livepatch service, run the following commands in the Terminal app, but replace the token in the second command with your own. sudo snap install canonical-livepatch sudo canonical-livepatch enable d3b07384d113edec49eaa6238ad5ff00 That’s it. You can check to see if you're running the Canonical Kernel Livepatch service on your Ubuntu 14.04 LTS machine at any time with the following command. If it says "true" under the fully-patched entry, then it means you're running the latest available kernel for your system. canonical-livepatch status Source
  14. Linux kernel 4.12 RC3 released Even if it's Memorial weekend, Linus Torvalds is on the job announcing the release and immediate availability of the third RC (Release Candidate) milestone of the upcoming Linux 4.12 kernel series. According to Linus Torvalds, the development of Linux kernel 4.12 continues to look good, and today's third Release Candidate build is a fairly normal patch consisting of two thirds updated GPU, SCSI, NVME, TTY, and Block drivers, and the rest is split between networking stack changes, core kernel, header files, XFS, and arch improvements. The biggest change, however, is a documention update as the Intel pstate docs were converted to the RST format. "Hey, things continue to look good, and RC3 isn't even very big. I'm hoping there's not another shoe about to drop, but so far this really feels like a nice calm release cycle, despite the size of the merge window. Knock wood," said Linus Torvalds in the mailing list announcement. Anyway, RC3 has a little bit of everything. The biggest single change is actually just a documentation update." Linux kernel 4.12 to hit the streets early July 2017 The development cycle of the Linux 4.12 kernel series is still in early stages and we should expect to see at least four such Release Candidate (RC) versions released in the coming weeks, which can only mean that Linux kernel 4.12 will hit the streets in early July 2017, be it either the 2nd or the 9th, depending on if there will be seven or eight RCs released. Until then, you can help with the testing by downloading the Linux kernel 4.12 Release Candidate 3 source tarball right now from kernel.org or via our website, compile and install it on your favorite GNU/Linux distribution, and report bugs on the issue tracker. Please try to keep in mind not to replace your stable kernel with this development version, nor deploy it on a production environment. Source
  15. CentOS maintainer Johnny Hughes informs the community of the Red Hat Enterprise Linux-based and security-oriented operating system about the availability of an important kernel update. As CentOS is based on the freely distributed sources of the Red Hat Enterprise Linux operating system, it also inherits its security updates, and the latest one patches five vulnerabilities discovered recently in the kernel packages of Red Hat Enterprise Linux 7, affecting CentOS 7 users too. According to the upstream security advisory, which was marked by Red Hat as important, the updated kernel packages were patched against a buffer overflow (CVE-2017-7308) discovered in Linux kernel's packet_set_ring() function, which could allow a local attacker with CAP_NET_RAW access to crash of the system. Another vulnerability (CVE-2016-8646) was discovered in Linux kernel's shash_async_export() function, which lets unprivileged local users attempt forcing the in-kernel hashing algorithms into decrypting an empty data set. Additionally, it was found the mounting a crafted EXT4 partition as read-only could lead to SLAB-Out-of-Bounds reads and memory corruption (CVE-2016-10208). Users are urged to update to kernel-3.10.0-514.21.1.el7 The fourth security issue (CVE-2017-5986) patched in this update is about malicious applications that could trigger a BUG_ON in Linux kernel's sctp_wait_for_sndbuf function if the socket tx buffer is full. More details on this flaw can be found on the respective CVE report and Red Hat's security advisory. Finally, the fifth security flaw (CVE-2016-7910) was discovered in Linux kernel's implementation of seq_file, which could allow a local attacker to manipulate memory in the put() function pointer, thus leading to memory corruption or allowing the attacker to escalate his/her privileges on the vulnerable system. CentOS 7 users are urged to update their installations to kernel-3.10.0-514.21.1.el7 as soon as possible. To perform a full system update, type the "su -c 'yum update'" command in your favorite terminal emulator or virtual console. After a kernel update, make sure that you reboot your computer for the new version to take effect. Source
  16. Linux kernel 4.11.2 released Greg Kroah-Hartman was proud to announce the release of the second maintenance update to the Linux 4.11 kernel series, Linux 4.11.2, which is now considered the latest stable kernel that's available for GNU/Linux distributions. Linux kernel 4.11.2 is here only one week after the first point release in the new stable series, and it's a major update changing a total of 131 files, with 1402 insertions and 766 deletions, according to the appended shortlog. Greg Kroah-Hartman also released new maintenance updates for the Linux 4.10, 4.9, 4.4, and 3.18 kernel series, for which we have a separate article on the website. "I'm announcing the release of the 4.11.2 kernel. All users of the 4.11 kernel series must upgrade. The updated 4.11.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.11.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary," said Greg Kroah-Hartman. F2FS, CIFS, EXT4, and x86 improvements, updated drivers Linux kernel 4.11.2 adds various improvements to Samsung's F2FS file system, along with some small bug fixes to CIFS, EXT4, Ceph, crypto, JBD2, OrangeFS, OverlayFS, pstore, xattr, IOMap, and DAX. It also adds a bunch of enhancements to the x86, ARM64 (AArch64), ARM, and PowerPC (PPC) hardware architectures, and ships with the usual core kernel, tools and mm changes, as well as an updated networking stack with better Bluetooth support. Lots of drivers have been updated in the Linux 4.11.2 kernel, including those for InfiniBand (Marvell MLX4, Intel HFI1, IPoIB), crypto, Bluetooth (Broadcom and Intel), ATA, DAX, MD, Non-Volatile Dual In-line Memory Module (NVDIMM), staging (gdm724x, vt6656, wilc1000), iSCSI, TTY (amba-pl011, omap-serial, Samsung), VFIO, and USB devices. If you're using a GNU/Linux distribution powered by a kernel from the Linux 4.11 series, you need to update to Linux kernel 4.11.2 right now. The Linux kernel 4.11.2 source archive is available for download from kernel.org. Source
  17. Linux kernel 4.12 RC1 released Linus Torvalds kicked off the development of the Linux 4.12 kernel series by announcing the availability of the first Release Candidate (RC) a day early than expected due to the Mother's Day celebration and last-minute pull requests. According to Linus Torvalds, Linux kernel 4.12 RC1 is a pretty large patch that contains numerous additions, including support for AMD's next-generation Radeon RX Vega GPUs, along with a new driver for Intel Atom IPUs (Image Processing Units). The rest of the changes consist of miscellaneous updates to various support hardware architectures, filesystems, networking drivers, headers, documentation, and core files. As usual, you can always study the appended shortlog if you're curious to know what devices or drivers have been updated. "Despite it being fairly large, it has (so far) been pretty smooth. I don't think I personally saw any breakage at all, which is always nice. Usually I end up having something break, or trigger some silly build failure that really should have been noticed before it even got to me, but so far things are looking good," said Torvalds. Linux kernel 4.12 should hit the streets in early July 2017 We're aware of the fact that development of the Linux 4.12 kernel series just started with this first Release Candidate (RC) build, but we can also estimate its arrival date, which should be in early July, either the 2nd or the 9th, depending on if there will be seven or eight such RC versions released during its entire cycle. There's a lot of time until then, and if you want to get an early taste of the Linux 4.12 kernel series, download the RC1 tarball right now from kernel.org or via our website if you want to compile it for your architecture in an attempt to report any bugs you might encounter. Please don't use this kernel in a stable, production environment. Source
  18. Updating Ubuntu 16.10 Canonical announced the availability of an updated kernel patch for all supported Ubuntu Linux releases, addressing a security vulnerability discovered recently in the upstream Linux kernel. The security issue affects the Ubuntu 14.04 LTS (Trusty Tahr) and Ubuntu 16.10 (Yakkety Yak) operating systems, as well as all of their derivatives, including Xubuntu, Lubuntu, Kubuntu, Ubuntu MATE, Ubuntu GNOME, Ubuntu Studio, Ubuntu Kylin, Ubuntu Budgie, and Ubuntu Server. The issue appears to have been discovered by Alexander Popov in Linux kernel's SCTP (Stream Control Transmission Protocol) implementation as a race condition that could allow a local attacker to crash the system by causing a denial of service (DoS). "Alexander Popov discovered that a race condition existed in the Stream Control Transmission Protocol (SCTP) implementation in the Linux kernel. A local attacker could use this to cause a denial of service (system crash)," reads the respective Ubuntu security advisory. Trusty, Xenial, and Yakkety HWE kernels also available As expected, Canonical also release updated HWE (Hardware Enablement) kernels for the Ubuntu 12.04.5 LTS, Ubuntu 14.04.5 LTS, and Ubuntu 16.04.2 LTS releases, urging all users of these Ubuntu Linux variants to update their installations as soon as possible. The new kernel versions are linux-image 3.13.0.117.127 for Ubuntu 14.04 LTS, linux-image 4.8.0.49.61 for Ubuntu 16.10, linux-image-lts-trusty 3.13.0.117.108 for Ubuntu 12.04.5 LTS, linux-image-lts-xenial 4.4.0.75.62 for Ubuntu 14.04.5 LTS, and linux-image-hwe-16.04 4.8.0.49.21 for Ubuntu 16.04.2 LTS. To update your Ubuntu OS, you'll need to run the "sudo apt-get update && sudo apt-get dist-upgrade" command in the Terminal app, or fire up the Software Updater utility and install all available updates. Make sure you reboot your computer after installing the new kernel version. More details are provided by Canonical at https://wiki.ubuntu.com/Security/Upgrades. Source
  19. Threat researchers from Cisco have shared details on a new and rapidly spreading attack targeting web servers running on systems powered by outdated versions of Linux. According to Cisco, upward of 400 different hosts were affected each day on March 17 and 18, with attackers successfully compromising more than 2,700 URLs at the time of publishing. The attackers are compromising legitimate websites, Cisco said, with most of the affected web servers running on the Linux 2.6 kernel—an outdated version that was first released in 2003. The location of compromised servers have been found throughout the world, but have a particularly high concentration in Germany and the United States. “It is possible that attackers have identified a vulnerability on the platform and been able to take advantage of the fact that these are older systems that may not be continuously patched by administrators,” Cisco’s Martin Lee wrote in a blog post late Thursday. In order to execute the attack, cybercriminals compromise an existing website, insert a line of JavaScript to multiple .js files hosted on the site, causing visitors to load and execute a new JavaScript file served from compromised third-party host. “We observed the second stage sites serving what appears to be pay per view fraud pages, where the visitor’s browser loads multiple advertisements to generate revenue for the attacker,” Lee said. “However, there is anecdotal evidence that visitors have been infected with Trojan malware as part of this final step.” Many of the affected hosts have been identified as compromised and cleaned, Cisco said. Lee explained that some security products may detect the JavaScript redirect as being similar to that previously used in the Blackhole exploit kit, but Cisco has no evidence suggesting that the attacks are related to Blackhole rather than an example of code reuse. “This large scale compromise of an aging operating system, highlights the risks posed by leaving such systems in operation,” Lee said. "Systems that are unmaintained or unsupported are no longer patched with security updates," he continued. "When attackers discover a vulnerability in the system, they can exploit it at their whim without fear of it being remedied. In April 2014, Windows XP will become unsupported. Organizations urgently need to review their use of unsupported systems in operation. Such systems need to be upgraded where possible, or regularly monitored to detect compromise. Just yesterday, researchers from Imperva issued a threat advisory about an old PHP vulnerability that was patched in 2012 but actively being exploited in attacks. While this particular PHP flaw was discovered in March 2012 and patched in May, a public exploit began making the rounds in October 2013, Imperva said in its advisory. Imperva's honeypots detected more than 30,000 campaigns using some form of the exploit within three weeks of its publication. The fact that the exploit became publicly available more than a year later suggests criminals were still enjoying some degree of success targeting this vulnerability, Barry Shteiman, director of security strategy at Imperva, told SecurityWeek. “Large numbers of vulnerable unpatched systems on the Internet are tempting targets for attackers,” Cisco’s Lee said. “Such systems can be used as disposable one-shot platforms for launching attacks. This makes it all the more important that aging systems are properly maintained and protected.” Cisco has provided a list of compromised URLs here and here, which can be used for blacklisting and URL filtering in order to prevent users from visiting those pages. Earlier this week, ESET warned of a widespread attack campaign that has infected more than 25,000 Linux and UNIX servers around the world. According to ESET, the servers are being hijacked by a backdoor Trojan as part of a campaign the researchers are calling 'Operation Windigo.' Once infected, victimized systems are leveraged to steal credentials, redirected web traffic to malicious sites and send as much as 35 million spam messages a day. Source
×
×
  • Create New...