This Week In Security: Pacman, Hetzbleed, And The Death Of Internet Explorer – Hackaday

Theres not one, but two side-channel attacks to talk about this week. Up first is Pacman, a bypass for ARMs Pointer Authentication Code. PAC is a protection built into certain ARM Processors, where a cryptographic hash value must be set correctly when pointers are updated. If the hash is not set correctly, the program simply crashes. The idea is that most exploits use pointer manipulation to achieve code execution, and correctly setting the PAC requires an explicit instruction call. The PAC is actually indicated in the unused bits of the pointer itself. The AArch64 architecture uses 64-bit values for addressing, but the address space is much less than 64-bit, usually 53 bits or less. This leaves 11 bits for the PAC value. Keep in mind that the application doesnt hold the keys and doesnt calculate this value. 11 bits may not seem like enough to make this secure, but keep in mind that every failed attempt crashes the program, and every application restart regenerate the keys.

What Pacman introduces is an oracle, which is a method to gain insight on data the attacker shouldnt be able to see. In this case, the oracle works via speculation attacks, very similar to Meltdown and Spectre. The key is to attempt a protected pointer dereference speculatively, and to then observe the change in system state as a result. What you may notice is that this requires an attack to already be running code on the target system, in order to run the PAC oracle technique. Pacman is not a Remote Code Execution flaw, nor is it useful in gaining RCE.

One more important note is that an application has to have PAC support compiled in, in order to benefit from this protection. The platform that has made wide use of PAC is MacOS, as its a feature baked in to their M1 processor. The attack chain would likely start with a remote execution bug in an application missing PAC support. Once a foothold is established in uprivileged userspace, Pacman would be used as part of an exploit against the kernel. See the PDF paper for all the details.

The other side-channel technique is a new take on an old idea. Hertzbleed is based on the idea that its possible to detect the difference between a CPU running at base frequency, and that CPU running at a boost frequency. The difference between those two states can actually leak some information about what the CPU is doing. Theres a pre-release PDF of their paper to check out for the details. The biggest result is that the standard safeguard against timing attacks, constant-time programming, is not always a reliable security measure.

It works because max frequency is dependent on the processor Thermal Design Power (TDP), the maximum amount of power a CPU is designed to use and amount of heat to dissipate. Different instructions will actually use different amounts of power and generate more or less heat based on this. More heat means earlier throttling. And throttling can be detected in response times. The details of this are quite fascinating. Did you know that even running the same instructions, with different register values, results in slightly different power draw? They picked a single cryptographic algorithm, SIKE, a quantum-safe key exchange technique, and attempted to extract a servers secret key through timing attacks.

There is a quirk in SIKE, also discovered and disclosed in this research, that its possible to short-circuit part of the algorithm, such that a series of internal, intermediary steps result in a value of zero. If you know multiple consecutive bits of the static key, its possible to construct a challenge that hits this quirk. By extension, you can take a guess at the next unknown bit, and it will only fall into the quirk if you guessed correctly. SIKE uses constant-time programming, so this odd behavior shouldnt matter. And here the Hertzbleed observation factors in. The SIKE algorithm consumes less power when doing a run containing this cascading-zero behavior. Consuming less power means that the processor can stay at full boost clocks for longer, which means that the key exchange completes slightly more quickly. Enough so, that it can be detected even over a network connection. They tested against Cloudflares CIRCL library, and Microsofts PQCrypto-SIDH, and were able to recover secret keys from both implementations, in 36 and 89 hours respectively.

There is a mitigation against this particular flaw, where its possible to detect a challenge value that could trigger the cascading zeros, and block that value before any processing happens. It will be interesting to see if quirks in other algorithms can be discovered and weaponized using this same technique. Unfortunately, on the processor side, the only real mitigation is to disable boost clocks altogether, which has a significant negative effect on processor performance.

