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

Segfault when setting key for chacha20 #51

Closed
mscdex opened this issue Oct 9, 2021 · 3 comments
Closed

Segfault when setting key for chacha20 #51

mscdex opened this issue Oct 9, 2021 · 3 comments

Comments

@mscdex
Copy link

mscdex commented Oct 9, 2021

As in #50, I'm only explicitly compiling in support for chacha20, however when I set the key via PRAGMA key = 'foobarbaz', I get a segfault. Here's the backtrace:

0x00007ffff41dccfd in sqlite3mcGetCipherParameter (cipherParams=0x7ffff41dd14c <sqlite3mcFreeCodecParameterTable>, paramName=0x7ffff41f8f5f "legacy") at ../deps/sqlite3/sqlite3mc_amalgamation.c:256475
256475	  for (; strlen(cipherParams->m_name) > 0; ++cipherParams)
(gdb) bt
#0  0x00007ffff41dccfd in sqlite3mcGetCipherParameter (cipherParams=0x7ffff41dd14c <sqlite3mcFreeCodecParameterTable>, paramName=0x7ffff41f8f5f "legacy") at ../deps/sqlite3/sqlite3mc_amalgamation.c:256475
#1  0x00007ffff41dc01f in AllocateChaCha20Cipher (db=0x4a22050) at ../deps/sqlite3/sqlite3mc_amalgamation.c:255434
#2  0x00007ffff41dd5d3 in sqlite3mcCodecSetup (codec=0x7fffe0008950, cipherType=3, userPassword=0x4a35470 "foobarbaz", passwordLength=9) at ../deps/sqlite3/sqlite3mc_amalgamation.c:256716
#3  0x00007ffff41e13ee in sqlite3mcCodecAttach (db=0x4a22050, nDb=0, zPath=0x4a22eac "/tmp/encrypted.db", zKey=0x4a35470, nKey=9) at ../deps/sqlite3/sqlite3mc_amalgamation.c:258683
#4  0x00007ffff41e1654 in sqlite3_key_v2 (db=0x4a22050, zDbName=0x0, zKey=0x4a35470, nKey=9) at ../deps/sqlite3/sqlite3mc_amalgamation.c:258758
#5  0x00007ffff41dfdba in sqlite3mcFileControlPragma (db=0x4a22050, zDbName=0x0, op=14, pArg=0x7fffe7ffddd0) at ../deps/sqlite3/sqlite3mc_amalgamation.c:257939
#6  0x00007ffff413af73 in sqlite3Pragma (pParse=0x7fffe7ffea90, pId1=0x7fffe7ffe0d8, pId2=0x7fffe7ffe0f0, pValue=0x7fffe7ffe120, minusFlag=0) at ../deps/sqlite3/sqlite3mc_amalgamation.c:129007
#7  0x00007ffff4176a94 in yy_reduce (yypParser=0x7fffe7ffe090, yyruleno=247, yyLookahead=1, yyLookaheadToken=..., pParse=0x7fffe7ffea90) at ../deps/sqlite3/sqlite3mc_amalgamation.c:162666
#8  0x00007ffff4177fd5 in sqlite3Parser (yyp=0x7fffe7ffe090, yymajor=1, yyminor=...) at ../deps/sqlite3/sqlite3mc_amalgamation.c:163298
#9  0x00007ffff4179227 in sqlite3RunParser (pParse=0x7fffe7ffea90, zSql=0x4a35588 "", pzErrMsg=0x7fffe7ffea68) at ../deps/sqlite3/sqlite3mc_amalgamation.c:164594
#10 0x00007ffff4140ff2 in sqlite3Prepare (db=0x4a22050, zSql=0x4a35718 "PRAGMA key = 'foobarbaz'", nBytes=24, prepFlags=128, pReprepare=0x0, ppStmt=0x7fffe7ffed38, pzTail=0x7fffe7ffed40) at ../deps/sqlite3/sqlite3mc_amalgamation.c:131874
#11 0x00007ffff41412dc in sqlite3LockAndPrepare (db=0x4a22050, zSql=0x4a35718 "PRAGMA key = 'foobarbaz'", nBytes=24, prepFlags=128, pOld=0x0, ppStmt=0x7fffe7ffed38, pzTail=0x7fffe7ffed40) at ../deps/sqlite3/sqlite3mc_amalgamation.c:131956
#12 0x00007ffff4141532 in sqlite3_prepare_v3 (db=0x4a22050, zSql=0x4a35718 "PRAGMA key = 'foobarbaz'", nBytes=24, prepFlags=0, ppStmt=0x7fffe7ffed38, pzTail=0x7fffe7ffed40) at ../deps/sqlite3/sqlite3mc_amalgamation.c:132062
(gdb) print *cipherParams
$1 = {m_name = 0x10ec8348e5894855 <error: Cannot access memory at address 0x10ec8348e5894855>, m_value = -125990584, m_default = -129660088, m_minValue = 272665416, m_maxValue = -389576376}

If I compile in all codecs/ciphers, then it works fine, so I suspect there is code assuming the size of globalCodecParameterTable or something similar.

@mscdex
Copy link
Author

mscdex commented Oct 9, 2021

I was able to quickly verify that it's the same underlying problem as in #50. If I explicitly change:

#define CODEC_TYPE_CHACHA20  3

to

#define CODEC_TYPE_CHACHA20  1

and rebuild, then everything works fine.

@utelle
Copy link
Owner

utelle commented Oct 9, 2021

Yes, the cause of the problem is indeed the same as in #50. I will provide a fix soon.

"Fixing" the problem by simply changing the numeric id of a cipher scheme is not recommended, because using the same numeric cipher id for different cipher schemes can possibly cause problems in the long run.

utelle added a commit that referenced this issue Oct 9, 2021
If some of the cipher schemes are excluded from compilation, executing cipher-related pragmas could lead to crashes due to wrong indexing based on the numeric cipher ids. Numeric cipher ids are now handled correctly.

Note: The default configuration with all cipher schemes enabled is not affected.
@mscdex
Copy link
Author

mscdex commented Oct 9, 2021

I've verified this is fixed now. Thanks!

@mscdex mscdex closed this as completed Oct 9, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants