Como detectar problemas de desserialização de java?

Question

gostaria de poder detectar problemas com desserialização em código java.O que devo procurar?Por exemplo, como alguém determinaria se algum código java tenta explorar "bug do calendário java"?Observe que não sou um programador Java, mas entendo bem os conceitos por trás da serialização e do OOP.Estou tentando implementar algumas verificações de segurança (algo como uma ferramenta de aviso do compilador).

EDITAR: com base nos comentários, gostaria de mudar um pouco a pergunta:Considero todo o código analisado "não confiável", existe uma maneira de avaliar o perigo potencial?Quer dizer, posso dizer que o código A é mais perigoso que o B no que diz respeito ao bug de desserialização?O que devo procurar?

Answer 1

Em primeiro lugar, você precisa entender o seu contexto para determinar as ameaças à segurança.(Quando falo sobre “confiança”, estou tomando um pequeno atalho.Estou falando deliberadamente malicioso.)

Se os dados serializados foram criados, mantidos e lidos com a mesma confiança, então não há nenhum problema real (além dos bugs padrão).Observe que se você escrever qualquer informação confidencial, os dados serializados também serão confidenciais (parece óbvio, mas há uma boa dose de indireção aí).

Se os dados serializados não forem confiáveis ​​por qualquer motivo, há um pouco mais a considerar.A estrutura interna dos objetos recriados pode ser “incomum”.Os dados podem não ser consistentes.Você pode ter compartilhado objetos mutáveis ​​que deveriam ser separados.A desserialização pode causar um loop infinito, ou um loop não infinito que simplesmente não pode ser concluído antes da morte térmica do universo.E é claro que os dados podem ser mentiras.

Se você estiver escrevendo um código de biblioteca usado por códigos menos confiáveis, as coisas ficarão mais interessantes:

No caso de "bug de calendário" (e similares), trata-se de desserializar um fluxo arbitrário com dados e códigos maliciosos.As Diretrizes de Codificação Segura Java sugerem fazer verificações de segurança (usando o "Modelo de Segurança Java2") dentro de readObject métodos, o que implica que você não deve chamar a desserialização com mais confiança do que o código e os dados.

Do lado dos objetos desserializáveis, as coisas são mais complicadas.Objetos fornecidos por ObjectInputStream através readObject, readUnshared, defaultReadObject, readFields ou apenas a desserialização padrão pode ter referências capturadas por código malicioso ou, para classes não finais, ser subclassificadas de forma maliciosa.Um objeto também pode ser usado durante a desserialização, quando parcialmente inicializado.A desserialização não invoca um construtor "real" da classe desserializada (readObject/readObjectNoData é uma espécie de psuedo-construtor, que não pode definir finale).É tudo um pesadelo, então você provavelmente não quer tornar suas classes sensíveis serializáveis.

Houve uma série de vulnerabilidades na implementação de serialização e desserialização.Você realmente não precisa se preocupar com isso, a menos que esteja implementando você mesmo.

Answer 2

Hmm ... sua pergunta é um pouco geral. Você deu uma olhada em isto artigo? É sobre o algoritmo de serialização de Java, mas do cache do Google, porque a página principal parece estar baixa no momento.

Answer 3

Eu teria pensado que a melhor maneira de derrotar o código que explora falhas de segurança conhecidas em Java é atualizar para uma versão Java que corrija o bug.E a próxima melhor maneira (de lidar com bugs relacionados à serialização) é tratar todos os dados serializados de fontes desconhecidas/não verificadas/inseguras como suspeitas.

Tentar detectar problemas analisando o código Java em busca de bugs de segurança não é fácil e requer um conhecimento profundo dos mecanismos Java que estão sendo usados ​​e podem ser explorados.Tentar detectar tentativas de exploração (em geral) seria ainda mais difícil, especialmente se você estiver procurando explorações para falhas de segurança de dia zero.Tenha em mente que existem outros vetores potenciais.

(Se houvesse maneiras fáceis de encontrar falhas de segurança desconhecidas em Java, você pode apostar que a Sun e outros pesquisadores de segurança já as teriam usado.)

Answer 4

Se você serializar seu objeto Java para transferi -lo para um aplicativo separado, por que não considerar assinar o objeto com uma chave compartilhada entre os aplicativos? Deve ser suficiente para se defender do ataque de homem no meio.

Voltando ao núcleo do problema de verificação, a verificação é extremamente difícil para idiomas de uso geral. Você deve procurar publicações científicas sobre este tópico. Eu acho que a técnica mais comumente aplicada é Sandboxing. A segunda abordagem é restringir a linguagem e proibir a execução de comandos perigosos, por exemplo, Biblioteca Yahoo Caja usa essa técnica.