• XSS.stack #1 – первый литературный журнал от юзеров форума

M1/2 spectre, meltdown? rowhammer?

drpalpatine

(L3) cache
Пользователь
Регистрация
04.08.2021
Сообщения
260
Решения
1
Реакции
108
Гарант сделки
2
Депозит
0.0001
the cool M1/2 chips himself are top but look like apple did not eat the spectre still --> i will be very surprise if still a meltdown side channel is possible is less difficult to mitigate --> but so far there is no research inside public
such design flaws like rowhammer + meltdown--> but logic flaws like spectre are bastards that will sit for long --> cool for us)
meltdown is easy fix --> this is not a secret but with rowhammer --> if you can change physics --> you can fix him
--> some extra mitigations sit on top of ECC is good --> there are still top experimental papers --> but they are still beer talk --> not many practical results
everything for M1 is from 5nm from TSMC)) --> sad cry from amd+intel
everything is thermal cool because of less power consumption compare to amd 7mm from TSMC +intel latest chips (10mm?)

there is speculative execution --> so all the rich cool members with the cool M1/2 chips himself --> can anyone throw some spectre gadgets --> forget about meltdown
--> simple script kid cannot clone such git repo simple side channel inside x86 arch --> change intrinsics --> port spectre to arm
from my knowledge --> there is no rollback for modify to L1 or L2 in case of branch misprediction --> is that correct?
i immediately remember reading such ARM killed array bounds spectre with a new instruction for speculative barrier --> insert between array bounds test + array access himself
arstechnica.com/gadgets/2018/01/meltdown-and-spectre-heres-what-intel-apple-microsoft-others-are-doing-about-it/

my final thoughts -->
meltdown --> 90% killed
rowhammer --> if you study physics --> you can say he is still alive lurking inside DRAM to wait for the first bit flips))
--> also yellow raise such good point --> memory cell size is decrease himself
but you can ask ECC will protect my DRAM from attackers like drpalpatine? --> funny but only 60% true --> ECC rely on accuracy inside signal detection --> with decrease cell size --> SNR decreases + there is too much error rate fuck ECC inside ass for example high frequency/clusters
spectre --> 90% alive --> but i am hope that remaining 10% is true --> birth to new variants of spectre/ even new side channels himself

there is top interest but not hardware --> please who knows what? --> did anyone study speculative execution inside the apple silicon?
 
Последнее редактирование:
Пожалуйста, обратите внимание, что пользователь заблокирован
memory cell size is decrease himself
Ставлю штуку баксов - что црушные рожы Rowhammer-ом повышают права уже давно и что это вскроется в течение следующих 3-5ти лет.
I bet you a thousand bucks - that the CIA has been using Rowhammer for a long time and are escalate privs and that this will become known in the next 3-5 years.
 
from defendera perspective -->
a simple 0x0 pixel iframe with js code inside your idle tab cannot fuck your memory --> rowhammer will do him
SEC-DED --> everything is simple for 1 bit flip correction --> detection up to 2 bits but nothing he can do such corrections for >1 bit
hamming codes --> but he same cannot correct >1 bit flips + he will require more parity bits
reed solomon codes --> cool with multiple bit errors + you can even configure to error patterns --> but overhead both compute + memory
bch codes --> more cool + more overhead with such polynomial arithmetic

cache will sit between us + access physical memory repeated --> simply we flush the cache --> cflush

we can use movntdqa/movntdq --> non temporal instructions without cache data
movntdqa xmm0, [rax]

everything is simply sad from rowhammer --> if you are a special target inside NSA/CIA
 
Пожалуйста, обратите внимание, что пользователь заблокирован
Скрытый контент для пользователей: .
 
not exactly for M1/2 but interesting anyway:

https://arxiv.org/abs/2309.02545
"Mayhem: Targeted Corruption of Register and Stack Variables"
In the past decade, many vulnerabilities were discovered in microarchitectures which yielded attack vectors and motivated the study of countermeasures. Further, architectural and physical imperfections in DRAMs led to the discovery of Rowhammer attacks which give an adversary power to introduce bit flips in a victim's memory space. Numerous studies analyzed Rowhammer and proposed techniques to prevent it altogether or to mitigate its effects.
In this work, we push the boundary and show how Rowhammer can be further exploited to inject faults into stack variables and even register values in a victim's process. We achieve this by targeting the register value that is stored in the process's stack, which subsequently is flushed out into the memory, where it becomes vulnerable to Rowhammer. When the faulty value is restored into the register, it will end up used in subsequent iterations. The register value can be stored in the stack via latent function calls in the source or by actively triggering signal handlers. We demonstrate the power of the findings by applying the techniques to bypass SUDO and SSH authentication. We further outline how MySQL and other cryptographic libraries can be targeted with the new attack vector. There are a number of challenges this work overcomes with extensive experimentation before coming together to yield an end-to-end attack on an OpenSSL digital signature: achieving co-location with stack and register variables, with synchronization provided via a blocking window. We show that stack and registers are no longer safe from the Rowhammer attack.

...

stack/register variables can be flipped via fault injection, affecting execution flow in security-sensitive code. There are mitigation strategies you may be interested in incorporating into your code:

Take this vulnerable code, for example:

int auth = 0;
// password check code that sets auth variable
if (auth != 0)
return AUTH_SUCCESS;
else
return AUTH_FAILURE;

The idea is that any bit can be flipped in auth, and it will result in a mis-authentication. We prove this is a potential vulnerability in OpenSSH, OpenSSL, MySQL, and SUDO. To mitigate this, it is important to have tight logic such that a single-bit flip will not result in unintended execution. For example:

int auth = 0xbe405d1a;
// password check code that sets auth variable to 0x23ab9701 is successful
If (auth == 0x23ab9701)
return AUTH_SUCCESS;
else
return AUTH_FAILURE;


In this case, the auth variable must be corrupted into the exact authentication pattern, which is fairly improbable.

I think I'll start to use this in my code.
 


Напишите ответ...
  • Вставить:
Прикрепить файлы
Верх