[HN Gopher] Hot Pixel' Attack Steals Data from Apple, Intel, Nvi...
___________________________________________________________________
Hot Pixel' Attack Steals Data from Apple, Intel, Nvidia, and AMD
Chips
Author : uguuo_o
Score : 73 points
Date : 2023-05-27 13:41 UTC (9 hours ago)
(HTM) web link (www.tomshardware.com)
(TXT) w3m dump (www.tomshardware.com)
| vrtnis wrote:
| 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?
| ngneer wrote:
| 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?".
| slashdev wrote:
| > 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.
| cumshitpiss wrote:
| [dead]
| formerly_proven wrote:
| > Also this requires access to system temperatures and other
| metrics that are absolutely not available from JavaScript.
|
| The Chrome developers at Google are preparing a WebHWiNFO
| proposal as we speak.
| jwilk wrote:
| You reminded me of this: https://twitter.com/twowordhorror
| Xeoncross wrote:
| > 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.
| kwantam wrote:
| 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.
| slashdev wrote:
| 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.
| ngneer wrote:
| 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.
| SideQuark wrote:
| 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.
| alain94040 wrote:
| 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.
| jmclnx wrote:
| >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.
|
| https://tildegit.org/solene/obsdfreqd
|
| edit: grammer
___________________________________________________________________
(page generated 2023-05-27 23:01 UTC)