Lua exposure to C vulnerabilities?

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Lua exposure to C vulnerabilities?

Russell Haley
I'm throwing this out there as a general discussion. I only have a dilitants understanding of c and security (and I'm on my phone, so typing is at a premium). 

I have understood that some languages written in C suffer from security vulnerabilities inherent in the host language. What are the chances that Lua also suffered from such vulnerabilities? If you wish to simply point to external References that would be fine. 

Thanks!
Russ



Sent from my BlackBerry 10 smartphone on the Virgin Mobile network.
Reply | Threaded
Open this post in threaded view
|

Re: Lua exposure to C vulnerabilities?

Florian Weimer
* Russell Haley:

> I have understood that some languages written in C suffer from
> security vulnerabilities inherent in the host language.

That's only true for languages which provide access to the C type
system or something closely related (C++ is the prime example).  Lua
does not do this.

Reply | Threaded
Open this post in threaded view
|

Re: Lua exposure to C vulnerabilities?

Russell Haley
Thanks Florian. So does interfacing a C library (written poorly by me!) with Lua ‎protect me from potential vulnerabilities in that library?

Russ

Sent from my BlackBerry 10 smartphone on the Virgin Mobile network.
  Original Message  
From: Florian Weimer
Sent: Sunday, September 18, 2016 11:19 AM
To: [hidden email]
Reply To: Lua mailing list
Subject: Re: Lua exposure to C vulnerabilities?

* Russell Haley:

> I have understood that some languages written in C suffer from
> security vulnerabilities inherent in the host language.

That's only true for languages which provide access to the C type
system or something closely related (C++ is the prime example). Lua
does not do this.


Reply | Threaded
Open this post in threaded view
|

Re: Lua exposure to C vulnerabilities?

Tim Hume
Hi Russ,

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.

Cheers,

Tim.

On Sun, 18 Sep 2016, Russell Haley wrote:

> Thanks Florian. So does interfacing a C library (written poorly by me!)
> with Lua protect me from potential vulnerabilities in that library?
>
> Russ
>
> Sent from my BlackBerry 10 smartphone on the Virgin Mobile network.
>   Original Message From: Florian Weimer Sent: Sunday, September 18, 2016
> 11:19 AM To: [hidden email] Reply To: Lua mailing list Subject: Re:
> Lua exposure to C vulnerabilities?
>
> * Russell Haley:
>
>> I have understood that some languages written in C suffer from
>> security vulnerabilities inherent in the host language.
>
> That's only true for languages which provide access to the C type
> system or something closely related (C++ is the prime example). Lua
> does not do this.
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Lua exposure to C vulnerabilities?

Soni "They/Them" L.


On 18/09/16 07:38 PM, Tim Hume wrote:

> Hi Russ,
>
> 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.
>
> Cheers,
>
> Tim.
>
> On Sun, 18 Sep 2016, Russell Haley wrote:
>
>> Thanks Florian. So does interfacing a C library (written poorly by
>> me!) with Lua protect me from potential vulnerabilities in that library?
>>
>> Russ
>>
>> Sent from my BlackBerry 10 smartphone on the Virgin Mobile network.
>>   Original Message From: Florian Weimer Sent: Sunday, September 18,
>> 2016 11:19 AM To: [hidden email] Reply To: Lua mailing list
>> Subject: Re: Lua exposure to C vulnerabilities?
>>
>> * Russell Haley:
>>
>>> I have understood that some languages written in C suffer from
>>> security vulnerabilities inherent in the host language.
>>
>> That's only true for languages which provide access to the C type
>> system or something closely related (C++ is the prime example). Lua
>> does not do this.
>>
>>
>>

So, like, an io.open with a very large filename could allow arbitrary
code execution? O_o

--
Disclaimer: these emails may be made public at any given time, with or without reason. If you don't agree with this, DO NOT REPLY.


Reply | Threaded
Open this post in threaded view
|

Re: Lua exposure to C vulnerabilities?

Tim Hume
>
> So, like, an io.open with a very large filename could allow arbitrary code
> execution? O_o
>
>
Don't know about io.open, ... but the original poster said it was his own
C library he was interfacing. So who knows what could happen inside the C
library when the code is run from a Lua program, or anything else for that
matter? The solution is to fix the root cause of the problem.

Cheers,

Tim.

Reply | Threaded
Open this post in threaded view
|

Re: Lua exposure to C vulnerabilities?

Russell Haley
I agree that fixing instability in one's code is best. However, the library is hypothetical. (note, I only have a rudimentary understanding of these issues.) If my 'library' failed to do proper bounds checking and had the potential for buffer overruns (for example) when exposed to a network, would calling said library from Lua protect me?

Russ

Sent from my BlackBerry 10 smartphone on the Virgin Mobile network.
  Original Message  
From: Tim Hume
Sent: Sunday, September 18, 2016 3:53 PM
To: Lua mailing list
Reply To: Lua mailing list
Subject: Re: Lua exposure to C vulnerabilities?

>
> So, like, an io.open with a very large filename could allow arbitrary code
> execution? O_o
>
>
Don't know about io.open, ... but the original poster said it was his own
C library he was interfacing. So who knows what could happen inside the C
library when the code is run from a Lua program, or anything else for that
matter? The solution is to fix the root cause of the problem.

Cheers,

Tim.


Reply | Threaded
Open this post in threaded view
|

Re: Lua exposure to C vulnerabilities?

Coda Highland
On Sun, Sep 18, 2016 at 5:36 PM, Russell Haley <[hidden email]> wrote:
> I agree that fixing instability in one's code is best. However, the library is hypothetical. (note, I only have a rudimentary understanding of these issues.) If my 'library' failed to do proper bounds checking and had the potential for buffer overruns (for example) when exposed to a network, would calling said library from Lua protect me?
>
> Russ

