<https://www.sqlite.org/draft/sqlar.html>

One important security issue and several unimportant ones.

Security issue:

The built-in path functions of some operating systems interpret file paths 
beginning with a path separator as relative to the root of the drive rather 
than the current subdirectory.  For instance

    tmp/read.me <-- subdirectory called 'tmp' of default path
    /tmp/read.me <-- subdirectory called 'tmp' of the default drive's root

A 'name' field in a SQLite archive file could be edited to hold such a path.  
This would be a vulnerability if a utility used to 'unpack' an archive is 
accidentally given too much power, as 'install' scripts often are.  I would 
suggest some attention be paid to this issue in the command-line tools which 
understand archives, that built-in functions which store the 'name' field not 
store leading path separators, and that functions which restore from the 'name' 
field filter out leading path separators.  This could be done with a single 
'sqlar_sanitizeName()' function (you can probably think of a better name for 
it) called by both packer and expander functions.

You might also want to ponder whether a 'name' starting with 'c:\' should be 
allowed, and what the command-line tools should do about it if it isn't.

Other issues:

Because not all operating systems use the same character as a subdirectory 
separator, you might document whether archives always use the '/' character as 
a path separator.  Proper programmers know what they're doing, but naive 
Windows users might not.

Is there a good reason for the 'sz' column to be called 'sz' and not 'size' or 
'length' ?  I dislike pointless abbreviation.

If you're renaming the 'sz' field, please consider whether to rename 'name' to 
'path', which is closer to the industry standard.

Does the deflated stream include a header which says "what follows is deflated 
data" ?  If not, what will you do when users want to use better algorithms than 
'Deflate' ?  You need either a column which tells the user which compression 
method was used (including 'none') or a function which extracts this 
information from the stored BLOB.

If you expect SQLite archive files to eventually feature other methods of 
compression than 'Inflate', the documentation should make it clear whether this 
would be done by changing sqlar.c or by supplying other files like sqlar.c.  In 
the latter case, the name and functions of sqlar.c should be changed to reflect 
that they are the 'Inflate' versions.

Simon.
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to