Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Try to make sudo less vulnerable to Rowhammer attacks

github.com

Post reply on HN
Print view View original

121–130 of 147 posts

Re: Try to make sudo less vulnerable to Rowhammer attacks

#121

Post by IshKebab »

randomdata wrote: post #51
IshKebab wrote: post #21

Earlier quoted context omitted.

I don't think there are going to be a large number of inexperienced Rust programmers. Inexperienced programmers write Javascript or Python, not Rust.

Yet the vocal majority of Rust users present themselves as being inexperienced programmers. I expect it is not just an act – that the vocal majority truly are inexperienced, and I expect the segment of users who are novices is much larger than you suggest. The fact of the matter is that the novices have always been drawn to the 'hot new technology' and it is unlikely that Rust, being today's 'hot new technology', is…

> the vocal majority of Rust users present themselves as being inexperienced programmers

No they don't.

Re: Try to make sudo less vulnerable to Rowhammer attacks

#122

Post by junon »

notpushkin wrote: post #94
ufo wrote: post #87

Earlier quoted context omitted.

I'm slightly bothered that the numbers don't have the same number of digits. The rows are not perfectly aligned!

I'm also wondering why the bits are alternated in the numbers. Why can't we just set AUTH_SUCCESS to 0xffffffff and all the denied / error states to mostly-zeros?

Because you don't want to have the wrong error code even if it's a failure code.

Thus you have to figure out how to otherwise handle an enum whereby you can be reasonably assured of its value even with a flipped bit, hence the hamming distance.

Re: Try to make sudo less vulnerable to Rowhammer attacks

#123

Post by junon »

lifthrasiir wrote: post #113
jareklupinski wrote: post #23

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 :)

I'm not sure how those values are derived. Yes, the Hamming distances between them should be maximized, but the current values don't seem to be optimized for that: 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 Sure, AUTH_SUCCESS and AUTH_FAILURE have a Hamming distance of 28, but it takes only 11 or 16 b…

> By the way, finding a binary code with maximal Hamming distance is an open problem [1] [2].

This was my next question. It'd be great if there was an algorithm for finding N codes as close to equidistant as possible.

Re: Try to make sudo less vulnerable to Rowhammer attacks

#124

Post by dist-epoch »

PrimeMcFly wrote: post #90
dist-epoch wrote: post #81

Earlier quoted context omitted.

For example 7zip decompression CRC failures that resolve on a second try. It would be longer to explain how, but I tracked it multiple times to a single bit flip in the decompressed output.

Thanks, that's pretty interesting. I'd actually be really interested if you would care to explain how, I think others would find it interesting also. I'm not even sure how I would approach trying to do that.

Typically decompressing software deletes the output file if there is a CRC error.

But I use 7zip as a library, so if I get a CRC error I still have the output. Which in my case is JSON files. By careful diffing and going over them I could identify single bit flips like '{"base": 10}' being decompressed to '{"bbse": 10}'. I made this example up, letter 'a' becoming 'b' might be a multi-bit flip, but you get the idea.

Re: Try to make sudo less vulnerable to Rowhammer attacks

#125

Post by dist-epoch »

TillE wrote: post #88
dist-epoch wrote: post #81

Earlier quoted context omitted.

For example 7zip decompression CRC failures that resolve on a second try. It would be longer to explain how, but I tracked it multiple times to a single bit flip in the decompressed output.

I've also seen that, often enough that a hardware issue is extraordinarily unlikely. It's almost certainly just a boring old software bug.

Popular compressors like 7zip are some of the best tested software on the planet, because corruption is immediately detected.

And we know hardware bugs are real, that's the whole point of rowhammer.

You might want to look at Facebook research:

> “Silent data corruptions are not limited to rare one in a million occurrences within a large-scale infrastructure. These errors are systemic and are not as well understood as the other failure modes like Machine Check Exceptions.” A large part of the responsibility should be shared by device makers, Facebook says.

https://www.nextplatform.com/2021/03/01/facebook-architects-...

Re: Try to make sudo less vulnerable to Rowhammer attacks

#126

Post by [deleted] »

lifthrasiir wrote: post #113
jareklupinski wrote: post #23

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 :)

I'm not sure how those values are derived. Yes, the Hamming distances between them should be maximized, but the current values don't seem to be optimized for that: 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 Sure, AUTH_SUCCESS and AUTH_FAILURE have a Hamming distance of 28, but it takes only 11 or 16 b…

[deleted]

Re: Try to make sudo less vulnerable to Rowhammer attacks

#127

Post by xgk »

userbinator wrote: post #112

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…

This is misleading.

I recommend [1] as an introduction to the semiconductor physics behind the Rowhammer problem. Rowhammer is an instance of the "weird machine" problem behind many security problems, i.e. a mismatch between two abstractions: the abstraction we pretend describes the system, vs the reality of the system. In the case of Rowhammer, that is the abstraction of memory as a digital device, against the reality of storing bits with capacitors and wires, ie. analog devices. Clearly a leaky abstraction. The denser you pack those capacitors and wires, the more leaky.

[1] A. J. Walker, S. Lee, D. Beery, On DRAM Rowhammer and the Physics of Insecurity. https://ieeexplore.ieee.org/document/9366976

Re: Try to make sudo less vulnerable to Rowhammer attacks

#128

Post by oasisaimlessly »

bogantech wrote: post #119
userbinator wrote: post #112

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…

> Rowhammer is a hardware problem ---- defective RAM --- not a software one. 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"

> there's various ways to try to mitigate it but the only way to completely avoid it would probably be to use SRAM

Why wouldn't storing a cryptographically-secure checksum on every RAM row work?

Re: Try to make sudo less vulnerable to Rowhammer attacks

#129

Post by oasisaimlessly »

dist-epoch wrote: post #48

Even without an explicit attack, today's memory is pretty fragile, I'm regularly seeing bit flips.

I've seen bitflips on overclocked systems. Some ram is overclocked out-of-the-box; try disabling BIOS features like "XMP" (Intel Extreme Memory Profiles). Always use MemTest86 or similar to make sure your hardware is good when building a new system or changing BIOS settings.

Re: Try to make sudo less vulnerable to Rowhammer attacks

#130

Post by theamk »

xgk wrote: post #127
userbinator wrote: post #112

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…

This is misleading. I recommend [1] as an introduction to the semiconductor physics behind the Rowhammer problem. Rowhammer is an instance of the "weird machine" problem behind many security problems, i.e. a mismatch between two abstractions: the abstraction we pretend describes the system, vs the reality of the system. In the case of Rowhammer, that is the abstraction of memory as a digital device, against the reali…

I think it's important to differentiate "a mismatch between two abstractions" and "hardware bug". Because you can frame any sort of hardware (or even software!) problem like this:

"Capacitor plague of 2000 was a mismatch between two abstractions: the abstraction that capacitor actually provides datasheet-described amount of capacitance vs the reality of the system"

"Toyota unintended acceleration was a mismatch between two abstractions: the abstraction that ECU properly responds to accelerator pedal release vs the reality of the system"

Yes, digital systems are made of analog parts, but that's not a reason to accept systems behaving out of spec. For the last 50 years, the specifications for RAM have been pretty clear: as long as all datasheet requirements are obeyed, the only way to change stored data in one location should be to do a write to that location. If a memory chip does not act according to its own datasheet, it's not a "leaky abstraction", it's a hardware bug.

(Now, can this be fixed economically? I don't know, I could believe the answer is "no". However, the solution in this case is not software workarounds, but rather to make a new spec: "RH-RAM is like regular RAM but cannot tolerate certain access pattern")

Post reply on HN