Posted by Ard Biesheuvel, Google Open Source Security Team 

Linux kernel support for the 32-bit ARM architecture was contributed in the late 90s, when there was little corporate involvement in Linux development, and most contributors were students or hobbyists, tinkering with development boards, often without much in the way of documentation.

Now 20+ years later, 32-bit ARM’s maintainer has downgraded its support level to ‘odd fixes,’ while remaining active as a kernel contributor. This is a common pattern for aging and obsolete architectures: corporate funding for Linux kernel development has tremendously increased the pace of development, but only for architectures with a high return on investment. As a result, the 32-bit ARM port of Linux is essentially in maintenance-only mode, and lacks core Linux advancements such as THREAD_INFO_IN_TASK or VMAP_STACK, which protect against stack overflow attacks.

The lack of developer attention does not imply that the 32-bit ARM port has ceased to make economic sense, though. Instead, it has evolved from being one of the spearheads of Linux innovation to a stable and mature platform, and while funding its upstream development may not make sense in the long term, deploying 32-bit ARM into the field today most certainly still makes economic sense when margins are razor thin and BOM costs need to be kept to an absolute minimum. This is why 32-bit ARM is still widely used in embedded systems like set-top boxes and wireless routers.

Running 32-bit Linux on 64-bit ARM systems

Ironically, at these low price points, the DRAM is actually the dominant component in terms of BOM cost, and many of these 32-bit ARM systems incorporate a cheap ARMv8 SoC that happens to be capable of running in 64-bit mode as well. The reason for running 32-bit applications nonetheless is that these generally use less of the expensive DRAM, and can be deployed directly without the need to recompile the binaries. As 32-bit applications don’t need a 64-bit kernel (which itself uses more memory due to its internal use of 64-bit pointers), the product ships with a 32-bit kernel instead.

If you’re choosing to use a 32-bit kernel for its smaller memory footprint, it’s not without risks. You’ll likely experience performance issues, unpatched vulnerabilities, and unexpected misbehaviors such as:

• 32-bit kernels generally cannot manage more than 1 GiB of physical memory without resorting to HIGHMEM bouncing, and cannot provide a full virtual address space of 4 GiB to user space, as 64-bit kernels can.
• Side channels or other flaws caused by silicon errata may exist that haven’t been mitigated in 32-bit kernels. For example, the hardening against Spectre and Meltdown vulnerabilities were only done for ARMv7 32-bit only CPUs, and many ARMv8 cores running in 32-bit mode may still be vulnerable (only Cortex-A73 and A75 are handled specifically). And in general, silicon flaws in 64-bit parts that affect the 32-bit kernel are less likely to be found or documented, simply because the silicon validation teams don’t prioritize them.
• The 32-bit ARM kernel does not implement the elaborate alternatives patching framework that is used by other architectures to implement handling of silicon errata, which are particular to certain revisions of certain CPUs. Instead, on 32-bit multiplatform kernels, we simply enable all errata workarounds that may be needed by any of the cores that may ever run the image in question, potentially affecting performance unnecessarily on cores that have no need for them.
• Silicon vendors are phasing out 32-bit support in the longer term. Given an ecosystem containing a handful of operating systems and thousands of applications, support for 32-bit operating systems (which is more complex technically) is highly likely to be dropped first. For products with longer life cycles, long-term procurement contracts for components available today are usually much more costly than adjusting the BOM over time and using newer, cheaper parts.
• The 32-bit kernel does not implement kernel address space randomization, and even if it did, its comparatively tiny address space simply leaves very little space for randomization. Other hardening features, such as rodata=full or hierarchical eXecute Never attributes, are missing as well on 32-bit, and are not likely to be implemented, either due to lack of support in the architecture, or because of the complexity of the 32-bit memory management code, which still supports all of the different architecture revisions dating back to the initial Linux port running on the Risc PC.

Keeping the 32-bit ARM kernel secure

There are cases, though, where using the 32-bit kernel is the only option, e.g., if the CPUs are in fact 32-bit only (which is the case even for some ARMv8 cores such as Cortex-A32), or when relying on an existing 32-bit only codebase running in the kernel (drivers for legacy peripherals). Note that in such cases, it still makes sense to use the most recent kernel version compatible with the hardware, since we are in fact making an effort to enable some of the existing hardening features on 32-bit ARM as well.

• THREAD_INFO_IN_TASK for v7 SMP cores