No, it would not protect you that way.

Best practices when it comes to writing secure code amounts to "don't
do it yourself."

If you want Lua to protect you, then don't write your library in C --
write as much of it as possible in Lua, and only call out to C for the
parts that you can't do in Lua (or that profiling shows is
prohibitively expensive in Lua).

If you must write your code in C, then still don't do stuff yourself.
For example, don't allocate buffers manually; use a library. Don't use
[] notation to access arrays through a pointer; use a bounds-checked
accessor that knows the size of the content.

/s/ Adam

Reply | Threaded
Open this post in threaded view
|

Re: Lua exposure to C vulnerabilities?

Russell Haley
Thank you that's really what I needed to know. I am writing everything in Lua so far but there are libraries I am using that rely on C such as luaxml and luasys (possibly to be replaced with cqueues). ‎It made me curious as to the protection afforded me by the abstraction of calling C from Lua. 

Russ

Sent from my BlackBerry 10 smartphone on the Virgin Mobile network.
  Original Message  
From: Coda Highland
Sent: Sunday, September 18, 2016 5:44 PM
To: Lua mailing list
Reply To: Lua mailing list
Subject: Re: Lua exposure to C vulnerabilities?

On Sun, Sep 18, 2016 at 5:36 PM, Russell Haley <[hidden email]> wrote:
> I agree that fixing instability in one's code is best. However, the library is hypothetical. (note, I only have a rudimentary understanding of these issues.) If my 'library' failed to do proper bounds checking and had the potential for buffer overruns (for example) when exposed to a network, would calling said library from Lua protect me?
>
> Russ

No, it would not protect you that way.

Best practices when it comes to writing secure code amounts to "don't
do it yourself."

If you want Lua to protect you, then don't write your library in C --
write as much of it as possible in Lua, and only call out to C for the
parts that you can't do in Lua (or that profiling shows is
prohibitively expensive in Lua).

If you must write your code in C, then still don't do stuff yourself.
For example, don't allocate buffers manually; use a library. Don't use
[] notation to access arrays through a pointer; use a bounds-checked
accessor that knows the size of the content.

/s/ Adam


Reply | Threaded
Open this post in threaded view
|

Re: Lua exposure to C vulnerabilities?

Sean Conner
It was thus said that the Great Russell Haley once stated:

> Thank you that's really what I needed to know. I am writing everything in
> Lua so far but there are libraries I am using that rely on C such as
> luaxml and luasys (possibly to be replaced with cqueues). It made me
> curious as to the protection afforded me by the abstraction of calling C
> from Lua. 

  You still have to be careful to call the proper Lua functions.  This
function may casue the program to crash:

        int cancrash(lua_State *L)
        {
          lua_pushinteger(L,strlen(lua_tostring(L,1)));
          return 1;
        }

whereas this one won't (Lua will throw an error):

        int nocrash(lua_State *L)
        {
          lua_pushinteger(L,strlen(luaL_checkstring(L,1)));
          return 1;
        }

  -spc


Reply | Threaded
Open this post in threaded view
|

AW: Lua exposure to C vulnerabilities?

Eike Decker
In reply to this post by Russell Haley

It hasn’t mentioned yet and I am not entirely sure, but loading compiled Lua code (binary files) is insecure too I believe, as instructions in that byte code can do various nefarious things.

 

Cheers,

Eike

 

 

Von: [hidden email]
Gesendet: Sonntag, 18. September 2016 18:29
An: [hidden email]
Betreff: Lua exposure to C vulnerabilities?

 

I'm throwing this out there as a general discussion. I only have a dilitants understanding of c and security (and I'm on my phone, so typing is at a premium). 

 

I have understood that some languages written in C suffer from security vulnerabilities inherent in the host language. What are the chances that Lua also suffered from such vulnerabilities? If you wish to simply point to external References that would be fine. 

 

Thanks!

Russ

 

 

 

Sent from my BlackBerry 10 smartphone on the Virgin Mobile network

 

 

 

 

Reply | Threaded
Open this post in threaded view
|

Re: AW: Lua exposure to C vulnerabilities?

Laurent FAILLIE
Hello,

> If my 'library' failed to do proper bounds checking and had the potential for buffer overruns (for example)
> when exposed to a network, would calling said library from Lua protect me?



First of all, the problem is not due to C language but too the library itself ... and the problem is the same if you call it from any language.
I mean, as long as you call this library API, the "upper" language has strictly no way to prevent buffer overrun or such : the controle is totaly on the hands of the library developper.
You may reduce the risk by checking arguments before API calls (but it's true to whatever language), but unsecure library will remain unsecure.

Bye

Laurent
Reply | Threaded
Open this post in threaded view
|

Re: Lua exposure to C vulnerabilities?

Roberto Ierusalimschy
In reply to this post by Tim Hume
> 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

Reply | Threaded
Open this post in threaded view
|

Re: Lua exposure to C vulnerabilities?

Florian Weimer
In reply to this post by Russell Haley
* Russell Haley:

> Thanks Florian. So does interfacing a C library (written poorly by
> me!) with Lua ‎protect me from potential vulnerabilities in that
> library?

It depends what you are doing.  Lua itself tries to prevent crashing
the program by misusing libc functions (no malloc and free, for
example).  Your Lua wrapper could do something similar.

It will not magically fix vulnerabilities that are unrelated to misuse
of library interfaces, though.

For example, if a DNS processing library has name resolution context
allocation and deallocation functions, the Lua interface could make
sure that you cannot call them in the wrong order, and thus avoid
issues related to that (use-after-free problems, for example).  But if
the DNS library crashes while processing certain DNS responses, the
Lua wrapper will not affect that at all.