Hacker News Reader

Comment by Negitivefrags | Hacker News Reader

A buffer overrun can't overwrite random memory that isn't mapped into your process. We solved this issue with virtual memory like 35 years ago.

View on HN

Kind of... We solved this issue like 35 years ago and then broke it again in the last decade. First CPU timing attacks allowed peeking at secret key generation in shared environments. Then we got rowhammer which ignores your mapping. Now we got memory access timing attacks which allow probing kernel memory mapping and bypassing ASLR.

While you can't easily write into other processes anymore, the barrier is more of a suggestion again.

"ignores your mapping" is pretty generous considering rowhammer doesn't work on ECC RAM.

From https://en.m.wikipedia.org/wiki/Row_hammer

> Tests show that simple ECC solutions, providing single-error correction and double-error detection (SECDED) capabilities, are not able to correct or detect all observed disturbance errors because some of them include more than two flipped bits per memory word

But anyway - even if ECC was perfect at preventing the issue, lots of hosts do not use ECC. That includes practically every desktop.

So you're saying there will be a web assembly version in a few years that will claim to be a huge advancement?

Yeah, just like that time microsoft invented lambda functions

Correct, but in practice memory has permissions on a page level and most pages today are 4K. So a page containing a buffer is also likely to contain other data as well. Unless you are going to isolate each buffer by placing it in its own page.

That doesn't make sense to me. So an OS will assign a 4K page of memory to multiple processes, with some granularity that each process "should" only be able to write/read some of it?

So your 1tb linked-list/hashtable that holds all the mail servers email, and is conveniently persisted because ram is the disk, and everything on the heap is magically permanent - isn't at risk?

Reply on news.ycombinator.com