> By forcing one of the three variables of DVFS (heat, power, or frequency) to become a constant, the researchers can then monitor the other two variables to distinguish which instructions are being executed, even with enough precision to ascertain the different operands of the same instruction.
Sounds like one of those attacks that works in theory but is too impractical to use in real life. This is harder than cache side channel attacks, and we still haven’t seen much use of those in the wild, years later.
> Ultimately, this furthers other attacks, like website fingerprinting.
Umm no. Did ChatGPT write that? Fingerprinting isn’t an attack and that’s not how it works. Also this requires access to system temperatures and other metrics that are absolutely not available from JavaScript.
The paper, which is linked from the article, demonstrates a browser "fingerprinting" attack, which is to say, stealing pixels from one iframe using another iframe (which is quite clearly a violation of the safety properties the browser is supposed to provide).
It's unfortunate that this article is poor, but the paper itself is clear and readable.
Why do they call that browser fingerprinting? That’s a clearly a violation of browser isolation policies, but I don’t see the connection to fingerprinting. Also there are much easier ways to do actual fingerprinting. That involves finding a large number of statistically unique things and combining them to identify repeat visits from a particular device without cookies or local storage.
I think it is less about a server fingerprinting a client and more about one website using broken browser isolation to fingerprint other websites being visited. In the example, they leak whether a pixel is black or white by scaling it to fit the full canvas and then triggering 200-400 renders.
Different browsers will leak different data from this (and subsequent)
methods. And so what if there are some easier things one can gather; fingerprinting relies on gathering many things. You claim it needs a "large number of statistically unique" items, which is wrong. One statistically unique item is enough, but that's hard.
What is actually used is enough (not large, not small, not one usually... just enough) items with some spread in statistics such that one gathers enough such things so they can conclude to some level of certainty the device is uniquely determined.
Thus any new piece of data that provides any amount of device discrimination is useful. This new method fits the bill. And it will open the door to much more advanced attacks, as all new attacks do.
Having done both fingerprinting and anti- fingerprinting tech for DoD work I'm quite confident I know what I'm talking about.
Easier ways, i.e., more well known, are also more commonly spoofed, blocked, faked, or mitigated by all major intelligence agencies and large sections of industry. New methods are always welcome, and they too will eventually become less useful as mitigations and defenses are developed. It's an arms race, and you're happy to throw rocks at people in T-shirts when professionals have moved on to more sophisticated weapons and armor.
>The attack requires data from the PC's internal power, temp, and frequency sensors, but this information can be accessed from user accounts that don't have administrator access
Looks like only a local user can do this, but the article is not to clear on that.
Anyway this seems very hard to do. Also I wonder if using OpenBSD's port obsdfreqd can prevent this. Based upon usage, it will adjust the frequency and CPU Temp on the fly.
This highlights subtly different thinking processes in the security industry. Real world adversaries think "this is an interesting asset, how can we get to it, with our available primitives?" whereas academic researchers think "this is an interesting primitive, what kind of assets would make the paper work?".
I found the paper didn't live up to its claims. It said:
the ever-changing behavior of these SoCs is also visible via internal measurement sensors, allowing us to distinguish between executed instructions, and even different operands of the same instruction
But when you read further and see what they tried:
We then selected one Arm instruction from each data-processing bucket,testingstores(str),AESinstructions(aese, aesmc), rotate right (ror), bitwise and (and), and both integer and floating-point addition (add, fadd) and multiplication (mul, fmul). We run each instruction in a loop on all available P-cores on each test device
What they did is define a handful of known workloads, with very different power profiles. And then they find that they can tell them apart by looking at the power of the chip. Well, duh.
Table 19 from the paper seems to show pixel extraction accuracy is highest for AMD Radeon (94%) but lower for M1/M2 (~60%). Can't seem to find an explanation for this variation though. Thoughts?
The article mentions 0.1 bit per second, but cpu's are handling mb's in seconds, so is this actually sufficient, even at 1 bit per second, to gain any useful insight from the system?
17 comments
[ 1.0 ms ] story [ 60.1 ms ] threadSounds like one of those attacks that works in theory but is too impractical to use in real life. This is harder than cache side channel attacks, and we still haven’t seen much use of those in the wild, years later.
> Ultimately, this furthers other attacks, like website fingerprinting.
Umm no. Did ChatGPT write that? Fingerprinting isn’t an attack and that’s not how it works. Also this requires access to system temperatures and other metrics that are absolutely not available from JavaScript.
No problem, just use a zero-day to get full system access and then you can read the temps and send them back to JavaScript.
It's unfortunate that this article is poor, but the paper itself is clear and readable.
What is actually used is enough (not large, not small, not one usually... just enough) items with some spread in statistics such that one gathers enough such things so they can conclude to some level of certainty the device is uniquely determined.
Thus any new piece of data that provides any amount of device discrimination is useful. This new method fits the bill. And it will open the door to much more advanced attacks, as all new attacks do.
Easier ways, i.e., more well known, are also more commonly spoofed, blocked, faked, or mitigated by all major intelligence agencies and large sections of industry. New methods are always welcome, and they too will eventually become less useful as mitigations and defenses are developed. It's an arms race, and you're happy to throw rocks at people in T-shirts when professionals have moved on to more sophisticated weapons and armor.
Feel free to address the content of the message once you have actual facts. To help you get some I'd recommend reading a few recent papers from https://scholar.google.com/scholar?hl=en&as_sdt=0%2C15&q=bro...
The Chrome developers at Google are preparing a WebHWiNFO proposal as we speak.
Looks like only a local user can do this, but the article is not to clear on that.
Anyway this seems very hard to do. Also I wonder if using OpenBSD's port obsdfreqd can prevent this. Based upon usage, it will adjust the frequency and CPU Temp on the fly.
https://tildegit.org/solene/obsdfreqd
edit: grammer
But when you read further and see what they tried:
We then selected one Arm instruction from each data-processing bucket,testingstores(str),AESinstructions(aese, aesmc), rotate right (ror), bitwise and (and), and both integer and floating-point addition (add, fadd) and multiplication (mul, fmul). We run each instruction in a loop on all available P-cores on each test device
What they did is define a handful of known workloads, with very different power profiles. And then they find that they can tell them apart by looking at the power of the chip. Well, duh.