6 ms·

The article describes the current format as a zip of files where the main content of presentation slides is stored in a `content.xml` file within. Yes, sqlite m

The article describes the current format as a zip of files where the main content of presentation slides is stored in a `content.xml` file within. Yes, sqlite may have had file format vulnerabilities in the past, but I cannot imagine trusting it less than any xml library in existence.

vlovich123 6y ago
You’d think so from reading [1]. [2] though paints a very different picture. > The attacker can submit a maliciously crafted database file to the application that the application will then open and query. I think it’s not impossible to secure SQLite better but it takes some work (like how Chrome sandboxes it in a separate process). [1] https://www.sqlite.org/security.html https://www.sqlite.org/security.html [2] https://www.sqlite.org/cves.html https://www.sqlite.org/cves.html
- TylerE 6y ago
  I think his point is that if an attacker wants to give you bad data, there is already zero barrier to editing an XML file inside a zip.
- moonchild 6y ago
  > [2] though paints a very different picture. I don't agree. That document states that the CVEs have historically required one of two preconditions: > The attacker can submit and run arbitrary SQL statements. > The attacker can submit a maliciously crafted database file to the application that the application will then open and query. If you look at the actual list of CVEs, all but one start with ‘Malicious SQL statement’. The single one that doesn't is suffixed with ‘The bug never appeared in any official SQLite release’. In other words, there has never been an official release of SQLite which was vulnerable when presented with a crafted database file.
  - ori_b 6y ago
    > If you look at the actual list of CVEs, all but one start with ‘Malicious SQL statement’. The single one that doesn't is suffixed with ‘The bug never appeared in any official SQLite release’. The list on the page is partial, and the language on that page is disturbingly dismissive. Reading leaves me more concerned that they're too arrogant to take security researchers seriously.
    - 0zymandiass 6y ago
      I'm sure they aren't perfect, but their test suite and extensive fuzz testing is far better than any XML or JSON parser I've ever seen https://www.sqlite.org/testing.html https://www.sqlite.org/testing.html
      - fpoling 6y ago
        I do not agree about JSON. As a format it is so trivial one can cover it with few test cases. SQL dialect that SQLite uses is vastly more complex.
        thristian 6y ago
        You'd think so, but in practice no two JSON parsers have the same bugs, so it's more complex than you might think: http://seriot.ch/json/parsing.html#all_results http://seriot.ch/json/parsing.html#all_results
        dathinab 6y ago
        Think about it if even JSON which is kinda simple has that many problems with parsers how likely is it that something multiple degrees of complexity higher which wasn't developed with untrusted database fiels in mind is secure? Besides that the large majority of thinks tested in your link are irrelevant for the security in this use-case. They do matter if you need fully stable de- and re-serialization or e.g. have a fully trusted validator. E.g. for certain security token use-cases it matters. Many of the thinks which are marked as failure could even be considered as a "more robust" or "more secure" (through not fully standard conform) parser. E.g. parsing tailing commas (disallowed by JSON), rejecting certain unescaped control/special characters (which JSON allows), rejecting to long field values (which JSON allows) or similar. What matters is that a) it has a protection about to deep recursion and as such no stack overflow can happen, b) it makes sure the text it outputs is correctly encoded (independent of weather or not it was well-formed in the JSON blob) and c) it doesn't crash in a way which leads to security problems (which the test suite you linked doesn't differentiate from "acceptable" crashes).
  - trevyn 6y ago
    I feel like there should be a way to make a maliciously crafted database file execute arbitrary SQL... SQLite doesn't do stored procedures, but there's gotta be something in that surface area.
    - moonchild 6y ago
      I expect the majority of the vulnerabilities were in the command parser. Which attack vector is gone from the database file.
      - yc12340 6y ago
        AFAIK, SQLite stores database schema as text, so certain subset of parser still has to be invoked on untrusted DDL.
    - gfody 6y ago
      if select is all you need then a view would suffice
    - dathinab 6y ago
      > SQLite doesn't do stored procedures Link: https://www.sqlite.org/gencol.html https://www.sqlite.org/gencol.html Example: CREATE TABLE t1( a INTEGER PRIMARY KEY, b INT, c TEXT, d INT GENERATED ALWAYS AS (a*abs(b)) VIRTUAL, e TEXT GENERATED ALWAYS AS (substr(c,b,b+1)) STORED ); Note how you can call functions in the columns. Thats one feature which a hardened sqlite for less trusted documents would need to not have.
  - oever 6y ago
    The proposal to use sqlite database files instead of zip files falls under the precondition that an attacker can submit a maliciously crafted database file. So the security concerns apply. SQLitte is mostly used in situations where neither the database nor the SQL statements can be provided by the attacker. If SQLite is used to exchange data both of these attack vectors are available.
- infogulch 6y ago
  https://www.sqlite.org/cves.html https://www.sqlite.org/cves.html 18 CVEs http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=xml http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=xml > There are 1776 CVE Records that match your search. Do I win?
  - fastball 6y ago
    Probably better to compare Apples and Apples[1]. > There are 126 CVE Records that match your search. [1] https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=sqlite https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=sqlite
    - infogulch 6y ago
      That's fair. Though the disparity is still an order of magnitude... More seriously, my point is that SQLite is very unlikely to be the most vulnerable piece of software in your stack. It's probably the most stable and bug free piece of software that you use on a day to day basis that hasn't been formally proven correct. Even openoffice itself has more CVEs: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=openoffice https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=openoffice And some of them are due to the very issue I brought up above... > CVE-2012-0037 Redland Raptor (aka libraptor) before 2.0.7, as used by OpenOffice 3.3 and 3.4 Beta, LibreOffice before 3.4.6 and 3.5.x before 3.5.1, and other products, allows user-assisted remote attackers to read arbitrary files via a crafted XML external entity (XXE) declaration and reference in an RDF document.
      - patrec 6y ago
        > My point is that SQLite is very unlikely to be the most vulnerable piece of software in your stack. Sqlite is very high quality, but I am rather doubtful this is true if you actually care about having a secure system to start with. I can think of three main reasons an office suite would have serious security vulnerabilities: 1. It's written in an unsuitable, memory-unsafe, programming language (as most office suites sadly are). 2. It includes an unsuitable programming language for scripting purposes (Word Macros are of course infamous for this). 3. Vulnerabilities in one of its dependencies (like XML parsers) If you care to, 1 and 2 are very easy to avoid and 3 will be pretty hard to avoid completely, but you can limit your exposure. You need a GUI toolkit at the minimum, but you can completely avoid parsing as an attack vector by either not using a braindamaged format like XML in the unlikely case you don't need compatibility, or if you must, use an xml (zip etc.) parser written in a memory safe language. If you followed all other steps, but chose sqlite instead, I'd say chances a very good it's now your main vulnerability.
- thayne 6y ago
  I think the GP is more an statement of how bad security is with XML than how good it is with SQLite. See for example https://owasp.org/www-community/vulnerabilities/XML_External_Entity_(XXE)_Processing https://owasp.org/www-community/vulnerabilities/XML_External....
fpoling 6y ago
At work we used a library that relied on Expat XML parser. After 20 years it still gets exploitable bugs. As the software was Windows-only we patched the library to use OS API for XML parsing to delegate to Microsoft the job of fixing security bugs.

vlovich123 6y ago

You’d think so from reading [1]. [2] though paints a very different picture. > The attacker can submit a maliciously crafted database file to the application that the application will then open and query. I think it’s not impossible to secure SQLite better but it takes some work (like how Chrome sandboxes it in a separate process). [1] https://www.sqlite.org/security.html https://www.sqlite.org/security.html [2] https://www.sqlite.org/cves.html https://www.sqlite.org/cves.html

TylerE 6y ago
I think his point is that if an attacker wants to give you bad data, there is already zero barrier to editing an XML file inside a zip.
moonchild 6y ago
> [2] though paints a very different picture. I don't agree. That document states that the CVEs have historically required one of two preconditions: > The attacker can submit and run arbitrary SQL statements. > The attacker can submit a maliciously crafted database file to the application that the application will then open and query. If you look at the actual list of CVEs, all but one start with ‘Malicious SQL statement’. The single one that doesn't is suffixed with ‘The bug never appeared in any official SQLite release’. In other words, there has never been an official release of SQLite which was vulnerable when presented with a crafted database file.
- ori_b 6y ago
  > If you look at the actual list of CVEs, all but one start with ‘Malicious SQL statement’. The single one that doesn't is suffixed with ‘The bug never appeared in any official SQLite release’. The list on the page is partial, and the language on that page is disturbingly dismissive. Reading leaves me more concerned that they're too arrogant to take security researchers seriously.
  - 0zymandiass 6y ago
    I'm sure they aren't perfect, but their test suite and extensive fuzz testing is far better than any XML or JSON parser I've ever seen https://www.sqlite.org/testing.html https://www.sqlite.org/testing.html
    - fpoling 6y ago
      I do not agree about JSON. As a format it is so trivial one can cover it with few test cases. SQL dialect that SQLite uses is vastly more complex.
      - thristian 6y ago
        You'd think so, but in practice no two JSON parsers have the same bugs, so it's more complex than you might think: http://seriot.ch/json/parsing.html#all_results http://seriot.ch/json/parsing.html#all_results
        dathinab 6y ago
        Think about it if even JSON which is kinda simple has that many problems with parsers how likely is it that something multiple degrees of complexity higher which wasn't developed with untrusted database fiels in mind is secure? Besides that the large majority of thinks tested in your link are irrelevant for the security in this use-case. They do matter if you need fully stable de- and re-serialization or e.g. have a fully trusted validator. E.g. for certain security token use-cases it matters. Many of the thinks which are marked as failure could even be considered as a "more robust" or "more secure" (through not fully standard conform) parser. E.g. parsing tailing commas (disallowed by JSON), rejecting certain unescaped control/special characters (which JSON allows), rejecting to long field values (which JSON allows) or similar. What matters is that a) it has a protection about to deep recursion and as such no stack overflow can happen, b) it makes sure the text it outputs is correctly encoded (independent of weather or not it was well-formed in the JSON blob) and c) it doesn't crash in a way which leads to security problems (which the test suite you linked doesn't differentiate from "acceptable" crashes).
- trevyn 6y ago
  I feel like there should be a way to make a maliciously crafted database file execute arbitrary SQL... SQLite doesn't do stored procedures, but there's gotta be something in that surface area.
  - moonchild 6y ago
    I expect the majority of the vulnerabilities were in the command parser. Which attack vector is gone from the database file.
    - yc12340 6y ago
      AFAIK, SQLite stores database schema as text, so certain subset of parser still has to be invoked on untrusted DDL.
  - gfody 6y ago
    if select is all you need then a view would suffice
  - dathinab 6y ago
    > SQLite doesn't do stored procedures Link: https://www.sqlite.org/gencol.html https://www.sqlite.org/gencol.html Example: CREATE TABLE t1( a INTEGER PRIMARY KEY, b INT, c TEXT, d INT GENERATED ALWAYS AS (a*abs(b)) VIRTUAL, e TEXT GENERATED ALWAYS AS (substr(c,b,b+1)) STORED ); Note how you can call functions in the columns. Thats one feature which a hardened sqlite for less trusted documents would need to not have.
- oever 6y ago
  The proposal to use sqlite database files instead of zip files falls under the precondition that an attacker can submit a maliciously crafted database file. So the security concerns apply. SQLitte is mostly used in situations where neither the database nor the SQL statements can be provided by the attacker. If SQLite is used to exchange data both of these attack vectors are available.
infogulch 6y ago
https://www.sqlite.org/cves.html https://www.sqlite.org/cves.html 18 CVEs http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=xml http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=xml > There are 1776 CVE Records that match your search. Do I win?
- fastball 6y ago
  Probably better to compare Apples and Apples[1]. > There are 126 CVE Records that match your search. [1] https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=sqlite https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=sqlite
  - infogulch 6y ago
    That's fair. Though the disparity is still an order of magnitude... More seriously, my point is that SQLite is very unlikely to be the most vulnerable piece of software in your stack. It's probably the most stable and bug free piece of software that you use on a day to day basis that hasn't been formally proven correct. Even openoffice itself has more CVEs: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=openoffice https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=openoffice And some of them are due to the very issue I brought up above... > CVE-2012-0037 Redland Raptor (aka libraptor) before 2.0.7, as used by OpenOffice 3.3 and 3.4 Beta, LibreOffice before 3.4.6 and 3.5.x before 3.5.1, and other products, allows user-assisted remote attackers to read arbitrary files via a crafted XML external entity (XXE) declaration and reference in an RDF document.
    - patrec 6y ago
      > My point is that SQLite is very unlikely to be the most vulnerable piece of software in your stack. Sqlite is very high quality, but I am rather doubtful this is true if you actually care about having a secure system to start with. I can think of three main reasons an office suite would have serious security vulnerabilities: 1. It's written in an unsuitable, memory-unsafe, programming language (as most office suites sadly are). 2. It includes an unsuitable programming language for scripting purposes (Word Macros are of course infamous for this). 3. Vulnerabilities in one of its dependencies (like XML parsers) If you care to, 1 and 2 are very easy to avoid and 3 will be pretty hard to avoid completely, but you can limit your exposure. You need a GUI toolkit at the minimum, but you can completely avoid parsing as an attack vector by either not using a braindamaged format like XML in the unlikely case you don't need compatibility, or if you must, use an xml (zip etc.) parser written in a memory safe language. If you followed all other steps, but chose sqlite instead, I'd say chances a very good it's now your main vulnerability.
thayne 6y ago
I think the GP is more an statement of how bad security is with XML than how good it is with SQLite. See for example https://owasp.org/www-community/vulnerabilities/XML_External_Entity_(XXE)_Processing https://owasp.org/www-community/vulnerabilities/XML_External....

fpoling 6y ago

At work we used a library that relied on Expat XML parser. After 20 years it still gets exploitable bugs. As the software was Windows-only we patched the library to use OS API for XML parsing to delegate to Microsoft the job of fixing security bugs.