[Frdric Basse] has a Google Nest Hub, and he really wanted to run his own Linux distro on it. Theres a problem, though. The Nest uses secure boot, and theres no official way to unlock the bootloader. Since when would a dedicated hacker let that stop him? The first step was finding a UART interface, hidden away on some unterminated channels of a ribbon cable. A custom breakout board later, and he had a U-Boot log. Next was to run through the bootup button combinations, and see what U-Boot tried to do with each. One of those combinations allows booting from a recovery.img, which would be ideal, if not for secure boot.

The great thing about U-Boot is that its Open Source under the GPL, which means that the source code should be available for perusal. Find a bug in that source, and you have your secure boot bypass. Open Source also allows some fun approaches, like running portions of the U-Boot code in userspace, and exercising it with a fuzzer. Thats the approach that found a bug, where a block size greater than 512 bytes triggers a buffer overflow. Its a generally safe assumption, as there arent really any USB storage devices with a block size greater than 512.

Never fear, a device like the Raspberry Pi Pico can run TinyUSB, which allows emulating a USB device with whatever block size you specify. A test determined that this approach did result in a repeatable crash on the real device. The code execution is fairly straightforward, writing a bunch of instructions that are essentially noop codes pointing to a payload, and then overwriting the return pointer. Code execution in the can, all that remained was to overwrite the command list and execute a custom U-Boot script. A thing of beauty.

The lowly ping command. How much can a single pair of packets tell us about a network and remote host? According to [HD Moore], quite a bit. For example, take the time given for a ping response, and calculate a distance based on 186 miles per millisecond. Thats the absolute maximum distance away that host is, though a quarter and half of that amount are reasonable lower and upper limits for a distance estimate. TTL very likely started at 64, 128, or 255, and you can take a really good guess at the hops encountered along the way. Oh, and if that response started at 64, its likely a Linux machine, 128 for Windows, and 255 usually indicates a BSD-derived OS.

Receiving a destination host unreachable message is interesting in itself, and tells you about the router that should be able to reach the given IP. Then theres the broadcast IP, which sends the message to every IP in the subnet. Using something like Wireshark for packet capture is enlightening here. The command itself may only show one response, even though multiple devices may have responded. Each of those responses have a MAC address that has can be looked up to figure out the vendor. Another interesting trick is to spoof the source IP address of a ping packet, using a machine you control with a public IP address. Ping every device on the network, and many of them will send the response via their default gateway. You might find an Internet connection or VPN that isnt supposed to be there. Who knew you could learn so much from the humble ping.

Internet Explorer is Really, Truly, Dead. If you were under the impression, as I was, that Internet Explorer was retired years ago, then it may come as a surprise to know that it was finally done in only this past week. This months patch Tuesday was the last day IE was officially supported, and from now on its totally unsupported, and is slated to eventually be automatically uninstalled from Windows 10 machines. Also coming in this months patch drop was finally the fix for Follina, as well as a few other important fixes.

Theres a new record for HTTPS DDOS attacks, set last week: Cloudflare mitigated an attack consisting of 26 million requests per second. HTTPS attacks are a one-two punch consisting of both raw data saturation, as well as server resource exhaustion. The attack came from a botnet of VMs and servers, with the largest slice coming from Indonesia.

Running the free tier of Travis CI? Did you know that your logs are accessible to the whole world via a Travis API call? And on top of that, the whole history of runs since 2013 seems to be available. It might be time to go revoke some access keys. Travis makes an attempt to censor access tokens, but quite a few of them make it through the sieve anyways.

Ever wonder what the risk matrix looks like for TPM key sniffing on boot? Its not pretty. Researchers at Secura looked at six popular encryption and secure boot applications, and none of them used the parameter encryption features that would encrypt keys on the wire. The ironic conclusion? discrete TPM chips are less secure than those built in to the motherboards firmware.

See more here:
This Week In Security: Pacman, Hetzbleed, And The Death Of Internet Explorer - Hackaday