Christiaan008
2 HN recommenders · recommended in 9 months, 2016–2024
45:14 · 24K views · Feb 9, 2012
Artem Dinaburg's DEF CON 19 talk on bit-squatting, where flipped bits in DRAM cause devices to contact domains that differ by one bit from legitimate ones. He shows how registering such domains can hijack traffic without exploiting any software bug.
HN cites it in ECC memory debates and bit-flip discussions as concrete evidence that memory errors have real security consequences.
10 comments from Hacker News
I'm sure all of you who love debating ECC will enjoy this defcon video: this video "DEFCON 19: Bit-squatting: DNS Hijacking Without Exploitation (w speaker)"
There was a good Defcon talk about some security implications of this phenomenon (specifically, DNS squatting) around a decade ago: this video
Depends on how you encrypt over HTTP. You can achieve similar benefits of verification with PGP and similarly rich object level encryption. Be careful of gotchas in how PGP or similar work, if you choose it (notable what is or isn't plaintext). Object level encryption typically allows for better separation of concerns as it does not bottleneck to a unique domain:port to seperate encryption contexts. It also eases separation of public facing encryption risks from private internal ones. If a public server is breached, all HTTPS traffic can be read, but if it proxies a more secure, perhaps simpler application environment (perhaps a microservice for the specific functionality), then that application environment is not affected by vulnerabilities in unrelated public facing features (like a backup microservice might not care about how to render HTML/JavaScript, so wouldn't be vulnerable to common web XSS attacks). It allows other benefits like: - it faciliates only user can decrypt data being sent (good for backups) - intermediate services to load balance and block DOS don't have to be exposed to the plaintext data, only the necessary service that needs it - many to many encrypted messages over one connection (TLS is many to 1 decrypting endpoints) - intermediate caching and redelivery of messages can be done with ease - it likely is harder to be at risk of bitflips ( this video ) - similarly verification of the data with signatures reduces risk of data corruption being missed that ma
I want a laptop with 64 or 128 GiB of Chipkill ECC RAM. Any of this soldered-on, anti-R2R/-consumer Apple trend-copying is BS. This crap about "YAGNI" or "it costs too much" have no idea what they're talking about and don't understand the reasons or use-cases. At home, I may have a 96 core EPYC with 512 GiB of Reg'd ECC RAM, but it doesn't have the locality or reachability of something that's with you. Network presence and low-latency aren't a given. [LINK] Edit: Resources: [LINK] [LINK] [LINK] [PDF] [LINK] DEFCON 19: Bit-squatting: DNS Hijacking Without Exploitation (trivia: at the time of filming, I was excessively-hungover and laying across 6 seats in the middle of an empty area to the extreme right, from the podium's perspective. I did watch the presentation with sunglasses on indoors because my eyes weren't cooperating nicely with photons.) this video Edit follow-on: And I don't want to lug-around a 17" Russian tank laptop that needs wheeled tracks to move. 13-15" max.
On the post, if Linus is referring to low-end Xeon and workstation non-Xeon lacking ECC, I think it's completely idiotic. Nearly all infrastructure should be baking in ECC as standard rather than some "option" to not have silent, unknowable, probabilistic corruption that is realistically realizable on a near-daily basis given the orders of magnitude of network, storage and computational volumes of today (and the future) by ever lower tiers of end-users and common examples of network infrastructure. DEFCON 19: Bit-squatting: DNS Hijacking Without Exploitation (w speaker) this video