lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On 28 Jan 2017, Solra Bizna <> wrote:

-- Part of a hypothetical messaging server
local function file_exists(path)
   local f =,"r")
   if f then f:close() return true
   else return false
> [...]
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

In my opinion, the IO functions should throw an error any time a file
path string contains an embedded NUL. Other functions are less
> [...]


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 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:

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.


        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

        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.


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

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.


sur-behoffski (Brenton Hoff)
Programmer, Grouse Software