kernelsauce / turbo

Turbo is a framework built for LuaJIT 2 to simplify the task of building fast and scalable network applications. It uses a event-driven, non-blocking, no thread design to deliver excellent performance and minimal footprint to high-load applications while also providing excellent support for embedded uses.
http://turbo.readthedocs.io/
Apache License 2.0
525 stars 84 forks source link

Security Issues associated with Debug Library Functions debug.getinfo and debug,traceback #354

Open GINUGEORGE opened 4 years ago

GINUGEORGE commented 4 years ago

Security Issues associated with Debug Library Functions debug.getinfo and debug,traceback

WRT https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-19391

debug.getinfo has a type confusion issue that leads to arbitrary memory write or read operations, because certain cases involving valid stack levels and > options are mishandled.

NOTE: The LuaJIT project owner states that the debug libary is unsafe by definition and that this is not a vulnerability. When LuaJIT was originally developed, the expectation was that the entire debug library had no security guarantees and thus it made no sense to assign CVEs. However, not all users of later LuaJIT derivatives share this perspective.

WRT https://www.lua.org/pil/23.html

Unlike the other libraries, you should use the debug library with parsimony. First, some of its functionality is not exactly famous for performance. Second, it breaks some sacred truths of the language, such as that you cannot access a local variable from outside the function that created it.

WRT http://lua-users.org/wiki/DebugLibraryTutorial

6.10 – The Debug Library

This library provides the functionality of the debug interface to Lua programs. You should exert care when using this library. Several of its functions violate basic assumptions about Lua code (e.g., that variables local to a function cannot be accessed from outside; that userdata metatables cannot be changed by Lua code; that Lua programs do not crash) and therefore can compromise otherwise secure code. Moreover, some functions in this library may be slow.

Also Refer https://github.com/LuaJIT/LuaJIT/pull/526.

As per the above excerpts, debug library functions should be avoided using in Production Environments. But in the turbo lua source code, we can see that certain debug library functions such as debug.getinfo and debug.traceback have been used in the below mentioned files :

debug.traceback - https://github.com/kernelsauce/turbo/blob/master/turbo/ioloop.lua#L524

debug.getinfo - https://github.com/kernelsauce/turbo/blob/master/turbo/log.lua#L284

Is it safe to use these functions in the Production Environment ? Please justify the usage and share your suggestions/inputs.

kernelsauce commented 3 years ago

Yes, I agree it is not optimal to use this. It is simple to remove the stack tracing that it is used for, its only for ease of debugging and does not serve any function beyond that. But given the circumstance that it is used its unlikely that it is exploitable. Correct me if I'm wrong.

hippi777 commented 3 years ago

hi folks :)

i didnt give a feedback to this previously only cuz its a matter of ensuring that no abuse can happen, and ive thought that once upon the time i will check myself if theres anything to be afraid of or not or what should be done to play safe... for a sandbox, users must not reach the raw debug stuffs (neither on puc lua), but they can get tools that utilize anything from there behind the scenes without getting any ability to give these malicious input, or abuse output(?), while here the question is if a request (or any resulting stored data) that could reach these functions could do any harm to either the sysadmin or the rest of the users, but using the debug lib only takes extra caution, not changes the game... here, its about validating the input, and/or tracking down what functions use these, but on the 1st place i would worry about nasty requests in general, and i would test spec chars, marginal/extreme lengths, erroneous protocol usages and weird header usage, doing this either/both while reading the codes to see what data travels where, or via fuzzing, both to try to attack turbo and any application that is written on top of it, while probably the greatest attack-vector is still most possible in any custom app running on top of it :D

(sorry if i have said nothing but the obvious stuffs :D )