¿Cómo puede la contaminación de Heap causar una falla de seguridad?

4

Encontré esta regla en CERT Secure Coding Standart para Java. Heap Pollution . Entiendo que esto puede hacer que el programa lance una excepción en el tiempo de ejecución, pero no puedo entender cómo esto podría causar un problema de seguridad como DOS o algo así. ¿Alguien podría explicar un escenario en el que un atacante podría explotar la contaminación de un montón?

    
pregunta Exagon 16.04.2016 - 17:30
fuente

2 respuestas

2

Tomaría el ejemplo similar de enlace que ha citado . En el ejemplo, obtendré el ID de usuario (Integer) como argumento e intentaré validarlo contra la base de datos.

class ListUtility {
  private static void addToList(List list, Object obj) {
    list.add(obj); // Unchecked warning
  }


  private static boolean validateUser(List list){
     boolean isValidUser=false;
     Statement stmt = conn.createStatement(); //conn is a jdbc Connection 
     String Query="SELECT userid FROM Customers WHERE userid='"+list.get(0)+"'"; //developer expects list.get(0) is a integer
     ResultSet rs = stmt.executeQuery(Query);
     if (rs.next()) {
         System.out.println("Valid User");
         isValidUser=true;
       }      
     return isValidUser; //returns true for args[0]=something' or '1'='1
   }


  public static void main(String[] args) {
    List<Integer> list = new ArrayList<Integer> ();
    addToList(list, args[0]); //arg[0] is expected to be a valid userid of type Integer(say)
    validateuser(list);

  }

}

Ahora, si invoco el programa con el argumento something' or '1'='1 , se imprimirá "Valid User" . Esta es una inyección típica de Sql. Pero esto tuvo éxito debido a la Contaminación del Heap donde agregamos args[0] a list a pesar de que el tipo no coincide.

La contaminación del montón es posible en este caso porque la información de tipo parametrizada se descarta antes de la ejecución.

La llamada a addToList(list,args[0]) logra agregar una cadena a la lista, aunque la lista es de tipo List<Integer> . Además, la llamada a validateUser(List list) toma la lista del tipo List<Object> en lugar del estricto List<Integer> .

Este tiempo de ejecución de Java no lanza una excepción ClassCastException ya que la lista de valores no se leyó con un tipo no válido en este ejemplo. Porque la lista nunca se lee estrictamente como List<Integer> .

    
respondido por el Sravan 14.09.2016 - 07:01
fuente
0

Es muy poco probable que ocurra, pero es posible:

Si algunos programadores manejan mal una advertencia no verificada lanzando ClassCastException al convertir algunos valores enteros sin signo en un entero con signo que podría permitir que un atacante omita a Integer.MIN_VALUE y Integer.MAX_VALUE en un ataque de desbordamiento de entero.

    
respondido por el Rilke Petrosky 16.04.2016 - 22:05
fuente

Lea otras preguntas en las etiquetas