Schneier on Security

Clive Robinson • September 23, 2025 1:29 PM

@ ALL,

There is a fly in the ointment to this high five clapping party.

As Apple says in,

https://security.apple.com/blog/memory-integrity-enforcement/

“Consider that MTE can be configured to report memory corruption either synchronously or asynchronously. In the latter mode, memory corruption doesn’t immediately raise an exception, leaving a race window open for attackers.”

Consider the above statement carefully.

Rewritten it says that,

“Asynchronous writes to memory cells leave race conditions open that are vulnerabilities.”

That is the question arises as to,

“Can asynchronous memory cell changes be prevented?”

With all memory cell technology currently the answer to this is “unavoidably true”. Because the changes in the cell are not caught/flaged externally when the memory cell change happens.

Put simply the change is hidden behind the multiplexer on the memory cell output, that hides/selects the cell from the appropriate memory bus pin.

We know that RowHammer style attacks work against memory cells that are not selected.

This issue was known about back in the 1970’s and earlier when looking at Error Correction and Detection for memory that would be used in high radiation environments.

Now a second question arises.

“If an asynchronous memory cell write is a “race condition vulnerability” for one memory cell, can it be a vulnerability for two or more memory cells in the same race condition time frame?

To which the answer is obviously “Yes”.

So consider the “tagging mechanism” at the end of the day it is going to be one or more additional memory cells.

So another question arises,

“If you can change a memory cell in a variable location asynchronously, can you in the same time period of the race condition change one or more memory cells in the tag location, so that it changes in a way that the variable location change is not flagged at the end of the race condition time period?”

The answer is “Yes”.

The only remaining question is,

“How difficult would it be for an attacker to do this?”

And the answer ranges across a very wide span dependent upon many things.

The problem is it remains “possible”.

If people are honest about it they will confirm we knew back before our host @Bruce was born that memory could be changed asynchronously and thus undetectably. We also later knew that in DRAM adjacent rows of memory cells could effect each other when densely packed causing asynchronous changes.

Assumptions were made about the efficacy of “Error Correcting Codes”(ECC) and the difficulty of changing adjacent row bits. The result was it was assumed that it was a “non-issue”… Then RowHammer happened and suddenly it was a “proven exploitable issue”.

Just something to remember,

“Sometimes the assumed impossible can be not just possible, but undetectably so…”

AND don’t make the mistake of thinking Apple’s Research people do not know this…

They do, and are deliberately avoiding talking about it…

You will see this if you read the entire document. Because you will find they “qualify” all of their claims to above the “ALU Level” in the “computing stack” and quite a bit above the “CPU Level” for others.

Memory cell attacks by power supply disruption, EM Fault injection, and other similar low down the stack attacks are way way below Apple’s protections in the Computing Stack.

Apple “are assuming” they can isolate the low level part of the computing stack at the CPU level.

Well there are such things as “Reach Around Attacks” and I talked about them a few years back with “Castles-v-Prisons” and when RowHammer proved them for all who could read and assimilate.

Put simply by “rattling the memory” RowHammer caused DRAM power supply and other common bus electrical noise deep inside the computer, that kind of acted like a “Brown Out” does in your home where the lights flicker etc. Mostly they go by without issue but when done actively it can cause electronic and electrical items to “soft fail” or worse “hard fail”. The same happens with RowHammer to the memory chips in your device.

You can do this “rattling” like quite a few other “reach around attacks” from way up the computing stack as it can be done via web pages.

Active EM attacks can be done from so far up the computing stack they are performed from quite a distance outside your device…

So just be prepared for these in the next decade or so.

If of course OS level “Client Side Scanning” via AI does not do it way more easily.

You did know that Apple have put not just “client side scanning” in their OS, but a BlueTooth low energy mesh network by which it can “ET Phone Home”?

Clive Robinson • September 23, 2025 4:39 PM

@ Anonymous Coward,

I would not really use the example of,

“password protect every memory allocation in hardware”

The tag is the unused upper 4bits in a byre pointer address due to it pointing at a 64bit word.

So there can only be 16 tag values so hardly “passwords” and ordinarily considered “no where near secure” for anything with only 16 values (think having a 1digit PIN for your bank card)…

Due to the way gate level circuits are implemented to keep real estate abd power consumption down whilst keeping speed up such tag hardware in the past has been more like a multibit parity check. That is four bits for every memory word XORed.

So in effect it’s more like a “stream cipher”… That is a pseudo random key is generated and used to encrypt a hash of the value.

If that top nibble of the word used as an address pointer matches then it’s assumed to be valid.

If the “pointer” being used does not match then the memory bus level hardware below the CPU level in the computing stack throws an exception.

Thus if as is oft the case with malware attacks, if you as an attacker offset the pointer or overwrite it in some way, then your chance of having a valid tag is low. Thus a hardware exception hits and the program gets halted.

Clive Robinson • September 25, 2025 6:57 PM

@ wiredog, Mexaly

With regards,

“The security people where I work all have iPhones. Well, the more paranoid have cheap non-smart flip phones.”

None are “paranoid enough” and I can say that as a design engineer who used to design not just cellular and cordless phones with enhanced security, but also computing devices which likewise were more secure than standard Consumer and Commercial devices.

The little I’ve seen of Apple’s phone design really does not impress me at all security wise.

The point I made about “secure message Apps” being not secure in a system, applies to all current mobile phone and smart devices.

“They are designed incorrectly to give security.”

That’s because at the end of the day,

“They are designed for profit not security, because security costs real money.”

Clive Robinson • September 26, 2025 10:20 AM

@ Jonathan Wilson, ALL,

“Why has no-one implemented (either on a phone or a PC) hardware encrypted memory of the sort Microsoft has on the Xbox? (where the raw data that is stored in the DRAM is encrypted).”

Many people have tried it, and they have all failed in some way,that negates,

“That would make all the various DRAM attacks impossible.”

Encrypting a single “stream of data” once without modification is secure.

Encrypting files multiple times or with multiple changes, opens up all sorts of sometimes trivial attack vectors.

For instance the “key” does it change every time or is it locked to the memory location.

With a stream cipher or block cipher used as the equivalent you quickly and easily get the “Multiple Key Use” issue that turns the “Perfect Secrecy” of the “One Time Pad” into a cipher that can moderately easily be broken even by hand with as little as two encipher texts under the same key (ie “in depth”).