News for hackers. Stuff that matters.
Re:Remote code execution vulnerability in SQLite by ynniv on Friday December 14, 2018 @07:16PM (#18686106)
They're only vulnerable to RCE if image data can be supplied remotely. What's the analog here? Accessing the JavaScript API? Specifying a query string? Maliciously encoded data? Some of these are scarier than others.
Re:Remote code execution vulnerability in SQLite by tptacek on Friday December 14, 2018 @07:28PM (#18686179)
This isn't, like, a real debate. Go here:

https://pwnies.com/

Start with the 2018 nominations but feel free to check the archives. Drive-by browser vulnerabilities are RCEs.

Re:Remote code execution vulnerability in SQLite by blattimwind on Friday December 14, 2018 @07:57PM (#18686311)
> Drive-by browser vulnerabilities are RCEs.

I would never argue they aren't, but by this logic ("it's like saying PDF or JPEG parsers can't be vulnerable to RCE") virtually every code execution vuln in a library can be called RCE. I haven't noticed this to be the case with e.g. libtiff vulnerabilities (of which many make it into my inbox regularly), although image libraries are one of the cases were CE = RCE is still fairly reasonable.

Let's assume this SQLite bug is only exploitable if you can input arbitrary SQL. Almost no applications use it this way (except Chrome). I think it's clearly unreasonable to call it a RCE in SQLite then.

Re:Remote code execution vulnerability in SQLite by tptacek on Friday December 14, 2018 @08:28PM (#18686431)
Uh, no, for example, it could also potentially impact any application that uses sqlite as (part of) a file format.
Re:Remote code execution vulnerability in SQLite by stefan_ on Friday December 14, 2018 @10:57PM (#18686952)
In that sense, soon USB kernel stacks have remote code execution vulnerabilities because browsers added dumb APIs.

Should we fix bugs? Yes. Should we scream at people that expose raw APIs they don't understand far beyond their design constraints? Yes yes yes.

Re:Remote code execution vulnerability in SQLite by ynniv on Saturday December 15, 2018 @09:45AM (#18688542)
I think you're assuming the target is a browser, but my question was how this might affects servers. Does the attack use malicious SQL statements, API calls, or encoded data?
Re:Remote code execution vulnerability in SQLite by tzakrajs on Friday December 14, 2018 @08:51PM (#18686529)
Technically, this attack is actually is two separate attacks in a chain. The first node in the chain is delivering malicious SQL. The second node is executing code remotely via SQLite. The proof is that SQLite or the application linking it could have mitigated this attack independently by either filtering the query string or better protecting the memory which is being written to.

In practice, however, the community gets more bang for their buck if they label the SQLite code execution vulnerability as an RCE since the vast majority of use is in a networked setting. You have to remember the audience used for these terms. They aren’t scientists in the traditional sense where taxonomy is highly aligned the ontology — instead, the labeling serves the operators with metaphors that depart from reality insofaras they increase security engineers ability to do their job effectively.