Lua [in]security and the distributors

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

Lua [in]security and the distributors

Jonas Thiem
Hi *,

the Lua crash exploit published since April 2013 is unfixed in:

* Debian stable
* Fedora
* OpenSuse
* Ubuntu 12 LTS (still supported)

.. or in other words, every distribution I checked so far. On the IRC
channel people told me that Lua use for sandboxing is very common, so
this seems to be a notable problem.

So, another crazy idea: what about you make front page announcements
for discovered exploits? A bit like the big red boxes libpng uses:
http://www.libpng.org/pub/png/libpng.html

Or maybe the conclusion is just that distributions don't give a sh**
about a secure Lua. Which raises another question: maybe Lua should
release an up-to-date tarball after each discovered bug to make it
easier for people to compile a secure, up-to-date Lua themselves? Last
time I got the response "don't worry about that" which kind of
suggested to let distributors take care of an up-to-date Lua, but
apparently that's not happening.

I am just throwing ideas in the room, maybe none of them are worth
pursueing - but I guess this situation is worth talking about.

Regards,
Jonas Thiem

Reply | Threaded
Open this post in threaded view
|

Re: Lua [in]security and the distributors

Enrico Tassi
On Tue, Aug 26, 2014 at 04:06:22PM +0200, Jonas Thiem wrote:
> the Lua crash exploit published since April 2013 is unfixed in:
>
> * Debian stable