The v5.16 release of the Linux kernel implements support for THREAD_INFO_IN_TASK when running on ARMv7 SMP systems. This protects the kernel’s per-task bookkeeping (called thread_info), which lives on the far (and normally unused) end of the stack, against stack overflows which may occur in rare -yet sometimes exploitable- cases where the control flow of the program simply ends up accumulating more state than the stack can hold. (Note that a stack overflow is not the same as a stack buffer overflow, where the overflow happens in the opposite direction.)

By moving thread_info off the stack and into the kernel heap, and by using a special SMP CPU register to keep track of its location, we can mitigate the risk of stack overflows resulting in thread_info corruption. However, it does not prevent stack overflows themselves: these may still occur, and result in corruption of other data structures that happen to be adjacent to the task stack in memory.

• THREAD_INFO_IN_TASK for other cores

For CPUs that lack this special SMP CPU register, we also proposed an implementation of THREAD_INFO_IN_TASK that is expected to land in v5.18. Instead of a special register, it uses a global variable to keep track of the location of thread_info.

• VMAP_STACK support

Preventing stack overflows from corrupting unrelated memory contents is the goal of VMAP_STACK, which we are enabling for 32-bit ARM as well. When VMAP_STACK is enabled, kernel mode stacks are allocated from the kernel heap as before, but mapped into a different part of the kernel’s address space, and surrounded by guard regions, which are guaranteed to be kept unpopulated. Given that accesses to such unpopulated regions will trigger an exception, the kernel’s memory management layer can step in and terminate the program as soon as a stack overflow occurs, and prevent it from causing memory corruption.

Support for IRQ stacks

Coming up with a bounded worst case on which to base the size of the kernel stack is rather hard, especially given the fact that it is shared between the program itself and any exception handling routines that may be called on its behalf, including interrupt handlers. To mitigate the risk of a pathological worst case occurring, where an interrupt fires that needs a lot of stack space right at a time when most of the stack is already being used by the program, we are also enabling IRQ_STACKS for 32-bit ARM, which will run handlers of both hard and soft interrupts from a dedicated stack, one for each CPU. By decoupling the task and interrupt contexts like this, the likelihood that a well-behaved program needs to be terminated due to stack overflow should be all but eliminated.

Conclusion

With these changes in place, kernel stack overflow protection will be available for all ARM systems supported by Linux, including ancient ones like the Risc PC or Netwinder, provided that it runs a Linux distribution that is keeping up with the times.

However, relying on legacy hardware and software comes with a risk, and even though we try to help keep users of the 32-bit kernel as safe as we reasonably can, it is not the right choice for new designs that incorporate 64-bit capable hardware.

It’s never too late to prevent children from being dragged to the dark side and to ensure their skills are a force for good

The post Teenage cybercrime: How to stop kids from taking the wrong path appeared first on WeLiveSecurity

What does progress in technology mean? – IRS makes a U-turn on facial recognition but questions remain – What retailers need to know about cyberthreats

The post Week in security with Tony Anscombe appeared first on WeLiveSecurity

Progress is a driving force of humanity, but what does that word “progress” really mean and what part do we have to play?

The post Folding the impossible into the reality of normal life appeared first on WeLiveSecurity

Posted by Eduardo Vela, Vulnerability Matchmaker 

Until December 31 2022 we will pay 20,000 to 91,337 USD for exploits of vulnerabilities in the Linux Kernel, Kubernetes, GKE or kCTF that are exploitable on our test lab.

We launched an expansion of kCTF VRP on November 1, 2021 in which we paid 31,337 to 50,337 USD to those that are able to compromise our kCTF cluster and obtain a flag. We increased our rewards because we recognized that in order to attract the attention of the community we needed to match our rewards to their expectations. We consider the expansion to have been a success, and because of that we would like to extend it even further to at least until the end of the year (2022).

During the last three months, we received 9 submissions and paid over 175,000 USD so far. The submissions included five 0days and two 1days. Three of these are already fixed and are public: CVE-2021-4154, CVE-2021-22600 (patch) and CVE-2022-0185 (writeup). These three bugs were first found by Syzkaller, and two of them had already been fixed on the mainline and stable versions of the Linux Kernel at the time they were reported to us.

Based on our experience these last 3 months, we made a few improvements to the submission process:

