3 ms·

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/cve

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.
    - oever 6y ago
      Or run the IO in a sandbox where it is streamed out in a simpler/safer format. Or run the entire suite in a sandbox like we do with parts of web browsers.
      - patrec 6y ago
        How is this better than just avoiding the problem in the first place?
        fastball 6y ago
        Because SQLite, as a general purpose database system, can be used for loads of things. A two-piece component (DB + sandbox) that you use for 100 different things is going to end up much more secure (overall) and require less human effort than maintaining 100 different systems for each use case. It's like "don't roll your own crypto". That is the advice not because it's impossible to roll your own secure crypto, but because it is just much more likely that you will repeat bugs that other people have already figured out, so it is better if everyone is using one library so that when an issue is found and resolved, it applies to everyone. It is still good advice even though that 3rd party crypto lib is probably going to have a lot of unneeded functionality that actually increases the overall attack surface area than if you made your own for whatever your specific purpose is. I think the same logic applies here.
    - infogulch 6y ago
      You have crafted a nigh-impossible tower of requirements that you admit are way beyond what is commonly practiced in the software under question in order to disclaim the statement "SQLite is very unlikely to be the most vulnerable piece of software in your stack". Right now on the front page of HN is an article about how Microsoft was also a victim of what may come to be labeled the most impactful hack ever, a list which includes most (all?) US government agencies. The root vuln? A crap admin password used by an IT monitoring software company which has software deployed to an alarming percentage of the industry. I dunno man, I feel like my original statement is pretty reasonable. Let's please not move the goalposts to the moon. :)
dathinab 6y ago
No, the article just replaces the container with SQL but not the components (e.g. a slide). Which without extra changes are still XML, stored as text in the database. The change from storing the inner document format in something which is not XML is completely independent of changing the outer container to sqlite. SQL isn't really suited as a markup language so storing styles "flowing" text in it isn't that good of an idea. The article only recommends storing all separate blobs of styled text in tables (it also sidesteps the whole problem about flow text across multiple pages by simple using slides as an example ;=) ). Lastly I'm against using a "stock"/unhardened sqlite version, not sqlite in general. Ironically on of the features I would disable for now is related to text search but I don't remember the name of it so I can't really use it as an argument :=/. So if you ask me: - Change containers to a different format then zipped sql files, consider sqlite but use a hardened feature limited sqlite version. - Change the inner representation away from XML(1) (1): Ok, there are ways to safely use XML but this isn't useful for this discussion and they require a bunch of thinks which all reduce usability (of the XML library) and performance and only work for certain use-cases where you e.g. do not need fully stable serialization and de-serialization and might be limited to a subset of XML and don't rely on the verifier for anything "safety" realated and preferably don't use C/C++ to write a parser... so it's easier to just not do it tbh.

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.
  - oever 6y ago
    Or run the IO in a sandbox where it is streamed out in a simpler/safer format. Or run the entire suite in a sandbox like we do with parts of web browsers.
    - patrec 6y ago
      How is this better than just avoiding the problem in the first place?
      - fastball 6y ago
        Because SQLite, as a general purpose database system, can be used for loads of things. A two-piece component (DB + sandbox) that you use for 100 different things is going to end up much more secure (overall) and require less human effort than maintaining 100 different systems for each use case. It's like "don't roll your own crypto". That is the advice not because it's impossible to roll your own secure crypto, but because it is just much more likely that you will repeat bugs that other people have already figured out, so it is better if everyone is using one library so that when an issue is found and resolved, it applies to everyone. It is still good advice even though that 3rd party crypto lib is probably going to have a lot of unneeded functionality that actually increases the overall attack surface area than if you made your own for whatever your specific purpose is. I think the same logic applies here.
  - infogulch 6y ago
    You have crafted a nigh-impossible tower of requirements that you admit are way beyond what is commonly practiced in the software under question in order to disclaim the statement "SQLite is very unlikely to be the most vulnerable piece of software in your stack". Right now on the front page of HN is an article about how Microsoft was also a victim of what may come to be labeled the most impactful hack ever, a list which includes most (all?) US government agencies. The root vuln? A crap admin password used by an IT monitoring software company which has software deployed to an alarming percentage of the industry. I dunno man, I feel like my original statement is pretty reasonable. Let's please not move the goalposts to the moon. :)

dathinab 6y ago

No, the article just replaces the container with SQL but not the components (e.g. a slide). Which without extra changes are still XML, stored as text in the database. The change from storing the inner document format in something which is not XML is completely independent of changing the outer container to sqlite. SQL isn't really suited as a markup language so storing styles "flowing" text in it isn't that good of an idea. The article only recommends storing all separate blobs of styled text in tables (it also sidesteps the whole problem about flow text across multiple pages by simple using slides as an example ;=) ). Lastly I'm against using a "stock"/unhardened sqlite version, not sqlite in general. Ironically on of the features I would disable for now is related to text search but I don't remember the name of it so I can't really use it as an argument :=/. So if you ask me: - Change containers to a different format then zipped sql files, consider sqlite but use a hardened feature limited sqlite version. - Change the inner representation away from XML(1) (1): Ok, there are ways to safely use XML but this isn't useful for this discussion and they require a bunch of thinks which all reduce usability (of the XML library) and performance and only work for certain use-cases where you e.g. do not need fully stable serialization and de-serialization and might be limited to a subset of XML and don't rely on the verifier for anything "safety" realated and preferably don't use C/C++ to write a parser... so it's easier to just not do it tbh.