Just-in-time, or JIT, compilation could be considered a fundamental pillar of modern computing. JIT compilation turns script languages like JavaScript or intermediate 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, close to native speed. A new paper explores using JIT systems to detect Spectre-v2 attacks against processors.
Most modern processors gain performance by using a trick called “speculative execution”. The processor estimates the possible result of a comparison, and begins executing some of the next instructions before the results are actually known. If the processor has guessed correctly, things move on and there is a speed gain because it can jump ahead, but if the processor has guessed wrong, all instructions that have been executed and any side effects of running are discarded and execution continues on the current path. In theory, anyway.
In practice, the Specter class of attacks targets branch prediction. It was discovered that when the wrong branch was chosen, not all the results were really hidden; Patterns of branch guessing errors can be used to leak behavioral processing encryption keys and other activities. The attack evolved with research called Spectre-V2, which showed that non-privileged contexts, such as 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-explanatory code in the JIT, the processor can be tricked into loading cached versions of the instructions. The kernel’s fixes to prevent Specter attacks include identifying malicious code patterns that attack the branch prediction, and stopping or modifying it: By making the CPU 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 that 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 everyone, proving that the attack is at least plausible.
Research like this is unlikely to be an instant world meltdown, and will help find possible mitigations in the future to prevent these types of attacks. Operating systems that support a high-security “lock-down” mode, such as macOS and iOS, often disable JIT entirely, out of concern about these types of attacks. It is probably not necessary to disable JIT on every system, but attacks like this have a tendency to develop.
Huge 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 says, “Several vulnerabilities have been discovered in the Linux kernel that could lead to privilege escalation, denial of service, or information leaks.” Different, in this case, is a key word, and you should check the CVE list. I am waiting.
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 of what was coming. With over 1,200 vulnerability report IDs listed in the patch, manually understanding the security impact is extremely daunting if not downright impossible. A random sampling reveals vulnerabilities in compression handling, denial of service attacks by local users, and memory corruption that may or may not be exploitable, but with a large list that is hardly exhaustive.
For normal administrators and users, there isn’t much else to do besides apply the patches and hope they don’t cause any new problems. Linux overall has a better track record with patches that don’t break the entire system, but it’s not unheard of, and with this much churn, the chances of something going wrong increases. Patching is almost always a better option than not patching and hoping you don’t get owned!
Google Stops Bug Bounty Program Because of AI
“Stop beating yourself up” comes to mind. Google has discontinued the Google Open Source Vulnerability Rewards program, the bounty program offering rewards for finding bugs in the company’s open source releases.
Unsurprisingly, the bounty program is inundated with “low effort” and “low quality” AI generated reports. Google says the content has been overwhelmed with false reports that include AI hallucinations, and that the program will be re-evaluated in 2027. While AI-assisted, or even directed, security research is our new normal, if the results aren’t vetted by someone who can confirm they’re legitimate, submitting them won’t help anyone.
Can’t help but feel some schadenfreude that a company that pushes AI into every aspect of our lives is then affected by AI pushed everywhere, but in the end flooding developers with false reports prevents them from fixing the real bugs and benefits no one, so it’s hard to find a positive takeaway on this.
Retailer Asos Hacked, Ransomed
Customers of the Asos online clothing store who installed the Asos app received first 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 completely 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 in recent years, including a major hack in 2024 by the ShinyHunters group that led to compromises of Ticketmaster, AT&T, Lending Tree, and others. It is unclear how the Asos Snowflake instance was compromised.
Direct-to-consumer ransomware claims are not new, and are putting pressure on the affected company. The message itself is a well-phrased piece of propaganda that casts the hacked company as the villain who fails to protect customers by engaging in extortion demands. Asos so far shows that “basic customer information” such as name and contact information, but possibly not payment details.
Accenture contractor implicated in FBI hack
The FBI has removed a contractor from the multinational technology company Accenture, after determining that the breach of the Oracle PeopleSoft instance, which then led to the breach of information of the entire FBI agent and employee system, was preventable.
Details remain scarce, but this would imply that the vulnerability exploited by ShinyHunters was not a zero-day after all. One of the most dangerous phases of the vulnerability lifecycle is when both the bug and the patch are known, because researchers can often quickly deduce the vulnerability from the patch and write an exploit. That seems to be the case here.
Rarely are specific individuals directly responsible for patch cycles. Patching production services of large organizations are usually determined at the institutional level. Reading between the lines, the individual may have been directly tasked with doing the work to install the patches and not.
Last week, the ShinyHunters group made public statements that it has no plans to leak the stolen information, and is simply using it as a means to gain press coverage of its grievances against the FBI. The promise not to leak the addresses of the agents’ families is probably appreciated by the agents themselves, but is 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 country-level assignment of Google Domains for the “gh” (Ghana), “sl” (Sierra Leone), and “als” (American Samoa) top-level domains, the attackers were able to bypass automated domain owner checks to obtain SSL certificates.
To be usable, an attacker must be able to intercept and redirect traffic between a user and the compromised domain, and the user must attempt to connect to Google domains in that country’s TLD in the first place. The attack may have been targeted against specific countries, or is simply an opportunistic attempt to gather credentials. It is possible to use the certificates on malicious WiFi networks to try to capture user sessions from other Google domains and services.
Google has already implemented filters for those specific certificates in Chrome, but those fixes don’t help other browsers or services, and Google says it may not have identified all the compromised domains. Google also warns that the domains of other companies have also been compromised, and that these companies must take independent measures to protect their users, but the affected companies were not made available.
Hacking Lawnmowers
Researchers have found a series of vulnerabilities in the Mammmotion robotic lawnmower platform. After spending “several days on the Mammotion cloud”, they demonstrated a takeover of the administrator account and a full dump of all 337,000 customers, and for the cherry on top, unauthenticated access to the first-person mode on Mower. In case you wanted to help someone clean the lawn or just go for a drive around the neighborhood.
Having previously found security issues in Mammmotion products that were not, to put it delicately, fixed according to the current standards of security patching in the industry, the company was on the radar. In addition to discovering that there was no rate limit on brute-forcing account recovery and changing each user’s password, the team also found that factory systems lacked authentication at all, hard-coded authentication tokens were baked into the firmware, and it may be possible to add each customer’s mower to each account.
After repeated attempts by the team to get the company to establish security contacts and respond to the vulnerability reports, it seems that the problems that can be tested remotely 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 should not handle security reports as a company.