Los programas que se ejecutan con privilegios root han provocado innumerables desastres de seguridad de Unix. Es imprescindible que revise atentamente los programas con privilegios en relación con todos los tipos de problemas de seguridad, pero es igual de importante restablecer los programas con privilegios a un estado sin ellos tan rápido como sea posible a fin de limitar la cantidad de daños que puede provocar una vulnerabilidad que se pasó por alto.


Las funciones de administración de privilegios se pueden comportar de forma algo menos obvias, y presentan diferentes peculiaridades en las distintas plataformas. Estas incoherencias son especialmente pronunciadas al pasar de un usuario que no es root a otro.

Los controladores de señales y los procesos generados se ejecutan en el privilegio del proceso propietario, por lo que si el proceso se está ejecutando como root cuando se desencadena una señal o se ejecuta un subproceso, el controlador de señales funcionará con privilegios raíz. Es posible que un atacante aproveche estos privilegios elevados para realizar aún más daño.

No se deben realizar operaciones relacionadas con SMS específicas de iOS a menos que sean necesarias para la funcionalidad esencial de una aplicación. El malware escrito para dispositivos móviles suele aprovecharse de esta funcionalidad para robar dinero y datos a los usuarios.

Ejemplo 1: En los siguientes casos, la aplicación envía un mensaje SMS o lo escribe previamente y lo muestra al usuario, a quien se le solicita que lo envíe o lo cancele:

...
Device.OpenUri("sms:+12345678910");
...

Spring proporciona un mecanismo sencillo para convertir cualquier bean administrado por Spring en un objeto que se expone externamente a través de los protocolos RMI, HTTP, Burlap, Hessian y JMX. Cualquier método público de spring bean remoto se puede llamar externamente y los datos que se pasan entre el cliente y los objetos remotos están en texto sin formato. El principal problema de estos servicios es que están abiertos de forma predeterminada y no ofrecen garantías de confidencialidad o integridad desde el primer momento.

Spring proporciona un mecanismo sencillo para convertir cualquier bean administrado por Spring en servicios web a través de Spring WS o XFire. Cualquier método público del Spring bean remoto se puede llamar externamente y los datos que se pasan entre el cliente y los objetos habilitados para el servicio web están en texto sin formato. El principal problema de estos servicios es que están abiertos de forma predeterminada y no ofrecen garantías de confidencialidad o integridad desde el primer momento.

Windows proporciona las funciones MultiByteToWideChar(), WideCharToMultiByte(), UnicodeToBytes() y BytesToUnicode() para convertir cadenas de caracteres multibyte (normalmente ANSI) arbitrarias a cadenas Unicode (carácter ancho) y viceversa. Los argumentos de tamaño para estas funciones están especificados en diferentes unidades (una en bytes y la otra en caracteres) y su uso suele llevar a errores. En una cadena de caracteres multibyte, cada carácter ocupa una cantidad variable de bytes; por lo tanto, el tamaño de dichas cadenas se especifica más fácilmente como un número total de bytes. Sin embargo, en Unicode los caracteres siempre tienen un tamaño fijo y la longitud de las cadenas está definida por el número de caracteres que contienen. La especificación incorrecta de las unidades erróneas en un argumento de tamaño podría provocar un buffer overflow.

Ejemplo: la función siguiente toma un nombre de usuario especificado como cadena multibyte y un puntero a una estructura para la información de usuario y rellena la estructura con información sobre el usuario especificado. Como la autenticación de Windows utiliza Unicode para los nombres de usuario, el argumento de nombre de usuario se convierte primero desde una cadena multibyte a otra Unicode.

void getUserInfo(char *username, struct _USER_INFO_2 info){
WCHAR unicodeUser[UNLEN+1];
MultiByteToWideChar(CP_ACP, 0, username, -1,
     unicodeUser, sizeof(unicodeUser));
NetUserGetInfo(NULL, unicodeUser, 2, (LPBYTE *)&info);
}

Esta función transfiere de forma incorrecta el tamaño de unicodeUser en bytes en lugar de hacerlo en caracteres. Así pues, la llamada a MultiByteToWideChar() puede escribir hasta (UNLEN+1)*sizeof(WCHAR) caracteres anchos o (UNLEN+1)*sizeof(WCHAR)*sizeof(WCHAR) bytes, en la matriz unicodeUser, que solo tiene (UNLEN+1)*sizeof(WCHAR) bytes asignados. Si la cadena username contiene más de UNLEN caracteres, la llamada a MultiByteToWideChar() desbordará el búfer unicodeUser.

La clase sun.misc.Unsafe se utiliza para realizar operaciones inseguras de bajo nivel y no está diseñada para que la usen los desarrolladores.
La clase Unsafe solo se puede obtener mediante un código de confianza y normalmente se obtiene a través de la reflexión, ya que se puede usar para corromper el sistema o asignar manualmente memoria en masa que, si no se maneja adecuadamente, podría tener efectos perjudiciales en el sistema. Es absolutamente necesario que toda la funcionalidad alrededor de sun.misc.Unsafe se revise y pruebe cuidadosamente para que no tenga fallos.

Para cambiar una contraseña o crear una nueva cuenta de usuario, generalmente se necesita que se proporcione la nueva contraseña dos veces para fines de confirmación. Si se pasa una contraseña duplicada en lugar de pasarla dos veces, la API no se asegura de que el usuario no haya escrito mal la contraseña y elude el mecanismo de seguridad de confirmación de la contraseña.

Ejemplo 1:

    String password=request.getParameter("password");
    ...
    DefaultUser user = (DefaultUser) ESAPI.authenticator().createUser(username, password, password);