[webkit-dev] Blacklisting some sqlite functions

[Darin Fisher]

On Thu, Jan 7, 2010 at 10:02 AM, Brady Eidson <beidson at apple.com> wrote:

>
> On Jan 6, 2010, at 2:55 PM, Dumitru Daniliuc wrote:
>
> while doing a security review of chromium's implementation of HTML5 DBs,
> chris noted that some sqlite functions are potential security risks. thus,
> we would like to blacklist them (or rather, have a list of whitelisted
> functions). currently, WebCore's sqlite authorizer allows all functions, but
> has a FIXME comment that wonders what the right thing to do is
> (WebCore/storage/DatabaseAuthorizer.cpp:281).
>
>
> This code has long since shipped and although it hasn't achieved what you
> might call "wide use," a widespread change in behavior might break important
> clients.
>
> That said... the less function surface area available, the better.
>
> here are the functions we'd like to whitelist:
> http://www.sqlite.org/lang_corefunc.html: all of them, except
> load_extension(), random() and randomblob() (once we fix some layout tests
> that currently use randomblob()).
>
>
> No argument on disallowing load_extension().
>
> Are random() and randomblob() security risks?  Could you point us to a
> source explaining this?
>
> http://www.sqlite.org/lang_datefunc.html: all of them
>
> http://www.sqlite.org/lang_aggfunc.html: all of them
>
>
> Seems okay.
>
> in addition to these standard functions, we'd like to whitelist some
> functions from a few extensions chromium uses:
> full text search (fts2.c): whitelist snippet(), offsets(), optimize(), but
> not fts2_tokenizer().
> unicode data (icu.c): whitelist regexp(), lower(), upper(), like(), but not
> icu_load_collation().
>
>
> Is there any reason these are still Chromium-only?  Even though we're
> having problems getting different vendors to agree on SQL dialect issues
> with the spec, I think we should make an effort to keep WebKit unified.
>
>
Yes, it would be great if all WebKit based browsers supported these same
sqlite features.
-Darin




> I'm also going to forward this message on to some of our security
> colleagues at Apple, and we might have more feedback shortly.
>
> ~Brady
>
>
> any objection?
>
> thanks,
> dumi
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100107/b99c54c4/attachment.html>