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

31–40 of 147 posts

Re: Try to make sudo less vulnerable to Rowhammer attacks

#31

Post by mcculley »

rcthompson wrote: post #22
andrewaylett wrote: post #14

Earlier quoted context omitted.

It's not plausible in C, for the reasons you mention, but it might be more possible in other languages -- Rust, for example, only guarantees specific representations when instructed and doesn't allow for shared libraries without a specified representation, so it wouldn't have either issue for most application code. Dynamically-typed languages similarly should be able to choose enum values at runtime in many cases.

> Dynamically-typed languages similarly should be able to choose enum values at runtime in many cases. I wonder, is choosing random enum values at runtime more secure against Rowhammer than just having fixed values that were chosen randomly once and compiled in, since presumably the attacking code now has no way to know which bits it needs to flip? If so, it might even be desirable to implement this as a "secure enum…

From the commit: “The values used were chosen such that it takes a large number of bit flips to change from allowed to denied. Using random values doesn't really protect against this attack.”

It would be neat to see an algorithm that generates suitable values.

Re: Try to make sudo less vulnerable to Rowhammer attacks

#33

Post by addaon »

Palomides wrote: post #26
hlandau wrote: post #3

This is deeply interesting. I've sometimes contemplated the possibility of doing things like this to guard against memory errors causing mis-entry to particularly critical control flow paths - this is certainly an example of that. But never heard of anyone actually trying to do this until now. A "how to write rowhammer-resistant code" writeup would definitely be useful here - even if it is definitely something people…

it's a long-known hazard in embedded and highly reliable systems, there are terms like "single-event upset" that might lead you in interesting directions

Single event upsets are well-understood and easy (although not necessarily cheap) to mitigate in hardware -- ECC for RAM, CRCs for data in flight, and voting (or lockstep if detection is sufficeint) for computation. The challenge with Rowhammer is that it involves multiple, correlated bit flips; and depending on details of your system the correlations may be disguised by various remapping layers.

Re: Try to make sudo less vulnerable to Rowhammer attacks

#34

Post by School-Cotton »

delusional wrote: post #16
School-Cotton wrote: post #15

Earlier quoted context omitted.

Rust makes a particular class of bugs harder to write. That’s it. It doesn’t magically eliminate all bugs. “Susceptible to rowhammer” is not in the class of bugs that Rust helps with. No experienced Rust programmer actually believes it magically prevents all bugs or magically makes security-sensitive code immune to side channel attacks, so I don’t think anyone is being lulled into a false sense of security, no.

What about the Non-experienced Rust programmer? A lot of open source code are written by inexperienced people who understand the nuances of computer science primarily through hype. I think those are the kinds of people OP was asking about.

An inexperienced programmer is much more likely to make security-critical mistakes writing C or C++ than Rust anyway, even if they’re aware of the concept of undefined behavior, so I think Rust still has an advantage in this case.

You should avoid using security-critical tools written by people who don’t understand security, regardless of language.

Re: Try to make sudo less vulnerable to Rowhammer attacks

#35

Post by throwaway421967 »

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 don't get it, what's special about these numbers?

Re: Try to make sudo less vulnerable to Rowhammer attacks

#36

Post by jareklupinski »

throwaway421967 wrote: post #35
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 don't get it, what's special about these numbers?

i think their bitfields seem specifically chosen to mitigate rowhammer attacks (no repeating elements)?

Re: Try to make sudo less vulnerable to Rowhammer attacks

#37

Post by f_devd »

mcculley wrote: post #31
rcthompson wrote: post #22

Earlier quoted context omitted.

> Dynamically-typed languages similarly should be able to choose enum values at runtime in many cases. I wonder, is choosing random enum values at runtime more secure against Rowhammer than just having fixed values that were chosen randomly once and compiled in, since presumably the attacking code now has no way to know which bits it needs to flip? If so, it might even be desirable to implement this as a "secure enum…

From the commit: “The values used were chosen such that it takes a large number of bit flips to change from allowed to denied. Using random values doesn't really protect against this attack.” It would be neat to see an algorithm that generates suitable values.

The basic algorithm for the 2-enum case from the commit seems to just be `enum { A = rand(), B = ~A}`.

Although I'm not sure if it's optimal, the many case seems to be the same as the 2-case but repeated for every 2 items. I expect they double checked that the amount of bitflips is still pretty high.

Maybe a better algorithm for the many case would be something like the popcnt parallel patterns:

* 0b0101010101010101

* 0b0011001100110011

* 0b0000111100001111

* 0b0000000011111111

Since they would all have equal hamming distance between each of the entries.

Re: Try to make sudo less vulnerable to Rowhammer attacks

#38

Post by mcculley »

f_devd wrote: post #37
mcculley wrote: post #31

Earlier quoted context omitted.

From the commit: “The values used were chosen such that it takes a large number of bit flips to change from allowed to denied. Using random values doesn't really protect against this attack.” It would be neat to see an algorithm that generates suitable values.

The basic algorithm for the 2-enum case from the commit seems to just be `enum { A = rand(), B = ~A}`. Although I'm not sure if it's optimal, the many case seems to be the same as the 2-case but repeated for every 2 items. I expect they double checked that the amount of bitflips is still pretty high. Maybe a better algorithm for the many case would be something like the popcnt parallel patterns: * 0b0101010101010101…

Yeah, I was specifically wondering about n>2. Your approach seems reasonable.

Re: Try to make sudo less vulnerable to Rowhammer attacks

#39

Post by loeg »

stressinduktion wrote: post #32

Related, hardbool, it seems gcc can automatically handle this soon. https://blog.adacore.com/adacore-enhances-gcc-security-with-... and https://gcc.gnu.org/onlinedocs/gcc/Common-Type-Attributes.ht...

Not exactly; these constants in sudo are an enum of sorts (actually preprocessor macros). It's not just bool (and won't just be bool in many situations). It is cool to see GCC exploring automatic protection in this space; I just don't think it is relevant to what sudo did here.

Re: Try to make sudo less vulnerable to Rowhammer attacks

#40

Post by loeg »

rcthompson wrote: post #5

Couldn't compilers be configured to use such values for for any enum type? And maybe even auto-insert the appropriate check in the final unchecked else anywhere that enum type is otherwise exhaustively checked?

The problem with C and C++ is that enum values are explicitly incrementing, even when the user does not specify a literal value for each one. So if anything depends on a specific value (e.g., disk or network formats), this will break it. I think Rust enum values are similar, but I'm not a language expert.
Post reply on HN