4 ms·

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? Maliciou

by ynniv 8y ago

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.

tptacek 8y ago
This isn't, like, a real debate. Go here: https://pwnies.com/ https://pwnies.com/ Start with the 2018 nominations but feel free to check the archives. Drive-by browser vulnerabilities are RCEs.
- blattimwind 8y ago
  > 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.
  - tptacek 8y ago
    Uh, no, for example, it could also potentially impact any application that uses sqlite as (part of) a file format.
  - deleted 8y ago
    [deleted]
- stefan_ 8y ago
  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.
- ynniv 8y ago
  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?
tzakrajs 8y ago
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.

by ynniv 8y ago

tptacek 8y ago

This isn't, like, a real debate. Go here: https://pwnies.com/ https://pwnies.com/ Start with the 2018 nominations but feel free to check the archives. Drive-by browser vulnerabilities are RCEs.

blattimwind 8y ago
> 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.
- tptacek 8y ago
  Uh, no, for example, it could also potentially impact any application that uses sqlite as (part of) a file format.
- deleted 8y ago
  [deleted]
stefan_ 8y ago
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.
ynniv 8y ago
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?

tzakrajs 8y ago

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.