2010-12-02 20 views
21

Cette question est similaire à Exploitable PHP Functions.Fonctions Java exploitables

Les données corrompues proviennent de l'utilisateur, ou plus précisément d'un attaquant. Quand une variable contaminée atteint une fonction de puits, alors vous avez une vulnérabilité. Par exemple, une fonction qui exécute une requête sql est un puits, et les variables GET/POST sont des sources d'altération.

Quelles sont toutes les fonctions de récepteur dans la bibliothèque de classes Java (pour toutes les versions de Java)? Je suis à la recherche de fonctions qui introduisent une vulnérabilité ou software weakness. Je suis particulièrement intéressé par les vulnérabilités d'exécution de code à distance. Existe-t-il des classes/bibliothèques entières contenant des fonctionnalités désagréables qu'un pirate voudrait influencer? Comment les gens font accidentellement du code Java dangereux?

+3

* toutes * fonctions d'évier?Cette liste est infinie, car on peut définir arbitrairement plusieurs de ces fonctions. – meriton

+0

@meriton avez-vous vu la liste que j'ai construite pour PHP? – rook

+2

je crois qu'il se réfère au code de la bibliothèque java pas des bibliothèques de sous-sol – Woot4Moo

Répondre

8

code vulnérabilités d'exécution:

  1. réflexion privée, mais il est rare que les données viciées pour y arriver d'une manière dangereuse
  2. code natif Interop qui ne assez
  3. valide pas ses paramètres De-sérialiseurs. Probablement le plus dangereux puisque vous pourriez désérialiser des données non fiables. Certains sérialiseurs sont relativement sûrs et n'utilisent que des constructeurs/setters publics, mais d'autres accèdent à des champs privés. Et s'il n'y a pas de liste blanche, il peut y avoir des types arbitraires et des sélecteurs d'appel.
  4. Toute forme d'E/S, fichiers en particulier
  5. Chargement dynamique de bibliothèques. En particulier en utilisant un chemin relatif. En particulier par rapport au répertoire de travail au lieu du répertoire exécutable

(C'est sur le .net, mais je me attends Java d'être très similaire)

injection de données

Ensuite, il y a la famille d'injection de fonctions qui peuvent généralement être évitées en ne fonctionnant pas sur des chaînes mais en utilisant des fonctions de bibliothèque spécialisées. Ceux-ci ne conduisent généralement pas à l'injection de code arbitraire.

  1. html injectiong/XSS (en grande partie empêché par une vue de moteur que la production automatique échappe et propre à séparer échappés et cordes un-échappé (peut-être en utilisant différents types))
  2. injection SQL (empêchée par des instructions préparées)
  3. injection fichier-chemin
+0

+1 pour la désérialisation et le fichier E/S –

7

Je suis sûr que cette liste augmentera à mesure que je creuse en vue de trouver de véritables exploits:

  1. Spring classloader

  2. exceptions - Swallowed Comme il a été noté des exceptions ne peuvent pas avaler la cause directe d'une exploitation, mais elle peut conduire à la non-découverte de l'exploitation.

  3. String[] commands = {args[0]};
    Runtime.getRuntime().exec(commands);

    Je me rends compte qu'il est un élément assez trivial, mais le code en cours d'exécution similaire à celui ci-dessus peut vous permettre de passer quelque chose comme ceci: && del / si sous Windows ou ;rm -rf / sur * nix

Le plus grand les gens font du code Java dangereux en étant paresseux. Comme vous l'avez mentionné ne pas nettoyer l'entrée de l'utilisateur avant de l'exécuter.

+0

+1 je creuse aussi sur la découverte de vrais exploits :) – rook

+2

@Rook j'en ai un à propos de Apache Tomcat, mais je ne l'afficherai pas ici tant que le vendeur ne l'aura pas résolu. – Woot4Moo

27

Voici une liste basée sur mes recherches personnelles sur la sécurité Java côté client en général et sur l'Eclipse IDE pour voir quelles méthodes sont vérifiées par SecurityManager.

classloaders définissent des classes (= code Java arbitraire exécution):

java.lang.ClassLoader.defineClass 
java.net.URLClassLoader 

= exécution de code

Java Beans Introspection peut détourner classloaders en classes de chargement à partir d'une source non approuvée (example vuln - cve-2010-1622)

java.beans.Instrospector.getBeanInfo 

= L'exécution de code

d'accès aux fichiers

java.io.File (constructor) 
java.io.File.delete 
java.io.File.renameTo 
java.io.File.listFiles 
java.io.File.list 

= Modification/suppression de fichiers, répertoriant

flux de fichiers/classes de lecture

java.io.FileInputStream 
java.io.FileOutputStream 
java.io.FileReader 
java.io.FileWriter 
java.io.RandomAccessFile 

= Fichier accès en lecture/écriture

Java Propriétés système

System.setProperty 
System.getProperties 
System.getProperty 

= Quelques propriétés du système peuvent contenir des informations et des propriétés du système qui est presque sensible pourrait modifier l'exécution de choses critiques, je n'ai pas d'exemples, bien que

bibliothèques natives Chargement

System.load 
System.loadLibrary 

= exécution de code arbitraire

Exécution executables du système d'exploitation

Runtime.exec 
ProcessBuilder (constructor) 

Génération d'événements d'entrée du système natif

java.awt.Robot.keyPress/keyRelease 
java.awt.Robot.mouseMove/mousePress/mouseRelease 

(Peut-être farfelue car un serveur peut même pas avoir un environnement graphique)

Java réflexion - accès arbitraire (même privé) champs et méthodes

java.lang.Class.getDeclaredMethod 
java.lang.Class.getDeclaredField 
java.lang.reflection.Method.invoke 
java.lang.reflection.Field.set 
java.lang.reflection.Field.get 

= de divulguer des informations sensibles à l'exécution de code éventuel, selon les circonstances

Java moteur de script

javax.script.ScriptEngine.eval 

= exécution de code arbitraire

+0

+ 1x4 post impressionnant – rook

+0

@Rook: Merci! Je pense que la question est excellente. Je n'ai jamais vraiment regardé la sécurité Java sous cet angle précis. –

+0

+1 - excellent travail et un ensemble très complet de méthodes exploitables :) – vstoyanov