Re: Lua exposure to C vulnerabilities?

[Roberto Ierusalimschy <roberto@...>]

> I'd expect that if your C library has security issues, then using
> Lua or anything else that interfaces to that library will not
> protect you. For example, if your C code has buffer overflows, it
> doesn't matter how it is called - the overflow is there and will
> potentially cause you grief when the code is run. You'll need to fix
> up your C code.

I think Lua can (and should) protect the user from several security
issues from an underlying library. One clear way to improve secutiry
is validating arguments in the binding. (As a simple example, the
underlying C function 'strftime' has undefined behavior for unknown
conversion specifiers, but 'os.date' gives a clear error message in
those cases.)

Another way to improve security is to offer a higher-level API to
Lua than the raw C API. Such APIs could avoid invalid sequences of
operations, buffer overflows (by using its own buffers in controlled
ways), etc. (As examples, see in [1] and [2] how one can export
'opendir'/'readdir'/'closedir' to Lua using higher-level APIs. See
also how 'os.date' avoids buffer-overflow issues [3].)

[1] http://www.lua.org/pil/26.1.html
[2] http://www.lua.org/pil/29.1.html
[3] http://www.lua.org/source/5.3/loslib.c.html#os_date

-- Roberto