With over 16 million pulls per month, Google’s `distroless` base images are widely used and depended on by large projects like Kubernetes and Istio. These minimal images don’t include common tools like shells or package managers, making their attack surface (and download size!) smaller than traditional base images such as `ubuntu` or `alpine`. Even with this additional protection, users could still fall prey to typosquatting attacks, or receive a malicious image if the distroless build process was compromised – making users vulnerable to accidentally using a malicious image instead of the actual distroless image. This problem isn’t unique to distroless images – until now, there just hasn’t been an easy way to verify that images are what they claim to be.

Introducing Cosign

Cosign simplifies signing and verifying container images, aiming to make signatures invisible infrastructure – basically, it takes over the hard part of signing and verifying software for you.

We developed cosign in collaboration with the sigstore project, a Linux Foundation project and a non-profit service that seeks to improve the open source software supply chain by easing the adoption of cryptographic software signing, backed by transparency log technologies.

We’re excited to announce that all of our distroless images are now signed by cosign! This means that all users of distroless can verify that they are indeed using the base image they intended to before kicking off image builds, making distroless images even more trustworthy. In fact, Kubernetes has already begun performing this check in their builds.

As we look to the future, Kubernetes SIG Release’s vision is to establish a consumable, introspectable, and secure supply chain for the project. By collaborating with the sigstore maintainers (who are fellow Kubernetes contributors) to integrate signing and transparency into our supply chain, we hope to be an exemplar for standards in the cloud native (and wider) tech industry, said Stephen Augustus, co-chair for Kubernetes SIG Release.

How it works

To start signing distroless we integrated cosign into the distroless CI system, which builds and pushes images via Cloud Build. Signing every distroless image was as easy as adding an additional Cloud Build step to the Cloud Build job responsible for building and pushing the images. This additional step uses the cosign container image and a key pair stored in GCP KMS to sign every distroless image. With this additional signing step, users can now verify that the distroless image they’re running was built in the correct CI environment.

Right now, cosign can be run as an image or as a CLI tool. It supports:

  • Hardware and KMS signing
  • Bring-your-own PKI
  • Our free OIDC PKI (Fulcio)
  • Built-in binary transparency and timestamping service (Rekor)

Signing distroless with cosign is just the beginning, and we plan to incorporate other sigstore technologies into distroless to continue to improve it over the next few months. We also can’t wait to integrate sigstore with other critical projects. Stay tuned here for updates! To get started verifying your own distrolesss images, check out the distroless README and to learn more about sigstore, check out sigstore.dev.

How witches, wizards and superheroes can help your kids stay safe from cyber-villains, plus other parenting hacks to encourage your children to use secure passwords

The post Fantastic passwords and where your children can find them appeared first on WeLiveSecurity

The attack overwhelmed the systems of a Belgian ISP, leading to widespread service outages and disruptions

The post DDoS attack knocks Belgian government websites offline appeared first on WeLiveSecurity

Another in our occasional series demystifying Latin American banking trojans

The post Ousaban: Private photo collection hidden in a CABinet appeared first on WeLiveSecurity

Chrome 90 for Windows adopts Hardware-enforced Stack Protection, a mitigation technology to make the exploitation of security bugs more difficult for attackers. This is supported by Windows 20H1 (December Update) or later, running on processors with Control-flow Enforcement Technology (CET) such as Intel 11th Gen or AMD Zen 3 CPUs. With this mitigation the processor maintains a new, protected, stack of valid return addresses (a shadow stack). This improves security by making exploits more difficult to write. However, it may affect stability if software that loads itself into Chrome is not compatible with the mitigation. Below we describe some exploitation techniques that are mitigated by stack protection, discuss its limitations and what we will do next to approach them. Finally, we provide some quick tips for other software authors as they enable /cetcompat for their Windows applications.

Stack Protection

Imagine a simple use-after-free (UAF) bug where an attacker can induce a program to call a pointer of their choosing. Here the attacker controls an object which occupies space formerly used by another object, which the program erroneously continues to use. The attacker sets a field in this region that is used as a function call to the address of code the attacker would like to execute. Years ago an attacker could simply write their shellcode to a known location, then, in their overwrite, set the instruction pointer to this shellcode. In time, Data Execution Prevention was added to prevent stacks or heaps from being executable.

