4 ms·
> More fundamentally, data races aren’t the thing that attackers exploit except when those data races do lead to actual memory corruption (like use after free,
by AnthonyMouse 1y ago
> More fundamentally, data races aren’t the thing that attackers exploit except when those data races do lead to actual memory corruption (like use after free, double free, out of bounds, access to allocator metadata etc).
This is absolutely not true. One of the classic data races is when you do a set of operations like this non-atomically:
new_total = account.balance;
new_total -= purchase_price;
account.balance = new_total;
Which is a huge security vulnerability because it lets people double spend. Alice buys something for $1000 and something for $1 and instead of debiting her account by $1001 it debits it by $1 because the write for the second transaction clobbers the balance reduction from the first one.
Another common one is symbolic links. You check the target of a symbolic link and then access it, but between the check and the access the link changed and now you're leaking secrets or overwriting privileged data.
Data races are serious vulnerabilities completely independent of memory safety.
- tialaramex 1y agoThat filesystem example is a TOCTOU race, not a data race, and so it can happen in Rust or similar languages just the same. Although both TOCTOU races and data races are types of race condition, they are not the same thing. Many race conditions are an ordinary part of our lived experience - if you've ever thought "Oh, I need to buy more milk" and then went to a store but meanwhile your house mate, partner, colleague at work, or whatever were also out buying more milk, well, when you get back with milk there's too much milk, oops, that's a race condition, specifically a TOCTOU race - we checked the milk, then we purchased more milk, meanwhile someone else changed how much milk is there. Data races aren't like any real world experience. The way the machine actually works is too alien for us to get our heads around so we're provided with a grossly simplified "sequentially consistent" illusion when writing high level languages like C - in which things happen in some order. Data races are reality "bleeding through" if we don't follow the rules to preserve that illusion.
- stirfish 1y ago>TOCTUO Time of check to time of use https://en.wikipedia.org/wiki/Time-of-check_to_time-of-use https://en.wikipedia.org/wiki/Time-of-check_to_time-of-use I didn't know this, thank you
- pizlonator 1y agoI’ve fixed so many burning hot potato security bugs in my life and your data race example has never come up, not even once. Logic errors not preventable by any language or type system (like making sure you enforce policy in a setuid process) are far more likely than that.
- AnthonyMouse 1y agoIt depends what domain you're operating in. If you're only ever patching CVEs it shows up less, because if you've implemented that data race where the first and last lines are separate SQL queries, you're not going to get a CVE against the database software for it. Then it only even gets discovered if someone actually starts exploiting it or the race is so severe that it happens under normal use and then at the end of the quarter the accountants start asking why the numbers don't add up.
- pizlonator 1y agoNo memory safe language will protect you from getting your SQL queries wrong. Races in a database are not “data races” in the programming language sense, unless we’re debating. The hat query language to use
- AnthonyMouse 1y ago> No memory safe language will protect you from getting your SQL queries wrong. That's kind of the point. > Races in a database are not “data races” in the programming language sense Only in the sense that in a sufficiently large bureaucracy you get to power up the Somebody Else's Problem Field and blame the DBA for it. But that doesn't get you the missing money back.
- pizlonator 1y agoThis whole conversation is about memory safety of programming languages, not security vulns that no language can prevent