Hacker News new | past | comments | ask | show | jobs | submit login

I agree with your general point that "it's very hard to write safe C code", and

> people keep finding use-after-free bugs in sqlite3

is true, but

> that allow attackers to escalate the memory corruption into arbitrary code execution... bugs that have affected major projects, including iCloud and Chrome; here are a handful: there are lots more even from just the past year :/

is just incorrect. I'd strongly encourage you to read https://www.sqlite.org/cves.html




sqlite3 dev: "yes it's an use after free, but it's fine because the attacker don't control SQL query on most applications"

Application dev: "yes it's an SQL injection, but it's fine because this database is only used for unimportant data"

The thing is that the real attacks usually come by chaining a bunch of vulnerabilities together.


Well, the first CVE I linked was a bug in the full-text search engine and was confirmed by Apple, so I'm pretty sure I'm correct; but like, even if individual bugs don't manage to affect specific projects, it seems pretty strange to just discount them all out of hand as if they aren't important: even one bug is too many if they are avoidable (and most of these C bugs are).


In addition, I recommend others read https://news.ycombinator.com/item?id=27736216. It’s a thoughtful discussion that dispels the unintentional FUD of this thread.

Before today, I didn’t know that CVEs aren’t vetted and can be easily spammed for self-gain[1]. I should be more skeptical the next time I see scores of links to CVEs with 0 comments and bare-bones descriptions.

[1] https://news.ycombinator.com/item?id=25612429




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: