DRAMA: How Your DRAM Becomes a Security Problem

[@MatthijsvanDuin]

summary: the row buffers in DRAM behave effectively like a cache, and therefore may enable cache timing attacks.

[@dipi71]

I find it hard to believe that on any moderately busy system any attacker would be able to acquire clean enough DRAM timing information. The »noise« across such a system would render these kinds of attacks unfeasible, I reckon. Ergo: unleash your SETI/Folding/Numbercrunching-at-home clients everywhere!

[@DangerousPictures]

could someone please hack that iPhone and shut it up?

[@HuntersMoon78]

A hammer is a massive help to shut the piece of shit up!

[@DangerousPictures]

0Dark30 Not to say a rowhammer?

[@maverickstclare3756]

I get that at Uni. Stabbing should be allowed

[@MahenderSingh]

Good Job Michael & Anders

[@julianrothe28]

From a technical point of view, it would be possible to carry out an attack on different providers that targets security relevant data. The ability to read passwords from the DRAM is catastrophic.

[@MatthijsvanDuin]

obtaining information about memory access patterns does not yield the ability to read passwords from DRAM

[@kozlovskyi]

How about large or huge pages?

[@nullplan01]

Heh, when I run that program, I get a floating point exception.

[@puellanivis]

So… basically, DRAM providers need to stop providing timing differences between row-hits and row-misses (so like, always copy the data into the row buffer anew even on a row-hit)? We’re so interested in providing the fastest answer we can, we stop thinking about information leaking through timing… but I’ve known (and I’m not a super big security-following person) about timing-based information leakage for a long time… especially for constant-time byte-string comparison, etc… It reminds me of in Go 1.3, where they had to implement forced small-length map random iteration because code was being made that inherently relied upon this feature without really even realizing it… (typically, from tests where a run of the implementation defined the correct answers, which were then just plugged in as expected output, which we all know is _horribly_ not test-driven development, and is almost as worthless as not having any tests at all.)

[@johncochran8497]

They don't do that because the customers want speed, and because of locality of reference, it's HIGHLY likely that after accessing a row, more data within that row will also be wanted. The real solution is to not have the contents of a row cross a security boundary (for instance, if the rows were only 4K bits long, there wouldn't have been a problem. Also if the page size matches the row length, then there would also not be a problem). The problem could also be mitigated if the OS is aware of the row buffer size and using that information, never have the contents of a row cross a security boundary. This would cause a slight increase in memory consumption in a VM system, but would still allow for the speed benefits of using the row buffer and eliminate the security issue.

[@davejoseph5615]

So hostile code is running natively and is extracting data from the sandbox -- or code in the sandbox is able to read native code on the client?

[@davemullen5522]

If cpus use 4k page sizes, why wouldn't dram manufacturers make the row buffers 4k also? Wouldn't that solve the problem at least going forward maybe 5 years?

[@johncochran8497]

The issue is one of memory refresh in DRAM. The manufactures are NOT interested in the length of the rows, They're extremely interested in the NUMBER of rows. To be specific, they want 8K rows that need to be refreshed. By having 8K rows regardless of the size of the DRAM, that means that the refresh timing is the same regardless of the memory size. So the older memory chips had 8K rows of 1K bits. Technology improves and we get 8K rows of 2K bits, then 8K rows of 4K bits, 8K rows of 8K bits, and I fully expect the row lengths to increase to 16K and 32K bits or larger in the future. The reason that the manufactures are stuck on the 8K rows is because each row needs to be refreshed every 2ms, and when a refresh is active, the memory is effectively inaccessible until that refresh completes. If they increase the number of rows, the percent of time that the memory spends on refreshes increases. So a reasonable compromise is the 8K rows regardless of the size of the memory.

[@marcvandenbroeck3792]

common, the ddram runs in low-high speed against it's power concumption, the memory isn't copied in the cpu next execute without the interupt handler, the cycle is only as row hammer due setting a execute with address that in next cucle receives a NULL or FFFF address which runs in a cycle that never commes to phase STOP, that's the iverrun that the tranistors collapses, the capacitor is not a issue due the bank is just a piece off the machine, ECC in 4th gen running in parrallel multithreaded packages is by the hypervisor exploitd due the gen1 in OS operates in SOAP or WSDL as hypervisor, not the intell on chip is the way vit-flips flow, the design schemes are just for lack off knowledge unknown or seen as obsolete, the x86 in linux runs a POSIX in a x86, that's quite hard,

[@mcgeufer]

I´m not sure what´s worse. The security issue in our Ram or the fact that videos like this have below 10k views while videos from Alex Jones get millions... Seems like seeking imaginary problems are more fun than videos about really important topics.

[@jeffbenzos1017]

That reflects the reality we see at least, would be weird if this was the same reality with the view counts flipped on educational vs nationalist misinformation

[@Merth667]

You're comparing apples to underground cave systems, this is a technical speech dedicated to people mostly in the computer security industry, the other is a politics channel.

[@ko-Daegu]

mcgeufer Who is Alex ???

[@PassFissn]

Alex was here a year ago.

[@tomcarlson7932]

To be fair, the Atrazine in the water really is turning the frogs gay. Check out the gov studies. :')The proliferation of mass endocrine disrupters may very well be a larger problem to life being sustained than a simple timing attack.

[@PassFissn]

Which do i use Russian machine or virtual machine ?

[@Lukaazas9]

haha yeah that raised my eyebrow too :D

[@WizardNumberNext]

not exactly ranks are NOT sides of RAM module ranks are whole 64bit spaces of DIMM DIMM may have from 1 ranks (64bit wide DIMM) up to 4 (256bit wide DIMM) or even 8 ranks (512bit wide DIMM) ranks are there because no matter how wide is DIMM, there is only 64bit wide bus to RAM controller, hence switching between those sets of 64bit wide RANKS is needed) separate RANKS are always on separate chips BANKS are different - those are inside each chip and in case of SDRAM each chip could have up to 4 banks - I have no idea hom much of banks you can have on any of DDR SDRAM now basically RANKS is set of chips, which is 64bit wide most Registered RAM is 4 or 8 ranks wide

[@blindsniper35]

I think this might be the base for Spectre

[@markpenrice6253]

Naw, that's CPU based. This is more related to Rowhammer, just reading rather than forcing bit changes.

[@marcvandenbroeck3792]

the 64 that runs in 4 is wrong as the 4 regs A,B,C,D run in 64 the reg runs internall in Ax,Al two for the finall high low , reg A runs defined code, C is communicate for D data with B the second reg for the A in the in call sended asm mod against the soft-warchdog, intell-vd, the P-cap,and D-bit exploit , is protected in the intell x64 due the machine direct address is bypassed , guard by the in cold runtime the DRAMM is in pc attackable due the DRAMM is not in pc(s as a bank needs a dedicated pair in the slot a pc has just per ram a no relation in the way a bank operates, just the ammount in full board must be equall in sets off 2 pairs as no controller runs as seperate IMM,IPMI,in server is much difficulter, as the membank has it's own controller on the ECC slot against the alligned core per thread