Re: [sqlite] DEF CON (wasL A license plate of NULL)
On Mon, 12 Aug 2019 14:14:08 -0600
"Keith Medcalf" wrote:
> Perhaps I am just lazy but I see no point in engaging in extra work
> for no advantage
bool
is_true (bool tf) {
if (tf == true) {
return true;
}
return false;
}
--jkl
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] DEF CON (wasL A license plate of NULL)
On Aug 12, 2019, at 1:14 PM, Keith Medcalf wrote: > The only interesting thing is CVE-2015-7036, but I don't know if that was so > much an SQLite3 issue, as it was an issue in the use of the tokenizer by > Apple. In either case, Apple fixed their bugs and SQLite3 was hardened > against some inappropriate (unintended by the application developer) uses of > the fts3_tokenizer() function. Generally speaking, the issue was the availability of a built-in function accessible from the query language that took a function pointer as a parameter. Specifically, the vector was that an attacker with the ability to execute arbitrary SQL could cause execution to jump to the address of their choosing via the second parameter to fts3_tokenizer. Using established ROP techniques this could be used to gain control of the process. The attack is even more interesting when combined with Check Point Research's recent publication (search for "SELECT code_execution FROM * USING SQLite;"), which explains how to gain control of a process from a database file by replacing all of its tables with views containing malicious queries. Scott ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] DEF CON (wasL A license plate of NULL)
The difference, in Apple's case _very_ specifically, is that they sign the majority (all the rest? Unsure) of their files so that this style of exploit fails. Basically SQLite is being used to bypass an existing Apple-specific security control. Outside of the iOS world the applicability is a lot lower (if any) as you detail. Regards, Donald Shepherd. On Tue, 13 Aug 2019 at 06:14, Keith Medcalf wrote: > > On Monday, 12 August, 2019 11:09, Simon Slavin > wrote: > > >Some interesting things are emerging from this year's DEF CON. This > >one is related to an issue we've often discussed here. I hope you'll > >indulge this slightly off-charter post. > > > > > https://www.iheart.com/content/2019-08-12-clever-vanity-license-plate-backfires-on-man-winds-up-with-tons-of-tickets/ > > > > Perhaps more apropos is the following story from the Register, also > originating at DEF CON: > > https://www.theregister.co.uk/2019/08/10/memory_corruption_sqlite/ > > Although I would point out that the root problem is that the attacker > already has access to the file in order to change it, and therefore already > has presence on the machine. This is really no different that saying that > "if an attacker has access the filesystem to replace the login program, > that the login program can be compromised". In other words, much ado about > nothing. Solve the root issue (the inappropriate granting of access by > some other method) and the issue is resolved. > > This (seems to me) falls into the class of "if you have SYSTEM (root, for > the *nix crowd) authority" you can "exploit vulnerability X" to obtain > SYSTEM authority. Why on earth would you bother? Sure, you can exploit > the vulnerability but it gains you nothing that you do not already have. > Perhaps I am just lazy but I see no point in engaging in extra work for no > advantage (then again, maybe that is just the Control Systems background > rearing its head). > > As a side note, if one ALREADY HAS access to a machine hosting a database, > and ALREADY HAS access to be able to make arbitrary changes to the database > file, then the same exploit can be carried out on just about ANY system > running just about ANY database imaginable .. it is trivial to create a > view which replaces a table and have that view "do things" that are other > than what was intended by the original designer, and have the fact that the > table was replaced by a view remain "hidden" from routine uses. And in any > case, why bother with all the rigamarole. You can already copy the > contents of the database or make changes directly, so why go to such great > lengths to be able to achieve indirectly that which you can already do > directly? (Not to mention that there are already capabilities to monitor > for this sort of thing via the authorizer). > > Granted, it is not usual to "ship around" SQLServer or DB2 databases or > have those host "application file formats" quite like it is with SQLite3 > databases, but then, files (no matter the type) originating from > untrustworthy third-parties should be, well, untrusted. The same applies > to files which have been accessed (and perhaps modified) by untrustworthy > parties. The root problem is the prior untrustworthy access -- fix that > and the problem goes away. > > Conversely there is a great trend these days to "execute" data -- > thankfully something which SQLite3 does not do. An application might, but > that is an application problem and not a data problem. > > The only interesting thing is CVE-2015-7036, but I don't know if that was > so much an SQLite3 issue, as it was an issue in the use of the tokenizer by > Apple. In either case, Apple fixed their bugs and SQLite3 was hardened > against some inappropriate (unintended by the application developer) uses > of the fts3_tokenizer() function. > > https://www.sqlite.org/releaselog/3_28_0.html > Item 10 > > -- > 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 > ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] DEF CON (wasL A license plate of NULL)
On Monday, 12 August, 2019 11:09, Simon Slavin wrote: >Some interesting things are emerging from this year's DEF CON. This >one is related to an issue we've often discussed here. I hope you'll >indulge this slightly off-charter post. > >https://www.iheart.com/content/2019-08-12-clever-vanity-license-plate-backfires-on-man-winds-up-with-tons-of-tickets/> Perhaps more apropos is the following story from the Register, also originating at DEF CON: https://www.theregister.co.uk/2019/08/10/memory_corruption_sqlite/ Although I would point out that the root problem is that the attacker already has access to the file in order to change it, and therefore already has presence on the machine. This is really no different that saying that "if an attacker has access the filesystem to replace the login program, that the login program can be compromised". In other words, much ado about nothing. Solve the root issue (the inappropriate granting of access by some other method) and the issue is resolved. This (seems to me) falls into the class of "if you have SYSTEM (root, for the *nix crowd) authority" you can "exploit vulnerability X" to obtain SYSTEM authority. Why on earth would you bother? Sure, you can exploit the vulnerability but it gains you nothing that you do not already have. Perhaps I am just lazy but I see no point in engaging in extra work for no advantage (then again, maybe that is just the Control Systems background rearing its head). As a side note, if one ALREADY HAS access to a machine hosting a database, and ALREADY HAS access to be able to make arbitrary changes to the database file, then the same exploit can be carried out on just about ANY system running just about ANY database imaginable .. it is trivial to create a view which replaces a table and have that view "do things" that are other than what was intended by the original designer, and have the fact that the table was replaced by a view remain "hidden" from routine uses. And in any case, why bother with all the rigamarole. You can already copy the contents of the database or make changes directly, so why go to such great lengths to be able to achieve indirectly that which you can already do directly? (Not to mention that there are already capabilities to monitor for this sort of thing via the authorizer). Granted, it is not usual to "ship around" SQLServer or DB2 databases or have those host "application file formats" quite like it is with SQLite3 databases, but then, files (no matter the type) originating from untrustworthy third-parties should be, well, untrusted. The same applies to files which have been accessed (and perhaps modified) by untrustworthy parties. The root problem is the prior untrustworthy access -- fix that and the problem goes away. Conversely there is a great trend these days to "execute" data -- thankfully something which SQLite3 does not do. An application might, but that is an application problem and not a data problem. The only interesting thing is CVE-2015-7036, but I don't know if that was so much an SQLite3 issue, as it was an issue in the use of the tokenizer by Apple. In either case, Apple fixed their bugs and SQLite3 was hardened against some inappropriate (unintended by the application developer) uses of the fts3_tokenizer() function. https://www.sqlite.org/releaselog/3_28_0.html Item 10 -- 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