Without a CVE I can hardly convince Debian security people that the fix
is worth it (I'm not fully convinced myself).

I would like to fix Lua 5.1 (for the next stable release), but
unfortunately the patch on the website is for 5.2.2 only.  I'm attaching
a tentative one for 5.1.  I'm not very familiar with the source code, so
help is welcome.  In particular, the attached patch changes the argument
to luaD_checkstack also in the non-vararg case while the bug seems to be
related to vararg functions only.

> .. or in other words, every distribution I checked so far. On the IRC
> channel people told me that Lua use for sandboxing is very common, so
> this seems to be a notable problem.

Which channel?  Using a dynamic language for (real) sandboxing seems a
good recipe for a disaster, and as far as I recall Lua has not been
designed for sandboxing.

> Or maybe the conclusion is just that distributions don't give a sh**

This makes me wonder if you are serious or just trolling.  A patch that
fixes the Debian package would be way more effective that 100 emails
full of asterisks.

Best,
--
Enrico Tassi

Reply | Threaded
Open this post in threaded view
|

Re: Lua [in]security and the distributors

Enrico Tassi
On Tue, Aug 26, 2014 at 04:37:19PM +0200, Enrico Tassi wrote:
> help is welcome.  In particular, the attached patch changes the argument

Here it is,
--
Enrico Tassi

0004-Fix-stack-overflow-in-vararg-functions.patch (669 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Lua [in]security and the distributors

Jonas Thiem
In reply to this post by Enrico Tassi
On Tue, Aug 26, 2014 at 4:37 PM, Enrico Tassi <[hidden email]> wrote:
> On Tue, Aug 26, 2014 at 04:06:22PM +0200, Jonas Thiem wrote:
>> the Lua crash exploit published since April 2013 is unfixed in:
>>
>> * Debian stable
>
> Without a CVE I can hardly convince Debian security people that the fix
> is worth it (I'm not fully convinced myself).

Red Hat has asked for CVE classification:
http://www.openwall.com/lists/oss-security/2014/08/21/2

> Which channel?  Using a dynamic language for (real) sandboxing seems a
> good recipe for a disaster, and as far as I recall Lua has not been
> designed for sandboxing.

#lua on freenode

> This makes me wonder if you are serious or just trolling.  A patch that
> fixes the Debian package would be way more effective that 100 emails
> full of asterisks.

I already mailed Red Hat, helped them out with lots of details on the
bug tracker, and I emailed Ubuntu with no response for days, and I
wrote this email here, and I wrote another email which brought up how
hidden the lua.org/bugs.html page can be to downloading people with
extensive discussion responses.

And your response to this is I am not serious and trolling? Yea, thanks.

What about you HELP me emailing everyone instead of accusing me of
being a troll? At least *I* have already checked distributions and
mailed some of them, have you? (And I brought it up here after all)
Sorry that I haven't emailed the whole world myself yet.

>
> Best,
> --
> Enrico Tassi
>

Reply | Threaded
Open this post in threaded view
|

Re: Lua [in]security and the distributors

Pierre Chapuis
In reply to this post by Enrico Tassi
> On Tue, Aug 26, 2014 at 04:06:22PM +0200, Jonas Thiem wrote:

> Which channel?  Using a dynamic language for (real) sandboxing seems a
> good recipe for a disaster, and as far as I recall Lua has not been
> designed for sandboxing.

It has, or at least even PiL gives an example.
And people do use it for sandboxing.

Here is an example of a sandbox by Roberto:
http://lua-users.org/lists/lua-l/2013-12/msg00406.html


Reply | Threaded
Open this post in threaded view
|

Re: Lua [in]security and the distributors

Pierre Chapuis
In reply to this post by Jonas Thiem
> On Tue, Aug 26, 2014 at 4:37 PM, Enrico Tassi <[hidden email]> wrote:

> What about you HELP me emailing everyone instead of accusing me of
> being a troll? At least *I* have already checked distributions and
> mailed some of them, have you? (And I brought it up here after all)
> Sorry that I haven't emailed the whole world myself yet.

Just so you understand the context: Enrico maintains the
Lua package in Debian.


Reply | Threaded
Open this post in threaded view
|

Re: Lua [in]security and the distributors

Jonas Thiem
Right, that explains some stuff.

Enrico, sorry I blamed the distributors (which includes you?) so
publicly, it is just a bit sad to see how something published in April
2013 is still unfixed everywhere.

As you can see, I already mailed some distributions but not all of
them, since I am also trying to raise awareness about possible issues
with the information politics here. (the Lua website not having
security announcements mainly)

There was no valid reason for getting harsh on the distributors, after
all I guess it is a voluntary effort too. Sorry!

Regards,
Jonas Thiem



On Tue, Aug 26, 2014 at 4:51 PM, Pierre Chapuis <[hidden email]> wrote:

>> On Tue, Aug 26, 2014 at 4:37 PM, Enrico Tassi <[hidden email]> wrote:
>
>> What about you HELP me emailing everyone instead of accusing me of
>> being a troll? At least *I* have already checked distributions and
>> mailed some of them, have you? (And I brought it up here after all)
>> Sorry that I haven't emailed the whole world myself yet.
>
> Just so you understand the context: Enrico maintains the
> Lua package in Debian.
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Lua [in]security and the distributors

Jonas Thiem
In reply to this post by Pierre Chapuis
Just a tiny addition, aside from me trying to write a Lua code game I
also know someone else who has written a coding game that uses Lua for
sandboxing the player code.

On Tue, Aug 26, 2014 at 4:50 PM, Pierre Chapuis <[hidden email]> wrote:

>> On Tue, Aug 26, 2014 at 04:06:22PM +0200, Jonas Thiem wrote:
>
>> Which channel?  Using a dynamic language for (real) sandboxing seems a
>> good recipe for a disaster, and as far as I recall Lua has not been
>> designed for sandboxing.
>
> It has, or at least even PiL gives an example.
> And people do use it for sandboxing.
>
> Here is an example of a sandbox by Roberto:
> http://lua-users.org/lists/lua-l/2013-12/msg00406.html
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Lua [in]security and the distributors

David Heiko Kolf-2
In reply to this post by Jonas Thiem
Jonas Thiem wrote:
> Enrico, sorry I blamed the distributors (which includes you?) so
> publicly, it is just a bit sad to see how something published in April
> 2013 is still unfixed everywhere.

Well, to me the question would be whether this is entirely the
distributors problem. For security related bugs it might help to release
binary compatible new minor versions even of old Lua versions quickly
after a fix is found. Especially of Lua 5.1 as it is probably still the
most widely used version.

Though if a distribution continues to use Lua 5.2.2 instead of 5.2.3 (as
it sounds like in your original mail from 2014-08-21) then of course the
fix won't be in there and it should be obvious to everyone familiar with
program versions. (Released versions should never change).

Best regards,

David Kolf


Reply | Threaded
Open this post in threaded view
|

Re: Lua [in]security and the distributors

Jonas Thiem
There wasn't even a quick release of an update to 5.2.2 where this bug
was found originally, just 5.2.3 a few months later after this bug was
made public (though a patch was available to everyone willing to patch
themselves until 5.2.3 was finally released). So maybe doing a timely
updated release of the *current version* would be a first start before
bothering for the older ones like 5.1.

Also visibility of known issues seems to be a problem, it seems people
just don't check the bug page that often or assume it doesn't hold
security critical stuff that is unpatched in the download page's
latest tarball.


On Tue, Aug 26, 2014 at 7:02 PM, David Heiko Kolf <[hidden email]> wrote:

> Jonas Thiem wrote:
>> Enrico, sorry I blamed the distributors (which includes you?) so
>> publicly, it is just a bit sad to see how something published in April
>> 2013 is still unfixed everywhere.
>
> Well, to me the question would be whether this is entirely the
> distributors problem. For security related bugs it might help to release
> binary compatible new minor versions even of old Lua versions quickly
> after a fix is found. Especially of Lua 5.1 as it is probably still the
> most widely used version.
>
> Though if a distribution continues to use Lua 5.2.2 instead of 5.2.3 (as
> it sounds like in your original mail from 2014-08-21) then of course the
> fix won't be in there and it should be obvious to everyone familiar with
> program versions. (Released versions should never change).
>
> Best regards,
>
> David Kolf
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Lua [in]security and the distributors

Dirk Laurie-2
2014-08-26 19:27 GMT+02:00 Jonas Thiem <[hidden email]>:

> There wasn't even a quick release of an update to 5.2.2 where this bug
> was found originally, just 5.2.3 a few months later after this bug was
> made public (though a patch was available to everyone willing to patch
> themselves until 5.2.3 was finally released).

The official description of Lua's mission is:

> Lua is intended to be used as a powerful, lightweight, embeddable
> scripting language for any program that needs one.

It goes on to say:

> Being an extension language, Lua has no notion of a "main" program:
> it only works embedded in a host client, called the embedding program
> or simply the host.

and:

> The Lua distribution includes a sample host program called lua

I.e. the Lua interpreter we all love is no more than a sample; you
should be rolling your own.

Its license inter alia says this:

> THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY
> OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT
> LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.

I think using Lua in a security-sensitive environment goes beyond
what the designers claim it is good for. It's not that they are insensitive
to security issues, it's that they're not paranoid about them. But: the
only good security people are those considered to be paranoid by
everybody else.

In particular, Lua has a policy that there is one final release of the
outgoing release when a new release comes out. No further fixes,
even if there is a bug reported to be present already in Lua 3.1,
even if it offers a security exploit. That policy says there will never
be an official Lua 5.1.6.

I see only one solution. Someone who _is_ paranoid about security
should maintain a Secure Lua website, where for example
lua-5.1.5-secure.tar.gz would be available. When that site has built up
a reputation for excellence, ask lua.org to feature a link to it.

Reply | Threaded
Open this post in threaded view
|

Re: Lua [in]security and the distributors

Roberto Ierusalimschy
Probably I am missing something...

IIUC, more popular languages similar to Lua have dozens of "crash" bugs
in their current distributions with no patches applied, because there
are no patches for them. Is this ok (no patches applied because there
are no patches)? Would our sin be smaller if our single crash bug had no
known patch?

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Lua [in]security and the distributors

Coda Highland
On Tue, Aug 26, 2014 at 11:57 AM, Roberto Ierusalimschy
<[hidden email]> wrote:

> Probably I am missing something...
>
> IIUC, more popular languages similar to Lua have dozens of "crash" bugs
> in their current distributions with no patches applied, because there
> are no patches for them. Is this ok (no patches applied because there
> are no patches)? Would our sin be smaller if our single crash bug had no
> known patch?
>
> -- Roberto
>

Your "sin", if you could call it that, is that of being an upstream
maintainer in a packaging culture that pushes everything upstream if
at all possible.

/s/ Adam

Reply | Threaded
Open this post in threaded view
|

Re: Lua [in]security and the distributors

Florian Weimer
In reply to this post by Enrico Tassi
* Enrico Tassi:

> On Tue, Aug 26, 2014 at 04:37:19PM +0200, Enrico Tassi wrote:
>> help is welcome.  In particular, the attached patch changes the
>> argument
>
> Here it is,

I think the release team would accept this change for a point release:

<https://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload-stable>

Unless we ship existing Lua code which exposes this (i.e., not just
via loadstring), Debian won't issue a separate security advisory for
this bug.

Reply | Threaded
Open this post in threaded view
|

Re: Lua [in]security and the distributors

Matthew Wild
In reply to this post by Coda Highland
On 26 August 2014 20:31, Coda Highland <[hidden email]> wrote:
> Your "sin", if you could call it that, is that of being an upstream
> maintainer in a packaging culture that pushes everything upstream if
> at all possible.

Personally I think this "culture" is sensible. I'm an upstream
developer and consider it my responsibility to make the lives of
packagers as easy as possible - I'm the one who is most experienced
with the project, not them. At the end of the day I approach it this
way because I want good quality software in the hands of my users.

Regards,
Matthew

Reply | Threaded
Open this post in threaded view
|

Re: Lua [in]security and the distributors

Jay Carlson
In reply to this post by Roberto Ierusalimschy
On Aug 26, 2014, at 2:57 PM, Roberto Ierusalimschy <[hidden email]> wrote:

> Would our sin be smaller if our single crash bug had no
> known patch?

No. We especially love localized patches. They aren't sins, they're acts of benevolence. We want to use those patches. Because this patch doesn't really have a name (nor does 5.2.3+patch have a name) fewer people knew about this good work.

Full releases are a pain, and I don't want you to avoid disclosing experimental or one-off patches because it would imply a full release.  

Perhaps after a week or so on the mailing list, you could say: "OK, let's give our patch from 2014-04-01 the name '5.2.3 post1'." I think search engines would index that, so anybody could find your mailing list message. Obviously, 5.2.4 would later roll up those patches.

But having patches at all is better than keeping clean naming and no patches.

With software at this level of stability, it is sometimes difficult to do anything with names. In retrospect, I made a mess once from not wanting to name things. I had patched "1.8.0p6" to "1.8.0r1", "1.8.0r2", ending up at "1.8.1". Then I stopped naming things. Later, the next maintainer had to skip to "1.8.3" because there were so many third-party patchsets prematurely naming themselves "1.8.2". Mea culpa.

In the age of git, it's not such a big deal for a third party to play "patch secretary". De facto, a Debian maintainer has always been the secretary of last resort.

Jay
Reply | Threaded
Open this post in threaded view
|

Re: Lua [in]security and the distributors

Enrico Tassi
In reply to this post by Roberto Ierusalimschy
On Tue, Aug 26, 2014 at 03:57:39PM -0300, Roberto Ierusalimschy wrote:
> Probably I am missing something...
>
> IIUC, more popular languages similar to Lua have dozens of "crash" bugs
> in their current distributions with no patches applied, because there
> are no patches for them. Is this ok (no patches applied because there
> are no patches)? Would our sin be smaller if our single crash bug had no
> known patch?

Roberto, could you please comment on my patch for 5.1?
Is it correct?  Distro still ship 5.1 after all.

Best,
--
Enrico Tassi

Reply | Threaded
Open this post in threaded view
|

Re: Lua [in]security and the distributors

Roberto Ierusalimschy
> Roberto, could you please comment on my patch for 5.1?
> Is it correct?  Distro still ship 5.1 after all.

I would say it is correct: It seems logically correct, and it also
passes all standard tests plus the example for the problem.

-- Roberto


Reply | Threaded
Open this post in threaded view
|

Re: Lua [in]security and the distributors

Jonas Thiem
In reply to this post by Roberto Ierusalimschy

On 08/26/2014 08:57 PM, Roberto Ierusalimschy wrote:

> Probably I am missing something...
>
> IIUC, more popular languages similar to Lua have dozens of "crash" bugs
> in their current distributions with no patches applied, because there
> are no patches for them. Is this ok (no patches applied because there
> are no patches)? Would our sin be smaller if our single crash bug had no
> known patch?
>
> -- Roberto
>

I see two obvious choices:

1. You could simply announce Lua is unsuitable for sandboxing. However,
that would be sad since in practice many use it for that, and they
probably won't stop doing that.

2. You could make more visible security announcements on the homepage
when crash bugs (or other critical things) appear. (compare libpng
website with very prominent security notices)

I think the only problem here is communication, mainly that the website
offers an example demo sandbox and doesn't necessarily communicate 1.,
and that 2. wasn't really followed either.

It is very commendable that you released a timely patch in April 2013
and as you correctly noted: not all scripting languages watch their
crash exploits so closely. This makes Lua a lot more suitable and safer
for sandboxing than other languages, which is awesome!

It is more a case of "we can do even better with slight alterations",
rather than "Lua screwed up": it is just sad the patch WAS available,
and still wasn't adopted. That isn't a sin, but rather just awesomeness
that could have been but wasn't - and which would be worth pursuing.

Regards,
Jonas Thiem

Reply | Threaded
Open this post in threaded view
|

Re: Lua [in]security and the distributors

Roberto Ierusalimschy
> I see two obvious choices:
>
> [...]

I forgot to enclose my message in <sarcasm> ... </sarcasm> :-)

-- Roberto

12