111–120 of 147 posts
This is such a crazy hack to get some protection around key variables - by requiring 32-bit manipulation.
Why isn’t this just “done” on the phy layer, or somehow detected automatically in-flight? Does the compiler protect against it? At what performance penalty?
It’s really much nicer just not thinking too much about it and going on believing our bits.
Do not want.
Rowhammer is a hardware problem ---- defective RAM --- not a software one.
The sooner everyone starts returning defective RAM and putting pressure on the hardware manufacturers to maintain correctness, the sooner we can stop this descent into insanity.
"They can always work around it in software" is the attitude that let Rowhammer exist, and continuing to fulfill that expectation will only make things worse.
i enjoyed this part: #define AUTH_SUCCESS 0x52a2925 /\* 0101001010100010100100100101 */ #define AUTH_FAILURE 0xad5d6da /* 1010110101011101011011011010 */ #define AUTH_INTR 0x69d61fc8 /* 1101001110101100001111111001000 */ #define AUTH_ERROR 0x1629e037 /* 0010110001010011110000000110111 */ #define AUTH_NONINTERACTIVE 0x1fc8d3ac /* 11111110010001101001110101100 \*/ going to see how i can work this into a project :)
SUCC FAIL INTR ERR NONI
0 28 20 11 16 AUTH_SUCCESS
28 0 12 19 14 AUTH_FAILURE
20 12 0 31 16 AUTH_INTR
11 19 31 0 15 AUTH_ERROR
16 14 16 15 0 AUTH_NONINTERACTIVE
A quick Python search was able to find some alternatives:
0x0f7b74c5 0x810d2b99 0x63a64616 0xcab4a865 0xbe705abb
...maximizes all distances (17--19)
0x28d803a4 0x352ef6d3 0xdb61dce1 0xb3edf85c 0xe62f7508
...maximizes a distance from the first and others (21--22), disregarding other pairs (14--21)
By the way, finding a binary code with maximal Hamming distance is an open problem [1] [2].
[1] https://www.win.tue.nl/%7Eaeb/codes/binary-1.html
[2] https://math.stackexchange.com/questions/4288902/generation-...
I don't understand, isn't this pointless? I could just change some other data structure or variable, hell, I'll just change the sudo input buffer size and do a stack overflow, or a memcpy size into a heap overflow, or what stops me changing a jne (Jump if Not Equal) instruction to a jg (Jump if Greater) and bypassing the if's?
Earlier quoted context omitted.
RowHammer is not a thing of the past. In fact, modern DRAM chips are significantly more susceptible to RowHammer due to their increased chip density [1]. [1] https://arxiv.org/abs/2005.13121
Thanks for the link. I guess I thought wrong. But I have more questions. > with RowHammer protection mechanisms disabled I wonder what this means. Is it S/W mitigations or does it include H/W factors like disabling on-die ECC. It makes sense to me that with all other things being equal that higher density would lead to more susceptibility to Rowhammer. But as always, other things are not equal. I expect that on-die E…
I don't understand, isn't this pointless? I could just change some other data structure or variable, hell, I'll just change the sudo input buffer size and do a stack overflow, or a memcpy size into a heap overflow, or what stops me changing a jne (Jump if Not Equal) instruction to a jg (Jump if Greater) and bypassing the if's?
I'd argue its worse than pointless, at best it does nothing and at worse it seems to make the code harder to understand and audit, which could result in more future vulnerabilities.
Preventing known attacks is not pointless at all.
Earlier quoted context omitted.
>and malware looking to elevate root can just rig up ~/.bashrc, what use is this patch? Apologies for self promotion, but I wrote a relevant blog post that discusses this[0]. Is there any way of mitigating this trivial attack? I feel like the Unix/Linux security model is broken. [0]: https://cedwards.xyz/sudo-is-broken/
I’m not following your logic. How does the malicious-but-unprivileged user have write access to anywhere in the sysadmin’s PATH?
No. Do not want. Rowhammer is a hardware problem ---- defective RAM --- not a software one. The sooner everyone starts returning defective RAM and putting pressure on the hardware manufacturers to maintain correctness, the sooner we can stop this descent into insanity. "They can always work around it in software" is the attitude that let Rowhammer exist, and continuing to fulfill that expectation will only make thing…
No. Do not want. Rowhammer is a hardware problem ---- defective RAM --- not a software one. The sooner everyone starts returning defective RAM and putting pressure on the hardware manufacturers to maintain correctness, the sooner we can stop this descent into insanity. "They can always work around it in software" is the attitude that let Rowhammer exist, and continuing to fulfill that expectation will only make thing…
It always amazes me how people can be so confident yet so wrong.
It's a problem of physics - there's various ways to try to mitigate it but the only way to completely avoid it would probably be to use SRAM and that is going to be extremely expensive when talking 16GB and not nearly dense enough.
It's not some conspiracy by "Big RAM"
Earlier quoted context omitted.
Hardbool lets you use custom true and false representations with higher hamming distances. The sudo patch uses custom representations for their enum that have higher hamming distances. The only difference is that hardbool is for true/false and this patch is for AUTH_SUCCESS/AUTH_FAILURE/AUTH_ERROR etc. But that's irrelevant. It's the exact same technique.
> The only difference is that hardbool is for true/false and this patch is for AUTH_SUCCESS/AUTH_FAILURE/AUTH_ERROR etc. But that's irrelevant. It's very relevant! The problematic comparison in this code isn't true/false! A feature that only protects true/false does not help here.