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

101–110 of 147 posts

Re: Try to make sudo less vulnerable to Rowhammer attacks

#101

Post by defrost »

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

That matches my recollection- I started in broad STEM at university in the 1980s and as chip sizes were pushed smaller and denser there was always thought given to signal bleed | harmonics from too many lines too close together.

I suspect "observed in fabrication lab | not disclosed" dates back some years before the paper .. once observed there's always a path to exploitation - but why would anyone broadcast that?

By the time it was chit chat on IRC the general feeling was that some TLA has a working exploit. (obviously unpublished).

Re: Try to make sudo less vulnerable to Rowhammer attacks

#103

Post by defrost »

rcthompson wrote: post #8
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…

Well, that quote from Wikipedia says the published paper didn't include a working exploit. That might be true even if a working exploit was available after the paper was written and submitted but before it was published. (I don't know if this is the case here, but this sort of thing is common in scientific publishing.)

To clarify:

    Mind you, lots of things get kicked about and implemented before actual papers appear on them for the first time in public.
I was thinking of many examples I know where a technique is developed and used in industry (mineral exploration | remote imaging | secret spook stuff) and much later (five years or more) gets a first mention in acedemia .. where they may or may not get a robust working version happening .. just a rickety proof of concept.

Re: Try to make sudo less vulnerable to Rowhammer attacks

#104

Post by KerrAvon »

cedws wrote: post #86
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?

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

Re: Try to make sudo less vulnerable to Rowhammer attacks

#105

Post by _3u10 »

dist-epoch wrote: post #49
TacticalCoder wrote: post #43

Earlier quoted context omitted.

> I enjoyed this part Very nice indeed. Such a simple mitigation and it makes evil people sad, which makes me happy.

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

Most of the cloud works this way unless you are using bare metal / largest size instances.

Re: Try to make sudo less vulnerable to Rowhammer attacks

#106

Post by idatum »

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

doas.conf makes things clear to me what I'm enabling.

And we have the OpenBSD folks focused on clarity and security.

Re: Try to make sudo less vulnerable to Rowhammer attacks

#107

Post by kelnos »

jareklupinski wrote: post #83
trebligdivad wrote: post #24

Earlier quoted context omitted.

That's the section that made me post this snippet; crazy isn't it?!

can't edit original post, but i just realized after lining up the monospace how #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 *…

It sorta is, but isn't actually, sadly. I mean, if they were 28-bit values, they'd be binary complements, but they're actually 32-bit values, so they're really:

  #define AUTH_SUCCESS        0x052a2925  /* 00000101001010100010100100100101    */
  #define AUTH_FAILURE        0x0ad5d6da  /* 00001010110101011101011011011010    */
Doing a '!' operation in C on one of them won't yield the other value unless you also zero out the top 4 bits. Close enough, though... I still enjoy the symmetry as you did.

Anyway, I'm curious why three of the values they chose have all zeroes for the top 4 bits. I wonder if there's a security-related reason for that.

Re: Try to make sudo less vulnerable to Rowhammer attacks

#108

Post by zaroth »

jareklupinski wrote: post #83
trebligdivad wrote: post #24

Earlier quoted context omitted.

That's the section that made me post this snippet; crazy isn't it?!

can't edit original post, but i just realized after lining up the monospace how #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 *…

I think the theory is that means the most number of bits need to be flipped.

Because rowhammer is attacking the physical memory structure, it can’t function at the level that knows what AUTH_SUCCESS is.

This attack just targets raw bits, so we need to protect these crucial state variables from bit-flips.

Re: Try to make sudo less vulnerable to Rowhammer attacks

#109

Post by deadliftdouche »

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?

Re: Try to make sudo less vulnerable to Rowhammer attacks

#110

Post by deadliftdouche »

deadliftdouche wrote: post #109

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.
Post reply on HN