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

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.

Another common one is for example minecraft / source engine game server hosts as they commonly allow customers to install mods.

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.

Last time I looked, 70% of the internet runs on cPanel, which uses my perl compiler.

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

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   */

AUTH_FAILURE is still just !AUTH_SUCCESS (and almost a palindrome)

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.

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.

I don't get it, what's special about these numbers?

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.

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

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.

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 bit flips to go from AUTH_ERROR or AUTH_NONINTERACTIVE to AUTH_SUCCESS. (AUTH_ERROR can only happen from an internal error, so I believe AUTH_NONINTERACTIVE is easier to trigger.)

A quick Python search was able to find some alternatives:

    0x0f7b74c5 0x810d2b99 0x63a64616 0xcab4a865 0xbe705abb
    ...maximizes all distances (17--19)

    0x28d803a4 0x352ef6d3 0xdb61dce1 0xb3edf85c 0xe62f7508
    ...maximizes a distance from the first and others (21--22), disregarding other pairs (14--21)

It seems that fixing one element to be a bitwise negation of the first element is not a good search tactic in my short testing. Also as notpushkin noted, if you really want to disregard other pairs you should just make one pair with the maximal distance and derive every other code from them (say, -1 0 1 2 3 would work for this purpose).

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

[1] https://www.win.tue.nl/%7Eaeb/codes/binary-1.html

[2] https://math.stackexchange.com/questions/4288902/generation-...

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