Lua is much easier to sandbox than any other language I know of; basically it’s a one-liner to take a piece of code you’ve loaded and ensure it has no access to any functions outside the whitelist you provide. I would be terrified of such a feature if it used Javascript or something, but doing this securely in Lua is not that difficult.
Both Redis and Company of Heroes 2 have been exploited through LUA sandbox escapes. JavaScript has similar properties as LUA in that it generally doesn’t assume to have any connection to the outside world and comes with no garbage preloaded. On top of that, JS interpreters are used in browsers and hardened for that use.
I’d say that if Javascript were a fundamental issue, systems like CouchDB which expose Spidermonkey to the real world would have exploits found there. I can’t find one at quick glance.
5.1 was easy to attack because the Lua equivalents of eval would happily execute compiled bytecode. You can run arbitrary scripts safely in a sandbox but not arbitrary bytecode.
From 5.2 onwards you can pass an argument so the eval like functions ignore bytecode.
I’m not saying issues cannot be fixed as they come. I’m saying that I don’t buy the argument that Lua is that much of a safer option then stock V8 or Spidermonkey. The latter are exposed to attempts quite regularly.
V8 didn’t even exist at the time Lua 5.1 came out. Even with 5.2, the escapes all come from loading bytecode; they don’t seem relevant to the topic of loading source.
V8 has so many critical security vulnerabilities that Debian doesn’t even attempt to keep up with security updates in the stable release; they recommend that it “should not currently be used with untrusted content, such as unsanitized data from the Internet. “
Eh… I don’t think that’s a fair comparison since Redis is written in C and CouchDB is written in Erlang; obviously the latter will have a much better security track record.
Remote code execution through calling loaded C functions or reading data from memory in a database server doesn’t require any support of the host language.
So, I totally appreciate where you’re coming from here, and appreciate the background info around Lua, security, and embeddability.
I guess for me things like DNS belong in a ring of services where the server software for them is mega-hardened as much as is humanly possible. I’ve known about PowerDNS for years and worked at companies where it’s been implemented. It has a well earned reputation for solidity. Hopefully this is a configurable you can compile out for those who want to be ultra-paranoid.
On the one hand this sounds really cool. On the OTHER hand - exploits anyone? :)
Lua is much easier to sandbox than any other language I know of; basically it’s a one-liner to take a piece of code you’ve loaded and ensure it has no access to any functions outside the whitelist you provide. I would be terrified of such a feature if it used Javascript or something, but doing this securely in Lua is not that difficult.
Both Redis and Company of Heroes 2 have been exploited through LUA sandbox escapes. JavaScript has similar properties as LUA in that it generally doesn’t assume to have any connection to the outside world and comes with no garbage preloaded. On top of that, JS interpreters are used in browsers and hardened for that use.
I’d say that if Javascript were a fundamental issue, systems like CouchDB which expose Spidermonkey to the real world would have exploits found there. I can’t find one at quick glance.
http://benmmurphy.github.io/blog/2015/06/04/redis-eval-lua-sandbox-escape/
https://gist.github.com/corsix/6575486
https://www.cvedetails.com/vulnerability-list/vendor_id-45/product_id-19046/Apache-Couchdb.html
5.1 was easy to attack because the Lua equivalents of
evalwould happily execute compiled bytecode. You can run arbitrary scripts safely in a sandbox but not arbitrary bytecode.From 5.2 onwards you can pass an argument so the
evallike functions ignore bytecode.People have found sandbox escapes in Lua 5.2.
I’m not saying issues cannot be fixed as they come. I’m saying that I don’t buy the argument that Lua is that much of a safer option then stock V8 or Spidermonkey. The latter are exposed to attempts quite regularly.
https://apocrypha.numin.it/talks/lua_bytecode_exploitation.pdf
V8 didn’t even exist at the time Lua 5.1 came out. Even with 5.2, the escapes all come from loading bytecode; they don’t seem relevant to the topic of loading source.
V8 has so many critical security vulnerabilities that Debian doesn’t even attempt to keep up with security updates in the stable release; they recommend that it “should not currently be used with untrusted content, such as unsanitized data from the Internet. “
https://www.debian.org/releases/stretch/amd64/release-notes/ch-information.en.html#libv8
Eh… I don’t think that’s a fair comparison since Redis is written in C and CouchDB is written in Erlang; obviously the latter will have a much better security track record.
Remote code execution through calling loaded C functions or reading data from memory in a database server doesn’t require any support of the host language.
So, I totally appreciate where you’re coming from here, and appreciate the background info around Lua, security, and embeddability.
I guess for me things like DNS belong in a ring of services where the server software for them is mega-hardened as much as is humanly possible. I’ve known about PowerDNS for years and worked at companies where it’s been implemented. It has a well earned reputation for solidity. Hopefully this is a configurable you can compile out for those who want to be ultra-paranoid.