On Tuesday, 27 August, 2019 14:40, Jens Alfke <j...@mooseyard.com> wrote:
>> On Aug 27, 2019, at 12:21 PM, Keith Medcalf <kmedc...@dessus.com> wrote: >> Everything that has been touched by a third-party is inherently >> untrustworthy. Thus it is and thus it has always been. > Yes. I have a lot of experience with network coding and security, so > I'm aware of this, thanks. My question was simply whether SQLite > itself is considered safe when operating on an untrusted database > file. Considered by whom -- and what is the trustworthiness of that "whom" to be making that assessment? Personally speaking I find the developers of SQLite to be trustworthy and generally trust that SQLite3 will operate in accordance with its design. Furthermore, I trust that any issues where SQLite does not operate in accordance with its design will be fixed by said developers. I also trust that when presented with a trustworthy database file the library will operate in a trustworthy fashion. The necessary inference therefore is that if presented with an untrustworthy database file, then the whole shebang is untrustworthy. This inference would stand no matter what trustworthy party may claim that SQLite3 is trustworthy in the face of untrustworthy input. (And this applies to everything not just SQLite3). To assume otherwise is fraught with peril and is the cause of much security problems in the world today. >> Even ZIP files have a database schema that can be manipulated as >> does everything else. > The layout of a Zip file is vastly simpler than a SQLite database. > A Zip codec does not include an interpreter for a sophisticated > programming language. > Zip files do not contain program code that runs when the file is > read; SQLite databases can. In fact, if one forgets about ZIP (presumably meaning something trustworthy like Info-ZIP) then there are in fact a great many things that are capable of executing arbitrary code contained within what is ostensibly data, often by design. Can one trust that any given program when presented with untrustworthy input will not execute arbitrary code? No. One should expect that any given program when presented with untrustworthy input may operate in an untrustworthy manner, unless it is manifestly impossible for this to occur. Since determination of "manifestly impossible" is huge in scope, it is only done in very rare instances. Also, I do not think that SQLite, by design, executes any code that is stored within the database, assuming a trustworthy database file. However, if you are asking if one can craft an (untrustworthy) database file that may execute code contained within the database when it is opened, then this again devolves into the fact that the database file is itself untrustworthy, and as such all such bets are off. >> And how is this in anyway different from a zip process, or a rar >> processess or an uncompress process or any or a number of possibly >> trustworthy programs processing data coming from an untrustworthy >> source? (which includes things like Web Browsers, Video Players, and >> on and on) > Codecs used in such apps are considered attack surfaces and are > screened for vulnerabilities. (For example, Google found and fixed > some security holes in the TrueType font renderer when they added > web-font support to Chrome.) This is precisely what I'm asking about > SQLite — is it engineered with the assumption that a database file > may be malicious, or is the assumption "garbage in, garbage out"? And this is a known security problem (untrustworthy font files) that has existed for as long as I can recall (at least since GOOEYs were invented). The solution is, of course, to not permit the processing of files (including font files) that originate from untrustworthy sources. Just because one such hole has been found and fixed does not mean that others do not exist. In fact, it means that it is more likely that such holes exist but merely have not been published in the local tabloid yet. Nonetheless, it is again a matter of assigning trust and trustworthiness and the boundaries that apply to this trust. So, directly to your question "SQLite — is it engineered with the assumption that a database file may be malicious, or is the assumption "garbage in, garbage out"? The answer of course is a matter of trust. Yes, SQLite is engineered to operate in a trustworthy fashion even when presented with untrustworthy input and in fact the developers endeavour to fix any such issues found/reported. This however does not preclude the possible existence of situations where this is not the case or have not otherwise yet been reported and fixed. So again, we come back to the fact that no matter how trustworthy something is when presented with trusted inputs, its behaviour when presented with untrustworthy input cannot be guaranteed. That is to say that for all pipelines A -> B -> C where either of A or B is untrustworthy, then C must be untrustworthy as well (unless, of course, it is manifestly impossible for B to produce an untrustworthy result, which is extremely rare). >> Chrome is a Google product. Google's only revenue source is >> selling information that they have obtained from third- >> [anti-Google ranting removed] > This is not only off-topic and inaccurate (Google has many other > revenue sources), it's the sort of scenery-chewing conspiracy > theorizing that's beneath someone with your level of expertise. Check > yo'self. Perhaps they do have other sources of revenue but none come to mind, it is, I believe, an accurate assessment. -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