In response, attackers invented Return Oriented Programming (ROP). Here, attackers take advantage of the process’s own code, as that must be executable. With control of the stack (either to write values there, or by changing the stack pointer) and control of the instruction pointer, an attacker can use the `ret` instruction to jump to a different, useful, piece of code.

During an exploit attempt, the instruction pointer is changed so that instead of its normal destination, a small fragment of code, called an ROP gadget, is invoked instead. These gadgets are selected so that they do something useful (such as prepare a register for a function call) then call return.

These tiny fragments need not be a complete function in the normal program, and could even be found part-way through a legitimate instruction. By lining up the right set of “return” addresses, a chain of these gadgets can be called, with each gadget’s `ret` switching to the next gadget. With some patience, or the right tooling, an attacker can piece together the arguments to a function call, then really call the function.

Chrome has a multi-process architecture — a main browser process acts as the logged-in user, and spawns restricted renderer and utility processes to host website code. This isolation reduces the severity of a bug in a renderer as its process cannot do much by itself. Attackers will then attempt to use another sandbox escape bug to run code in the browser, which lets them act as the logged-in user. As libraries are mapped at the same address in different processes by Windows, any bug that allows an attacker to read memory is enough for them to examine Chrome’s binary and any loaded libraries for ROP gadgets. This makes preventing ROP chains in the browser process especially useful as a mitigation.

Enter stack-protection. Along with the existing stack, the cpu maintains a shadow stack. This stack cannot be directly manipulated by normal program code and only stores return addresses. The CALL instruction is modified to push a return address (the instruction after the CALL) to both the normal stack, and the shadow stack. The RET (return) instruction still takes its return address from the normal stack, but now verifies that it is the same as the one stored in the shadow stack region. If it is, then the program is left alone and it continues to work as it always did. If the addresses do not match then an exception is raised which is intercepted by the operating system (not by Chrome). The operating system has an opportunity to modify the shadow region and allow the program to continue, but in most cases an address mismatch is the result of a program error so the program is immediately terminated.

In our example above, the attacker will be able to make their initial jump into a ROP gadget, but on trying to return to their next gadget they will be stopped.

Some software may be incompatible with this mechanism, especially some older security software that injects into a process and hooks operating system functions by overwriting the prelude with `rax = &hook; push rax; ret`.


Chrome does not yet support every direction of control flow enforcement. Stack protection enforces the reverse-edge of the call graph but does not constrain the forward-edge. It will still be possible to make indirect jumps around existing code as stack protection is only validated when a return instruction is encountered, and call targets are not validated. On Windows a technology called Control Flow Guard (CFG) can be used to verify the target of an indirect function call before it is attempted. This prevents calling into the middle of a function, significantly reducing the scope of useful instructions for attackers to use. Another approach is provided by Intel’s CET which includes an ENDBRANCH instruction to prevent jumps into arbitrary code locations. Memory tagging tools such as MTE can be used to make it more difficult to modify pointers to valid code sequences (and makes UAFs more difficult in general). We are working to introduce CFG to Chrome for Windows, and will add other techniques over time.

By itself, stack protection can be bypassed in some contexts. For instance, stack protection does not prevent an attacker tricking a program into calling an existing function by entirely replacing an object containing a function pointer. This approach does not involve ROP as the function call happens instead of the expected call, and returns to the address it was originally called from, so must be allowed. However, the called function must be useful to an attacker, and most functions will not be. An example of an attack using this method is to craft a call to add the `–no-sandbox` argument to Chrome’s command line. This results in future renderers being launched without normal protections. Over time we will identify and remove such useful tools.

In the renderer, for performance reasons, our javascript and wasm engines may use memory that is both writable and executable at the same time. This allows an attacker to modify code that v8 is already going to execute, saving them the trouble of constructing a ROP chain. This explains why it was not our first priority to make v8 CET compatible, and why stack-protection is not yet enabled in the renderer.

