Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove embedded luasocket and prepare proper linking #5

Closed
wants to merge 1 commit into from
Closed

Remove embedded luasocket and prepare proper linking #5

wants to merge 1 commit into from

Conversation

horazont
Copy link
Contributor

Hi everyone,

This is the second of two pull requests (the first being against luasocket). Please read the linked luasocket pull request for all the details, I'll give a short summary here.

With the two fixes, it is possible to properly use luasec and luasocket without the duplicated code in the luasec repository. Luasocket has been modified to export the required symbols. This should fix any issues which arose, arise and will in future arise from inconsistency between luasec and luasocket.

If you have any suggestions for improvements or any kind of critique, please let me know so that we can fix that quickly.

best regards,
Jonas

@brunoos
Copy link
Member

brunoos commented Jan 30, 2014

It is easier to link version 0.5 against LuaSocket... if LuaSocket permits.

The code from LuaSocket 3.0 remains, so that LuaSec works out of the box.

@brunoos brunoos closed this Jan 30, 2014
Zash added a commit to Zash/luasec that referenced this pull request Aug 12, 2021
Background:

The SSL Context has a reference to the Lua state, commonly called L, for
use when invoking callbacks during TLS handshaking.

Earlier there was a crash due to the Lua State having changed between
context creation and access to it during TLS handshake.  This could
happen if the TLS context is created in one coroutine, which has
subsequently been garbage collected and its memory become invalid,
whereafter the TLS context is used to negotiate a TLS connection which
involves calling some callback.

Observation:

SIGSEGV in alpn_cb(), where arg/ctx -> L does not match the L earlier in
the stack, in meth_handshake().

    #0  __strcmp_sse2 () at ../sysdeps/x86_64/strcmp.S:1447
    lunarmodules#1  0x00005589415b1e1a in luaS_new (L=L@entry=0x5589444880a8, str=str@entry=0x7ff3f94b160e "SSL:ALPN:Registry") at lstring.c:246
    lunarmodules#2  0x00005589415a47b2 in auxgetstr (L=0x5589444880a8, t=0x558944488188, k=k@entry=0x7ff3f94b160e "SSL:ALPN:Registry") at lapi.c:617
    lunarmodules#3  0x00005589415a575b in lua_getfield (L=L@entry=0x5589444880a8, idx=idx@entry=-1001000, k=k@entry=0x7ff3f94b160e "SSL:ALPN:Registry") at lapi.c:657
    lunarmodules#4  0x00007ff3f94af3c5 in alpn_cb (s=<optimized out>, out=0x7ffdda0dc260, outlen=0x7ffdda0dc25f "", in=0x558943d14570 "\vxmpp-client", inlen=12, arg=0x55894450d2a8) at src/context.c:660
    lunarmodules#5  0x00007ff3f946751c in tls_handle_alpn (s=0x558943d6d540) at ../ssl/statem/statem_srvr.c:2147
    lunarmodules#6  0x00007ff3f944ddd8 in tls_parse_all_extensions (s=s@entry=0x558943d6d540, context=context@entry=128, exts=<optimized out>, x=x@entry=0x0, chainidx=chainidx@entry=0, fin=fin@entry=1) at ../ssl/statem/extensions.c:761
    lunarmodules#7  0x00007ff3f94677bc in tls_early_post_process_client_hello (s=0x558943d6d540) at ../ssl/statem/statem_srvr.c:1881
    lunarmodules#8  tls_post_process_client_hello (s=0x558943d6d540, wst=<optimized out>) at ../ssl/statem/statem_srvr.c:2225
    lunarmodules#9  0x00007ff3f945726b in read_state_machine (s=0x558943d6d540) at ../ssl/statem/statem.c:664
    lunarmodules#10 state_machine (s=0x558943d6d540, server=1) at ../ssl/statem/statem.c:434
    lunarmodules#11 0x00007ff3f9442f74 in SSL_do_handshake (s=0x558943d6d540) at ../ssl/ssl_lib.c:3615
    lunarmodules#12 0x00007ff3f94ad44f in handshake (ssl=0x558944811648) at src/ssl.c:120
    lunarmodules#13 meth_handshake (L=0x5589432a2268) at src/ssl.c:388
    lunarmodules#14 0x00005589415a8e61 in luaD_precall (L=L@entry=0x5589432a2268, func=func@entry=0x558944223f20, nresults=2) at ldo.c:503

    (gdb) frame 13
    lunarmodules#13 meth_handshake (L=0x5589432a2268) at src/ssl.c:388
    (gdb) p ctx
    $1 = (p_context) 0x5589433ab508

This is passed as 'arg' to alpn_cb(), note different pointer
arg=0x55894450d2a8.

Theory:

When selecting a context during SNI negotiation, the selected context
would be a different one from the one where meth_handshake() has updated
the Lua state reference. Thus the reference can still be invalid and
cause a crash when invoving a callback afterwards, such as the ALPN one.

Solution:

Update the Lua state reference on the selected SSL context after SNI.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants