De: ManifestaçãoAssunto: Falhas de segurança manifestam-se em (amplamente) quatro maneiras ...Data: 11.10.93
(Por favor, contribua enviando e-mail para ...)
[Citando o FAQ comp.security.unix]Falhas de segurança manifestam-se em (amplamente) quatro formas:
1) falhas de segurança física.
- Onde o problema potencial é causado por pessoas não autorizadas dandoacesso físico à máquina, onde isso pode permitir-lhes realizarcoisas que não deve ser capaz de fazer.
Um bom exemplo disso seria uma sala de estação de trabalho pública onde seriaser trivial para um usuário para reiniciar uma máquina em modo de usuário único e muckao redor com o filestore estação de trabalho, se não forem tomadas precauções.
Outro exemplo disso é a necessidade de restringir o acesso a sigilofitas de backup, o que pode (não) ser lido por qualquer usuário com acesso aoas fitas e uma unidade de fita, se eles estão destinados a ter permissão ounão.
2) Segurança e brechas em Softwares
- Quando o problema é causado por itens mal escrita de "privledged"software (daemons, cronjobs), que pode ser comprometida em fazer as coisasque eles não devem oughta.
O exemplo mais famoso é o "debug sendmail" buraco (vejabibliografia), que permitiria a um cracker para iniciar uma "raiz" shell.Isso poderia ser usado para excluir o seu filestore, criar uma nova conta, cópiaseu arquivo de senhas, qualquer coisa.
(Contrariamente à opinião popular, crack ataques via sendmail não eram apenasrestrita à "Internet Worm" infame - qualquer cracker poderia fazer issousando "telnet" para a porta 25 na máquina de destino. A história por trás de umburaco similar (desta vez no EMACS "move-mail" software) é descritoem [Stoll].)
Novos buracos aparecem como esta o tempo todo, e sua melhor esperança é de:
a: tentar estruturar o seu sistema para que, como software mínimo possível
executado com root / daemon / bin privilégios, e que não é conhecido por
ser robusto.
b: assinar uma lista que pode obter detalhes de problemas
e / ou correções para você o mais rápido possível, e então quando você ACT
receber informações.
> From: Wes Morgan
Tftpd, os quais podem apresentar problemas de segurança. >> Administração do sistema cuidadosa é a solução. A maioria destes programas> São inicializados / iniciados no momento da inicialização, você pode desejar modificar o seu arranque> Scripts (geralmente no arquivo / etc / etc / rc, / etc / diretórios rcX.d) para pré-> Respiro a sua execução. Você pode querer remover alguns utilitários completamente.> Para alguns utilitários, um simples chmod (1) pode impedir o acesso não autorizado a partir> Usuários.>> Em resumo, não confie em scripts de instalação / PROGRAMAS! Tais instalações> Tendem a instalar / executar tudo no pacote sem pedir-lhe. A maioria> Documentação de instalação inclui listas de "os programas incluídos no> Este pacote ", certifique-se de analisá-lo.
3) Uso de falhas de segurança incompatíveis
- Quando, por falta de experiência, ou sem culpa sua / seu próprio, oSystem Manager reúne uma combinação de hardware e software quequando usado como um sistema é falho do ponto de vista da segurança.É a incompatibilidade de tentar fazer duas desconexos, mas útilcoisas que cria a brecha de segurança.
Problemas como este são uma dor de encontrar, uma vez que um sistema é configurado eexecução, por isso é melhor para construir seu sistema com eles em mente. Énunca é tarde demais para ter um repensar, no entanto.
Alguns exemplos são detalhados a seguir, não vamos entrar em los aqui, seriaapenas estragar a surpresa.
4) A escolha de uma filosofia de segurança adequados e mantê-la.
> From: Gene Spafford
---
De: HackingAssunto: Idéias HackingData: 11/10/93
(Por favor, contribua enviando e-mail para ...)
[Muitas idéias tiradas de: HaxNet - APG V1.3: Guia para encontrar novos buracos]
NOTA: Eu acho que isso deve ser dividida em categorias gerais:1) Princípios gerais2) À procura de buracos no src (a maioria dos itens aqui)3) Olhando em distribuições binárias4) Olhando em configurações de site específico
As seguintes classificações gerais sugerem-se:1) SUID / SGID2) Códigos de retorno / condições de erro3) de entrada inesperada4) condições de corrida5) a autenticação6) confiança implícita7) parâmetros8) permissões9) interrompe10) I / O11) links simbólicos12) Daemons, particularmente aqueles que tomam a entrada do usuário.13) condições de corrida Kernel14) o que mais? - Por favor, adicionar categorias
(Divisão sugerida acima de em principal e sub-catagories)I: Suid binários e scripts
inesperadas interações do usuário
falho chama literárias
suposições implícitas de condições externas (links sym, loc. caminhos)
condições de corridaII: daemons em execução com privilegiada uid do
condições de corrida
pobres protectons arquivo
implícita proteções de arquivo
confiança
autenticaçãoIII: problemas de Kernel
Corrida condições Kernel
código de driver de dispositivo
O método passo seguinte foi criado por quatro Desenvolvimento de SistemasCorporation, que relatam uma taxa de sucesso de 65% nas hipóteses falhagerado. Fazer uma pesquisa abrangente de falhas do sistema operacionalrequer quatro passos:
Etapa 1) Conhecimento da estrutura de controle do sistema.===============================================
Para encontrar falhas de segurança, e identificar pontos fracos do projeto énecessário entender a estrutura de controle do sistema, e camadas.
Uma deve ser capaz de a lista:A) os objetos de segurança: os itens a serem protegidos. ou seja: um arquivo de usuários.B) os objetos de controle: itens que proteger os objetos de segurança. ou seja: um i-nodeC) os objetos do mútuo: objetos em ambas as classes. ou seja: o arquivo de senhas
Com essa lista, é possível representar graficamente um controlehierarquia e identificar potenciais pontos de ataque. Fazer fluxogramaspara dar uma quebra visual de relacionamentos definitivamente ajuda.
Leitura dos vários usuários, operadores e administradores devem manuaisfornecer essa informação.(Seguindo Pará provavelmente deve ser movido para uma seção de "legal")
Leitura e greping código fonte também deve ser valiosa. Para aquelessem uma licença de código, gostaria de sugerir que use LINUX, NET2 e BSD386distribuições a fim de ficar legal. Em algum momento futuro, pode ser capazpara assinar um contrato de trabalho entre uma pessoa ou uma empresa com acesso legalpara outras distribuições e membros participando ativamente deste projeto.
Parece que os extratos de código proprietário pode ser utilizado para acadêmicosestudo, desde que não sejam reutilizadas em um produto comercial - maisverificação entanto, é necessária.
Etapa 2) Gerar um inventário de falhas suspeitos. (Isto é, falha hipóteses)================================================== ======================Em particular, queremos:
História código:
O que UNIX src faz um sabor especial derivam? Isto é importantepara referências cruzadas (muitas vezes apenas um código de patches de fornecedores certos,que pode ter reutilizado, em sua reencarnação não corrigida por outros)
A referência cruzada sólido:
Que verificou que o bug no sistema operacional e qual a versão que nos impede deduplicar o trabalho.
Um bom começo seria listar todos os binários suid no sistema operacional váriossabores / versões. Em seguida, tentar descobrir por que cada programa é suid. ou seja:
rcp é suid root porque ele deve usar uma porta privilaged fazer utilizador
autenticação de nome.
Muitas vezes o código que nunca foi projetado para ser suid, é feita suid, duranteportar para resolver problemas de acesso a arquivos.
Precisamos desenvolver uma base de dados que serão capazes de olhar para pares etrigêmeos de dados, specificly: Objeto nome do programa, suid, sgid, acessado(Por que prog é SUID / SGID), OS sabor / versão e Flav / geniology vers.
Qualquer sugestões sobre como implementar tais DB um?
Etapa 3) Confirme hipóteses. (Teste e explorar falhas)================================================== ==
Etapa 4) Faça generalizações das fraquezas do sistema subjacente, para
que a falha representa uma instância específica.================================================== ===================
Caixa de ferramentas:=========AGREP: Sugiro a todos obter e instalar agrep de:
ftp cs.arizona.edu / agrep / agrep.tar.Z
Agrep suporta "janelas" para que ele possa olhar para as rotinas e sub-rotinas.Ele também suporta operadores lógicos e, portanto, é ideal para automatizara busca de muitas das falhas a seguir. ou seja
OU execvp ()]} / usr / local / src / *. c
PROGRAMA PERMUTATION: Outra ferramenta vale a pena produzir é um programa para gerartodas as permutações possíveis de bandeiras de linha de comando / argumentos a fim de descobrirrecursos não documentados, e tentar produzir erros.
TCOV:
CRASH: Enviado para USENET (o FTP arquivo?) (Descrição?)
PAPÉIS: Existem vários artigos que discutem métodos de encontrar falhas, e
presente suites de teste.
1) Um estudo Emphirical da confiabilidade do UNIX Utilitários, por Barton P.
Miller, Lars Fredriksen, e Bryan Então, Comm ACM, v33 n12, pp32-44,
Dezembro '90. Descreve um conjunto de testes para testar seqüências de entrada aleatória.
Os resultados indicaram que 25% dos programas pendurado, deixou de funcionar, ou se comportado mal.
Em um caso o sistema operacional caiu. Uma compreensão de buffer e registo
disposição no ambiente em questão, e a entrada esperada é provável
para produzir os resultados desejados.
2) O Mothra conjunto de ferramentas, em Proceedings of the 22 Hawaii International
Conferência sobre Sistemas e Software, páginas 275-284, Kona, HI, Janeiro 89
3) Estender Teste de Mutação para encontrar bugs Ambiental, por Eugene H.
Spafford, Prática de Software e Experiência, 20 (2) :181-189, Feb '90
4) Um estudo da IBM foi mencionado que foi submetido a USENIX alguns anos
atrás. (Alguém tem uma citação?).
Falhas específicas para verificar:============================1) Procure por rotinas que não fazer a verificação de limite, ou verificar a entrada.
ou seja: o gets () família de rotinas, onde é possível substituir
limites buffer. (Sprintf (?), Gets (), etc)
também: strcpy () que é porque a maioria tem src:
# Define SCYPYN ((a) (b)) strcpy (a, b, sizeof (a))
2) SUID / SGID rotinas escritas em uma das conchas, em vez de C ou
PERL.
3) SUID / SGID rotinas escritos em PERL que não usam o "taintperl"
programa.)
4) as rotinas SUID / SGID que usam o system (), popen (), execlp (), ou
execvp () chama para executar alguma outra coisa.
5) Qualquer programa que usa nomes de caminho relativo dentro do programa.
6) O uso de nomes de caminho relativo para especificar bibliotecas ligadas dinamicamente.
(Procure no Makefile).
7) Rotinas que não verificar códigos de retorno de erro de chamadas do sistema. (Ou seja:
fork (2), suid (2), etc), setuid () sim, como no famoso bug rcp
8) Os buracos podem ser encontrados no código que:
A) é portado para um novo ambiente.
B) recebe a entrada inesperada.
C) interage com outros software local.
D) acessa arquivos do sistema, como passwd, L.sys, etc
E) lê a entrada de um arquivo publicamente gravável / diretório.
F) não programas de diagnóstico que são tipicamente user-prova.
9) Código de ensaio para a entrada inesperada. Cobertura, fluxo de dados, e mutação
ferramentas de teste estão disponíveis.
10) Procure nas páginas do manual, e orienta os usuários para fazer advertências contra X, e
tente variações de X. O mesmo vale para "bugs" seção.
11) Procure raramente usados, ou funções incomuns ou comandos - leia para trás.
Em particular, à procura de bandeiras indocumentados / argumentos podem ser úteis.
Verifique as bandeiras que estavam em versões anteriores, ou em outras versões do sistema operacional. Verificar
para as opções que outros programas possam usar. Por exemplo, telnet utiliza-h
opção de fazer o login ...
direito, como a maioria login.c 's que eu vi ter:
if ((getuid ()) & & hflag) {
syslog ()
exit ()
}
12) Procure por condições de corrida.
13) A falha de software para autenticar que é realmente se comunicando
com o módulo de software ou hardware desejado que quer ser acessando.
14) Falta ou detecção de erros para redefinir os mecanismos de protecção na sequência de um
erro.
15) A aplicação deficiente, resultando em, por exemplo, códigos de condição de ser
inadequadamente testados.
16) a confiança implícita: B rotina assume rotina Um parâmetros estão corretas
A rotina, pois é um processo do sistema.
17) Sistema de lojas é de dados ou parâmetros de referência do usuário na utilizadores
espaço de endereço.
18) comunicação entre processos: as condições de retorno (OK passwd, ilegal
parâmetro, segmento de erro, etc) pode fornecer uma cunha significativa, esp.
quando combinado com (17).
19) os parâmetros do usuário podem não ser adequadamente verificados.
20) Os endereços que se sobrepõem ou se referem a áreas do sistema.
21) verifica código de condição pode ser omitido.
22) Falta de antecipar parâmetros incomum ou extraordinária.
23) Procure níveis do sistema onde os módulos envolvidos foram escritos por
programadores diferentes, ou grupos de programadores - buracos é provável
de ser encontrado.
24) Registros que apontam para a localização de um valor de parâmetros em vez
de passar o valor em si.
25) Qualquer programa executado com privilégios de sistema. (Progs muitos são dadas
uid 0, para facilitar o acesso a certas tabelas, etc)
26) Grupo ou lidos os arquivos temporários, buffers, etc
27) A falta de valores-limite e falta de registro / notificação uma vez que estes
ter sido disparado.
28) A alteração dos parâmetros de áreas críticas do sistema antes da sua execução
por um processo simultâneo. (Condições de corrida)
29) de contorno inadequada verificação em tempo de compilação, por exemplo, um usuário
pode ser capaz de executar código de máquina disfarçada de dados em uma área de dados.
(Se as áreas de texto e dados são compartilhados)
30 do usuário) incorretamente manuseio gerada interrupções assíncronas. Usuários
interromper um processo, realizar uma operação, e quer voltar
para continuar o processo ou começar outra vai freqüentemente deixam o
sistema em um estado desprotegido. Arquivos parcialmente escrita são deixadas abertas,
escrita indevido de mensagens infração proteção, configuração imprópria
de bits de proteção, etc ocorrem frequentemente.
31 Code) que usa fopen (3) sem definir o umask. (Por exemplo: em (1), etc)
Em geral, um código que não repõe o uid real e eficaz antes
bifurcação.
32 Trace) é seu amigo (ou truss em SVR4) para ajudar a descobrir o que
sistema chama um programa está usando.
33) Scan / usr / fs local de perto. Muitos administradores irão instalar software a partir de
da rede. Muitas vezes você vai encontrar tcpdump, top, nfswatch, ... raiz para suid'd
sua facilidade de uso.
34) Verifique os programas suid para ver se eles são os originalmente colocados no
do sistema. Administradores, por vezes, colocar em uma substituição passwd que é menos
segura do que a versão distribuída.
35 Olhar) para programas que estavam lá para instalar software ou pode ser carregada
módulos do kernel.
36) programas dinamicamente ligados em geral. Lembre-se LD_PRELOAD, eu acho
que foi a variável.
37) I / O canal de programação é um dos principais alvos. Procure por erros de lógica,
incoerências e omissões.
38) Veja se é possível para um programa de canal I / O para modificar-se, loop
para trás, e então executar o código recém-modificado. (Instrução de pré-carga
pode estragar tudo)
39) Se os canais de E / S agem como processadores independentes podem ter ilimitado
acesso à memória, assim o código do sistema pode ser modificado na memória antes de
de execução.
40 Olhar) para bugs exigindo falhas em múltiplos pedaços de software, ou seja, dizem
programa pode ser usado para alterar o arquivo de configuração / etc / b um programa agora assume
as informações em um ser correta e isso leva a resultados inesperados
(Basta olhar para quantos programas trust / etc / utmp)
41) Qualquer programa, especialmente aqueles sgid suid /, que permitem que escapa shell.
(Por favor, contribua enviando e-mail para
1) falhas de segurança física.
- Onde o problema potencial é causado por pessoas não autorizadas dandoacesso físico à máquina, onde isso pode permitir-lhes realizarcoisas que não deve ser capaz de fazer.
Um bom exemplo disso seria uma sala de estação de trabalho pública onde seriaser trivial para um usuário para reiniciar uma máquina em modo de usuário único e muckao redor com o filestore estação de trabalho, se não forem tomadas precauções.
Outro exemplo disso é a necessidade de restringir o acesso a sigilofitas de backup, o que pode (não) ser lido por qualquer usuário com acesso aoas fitas e uma unidade de fita, se eles estão destinados a ter permissão ounão.
2) Segurança e brechas em Softwares
- Quando o problema é causado por itens mal escrita de "privledged"software (daemons, cronjobs), que pode ser comprometida em fazer as coisasque eles não devem oughta.
O exemplo mais famoso é o "debug sendmail" buraco (vejabibliografia), que permitiria a um cracker para iniciar uma "raiz" shell.Isso poderia ser usado para excluir o seu filestore, criar uma nova conta, cópiaseu arquivo de senhas, qualquer coisa.
(Contrariamente à opinião popular, crack ataques via sendmail não eram apenasrestrita à "Internet Worm" infame - qualquer cracker poderia fazer issousando "telnet" para a porta 25 na máquina de destino. A história por trás de umburaco similar (desta vez no EMACS "move-mail" software) é descritoem [Stoll].)
Novos buracos aparecem como esta o tempo todo, e sua melhor esperança é de:
a: tentar estruturar o seu sistema para que, como software mínimo possível
executado com root / daemon / bin privilégios, e que não é conhecido por
ser robusto.
b: assinar uma lista que pode obter detalhes de problemas
e / ou correções para você o mais rápido possível, e então quando você ACT
receber informações.
> From: Wes Morgan
3) Uso de falhas de segurança incompatíveis
- Quando, por falta de experiência, ou sem culpa sua / seu próprio, oSystem Manager reúne uma combinação de hardware e software quequando usado como um sistema é falho do ponto de vista da segurança.É a incompatibilidade de tentar fazer duas desconexos, mas útilcoisas que cria a brecha de segurança.
Problemas como este são uma dor de encontrar, uma vez que um sistema é configurado eexecução, por isso é melhor para construir seu sistema com eles em mente. Énunca é tarde demais para ter um repensar, no entanto.
Alguns exemplos são detalhados a seguir, não vamos entrar em los aqui, seriaapenas estragar a surpresa.
4) A escolha de uma filosofia de segurança adequados e mantê-la.
> From: Gene Spafford
---
De: HackingAssunto: Idéias HackingData: 11/10/93
(Por favor, contribua enviando e-mail para
NOTA: Eu acho que isso deve ser dividida em categorias gerais:1) Princípios gerais2) À procura de buracos no src (a maioria dos itens aqui)3) Olhando em distribuições binárias4) Olhando em configurações de site específico
As seguintes classificações gerais sugerem-se:1) SUID / SGID2) Códigos de retorno / condições de erro3) de entrada inesperada4) condições de corrida5) a autenticação6) confiança implícita7) parâmetros8) permissões9) interrompe10) I / O11) links simbólicos12) Daemons, particularmente aqueles que tomam a entrada do usuário.13) condições de corrida Kernel14) o que mais? - Por favor, adicionar categorias
(Divisão sugerida acima de em principal e sub-catagories)I: Suid binários e scripts
inesperadas interações do usuário
falho chama literárias
suposições implícitas de condições externas (links sym, loc. caminhos)
condições de corridaII: daemons em execução com privilegiada uid do
condições de corrida
pobres protectons arquivo
implícita proteções de arquivo
confiança
autenticaçãoIII: problemas de Kernel
Corrida condições Kernel
código de driver de dispositivo
O método passo seguinte foi criado por quatro Desenvolvimento de SistemasCorporation, que relatam uma taxa de sucesso de 65% nas hipóteses falhagerado. Fazer uma pesquisa abrangente de falhas do sistema operacionalrequer quatro passos:
Etapa 1) Conhecimento da estrutura de controle do sistema.===============================================
Para encontrar falhas de segurança, e identificar pontos fracos do projeto énecessário entender a estrutura de controle do sistema, e camadas.
Uma deve ser capaz de a lista:A) os objetos de segurança: os itens a serem protegidos. ou seja: um arquivo de usuários.B) os objetos de controle: itens que proteger os objetos de segurança. ou seja: um i-nodeC) os objetos do mútuo: objetos em ambas as classes. ou seja: o arquivo de senhas
Com essa lista, é possível representar graficamente um controlehierarquia e identificar potenciais pontos de ataque. Fazer fluxogramaspara dar uma quebra visual de relacionamentos definitivamente ajuda.
Leitura dos vários usuários, operadores e administradores devem manuaisfornecer essa informação.(Seguindo Pará provavelmente deve ser movido para uma seção de "legal")
Leitura e greping código fonte também deve ser valiosa. Para aquelessem uma licença de código, gostaria de sugerir que use LINUX, NET2 e BSD386distribuições a fim de ficar legal. Em algum momento futuro, pode ser capazpara assinar um contrato de trabalho entre uma pessoa ou uma empresa com acesso legalpara outras distribuições e membros participando ativamente deste projeto.
Parece que os extratos de código proprietário pode ser utilizado para acadêmicosestudo, desde que não sejam reutilizadas em um produto comercial - maisverificação entanto, é necessária.
Etapa 2) Gerar um inventário de falhas suspeitos. (Isto é, falha hipóteses)================================================== ======================Em particular, queremos:
História código:
O que UNIX src faz um sabor especial derivam? Isto é importantepara referências cruzadas (muitas vezes apenas um código de patches de fornecedores certos,que pode ter reutilizado, em sua reencarnação não corrigida por outros)
A referência cruzada sólido:
Que verificou que o bug no sistema operacional e qual a versão que nos impede deduplicar o trabalho.
Um bom começo seria listar todos os binários suid no sistema operacional váriossabores / versões. Em seguida, tentar descobrir por que cada programa é suid. ou seja:
rcp é suid root porque ele deve usar uma porta privilaged fazer utilizador
autenticação de nome.
Muitas vezes o código que nunca foi projetado para ser suid, é feita suid, duranteportar para resolver problemas de acesso a arquivos.
Precisamos desenvolver uma base de dados que serão capazes de olhar para pares etrigêmeos de dados, specificly: Objeto nome do programa, suid, sgid, acessado(Por que prog é SUID / SGID), OS sabor / versão e Flav / geniology vers.
Qualquer sugestões sobre como implementar tais DB um?
Etapa 3) Confirme hipóteses. (Teste e explorar falhas)================================================== ==
Etapa 4) Faça generalizações das fraquezas do sistema subjacente, para
que a falha representa uma instância específica.================================================== ===================
Caixa de ferramentas:=========AGREP: Sugiro a todos obter e instalar agrep de:
ftp cs.arizona.edu / agrep / agrep.tar.Z
Agrep suporta "janelas" para que ele possa olhar para as rotinas e sub-rotinas.Ele também suporta operadores lógicos e, portanto, é ideal para automatizara busca de muitas das falhas a seguir. ou seja
OU execvp ()]} / usr / local / src / *. c
PROGRAMA PERMUTATION: Outra ferramenta vale a pena produzir é um programa para gerartodas as permutações possíveis de bandeiras de linha de comando / argumentos a fim de descobrirrecursos não documentados, e tentar produzir erros.
TCOV:
CRASH: Enviado para USENET (o FTP arquivo?) (Descrição?)
PAPÉIS: Existem vários artigos que discutem métodos de encontrar falhas, e
presente suites de teste.
1) Um estudo Emphirical da confiabilidade do UNIX Utilitários, por Barton P.
Miller, Lars Fredriksen, e Bryan Então, Comm ACM, v33 n12, pp32-44,
Dezembro '90. Descreve um conjunto de testes para testar seqüências de entrada aleatória.
Os resultados indicaram que 25% dos programas pendurado, deixou de funcionar, ou se comportado mal.
Em um caso o sistema operacional caiu. Uma compreensão de buffer e registo
disposição no ambiente em questão, e a entrada esperada é provável
para produzir os resultados desejados.
2) O Mothra conjunto de ferramentas, em Proceedings of the 22 Hawaii International
Conferência sobre Sistemas e Software, páginas 275-284, Kona, HI, Janeiro 89
3) Estender Teste de Mutação para encontrar bugs Ambiental, por Eugene H.
Spafford, Prática de Software e Experiência, 20 (2) :181-189, Feb '90
4) Um estudo da IBM foi mencionado que foi submetido a USENIX alguns anos
atrás. (Alguém tem uma citação?).
Falhas específicas para verificar:============================1) Procure por rotinas que não fazer a verificação de limite, ou verificar a entrada.
ou seja: o gets () família de rotinas, onde é possível substituir
limites buffer. (Sprintf (?), Gets (), etc)
também: strcpy () que é porque a maioria tem src:
# Define SCYPYN ((a) (b)) strcpy (a, b, sizeof (a))
2) SUID / SGID rotinas escritas em uma das conchas, em vez de C ou
PERL.
3) SUID / SGID rotinas escritos em PERL que não usam o "taintperl"
programa.)
4) as rotinas SUID / SGID que usam o system (), popen (), execlp (), ou
execvp () chama para executar alguma outra coisa.
5) Qualquer programa que usa nomes de caminho relativo dentro do programa.
6) O uso de nomes de caminho relativo para especificar bibliotecas ligadas dinamicamente.
(Procure no Makefile).
7) Rotinas que não verificar códigos de retorno de erro de chamadas do sistema. (Ou seja:
fork (2), suid (2), etc), setuid () sim, como no famoso bug rcp
8) Os buracos podem ser encontrados no código que:
A) é portado para um novo ambiente.
B) recebe a entrada inesperada.
C) interage com outros software local.
D) acessa arquivos do sistema, como passwd, L.sys, etc
E) lê a entrada de um arquivo publicamente gravável / diretório.
F) não programas de diagnóstico que são tipicamente user-prova.
9) Código de ensaio para a entrada inesperada. Cobertura, fluxo de dados, e mutação
ferramentas de teste estão disponíveis.
10) Procure nas páginas do manual, e orienta os usuários para fazer advertências contra X, e
tente variações de X. O mesmo vale para "bugs" seção.
11) Procure raramente usados, ou funções incomuns ou comandos - leia para trás.
Em particular, à procura de bandeiras indocumentados / argumentos podem ser úteis.
Verifique as bandeiras que estavam em versões anteriores, ou em outras versões do sistema operacional. Verificar
para as opções que outros programas possam usar. Por exemplo, telnet utiliza-h
opção de fazer o login ...
direito, como a maioria login.c 's que eu vi ter:
if ((getuid ()) & & hflag) {
syslog ()
exit ()
}
12) Procure por condições de corrida.
13) A falha de software para autenticar que é realmente se comunicando
com o módulo de software ou hardware desejado que quer ser acessando.
14) Falta ou detecção de erros para redefinir os mecanismos de protecção na sequência de um
erro.
15) A aplicação deficiente, resultando em, por exemplo, códigos de condição de ser
inadequadamente testados.
16) a confiança implícita: B rotina assume rotina Um parâmetros estão corretas
A rotina, pois é um processo do sistema.
17) Sistema de lojas é de dados ou parâmetros de referência do usuário na utilizadores
espaço de endereço.
18) comunicação entre processos: as condições de retorno (OK passwd, ilegal
parâmetro, segmento de erro, etc) pode fornecer uma cunha significativa, esp.
quando combinado com (17).
19) os parâmetros do usuário podem não ser adequadamente verificados.
20) Os endereços que se sobrepõem ou se referem a áreas do sistema.
21) verifica código de condição pode ser omitido.
22) Falta de antecipar parâmetros incomum ou extraordinária.
23) Procure níveis do sistema onde os módulos envolvidos foram escritos por
programadores diferentes, ou grupos de programadores - buracos é provável
de ser encontrado.
24) Registros que apontam para a localização de um valor de parâmetros em vez
de passar o valor em si.
25) Qualquer programa executado com privilégios de sistema. (Progs muitos são dadas
uid 0, para facilitar o acesso a certas tabelas, etc)
26) Grupo ou lidos os arquivos temporários, buffers, etc
27) A falta de valores-limite e falta de registro / notificação uma vez que estes
ter sido disparado.
28) A alteração dos parâmetros de áreas críticas do sistema antes da sua execução
por um processo simultâneo. (Condições de corrida)
29) de contorno inadequada verificação em tempo de compilação, por exemplo, um usuário
pode ser capaz de executar código de máquina disfarçada de dados em uma área de dados.
(Se as áreas de texto e dados são compartilhados)
30 do usuário) incorretamente manuseio gerada interrupções assíncronas. Usuários
interromper um processo, realizar uma operação, e quer voltar
para continuar o processo ou começar outra vai freqüentemente deixam o
sistema em um estado desprotegido. Arquivos parcialmente escrita são deixadas abertas,
escrita indevido de mensagens infração proteção, configuração imprópria
de bits de proteção, etc ocorrem frequentemente.
31 Code) que usa fopen (3) sem definir o umask. (Por exemplo: em (1), etc)
Em geral, um código que não repõe o uid real e eficaz antes
bifurcação.
32 Trace) é seu amigo (ou truss em SVR4) para ajudar a descobrir o que
sistema chama um programa está usando.
33) Scan / usr / fs local de perto. Muitos administradores irão instalar software a partir de
da rede. Muitas vezes você vai encontrar tcpdump, top, nfswatch, ... raiz para suid'd
sua facilidade de uso.
34) Verifique os programas suid para ver se eles são os originalmente colocados no
do sistema. Administradores, por vezes, colocar em uma substituição passwd que é menos
segura do que a versão distribuída.
35 Olhar) para programas que estavam lá para instalar software ou pode ser carregada
módulos do kernel.
36) programas dinamicamente ligados em geral. Lembre-se LD_PRELOAD, eu acho
que foi a variável.
37) I / O canal de programação é um dos principais alvos. Procure por erros de lógica,
incoerências e omissões.
38) Veja se é possível para um programa de canal I / O para modificar-se, loop
para trás, e então executar o código recém-modificado. (Instrução de pré-carga
pode estragar tudo)
39) Se os canais de E / S agem como processadores independentes podem ter ilimitado
acesso à memória, assim o código do sistema pode ser modificado na memória antes de
de execução.
40 Olhar) para bugs exigindo falhas em múltiplos pedaços de software, ou seja, dizem
programa pode ser usado para alterar o arquivo de configuração / etc / b um programa agora assume
as informações em um ser correta e isso leva a resultados inesperados
(Basta olhar para quantos programas trust / etc / utmp)
41) Qualquer programa, especialmente aqueles sgid suid /, que permitem que escapa shell.
Categorias:
3 comentários:
Aqui fica a dica para quem QUEM QUER SER UM INFORMATICO EXTREME.
Gostei do seu blog
Gostava que me desses algumas dicas,estou a começar agora quero mt aprender algo
BBamorzinho D q forma voce quer que eu o ajude ??
Postar um comentário
ORA VIVA, OLHA TEU COMENTARIO VALE MAIS DO QUE OURO PARA MIM, PRECISO DELE PARA MELHORAR A DISPONIBILIDADE DO BLOG.