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

91–100 of 147 posts

Re: Try to make sudo less vulnerable to Rowhammer attacks

#91

Post by poizan42 »

eth0up wrote: post #89

Moron disclaimer: I may not be one entirely, but I frequently emulate one. As a full-time Linux user, I haven't used sudo for years. Rather, I do 'su root'. However, I noticed several years ago (Debian) that upgrades would iterate twice, seemingly accommodating two accounts. Emulating a moron as I do, I never exerted the effort to learn why. I simply began, after 'su root', entering 'sudo su', which despite always ha…

You should use 'su - root' to get a root login shell. Otherwise you will still keep your old environment, including $HOME and $USER.

(The man page recommends using --login over the single dash, but it also says they are equivalent. Maybe I'm too much of a moron to understand the difference, but the single dash is less typing)

Re: Try to make sudo less vulnerable to Rowhammer attacks

#92

Post by [deleted] »

poizan42 wrote: post #91
eth0up wrote: post #89

Moron disclaimer: I may not be one entirely, but I frequently emulate one. As a full-time Linux user, I haven't used sudo for years. Rather, I do 'su root'. However, I noticed several years ago (Debian) that upgrades would iterate twice, seemingly accommodating two accounts. Emulating a moron as I do, I never exerted the effort to learn why. I simply began, after 'su root', entering 'sudo su', which despite always ha…

You should use 'su - root' to get a root login shell. Otherwise you will still keep your old environment, including $HOME and $USER. (The man page recommends using --login over the single dash, but it also says they are equivalent. Maybe I'm too much of a moron to understand the difference, but the single dash is less typing)

[deleted]

Re: Try to make sudo less vulnerable to Rowhammer attacks

#93

Post by Dylan16807 »

tlb wrote: post #45
HankB99 wrote: post #19

I thought that Rowhammer was a thing of the past. Out of curiosity I found code to test for this and ran it on some of my hosts. My old desktop - I7-4770K/DDR3 - was susceptible. My old server - Xeon X3460/DDR3+ECC - was not. I upgraded the desktop with components based on a Ryzen 7 7700X/DDR5. It tested not susceptible. I'm not sure if that's a result of RAM designed not to be susceptible or that (I think) DDR5 RAM…

LPDDR4 and above are supposed to have a feature to detect too many accesses to the same few rows and initiate a refresh cycle. Implementation quality may vary.

My understanding from some previous papers was that many chips put in a small hash table to count accesses, and this table could be worked around.

It's easy enough to deal with if they stop cheaping out. Each row is so wide. A 10 bit counter to trigger neighbor refreshes would barely take any space.

Re: Try to make sudo less vulnerable to Rowhammer attacks

#94

Post by notpushkin »

ufo wrote: post #87
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 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?

Re: Try to make sudo less vulnerable to Rowhammer attacks

#95

Post by foota »

loeg wrote: post #68
IshKebab wrote: post #57

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.

Couldn't you combine bools for bitwise masks to get this?

Re: Try to make sudo less vulnerable to Rowhammer attacks

#96

Post by Dylan16807 »

xgk wrote: post #72
tlb wrote: post #45

Earlier quoted context omitted.

LPDDR4 and above are supposed to have a feature to detect too many accesses to the same few rows and initiate a refresh cycle. Implementation quality may vary.

It has been possible to re-purpose such additional refresh cycles as an additional Rowhammer attack vector, see https://www.usenix.org/conference/usenixsecurity22/presentat...

So on RAM that needed 18,000 distance-1 accesses, they were able to mount an effective attack with 300,000 distance-2 accesses and 5000 distance-1 accesses.

That's not a particularly big assist, and doesn't sound hard to mitigate.

If TRR pushed the rows it refreshes 10% closer to triggering their own TRR, then those 300,000 accesses would have triggered multiple refreshes in the target row.

Re: Try to make sudo less vulnerable to Rowhammer attacks

#98

Post by themoonisachees »

throwaway421967 wrote: post #44
rsaxvc wrote: post #42

Earlier quoted context omitted.

Takes many bit flips to go from one pattern to another.

If that is the only constraint, wouldn't the goal be to be as far as possible from the only success state? the distance between success and failure is 28

Maybe, but in practice malware that makes sudo always fail is also bad. At the same time, getting 28 precise distance from row hammer is basically impossible.

Re: Try to make sudo less vulnerable to Rowhammer attacks

#99

Post by alwillis »

bpye wrote: post #80
wongarsu wrote: post #73

Earlier quoted context omitted.

Sudo has much more fine-grained abilities for more surgical use-cases, like giving users the ability to only execute certain commands as a certain user, with detailed logging and auditing. It has a pretty involved config file (the pdf docu for it is 80 pages long), a plugin system, a seperate log format and log server, etc I also believe those use-cases aren't that common anymore since multi-user systems fell out of…

doas [0, 1] in OpenBSD is somewhat simpler. [0] - https://man.openbsd.org/doas.1 [1] - https://man.openbsd.org/doas.conf.5

Switched to doas a couple of months ago on my FreeBSD box; it’s been a seamless switch.

Re: Try to make sudo less vulnerable to Rowhammer attacks

#100

Post by jmprspret »

kazinator wrote: post #64
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?

Yes; gcc and clang could, in principle, support an extension like: __attribute__((rand)) enum e { FOO, BAR, ... }; which randomizes the values, as an extension. You only need this in specific places, like setuid programs. Randomization can be bad because it wrecks build reproducibility; it would have to be tied to the GNU Build ID. If such an enum is used in any interface between files, the randomization has to be th…

A comment in the commit notes that randomisation does not necessary mitigate the issue.

Which is why only a couple of the values are random, with the others being those values, XOR'd with 0xff*

Post reply on HN