upvote

points

by theamk14 hours ago |
comments
upvoteby strenholme11 hours ago|
next
[-]
I should explain how MaraDNS uses Lua 5.1 (actually, Lunacy, my own fork with security bugs fixed as well as security hardening—including, yes, a patch against CVE-2014-5461), so you can get an idea of its attack surface.

MaraDNS has three components:

• MaraDNS, the authoritative server, which goes back all the way to 2001

• Deadwood, the recursive server, which was started back in 2007

• coLunacyDNS, which allows a DNS server to use Lua scripting; this didn’t exist until the COVID pandemic

Neither MaraDNS nor Deadwood use Lunacy (except as a scripting engine for converting documents); only coLunacyDNS uses Lunacy. coLunacyDNS uses a sandboxed and security hardened version of Lunacy (and, yes, I would accept bugs where someone could escape that sandbox), and the Lua scripts which coLunacyDNS uses can only be controlled by a local user and there is no capability to run Lua scripts remotely.

reply
upvoteby koolba11 hours ago|
parent|
[-]
> coLunacyDNS, which allows a DNS server to use Lua scripting; this didn’t exist until the COVID pandemic

Why would a DNS server use Lua scripting? Is this for dynamically responding to requests rather than doing a pure lookup?

reply
upvoteby strenholme11 hours ago|
parent|
[-]
It’s useful for things like 10.1.2.3.ip4.internal style queries, or having a DNS server that always returns a given IP for any query given to it.

More discussion is on the coLunacyDNS overview page:

https://samboy.github.io/MaraDNS/coLunacyDNS/

reply
upvoteby shakna13 hours ago|
prev|
next
[-]
Its important to maintain your dependencies, by say embedding Lua, rather than rebranding it and then claiming you have no security flaws.

If I can find a CVE that _may_ affect the stack in five minutes, what _actual_ problems lurk there?

You vendor Lua - thus, it _is_ your responsibility to review every Lua CVE. You've set yourself up as the maintainer by vendoring.

reply
upvoteby strenholme11 hours ago|
parent|
next
[-]
You weren’t replying to me. The parent poster made a good point—a vulnerability in Lua doesn’t mean software running Lua can necessarily be exploited—but, more to the point, I do update Lunacy and make sure it’s secure, just as I still take responsibility for verified important security holes in MaraDNS.

See this, for example:

https://samboy.github.io/MaraDNS/webpage/security.html#CVE-2...

reply
upvoteby selectively13 hours ago|
parent|
prev|
[-]
[flagged]
reply
upvoteby cesarb12 hours ago|
prev|
next
[-]
> It's important to look at the actual vulnerability at the context, and not just list any CVE which matches by version.

Unfortunately, that's not enough. Even if the vulnerable parts of the code are not being built, heck even if they have been completely erased from the source code, the auditors will still insist that you're vulnerable and must immediately upgrade, or else they will give your software a failing grade.

reply
upvoteby ajross13 hours ago|
prev|
[-]
That seems wildly naive in the post-XSS era. We've been here before, and that kind of analysis turns out to be wrong almost every time.

"Well, sure, this component is insecure but an attacker can't reach it" is like a 50%+ positive signal for an unexpected privilege elevation bug.

reply