81–90 of 147 posts
Even without an explicit attack, today's memory is pretty fragile, I'm regularly seeing bit flips.
> I'm regularly seeing bit flips. How?
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?
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 :)
That's the section that made me post this snippet; crazy isn't it?!
#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 */
Earlier quoted context omitted.
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…
Earlier quoted context omitted.
Rowhammer is not architecture specific, since it's the DRAM rather than the CPU. The paper linked in the patch references other works showing every defence at rowhammer can be bypassed somehow (I've not followed them all) - e.g. it specifically says that ECC and the like can be bypassed.
Interesting. I did not expect that Rowhammer was architecture specific, only that the test I found was. I also did not expect that the various defenses, including ECC, could be bypassed.
The attacker cannot control precisely which bits will be erroneous. When much more than 2 bits become erroneous, in a small fraction of the cases no error will be detected but a wrong value will be read at the next access.
However, in the majority of the cases an error will be detected, either non-correctable, or correctable in which case the corrected value will be wrong.
Despite the fact that wrong corrections are possible, in a system with ECC that is configured correctly it should be impossible for a RowHammer attack to escape detection, unlike for a system without ECC memory.
On a computer that is not defective, memory errors happen very seldom, typically one error after many months. Even only 2 correctable errors that happen in the same day represent an event that can be explained only by either a RowHammer attack or by a memory module that has become defective.
Therefore, a well configured computer with ECC memory should alert immediately its administrator when 2 on more errors happen in the same day, even if they had been correctable errors, because this requires immediate action, either stopping a RowHammer attack or replacing the defective memory module.
It would be pretty much impossible for any RowHammer attack to attain its target without triggering 2 or more ECC errors, which will reveal the attack attempt.
Only when there is no ECC the attack can proceed undetected for a time long enough to be successful.
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?
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.
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 :)
Earlier quoted context omitted.
> I'm regularly seeing bit flips. How?
For example 7zip decompression CRC failures that resolve on a second try. It would be longer to explain how, but I tracked it multiple times to a single bit flip in the decompressed output.
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 having sudo disabled, seems to make me proper root.
I'll often use synaptic package manager when I want a cleaner, easier interface to explore packages. If I only 'su root' it won't open unless I append .... something similar to 'pkex' to the end, but if I do 'sudo su', I can run it using only 'synaptic'. Regardless, I refuse to use sudo otherwise, even when I'm emulating something sentient.
Be afraid. There are morons using Linux, and some are quite productive despite.
Earlier quoted context omitted.
> I'm regularly seeing bit flips. How?
For example 7zip decompression CRC failures that resolve on a second try. It would be longer to explain how, but I tracked it multiple times to a single bit flip in the decompressed output.