Just-in-time, or JIT, compilation could be considered a fundamental backbone of modern computing. JIT compilation turns scripting languages like JavaScript or intermediary binary forms like Web Assembly into native code on the fly, giving web apps, and things that are web apps under the covers like Electron-based tools, near native speed. A new paper explores leveraging JIT systems to revive Spectre-v2 attacks against processors.
Most modern processors gain performance by using a trick called “speculative execution”. The processor guesses the likely result of a compare, and begins executing some of the next instructions before the results are actually known. If the processor guessed right, things continue and there is a speed gain because it can jump ahead, but if the processor guessed wrong, any instructions that were run and any side effects of running them are discarded and execution resumes on the actual path. In theory, anyhow.
In practice, the Spectre class of attacks targets branch prediction. It was discovered that when the wrong branch was chosen, not all of the results were truly hidden; Patterns of failures in guessing branches can be used to leak behavior processing encryption keys and other activities. The attacks evolved with the research dubbed Spectre-V2, which showed that non-privileged contexts, like non-root users and virtual machines, could poison the instruction prediction and use it to read arbitrary memory. Fixes to the Linux kernel and other platforms were required to mitigate the worst of the effects.
The paper shows that by using self-modifying code in the JIT, the processor can be tricked into loading cached versions of the instructions. The fixes to the kernel to prevent Spectre attacks include identifying malicious code patterns that attack the branch prediction, and stopping or changing them: By causing the CPU to execute the cached copy of instructions instead of the live copy, the attack ignores the fixed instructions entirely and can attack the branch prediction algorithm.
To prove the attack is feasible in the real world, the researchers targeted several JIT compilers, including the SpiderMonkey JavaScript engine used by Firefox, the eBPF JIT found in the Linux kernel, and GraalVM, the JIT used in Python. They found success with each, demonstrating that the attack is at least plausible.
Research like this is unlikely to be an instant world-melter, and will help find possible mitigations in the future to prevent these sorts of attacks. Operating systems that support a high-security “lock-down” mode, like macOS and iOS, often disable JIT entirely, out of concern about these sorts of attacks. There’s probably no need to start disabling JIT on every system, but attacks like these have a tendency to evolve.
Enormous List of Vulnerabilities Patched in Linux
Updated Linux kernels are available for most distributions, with a truly intimidating list of patched security issues. As this Debian post states, “Several vulnerabilities have been discovered in the Linux kernel that may lead to a privilege escalation, denial of service or information leaks.” Several, in this case, is a load-bearing word, and you should go check out the CVE list. I’ll wait.
This, apparently, is what the AI Vulnpocalypse looks like today. After Windows patched over a thousand vulnerabilities in a single Patch Tuesday, we probably had a pretty good idea what would be coming. With over 1,200 vulnerability report IDs listed in the patch, manually understanding the security impact is extremely daunting if not entirely impossible. A random sampling shows vulnerabilities in compression handling, denial of service attacks from local users, and memory corruption that may or may not be exploitable, but with a list this huge that’s hardly exhaustive.
For normal admins and users, there isn’t much else to do besides apply the patches and hope they don’t cause new problems. Linux overall has a better track record with patches not breaking they entire system, but it’s not unheard of, and with this much churn, the chances of something going wrong of course increases. Patching is almost always a better option than not patching and hoping you don’t get owned, though!
Google Stops Bug Bounty Program Because of AI
“Stop hitting yourself” comes to mind. Google has stopped the Google Open Source Vulnerability Rewards Program, the bounty program offering rewards for finding bugs in the companies open source releases.
Surprising nobody, the bounty program has been flooded with “low effort” and “low quality” AI generated reports. Google says maintainers were overwhelmed with false reports containing AI hallucinations, and that the program would be re-evaluated in 2027. While AI-assisted, or even directed, security research is our new normal, if the results aren’t checked by someone able to confirm they’re legitimate, submitting them helps nobody.
Can’t help but feel some schadenfreude that a company shoving AI into every aspect of our lives is then impacted by AI being shoved everywhere, but in the end swamping developers with bogus reports keeps them from fixing the real bugs and benefits nobody, so it’s hard to find a positive takeaway on this one.
Retailer Asos Hacked, Ransomed
Customers of the Asos online clothing store who installed the Asos app got first-hand evidence that the platform was hacked by a ransomware crew. The attackers used the Asos app push notifications to send an alert to all customers: “Dear Asos DPO and IT, we have fully compromised the Snowflake instance. Engage with us, or we will leak it.”
Snowflake is a cloud-scale database company, and has been implicated in several other attacks over the past few years, including a large hack in 2024 by the ShinyHunters group that led to compromises of Ticketmaster, AT&T, Lending Tree, and others. It’s unclear how the Asos Snowflake instance was compromised.
Direct-to-consumer ransomware demands aren’t new, and apply pressure to the impacted company. The message itself is a well-phrased piece of propaganda, casting the hacked company as the villain who isn’t protecting the customers by engaging in the extortion demands. Asos so far indicates that “basic customer information” like name and contact information, but possibly not payment details.
Accenture Contractor Implicated in FBI Hack
The FBI has removed a contractor from the multinational tech company Accenture, after determining that the breach of the Oracle PeopleSoft instance that then led to the breach of the information of the entire FBI agent and employee system, was avoidable.
Details remain scarce, but this would imply that the vulnerability used by ShinyHunters wasn’t a zero-day after all. One of the most dangerous phases of the vulnerability lifecycle is when both the bug and patch are known, because researchers can often quickly deduce the vulnerability from the patch and write an exploit. This seems to be what happened here.
Rarely are specific individuals held directly responsible for patch cycles. Patching production services of large organizations is usually determined at an institutional level. Reading between the lines, the individual may have been directly tasked with doing the work of installing the patches and didn’t.
Last week, the ShinyHunters group made public statements that it did not plan to leak the stolen information, and was simply using it as a means to get press coverage of their grievances against the FBI. The promise not to leak the addresses of the families of agents is probably appreciated by the agents themselves, but unlikely to do much to slow the pursuit.
Domain Registrars Hacked to get TLS
Ars Technica reports that three domain registrars were hacked and the access used to obtain certificates for Google domains.
By hacking the registrars and changing the assignment of country-level Google domains for the “gh” (Ghana), “sl” (Sierra Leone), and “as” (American Samoa) top-level domains, the attackers were able to pass automated domain ownership checks required for obtaining SSL certificates.
To be usable, an attacker would have to be able to intercept and redirect the traffic between a user and the compromised domain, and the user would have to be attempting to connect to the Google domains in that country TLD in the first place. The attack may have been targeted against those specific countries, or may have simply been an opportunistic attempt to harvest credentials. Conceivably, the certificates could be used on malicious WiFi networks to try to capture user sessions from other Google domains and services.
Google has already implemented filtering for the specific certificates in Chrome, but these fixes do not help other browsers or services, and Google says it may not have identified all the compromised domains. Google also cautions that the domains of other companies were also compromised, and that those companies must take independent action to protect their users, but the impacted companies were not provided.
Hacking Lawnmowers
Researchers found a series of vulnerabilities in the Mammotion robot lawnmower platform. After spending “a few days on Mammotion’s cloud”, they demonstrated an admin account takeover and a full dump of all 337,000 customers, and for the cherry on top, unauthenticated access to first-person mode on mower. In case you wanted to help tidy up someones lawn or just go for a drive around the neighborhood.
After finding previous security issues in Mammotion products which were not, to put it delicately, fixed according the current norms of security patching in the industry, the company was on the radar. In addition to discovering that there was no rate limiting on brute-forcing account recovery and changing any users password, the team also found that factory systems lacked any authentication at all, hard-coded authentication tokens were baked into the firmware, and it may be possible to add any customer’s mower to any account.
After repeated attempts by the team to get the company to set up security contacts and respond to the vulnerability reports, it appears that the issues whith are remotely testable have been resolved, but for a fun read be sure to check the article and the email threads as an example of how, probably, you shouldn’t handle security reports as a company.