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

71–80 of 147 posts

Re: Try to make sudo less vulnerable to Rowhammer attacks

#71

Post by xgk »

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.

Have you ever seen any even moderately detailed specification of what the DRAM manufacturers do in this regard? I have not, and I looked. I am deeply sceptical ....

I don't believe that Rowhammer mitigations happen inside the DRAM chips themselves, I think that they are being put into the memory controller that talks to DRAM. Since DRAMs with built-in Rowhammer defences would have to spend transistors on this defence, those transistors would be 'wasted' in situations where Rowhammer is not part of the attacker model.

Re: Try to make sudo less vulnerable to Rowhammer attacks

#72

Post by xgk »

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.

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...

Re: Try to make sudo less vulnerable to Rowhammer attacks

#73

Post by wongarsu »

pid1wow wrote: post #69

Given that the most common use of sudo is to give yourself root to run a command, and malware looking to elevate root can just rig up ~/.bashrc, what use is this patch? What use cases does it apply to and how common are they?

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 favor. There is an argument that most of us could use a vastly simpler tool instead to reduce the attack surface. But that tool wouldn't be sudo, because sudo is built around supporting all these use cases.

Re: Try to make sudo less vulnerable to Rowhammer attacks

#74

Post by xgk »

defrost wrote: post #7

This wikipedia article must surely be inaccurate: https://en.wikipedia.org/wiki/Row_hammer The initial research into the row hammer effect, published in June 2014, described the nature of disturbance errors and indicated the potential for constructing an attack, but did not provide any examples of a working security exploit. [1] [1] (June 24, 2014). "Flipping Bits in Memory Without Accessing Them: An Experimental Stu…

The possibility of flipping bits in DRAM in a Rowhammer like fashion, was known in the DRAM industry since at least the 1990s (sorry, no reference handy), and Rowhammer-like access was used in DRAM quality testing.

As silicon density increased, the issue became more urgent.

Re: Try to make sudo less vulnerable to Rowhammer attacks

#75

Post by forty »

charcircuit wrote: post #70
SkyMarshal wrote: post #65

Does anyone have any opinions on doas vs sudo? I've heard doas recommended as being more minimalistic, and various advantages that brings. What are the pros and cons between the two?

My opinion is to have neither. Requiring users to switch to an account that has different privileges is evidence of poor design of the operating system. Having a root user who has full privileges over the entire system is also poor design as it is the opposite of the principle of least privilege. If a user has the privilege to do something they should be able to do it with their normal account.

I'm happy that my mistakenly typed rm -rf / fail when I use my non root user (normal account) even though I also have root for when I do want to mess things up.

Re: Try to make sudo less vulnerable to Rowhammer attacks

#76

Post by thulle »

kazinator wrote: post #61

Someone in a comment suggested ... > gcc -DRND1=0x$(openssl rand -hex 4) ... That would cause grief to reproducible distro initiatives. It is perfectly good enough for the error code enumeration to be statically randomized into hard coded constants. The attacker is very unlikely to flip every single bit of one valid value so that it resembles another valid value. Even if the values were randomized at compile time, if…

> It is perfectly good enough for the error code enumeration to be statically randomized into hard coded constants.

A comment points out that they aren't randomized:

> 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.

Re: Try to make sudo less vulnerable to Rowhammer attacks

#77

Post by tlb »

xgk wrote: post #71
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.

Have you ever seen any even moderately detailed specification of what the DRAM manufacturers do in this regard? I have not, and I looked. I am deeply sceptical .... I don't believe that Rowhammer mitigations happen inside the DRAM chips themselves, I think that they are being put into the memory controller that talks to DRAM. Since DRAMs with built-in Rowhammer defences would have to spend transistors on this defence…

It makes sense to put it in the DRAM controller for many reasons. One is that the DRAM silicon process is optimized for memory but terrible for logic. Also, a DRAM bank is several chips in parallel to get the data bus width, and they would all have to duplicate the logic.

The disadvantage is that the controller and memory are made by different companies, so standards are required to agree on what access patterns are acceptable.

Re: Try to make sudo less vulnerable to Rowhammer attacks

#78

Post by wongarsu »

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…

I remember someone making a rust library for hardened bools, though with the idea of protecting against protecting against random bitflips, not targeted rowhammer attacks (though it should work about the same).

The feedback from the rust subreddit was basically protecting the bool but not the if statement is of limited use. Potentially it can even make it worse, since there is now more code being executed that might become bitflipped.

That inspired me to make a crate that periodically checksums your program code while it's running, to make sure it hasn't changed. Got it working on Windows and Linux, but then it ended up like most side projects. Maybe I should polish it up and publish it.

Re: Try to make sudo less vulnerable to Rowhammer attacks

#79

Post by wongarsu »

nuccy wrote: post #58
dist-epoch wrote: post #49

Earlier quoted context omitted.

This is for local sudo privilege escalation. If the attacker is already running code on your system, you kind of lost anyway.

Not really. An example out of top of my head, where this still might be useful are login nodes (used in many research clusters to allow users to enter and sumbit jobs) or shared web-hosting servers (few of those definitely still exist). There legitimate non-privileged users can run their programs and the end goal is to prevent them from getting root.

The last time I looked at the statistics the majority of the internet was still running on PHP, mostly wordpress installs. I'm willing to bet those are mostly on shared hosting with accounts separated by nothing but their linux user.

Re: Try to make sudo less vulnerable to Rowhammer attacks

#80

Post by bpye »

wongarsu wrote: post #73
pid1wow wrote: post #69

Given that the most common use of sudo is to give yourself root to run a command, and malware looking to elevate root can just rig up ~/.bashrc, what use is this patch? What use cases does it apply to and how common are they?

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

Post reply on HN