Intel announced CrossTalk, a new side-channel attack that can leak data from CPU buffers. It’s the same story we’ve heard before. Bits of internal CPU state can be inferred by other processes. This attack is a bit different, in that it can leak data across CPU cores. Only a few CPU instructions are vulnerable, like RDRAND, RDSEEED, and EGETKEY. Those particular instructions matter, because they’re used in Intel’s Secure Enclave and OpenSSL, to name a couple of important examples.

What’s happening here is that a “special register buffer” is shared between all the cores on a CPU, and is only used for a few instructions. That buffer can be inferred by existing data vulnerabilities, like MFBDS (Zombieload) and TAA. The mitigation is rather extreme. The entire processor is paused until the vulnerable instruction completes and the buffer is overwritten. The performance hit can be intense on some workloads.

And in other side-channel news, the Linux kernel just received a few fixes. The first is a fix for certain cases where speculative execution mitigations have been enabled, but they’re not actual active. The second bug was a case of performance optimization gone awry. An attacking process can simply set a couple of flags, and is given a pass, allowing a SPECTRE V4 attack. And finally, it was discovered that it was possible to re-enable speculative execution, and the machine will still report speculation is disabled. These bugs were announced publicly, and are in the process of being fixed.

Brave Browser

A bit of a kerfuffle developed this week around the Brave browser. A twitter user noticed something odd when visiting a few particular sites in the Brave browser — going to a particular web site, Binance.us, ended up sending him to an affiliated link. As you can imagine, this behavior from the browser that sells itself as being privacy-focused wasn’t exactly well received.

So when you are using the @brave browser and type in "binance[.]us" you end up getting redirected to "binance[.]us/en?ref=35089877" – I see what you did there mates 😂

— Cryptonator1337 (@cryptonator1337) June 6, 2020

What’s going on here? The first detail to note is that the affiliated link was an autofill, not a redirect. The official response clears up what’s going on here. Brave has an option, on by default, to show “Brave suggested sites” as part of the autofill list. These are sponsored links, and have a global referral code baked into the link. According to the official response, it was unintended for the sponsored suggested link to show up first in the list of autocompletes, where it was automatically selected by hitting enter.

GNUTLS 1.3 Compromise

A bug in GnuTLS was recently reported, where session resumption could be abused by a malicious server to launch a MitM attack against a TLS connection. Session resumption is built into the TLS 1.3 protocol, and is a way to avoid a full TLS handshake when a client re-connects to the server. Instead, on initial connection, the server sends an encrypted session snapshot — a session ticket. Because it’s encrypted by the server, the client can’t extract any data from the ticket. On a reconnection, the session ticket is sent instead of the normal handshake, and the included session data is used to resume the encrypted TLS connection.

It’s a good scheme, so long as the session ticket encryption is solid. On the other hand, if a server fails to set a good encryption key, then this scheme is just asking for problems. GnuTLS, up until a few days ago, seemed to be using an encryption key of all zeroes. It’s an unfortunate mistake, and a dangerous one. When a client sends the session ticket to a hostile server, it’s easily decrypted, and the client believes it’s talking to the original server.

Smart Contract Malware

The cryptocurrency world is a developing target for malware. Case in point, a malicious contract that was recently discovered on the Ethereum blockchain. This particular contract is reminiscent of the attack on The Dao back in 2016.

The big selling point of Ethereum is the smart contract. It’s a way to embed code into a blockchain, and automatically run that code on certain conditions. If we’ve learned anything from history like the obfuscated C contest, it’s that code isn’t always what it seems.

In this case, the problem is a reentry vulnerability. If another smart contract makes a withdrawal, this second smart contract has an opportunity to run its own code as a part of the withdrawal action. When that happens, it’s possible to make a call back into the vulnerable contract, and continue extracting money. The attack on a vulnerable contract like this one goes as follows: Deposit at least 1 ETH, which grants the right to make a withdrawal. Wait until others have invested in the same contract, and then use the vulnerability to withdraw everyone’s funds.

But hang on, this isn’t just a vulnerable contract, it’s a malicious one. The part of the contract that allows withdrawing money has a catch: only the creator of the contract is actually able to withdraw any funds. The whole thing is a malicious honeypot. The contract appears to contain an exploitable vulnerability, but really it steals the 1 Ether price of entry from anyone looking to drain the funds.

Breaking CMD.EXE

This is just fun, but as Microsoft doesn’t consider it a real security threat, it still works in Windows 10.

cmd.exe /c "ping 127.0.0.1/../../../../../../../../../../windows/system32/calc.exe"

What’s the story here? Cmd.exe is first trying to interpret the string as a relative path. “ping 127.0.0.1/” and the first “../” essentially cancel each other out. It’s not a vulnerability per se, but I can only imagine that this particular unexpected behavior could be abused. Imagine a ping test that takes a user input, and uses the cmd /c command to run the test. If user input isn’t sanitized, this quirk can be abused to run an arbitrary command.

Edit: Somehow I missed giving credit to [Julian Horoszkiewicz], who discovered this interesting issue.