Re: C-isms: \0 bytes & Lua's stdlib

[sur-behoffski <sur_behoffski@...>]

On 28 Jan 2017, Solra Bizna <solra@bizna.name> wrote:

> -- Part of a hypothetical messaging server
> local function file_exists(path)
>    local f = io.open(path,"r")
>    if f then f:close() return true
>    else return false
>    end
> end
> [...]
> The above code openly contains a security problem that could rightly
> be considered unimportant. However, what happens if
> read_string_from_socket is implemented in a way that allows NUL bytes
> in the returned string?
>
> And what happens if I send a message to someone named "/etc/passwd\0"?
> A message whose contents are the single line "scriptkiddie:...crypted
> password...:1337:1337:,,,:/home:/bin/bash"?
>
> In my opinion, the IO functions should throw an error any time a file
> path string contains an embedded NUL. Other functions are less
> critical.
> [...]

G'day,

You're confusing/conflating C's strings, which are always NUL-terminated,
with the 8-bit-clean Lua implementation, where any octet of the string
can be any value, including 0 (which, in ASCII encoding, is NUL).

read_string_from_socket is a potentially misleading name... merely
using io.read() to read _bytes_ (octets) from a socket is perhaps a
cleaner way of naming your activity, with the interpretation of the
material returned by the stream then up to the program/script to
deal with correctly (and carefully).

[As an aside, it's worth noting that avoiding magic characters and
"little bobby tables"-type code injection is a major issue always for
programs -- for example, Git was originally implemented as Bash scripts,
but was later rewritten as C programs, with one reason for the change
being the difficulty of correctly handling filenames with exotic
characters such as newlines (NL !), filenames starting with a dash and so
looking like options during filename globbing, and of course the
now-expected potential troubles of spaces interfering with the shell's
(Bash's) word processing.]

Regular readers of this list are going to roll their eyes, and say,
"Oh no, yet again, here comes his reference to the David A Wheeler essay on
the right and wrong way(s) of handling filenames, especially in the context
of file globbing in Bash shells again...", and yes, of course, I can't
restrain myself, so, here it is:

         http://www.dwheeler.com/essays/filenames-in-shell.html

David notes that any Posix-compliant system does not allow NULs in
filenames.  This comes into play when the C code takes the path Lua
"binary string" from the stack, and presents it to the OS interface.

The file /etc/passwd should have file permissions set such that a random
normal user cannot overwrite it, and the messaging server should, by
default, be running in an unprivileged state.  If you don't have both of
these conditions in place, it's a hideously hard task to then build a
message server that somehow knows what every possible combination of
malicious input looks like, and knows when and how to reject it, regardless
of the implementation language (APL, PL/1, Lua, C, Modula-2, Z80, ...)
Much of this comes down to how the messaging protocol is defined:  For
example, my ISP restricts the number and type of characters allowed in
usernames, such that '/', '\', ':', ',', ';', '@' and many other
characters are prohibited.

(The password, by contrast, is encouraged to be quite long -- 12 characters
or more -- and have high entropy.  Although dated, see Bruce Schneier's
"Safe Personal Computing" essay from 2004 for a raft of worthwhile
suggestions appropriate at that time.

        Passwords:

        You can't memorize good enough passwords any more, so don't bother.
        For high-security Web sites such as banks, create long random
        passwords and write them down.  Guard them as you would your cash:
        i.e., store them in your wallet, etc.

        Never reuse a password for something you care about. (It's fine to
        have a single password for low-security sites, such as for newspaper
        archive access.)  Assume that all PINs can be easily broken and plan
        accordingly.

        Never type a password you care about, such as for a bank account,
        into a non-SSL encrypted page.  If your bank makes it possible to do
        that, complain to them. When they tell you that it is OK, don't
        believe them; they're wrong.

URL:

        http://www.schneier.com/blog/archives/2004/12/safe_personal_c.html

Rather than writing passwords down, try to find a trustworthy password
manager -- Schneier's own manager, Password Safe, is one possibility:

        http://www.schneier.com/academic/passsafe/
        http://pwsafe.org/

Also, the "SSL is Safe" assumption in the original was, at one point a few
years back, being compromised by some vendors, who were found to be
deliberately injecting JavaScript code into pre-loaded customised browsers
that come with a machine -- the original intent apparently being to allow
them to sell advertising eyeballs to companies, but creating a potential
attack surface for hackers in the process.)

Aaaaagh!  Sorry for writing such a long message!  If you're still reading
this far, I hope that this has helped.

cheers,

sur-behoffski (Brenton Hoff)
Programmer, Grouse Software