• Reporting a 0day will not require including a flag at first. We heard some concerns from participants that exploiting a 0day in the shared cluster could leak it to other participants. As such, we will only ask for the exploit checksum (but you still have to exploit the bug and submit the flag within a week after the patch is merged on mainline). Please make sure that your exploit works on COS with minimal modifications (test it on your own kCTF cluster), as some common exploit primitives (like eBPF and userfaultfd) might not be available.
• Reporting a 1day will require including a link to the patch. We will automatically publish the patches of all submissions if the flag is valid. We also encourage you all to include a link to a Syzkaller dashboard report if applicable in order to help reduce duplicate submissions and so you can see which bugs were exploited already.
• You will be able to submit the exploit in the same form you submit the flag. If you had submitted an exploit checksum for a 0day, please make sure that you include the original exploit as well as the final exploit and make sure to submit it within a week after the patch is merged on mainline. The original exploit shouldn’t require major modifications to work. Note that we need to be able to understand your exploit, so please add comments to explain what it is doing.
• We are now running two clusters, one on the REGULAR release channel and another one on the RAPID release channel. This should provide more flexibility whenever a vulnerability is only exploitable on modern versions of the Linux Kernel or Kubernetes.

We are also changing the reward structure slightly. Going forward the rewards will be:

• 31,337 USD to the first valid exploit submission for a given vulnerability. This will only be paid once per vulnerability and only once per cluster version/build (available at /etc/node-os-release).
• 0 USD for exploits for duplicate exploits for the same vulnerability. The bonuses below might still apply.

Bonuses

• 20,000 USD for exploits for 0day vulnerabilities. This will only be paid once per vulnerability to the first valid exploit submission.
• To submit 0days, please test your exploit (we recommend to test it on your own kCTF cluster to avoid leaking it to other participants), make a checksum and send the checksum to us. Within a week after the vulnerability is fixed on the mainline, submit the form as a 1day and include the exploit of which you sent a checksum to us.
• 20,000 USD for exploits for vulnerabilities that do not require unprivileged user namespaces (CLONE_NEWUSER). This will only be paid once per vulnerability to the first valid exploit submission.
• Our test lab allows unprivileged user namespaces, so we will manually check the exploits to check if they work without unprivileged user namespaces when deciding whether to issue the bonus. We decided to issue additional rewards for exploits that do not require unprivileged user namespaces because containers default seccomp policy does not allow the use of unprivileged user namespaces on containers that are run without CAP_SYS_ADMIN. This feature is now available on Kubernetes and all nodes running on GKE Autopilot have it enabled by default.
• 20,000 USD for exploits using novel exploit techniques. This is a bonus in addition to the base rewards (applies for duplicate exploits). To qualify for this additional reward please send us a write-up explaining it.
• An example of something considered as a novel technique could be the exploitation of previously unknown objects to transform a limited primitive into a more powerful one, such as an arbitrary/out-of-bounds read/write or arbitrary free. For example, in all our submissions, researchers leveraged message queues to achieve kernel information leaks. We are looking for similarly powerful techniques that allow heap exploits to be “plugged in” and immediately allow kernel access. Another example is bypassing a common security mitigation or a technique for exploiting a class of vulnerabilities more reliably.

These changes increase some 1day exploits to 71,337 USD (up from 31,337 USD), and makes it so that the maximum reward for a single exploit is 91,337 USD (up from 50,337 USD). We also are going to pay even for duplicates at least 20,000 USD if they demonstrate novel exploit techniques (up from 0 USD). However, we will also limit the number of rewards for 1days to only one per version/build. There are 12-18 GKE releases per year on each channel, and we have two clusters on different channels, so we will pay the 31,337 USD base rewards up to 36 times (no limit for the bonuses). While we don’t expect every upgrade to have a valid 1day submission, we would love to learn otherwise. You can find the flag submission status for our clusters (and their versions) here.

We look forward to hearing from you, and continue to strengthen our shared ecosystem. If you are interested to participate but don’t know where to start, Arizona State University has a free public Kernel Exploitation workshop at https://dojo.pwn.college/challenges/kernel as part of an overall memory corruption course and you can find a community-maintained list of past Linux Kernel vulnerabilities, exploits and writeups curated by Andrey Konovalov at https://github.com/xairy/linux-kernel-exploitation.

This is part of our Vulnerability Reward Program, which we’ve been running for over 10 years, and the rules include some more information. Same as with our other rewards, we will double them if they are donated to charity, and submitters will be included on our site at bughunters.google.com. If you are ready to submit something, please read the instructions on our site here and if you have any other questions please contact us on Discord.