Programas que são executados com privilégios root causaram inúmeras catástrofes de segurança no Unix. É imperativo que você analise programas privilegiados cuidadosamente em busca de todos os tipos de problemas de segurança, mas é igualmente importante que esses programas privilegiados retornem a estado sem privilégios o mais rápido possível, a fim de limitar a quantidade de danos que uma vulnerabilidade despercebida pode ser capaz de causar.


Funções de gerenciamento de privilégios podem comportar-se de maneiras menos do que óbvias e têm peculiaridades diferentes dependendo da plataforma. Essas inconsistências são particularmente evidentes quando você está fazendo a transição de um usuário não root para outro.

Manipuladores de sinais e processos gerados são executados no privilégio do processo proprietário e, portanto, se um processo estiver em execução como root quando um sinal for acionado ou um subprocesso for executado, o manipulador de sinais ou subprocesso operará com privilégios de root. Um invasor pode ser capaz de aproveitar esses privilégios elevados para causar ainda mais danos.

As operações relacionadas a SMS específicas de iOS não devem ser realizadas a menos que sejam essenciais para a funcionalidade principal de um aplicativo. Os malwares desenvolvidos para dispositivos móveis muitas vezes abusam de tal funcionalidade a fim de roubar dinheiro ou dados do usuário.

Exemplo 1: Nesses casos, o aplicativo envia uma mensagem SMS ou escrita previamente e apresenta uma mensagem SMS ao usuário a qual ele ou ela é solicitado a enviar ou cancelar:

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

O Spring fornece um mecanismo fácil para transformar qualquer bean gerenciado pelo Spring em um objeto que é exposto externamente por meio dos protocolos RMI, HTTP, Burlap, Hessian e JMX. Qualquer método público do bean Spring remoto pode ser chamado externamente e os dados transmitidos entre o cliente e os objetos remotos estão em texto simples. O maior problema com esses serviços é que eles são abertos por padrão e não oferecem garantias de confidencialidade ou integridade por padrão.

O Spring fornece um mecanismo fácil para transformar qualquer bean gerenciado pelo Spring em serviços da web por meio do Spring WS ou XFire. Qualquer método público do bean Spring remoto pode ser chamado externamente e os dados que estão sendo passados entre o cliente e os objetos habilitados pelo serviço da web estão em texto simples. O maior problema com esses serviços é que eles são abertos por padrão e não oferecem garantias de confidencialidade ou integridade por padrão.

O Windows fornece as funções MultiByteToWideChar(), WideCharToMultiByte(), UnicodeToBytes() e BytesToUnicode() para converter entre cadeias de caracteres multibyte arbitrários (geralmente ANSI) e cadeias de caracteres Unicode (caracteres largos). Os argumentos de tamanho para essas funções são especificados em unidades diferentes (um em bytes e o outro em caracteres), fazendo com seu uso seja propenso a erros. Em uma cadeia de caracteres multibyte, cada caractere ocupa um número de bytes variável e, portanto, o tamanho dessas cadeias de caracteres é mais facilmente especificado como um número total de bytes. Por outro lado, em Unicode, os caracteres sempre têm um tamanho fixo, e os comprimentos de cadeias de caracteres são normalmente determinados pelo número de caracteres que as cadeias contêm. Especificar as unidades erradas por engano em um argumento de tamanho pode causar um buffer overflow.

Exemplo: A função a seguir usa um nome de usuário especificado como uma cadeias de caracteres multibyte e um ponteiro para uma estrutura de informações do usuário e preenche essa estrutura com informações sobre o usuário especificado. Como a autenticação do Windows usa Unicode para nomes de usuário, o argumento "username" é primeiro convertido de uma cadeias de caracteres multibyte em uma cadeias de caracteres 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);
}

Em seguida, essa função transmite incorretamente o tamanho de unicodeUser em bytes em vez de em caracteres. Portanto, a chamada para MultiByteToWideChar() pode gravar caracteres com um comprimento de até (UNLEN+1)*sizeof(WCHAR, ouUNLEN+1)*sizeof(WCHAR)*sizeof(WCHAR) bytes, no array unicodeUser, que tem apenas (UNLEN+1)*sizeof(WCHAR) bytes alocados. Se a string username contiver mais de UNLEN caracteres, a chamada para MultiByteToWideChar() causará um estouro no buffer unicodeUser.

A classe sun.misc.Unsafe é para executar operações inseguras e de baixo nível e não se destina ao uso por desenvolvedores.
A classe Unsafe só pode ser obtida por código confiável e normalmente é obtida por meio de reflexão, pois pode ser usada para corromper o sistema ou alocar manualmente memória heap que, se não for tratada adequadamente, poderá ter efeitos prejudiciais no sistema. É imperativo que toda a funcionalidade em torno de sun.misc.Unsafe seja cuidadosamente revisada e testada para estar ausente de falhas.

Alterar uma senha ou criar uma nova conta de usuário geralmente requer que a nova senha seja fornecida duas vezes para fins de confirmação. Passar uma senha duplicada em vez de passá-la duas vezes evita que a API verifique se o usuário não digitou a senha incorretamente e contorna o mecanismo de segurança de confirmação de senha.

Exemplo 1:

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