This week in security: Pacman, Hetzbleed, and the death of Internet Explorer

There is not one attack, but two attacks on the side channel to talk about this week. up first Pacman, bypass for ARM Indicator Authentication Token. PAC is a protection built into certain ARM processors, in which the 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 properly setting a protected access credential 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 does not hold the keys and does not calculate this value. 11 bits may not seem to be enough to make this safe, but keep in mind that every failed attempt crashes the program, and every application restart recreates the keys.

What Pacman offers is an oracle, a way of gaining insight into data that an attacker shouldn’t be able to see. In this case, the oracle works via speculative attacks, very similar to Meltdown and Specter. The key is to try not to speculatively reference the protected pointer, and then watch for a change in the system’s state as a result. What you may notice is that this would require an attack to actually run the code on the target system, in order for the PAC oracle technology to work. Pacman is not defective in remote code execution, nor is it useful for RCE acquisition.

Another important note is that the application must have PAC support bundled in to take advantage of this protection. The platform that has used PAC extensively is macOS, as it is a feature hidden in their M1 processor. The attack chain could potentially start with a remote execution glitch in an application that lacks PAC support. Once a foothold is established in the premium user space, Pacman will be used as part of an anti-kernel exploit. We see PDF paper For every detail.


Another side channel technique is a new take on an old idea. Hertzblade It is based on the idea that it is possible to detect the difference between a CPU operating at a base frequency, and a CPU operating at a boost frequency. The difference between these two states can cause some information to be leaked about what the CPU is doing. there PDF file before release From their papers to check the details. The biggest consequence is that the standard protection against timing attacks, i.e. constant-time programming, is not always a reliable security measure.

It works because the maximum frequency depends on the processor’s thermal design power (TDP), which is the maximum amount of power the CPU is designed to use and the amount of heat to dissipate. Different instructions will actually use different amounts of energy and generate more or less heat depending on that. More heat means early suffocation. Throttling can be detected in response times. The details of this are so amazing. Did you know that even running the same instructions, with different register values, results in a slightly different power draw? They chose one encryption algorithm, SIKE, a quantum secure key exchange technology, and tried to extract the server’s secret key through timing attacks.

An anomaly in SIKE, also discovered and revealed in this paper, is that it is possible to shorten part of the algorithm, such that a series of internal intermediate steps results in a value of zero. If you know multiple consecutive bits of the static key, it is possible to create a challenge that reaches this error. By extension, you can guess the next unknown bit, and it will only get weird if you guess correctly. SIKE uses constant time programming, so this strange behavior shouldn’t matter. Here are Hertzbleed monitoring factors. The SIKE algorithm consumes less power when performing a run that contains this zero-cascade behavior. Less power consumption means the processor can stay on full boost hours for longer, which means the key exchange completes a bit faster. It is enough, so that it can be detected even over a network connection. Tested against Cloudflare’s CIRCL library and Microsoft’s PQCrypto-SIDH, they were able to recover secret keys from both applications in 36 and 89 hours, respectively.

There is a mitigation for this particular flaw, where it is possible to detect a challenge value that can trigger consecutive zeros, and block that value before any processing occurs. It will be interesting to see if quirks in other algorithms can be detected and weaponized using the same technology. Unfortunately, on the processor side, the only real mitigation is to completely disable the boost clocks, which greatly negatively affects the performance of the processor.

Defeat Nest Secure Boot

[Frédéric Basse] He has a Google Nest Hub and He really wanted to run his own Linux distro on him. Although, there is a problem. Nest uses secure boot, and there is no official way to unlock the bootloader. Since when did a professional hacker allow this to be stopped? The first step was to find the UART interface, hidden away from some unterminated channel of the ribbon cable. Dedicated breaking board later, he had a U-Boot record. Next was to turn on the boot button groups, and see what the U-Boot tried to do with each one. One of these combinations allows booting from the recovery.img file, which would be ideal, if not for a secure boot.

The great thing about U-Boot is that it is open source under the GPL, which means that the source code has to be available to peruse. Find an error in this source, and you have a secure boot bypass. Open source also allows for some fun techniques, like running bits of U-Boot code in userspace, and practicing them with a fuse. This is the approach that found an error, where a block size greater than 512 bytes causes a buffer overflow. It’s a generally safe assumption, as there aren’t 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 to emulate a USB device whatever block size you select. A tester determined that this approach did indeed lead to frequent crashes on the real machine. Executing the code is fairly straightforward, writing a set of basic instructions noop Codes indicate the payload, then overwrite the return pointer. Executing the code in the enclosure, all that remains is to overwrite the list of commands and execute a custom U boot script. Something of a beauty.


humble ping ordering. How far can one pair of packets tell us about the network and the remote host? according to [HD Moore]calm down a little. For example, take the exact time of the ping response, and calculate the distance based on 186 miles per millisecond. This is the absolute maximum distance away from that host, although a quarter and a half of that amount is an upper and lower bound for the distance estimate. The TTL will very likely start at 64, 128, or 255, and you can take a really good guess at the hops you encountered along the way. Oh, and if this response starts at 64, it’s probably Linux, 128 for Windows, and 255 usually indicates a BSD-derived OS.

Receiving the “destination host unreachable” message is interesting in itself, and it tells you which router should be able to reach the specified IP address. Then there is the broadcast IP, which sends the message to every IP in the subnet. Using something like Wireshark to capture packets is helpful here. The same command may display only one response, although multiple devices may respond. Each of these responses has a searchable MAC address for the seller. Another interesting trick is spoofing the source IP address of the ping packet, using a device you control with a public IP address. Ping every device on the network, and many of them will send the response through their default gateway. You may find an internet connection or a VPN that is not supposed to be there. Who knew you could learn so much from the humble ping.

bit and byte

Internet Explorer is really, really dead. If you have the impression, as I have, that Internet Explorer has been out of action for years, it may come as a surprise to learn that it was finally done just last week. This month’s patch was the last day that IE was officially supported, and from now on it’s completely unsupported and is set to be automatically removed from Windows 10 devices. Also came the patch drop for this month. Finally the fix for FollinaPlus some other important fixes.

There is a new record for HTTPS DDOS attacks, set last week: Cloudflare mitigated the attack It consists of 26 million requests per second. HTTPS attacks are a binary attack that consists of raw data saturation, as well as depletion of server resources. The attack came from a botnet of virtual machines and servers, with the largest segment coming from Indonesia.

Running the free tier of Travis CI? Did you know this Your records are accessible to the entire world via the Travis API call? Moreover, the full history of operation since 2013 appears to be available. It might be time to revoke some access keys. Travis makes an attempt to censor the access tokens, but quite a few of them go through the sieve anyway.

Have you ever wondered what the risk matrix for sniffing a TPM key on boot would look like? It’s not pretty. Researchers at Secura studied six popular encryption and secure boot implementations, and none of them used parameter encryption features that would encrypt keys on the wire. ironic conclusion? Discrete TPM chips are less secure than those built into the motherboard’s firmware.