Finally, stack protection doesn’t stop the bugs in the first place. Everything we have discussed above is a mitigation that makes it more difficult to execute arbitrary code. If a programming error allows arbitrary writes then it is very unlikely that we can prevent this being used to run arbitrary code. Attackers will adapt and find new ways to turn memory safety errors into code execution.

Debugging Tips

You can see if Hardware-enforced Stack Protection is enabled for a process using the Windows Task Manager. Open task manager, open the Details Tab, Right Click on a heading, Select Columns & Check the Hardware-enforced Stack Protection box. The process display will then indicate if a process is opted-in to this mitigation. ‘Compatible Modules Only’ indicates that any dll marked as /cetcompat at build time will raise an exception if a return address is invalid.

You can see which Chrome processes are opted-out of CET by consulting the Mitigations field of chrome://sandbox and clicking ‘+’. All processes are included unless the mitigation CET_USER_SHADOW_STACKS_ALWAYS_OFF is present in the expanded details view.

If you are developing software, or debugging a problem in Chrome the shadow stack can be helpful as it includes only return addresses, and these cannot be corrupted by rogue writes elsewhere in the process. To see these registers use the `r` command in windbg with the mask option:

0:159> rM 8002

rax=00000000c000060a rbx=000000fa5bbfeff0 rcx=0000000000000030

rdx=0000000000000000 rsi=00007ffba4118924 rdi=000000fa5bbff1a0

rip=00007ffc1847b4a1 rsp=000000fa5bbfc0a0 rbp=000000fa5bbfc0a0

r8=000000fa5bbfc098 r9=0000000000000000 r10=0000000000000000

r11=0000000000000246 r12=000000fa5bbfe230 r13=000002c3450b5830

r14=000002c3450b7850 r15=000000fa5bbfc260

iopl=0 nv up ei pl zr na po nc

ssp=000000fa5c3fef10 cetumsr=0000000000000001

`ssp` points to the shadow stack region, `cetumsr` indicates if cet is enabled for the process.

You can then see the call stack within the shadow region using `dps @ssp`. Values are not overwritten so you can also see where you came from by looking a bit deeper: `dps @ssp-20`.

If a process is not compatible with Hardware-enforced Stack Protection, the system event log (Application Log) will include brief error reports (Id:1001). You can filter those related to cetcompat using the following powershell snippet:-

Get-WinEvent -MaxEvents 128 -FilterHashtable @{ LogName=’Application’; Id=’1001′ } `

| Where-Object {$_.Message -match ‘chrome.exe’} `

| Select-Object -First 8 `

| fl

These will include the following parameters:-

P1: application.exe

P2: application version

P3: application build ts

P4: faulting module .dll

P5: faulting module version

P6: faulting module build ts

P7: faulting offset in P4 from base_address

P8: exception code (c0000409)

P9: subcode (00…000030)

If Chrome is misbehaving and you think it might be because of cetcompat, it is possible to disable it using Image File Execution Options – we do not recommend this except for a limited period of testing. If you find you have to do this, please raise an issue on https://crbug.com so that we can investigate the failure.

Further Reading


/cetcompat is enabled for most processes for Chrome M90 on Windows. Enabling Hardware-enforced Stack Protection will layer with existing and future measures to make exploitation more difficult and so more expensive for an attacker, ultimately protecting the people who use Chrome every day.

The Patch Tuesday security update due in July should hammer the last nail in the coffin of Adobe Flash Player

The post Microsoft will soon remove Flash Player from Windows 10 devices appeared first on WeLiveSecurity

The agency’s new initiative will also warn about the high cost of the free lunch – the increased risk of malware exposure

The post INTERPOL aims to deal a blow to digital piracy appeared first on WeLiveSecurity

Governments as cyber-targets – FBI and Have I Been Pwned team up to notify Emotet victims – Mac users urged to plug a serious security hole

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

The data breach notification site now allows you to check if your login credentials may have been compromised by Emotet

The post FBI teams up with ‘Have I Been Pwned’ to alert Emotet victims appeared first on WeLiveSecurity

A year into the pandemic, ESET reveals new research into activities of the LuckyMouse APT group and considers how governments can rise to the cybersecurity challenges of the accelerated shift to digital

The post Prime targets: Governments shouldn’t go it alone on cybersecurity appeared first on WeLiveSecurity