This Week Safe: Retbleed, Post-Quantum, Python-atomicwrites, and the Mysterious Cuteboi

Yet another entry in the "why we can't have nice things" category, Retbleed was announced this week, as another speculative execution vulnerability. This is mitigated in hardware for AMD Zen 3 and Intel Generation 9 and later. For older devices, the attenuation performance is quite painful. What exactly differentiates it from previous weaknesses, and why didn't previous mitigations cover this issue?

Specter V2 leverages a CPU's indirect branch prediction to trigger speculative execution of code that shouldn't be executed in a given context. Even if the CPU eventually catches up and cancels the fake execution, there are still fingerprints left in the cache contents. The idea is that reading these fingerprints leaks real data that the attacker's process shouldn't have access to at all. The solution in the Linux kernel is "retpoline", a portmanteau of "return" and "trampoline". This gadget replaces a jmp instruction with a configuration, and finally a ret call instead. This seemed like an inexpensive solution to the problem.

What Retbleed brings to the table is a method to poison the speculative execution of these return statements as well. Their full paper (PDF) outlines the technique, which boils down to manipulating a CPU to use the vulnerable Branch Target Buffer (BTB) instead of the safer Return Stack Buffer (RSB). On vulnerable Intel systems, this means padding the RSB with enough data to push the actual target return out of the buffer. When the series of jumps and returns unfolds, the final return actually uses the BTB because the RSB has emptied or underestimated. Vulnerable AMD systems just seem to always use a BTB to predict returns, which makes exploiting there much easier.

Windows machines use a more aggressive mitigation policy, Indirect Branch Restricted Speculation (IBRS), which appears to completely mitigate this particular issue, although there may be more in the coming weeks. On Linux, retpoline mitigation is eventually replaced by IBRS by default, resulting in the performance hit described above.

If you are using one of the affected processors, you can use certain kernel parameters to control the mitigations put in place. retbleed=off uses existing retpoline mitigation if needed, but does not degrade performance further, at the expense of vulnerability to this attack. The default, retbleed=auto, will use all mitigations to make the machine as safe as possible without disabling simultaneous multithreading (SMT). And finally retbleed=auto,nosmt will actually disable SMT on the few models that technically need it for full mitigations. This is not set by default, as it is even more crippling to machine performance.

NIST goes post-quantum

While the quantum crypto-apocalypse has yet to be realized, the various standards agencies are working to stay ahead of the game by sponsoring research and then selecting cryptography schemes to use as standards new generation. In that vein, NIST has released an update to its post-quantum cryptography standards process. The big news here is that a few algorithms have been selected. Falcon, SPHINCS, CRYSTALS-Kyber and CRYSTALS-Dilithium. There certainly seems to be some sci-fi geeks among the attendees, judging by the names.

CRYSTALS-Kyber is a Key Wrapping Mechanism (KEM), a method for sharing a private key using only publicly sent messages, a la Diffie-Hellman. CRYSTALS-Dilithium and others are signature schemes, useful for verifying data. We look forward to seeing these standards rolled out across the various projects and applications we use daily.

PyPI, 2FA and a grumpy developer

In order to avoid security issues, the PyPI repository has deployed a security policy that forces maintainers of critical projects to use two-factor authentication for their accounts, and even sends free hardware keys. The inclusion criterion is to be in the top 1% of downloads for six months. There is a relevant question in the FAQ on the page: "Can a project unsubscribe or become uncritical in any way?" The official response reads, "No, once the project has been designated critical, it retains that designation indefinitely." At least one of...

This Week Safe: Retbleed, Post-Quantum, Python-atomicwrites, and the Mysterious Cuteboi

Yet another entry in the "why we can't have nice things" category, Retbleed was announced this week, as another speculative execution vulnerability. This is mitigated in hardware for AMD Zen 3 and Intel Generation 9 and later. For older devices, the attenuation performance is quite painful. What exactly differentiates it from previous weaknesses, and why didn't previous mitigations cover this issue?

Specter V2 leverages a CPU's indirect branch prediction to trigger speculative execution of code that shouldn't be executed in a given context. Even if the CPU eventually catches up and cancels the fake execution, there are still fingerprints left in the cache contents. The idea is that reading these fingerprints leaks real data that the attacker's process shouldn't have access to at all. The solution in the Linux kernel is "retpoline", a portmanteau of "return" and "trampoline". This gadget replaces a jmp instruction with a configuration, and finally a ret call instead. This seemed like an inexpensive solution to the problem.

What Retbleed brings to the table is a method to poison the speculative execution of these return statements as well. Their full paper (PDF) outlines the technique, which boils down to manipulating a CPU to use the vulnerable Branch Target Buffer (BTB) instead of the safer Return Stack Buffer (RSB). On vulnerable Intel systems, this means padding the RSB with enough data to push the actual target return out of the buffer. When the series of jumps and returns unfolds, the final return actually uses the BTB because the RSB has emptied or underestimated. Vulnerable AMD systems just seem to always use a BTB to predict returns, which makes exploiting there much easier.

Windows machines use a more aggressive mitigation policy, Indirect Branch Restricted Speculation (IBRS), which appears to completely mitigate this particular issue, although there may be more in the coming weeks. On Linux, retpoline mitigation is eventually replaced by IBRS by default, resulting in the performance hit described above.

If you are using one of the affected processors, you can use certain kernel parameters to control the mitigations put in place. retbleed=off uses existing retpoline mitigation if needed, but does not degrade performance further, at the expense of vulnerability to this attack. The default, retbleed=auto, will use all mitigations to make the machine as safe as possible without disabling simultaneous multithreading (SMT). And finally retbleed=auto,nosmt will actually disable SMT on the few models that technically need it for full mitigations. This is not set by default, as it is even more crippling to machine performance.

NIST goes post-quantum

While the quantum crypto-apocalypse has yet to be realized, the various standards agencies are working to stay ahead of the game by sponsoring research and then selecting cryptography schemes to use as standards new generation. In that vein, NIST has released an update to its post-quantum cryptography standards process. The big news here is that a few algorithms have been selected. Falcon, SPHINCS, CRYSTALS-Kyber and CRYSTALS-Dilithium. There certainly seems to be some sci-fi geeks among the attendees, judging by the names.

CRYSTALS-Kyber is a Key Wrapping Mechanism (KEM), a method for sharing a private key using only publicly sent messages, a la Diffie-Hellman. CRYSTALS-Dilithium and others are signature schemes, useful for verifying data. We look forward to seeing these standards rolled out across the various projects and applications we use daily.

PyPI, 2FA and a grumpy developer

In order to avoid security issues, the PyPI repository has deployed a security policy that forces maintainers of critical projects to use two-factor authentication for their accounts, and even sends free hardware keys. The inclusion criterion is to be in the top 1% of downloads for six months. There is a relevant question in the FAQ on the page: "Can a project unsubscribe or become uncritical in any way?" The official response reads, "No, once the project has been designated critical, it retains that designation indefinitely." At least one of...

What's Your Reaction?

like

dislike

love

funny

angry

sad

wow