top | item 41142969

(no title)

csears | 1 year ago

Would that be safe even with untrusted data? (Assuming you were the one who serialized and compiled the table)

discuss

order

pansa2|1 year ago

Lua should be robust in the face of untrusted source code. However untrusted bytecode is unsafe.

Dylan16807|1 year ago

Are you asking if there are special numbers or strings or some other kind of plain data that would glitch out the interpreter when they're read back in? That would be an impressive failure of a programming language.

Yes it's safe as long as you're serializing correctly (which isn't very hard).

wahern|1 year ago

By definition you can't trust that "untrusted data" has been serialized correctly.

Lua has strong sandboxing capabilities (i.e. ability to limit and control the environment visible from a chunk of code), but the Lua authors years ago explicitly disclaimed the ability to sandbox untrusted code. The compiler and runtime are not bug free. They don't have the resources, notwithstanding that compared to any other non-formally verified implementation their track record is pretty decent, even compared to past and current efforts from Sun, Microsoft, Mozilla, and Google. If you want to run untrusted Lua code, Lua sandboxing should be just the first of multiple line of defense, just as modern web browsers rely on various operating system mechanisms to constrain breakouts.

wahern|1 year ago

By definition you can't trust that "untrusted data" has been serialized correctly.

Lua has strong sandboxing capabilities (i.e. ability to limit and control the environment visible from a chunk of code), but the Lua authors years ago explicitly disclaimed the ability to sandbox untrusted code. The compiler and runtime are not bug free. They don't have the resources, notwithstanding that compared to any other non-formally verified implementation their track record is pretty decent, even compared to past and current efforts from Sun, Microsoft, Mozilla, and Google. If you want to run untrusted Lua code, Lua sandboxing should be just the first of multiple line of defense, just as modern web browsers rely on various operating system mechanisms (process separation, filesystem to constrain breakouts.