Curso MIT "Segurança de sistemas de computadores". Aula 21: Rastreamento de Dados, Parte 2

Instituto de Tecnologia de Massachusetts. Curso de Aula nº 6.858. "Segurança de sistemas de computador". Nikolai Zeldovich, James Mickens. 2014 ano

Computer Systems Security é um curso sobre o desenvolvimento e implementação de sistemas de computador seguros. As palestras abrangem modelos de ameaças, ataques que comprometem a segurança e técnicas de segurança baseadas em trabalhos científicos recentes. Os tópicos incluem segurança do sistema operacional (SO), recursos, gerenciamento de fluxo de informações, segurança de idiomas, protocolos de rede, segurança de hardware e segurança de aplicativos da web.

Palestra 1: “Introdução: modelos de ameaças” Parte 1 / Parte 2 / Parte 3
Palestra 2: “Controle de ataques de hackers” Parte 1 / Parte 2 / Parte 3
Aula 3: “Estouros de Buffer: Explorações e Proteção” Parte 1 / Parte 2 / Parte 3
Palestra 4: “Separação de Privilégios” Parte 1 / Parte 2 / Parte 3
Palestra 5: “De onde vêm os sistemas de segurança?” Parte 1 / Parte 2
Palestra 6: “Oportunidades” Parte 1 / Parte 2 / Parte 3
Palestra 7: “Sandbox do Cliente Nativo” Parte 1 / Parte 2 / Parte 3
Aula 8: “Modelo de Segurança de Rede” Parte 1 / Parte 2 / Parte 3
Aula 9: “Segurança de aplicativos da Web” Parte 1 / Parte 2 / Parte 3
Palestra 10: “Execução Simbólica” Parte 1 / Parte 2 / Parte 3
Aula 11: “Linguagem de Programação Ur / Web” Parte 1 / Parte 2 / Parte 3
Aula 12: Segurança de rede Parte 1 / Parte 2 / Parte 3
Aula 13: “Protocolos de Rede” Parte 1 / Parte 2 / Parte 3
Palestra 14: “SSL e HTTPS” Parte 1 / Parte 2 / Parte 3
Palestra 15: “Software Médico” Parte 1 / Parte 2 / Parte 3
Palestra 16: “Ataques de Canal Lateral” Parte 1 / Parte 2 / Parte 3
Palestra 17: “Autenticação de Usuário” Parte 1 / Parte 2 / Parte 3
Palestra 18: “Navegação Privada na Internet” Parte 1 / Parte 2 / Parte 3
Palestra 19: “Redes Anônimas” Parte 1 / Parte 2 / Parte 3
Palestra 20: “Segurança do telefone móvel” Parte 1 / Parte 2 / Parte 3
Palestra 21: “Rastreando Dados” Parte 1 / Parte 2 / Parte 3

Aluno: por que é simplesmente impossível digitalizar o código e não verificá-lo manualmente?

Professor: na prática, é isso que acontece. Os desenvolvedores sabem que sempre que o intérprete faz esse tipo de trabalho, ao retornar o valor retornado, é usado um código especial que atribui automaticamente o valor do sistema infectado a system.arraycopy (), que deve estar associado a ele.

Aluno: certo, mas qual é a parte manual do trabalho?

Professor: a parte do manual é principalmente descobrir qual deve ser a política de execução da auditoria. Em outras palavras, se você apenas olhar o TaintDroid padrão ou o Android padrão, eles farão algo por você, mas não poderão atribuir o Taint automaticamente da maneira correta. Portanto, alguém deve atribuir manualmente uma política de rastreamento.



Não parece que será um grande problema na prática. Mas se o número de aplicativos que usam métodos orientados à máquina aumenta constantemente, podemos ter pequenos problemas.

Outro tipo de dados com que se preocupar em termos de atribuição de uma infecção são as mensagens IPC. As mensagens IPC são essencialmente tratadas como matrizes. Portanto, cada uma dessas mensagens será associada a uma única mancha comum, que é a união de infecções de todas as suas partes constituintes.

Isso contribui para o desempenho do sistema, pois precisamos armazenar apenas uma marca de contaminação para cada uma dessas mensagens. Em um caso extremo, um grau de infecção será simplesmente reavaliado, mas nunca levará a uma diminuição na segurança. A pior coisa que pode acontecer ao mesmo tempo é que a rede não obterá dados que poderiam chegar lá sem consequências perigosas para a privacidade.

Portanto, quando você cria uma mensagem IPC, ela recebe a mancha combinada. Quando você lê o que recebeu nesta mensagem, os dados extraídos são infectados pela própria mensagem, o que faz sentido. É assim que as mensagens IPC são tratadas.

Também vale a pena se preocupar com a forma como o arquivo é processado. Portanto, cada arquivo recebe uma tag de contaminação e essa tag é armazenada com o arquivo em seus metadados em uma mídia de armazenamento estável, como um cartão de memória SD. Aqui, a mesma abordagem conservadora da infecção ocorre como nos casos anteriores. A idéia principal é que o aplicativo obtenha acesso a alguns dados confidenciais, por exemplo, a localização do GPS, e provavelmente irá gravar esses dados em um arquivo; portanto, o TaintDroid atualiza a tag de contaminação desse arquivo com o sinalizador GPS, após o qual o aplicativo é fechado. Posteriormente, outro aplicativo que lê esse arquivo pode ser incluído.



Quando ele entra na máquina virtual, no aplicativo, o TaintDroid vê que ele possui esse sinalizador e, portanto, todos os dados extraídos ao ler esse arquivo também terão esse sinalizador GPS. Eu acho que é bem simples.

Então, que coisas podemos infectar da perspectiva de Java? Existem basicamente cinco tipos de objetos Java que precisam de sinalizadores de contaminação. Em primeiro lugar, essas são variáveis ​​locais Variáveis ​​locais que são usadas no método. Voltando aos exemplos anteriores, podemos assumir que char c é uma variável.

Portanto, devemos atribuir sinalizadores a esses elementos. O segundo tipo são os argumentos do método Method; eles também devem ter sinalizadores de infecção. Ambas as coisas estão na pilha, então o TaintDroid precisa acompanhar o objetivo das bandeiras e muito mais para esses tipos de objetos.
Também precisamos atribuir sinalizadores aos campos de instância dos campos de instância de Objeto. Imagine que existe um certo objeto C, é um círculo, e eu quero saber seu raio. Portanto, temos o campo c.radius e devemos associar as informações de infecção para cada um desses campos: with e radius.
O quarto tipo de objeto Java são os campos de classe estática dos campos de classe estática, que também exigem informações de contaminação. Pode ser algo como circle.property, ou seja, uma descrição das propriedades do círculo para as quais atribuímos algumas informações a serem manchadas.

O quinto tipo são matrizes de matrizes, sobre as quais falamos anteriormente, e atribuímos uma informação comum de infecção para toda a matriz.

A idéia básica de implementar sinalizadores de contaminação para esses tipos de objetos Java é tentar armazenar sinalizadores de contaminação para uma variável próxima à própria variável.



Digamos que temos alguma variável inteira e queremos colocar algum tipo de poluição contaminada nela. Queremos tentar manter esse estado o mais próximo possível da variável, possivelmente por razões de garantir uma operação eficiente do cache no nível do processador. Se nos mantivermos muito distantes dessa variável, isso poderá causar problemas, porque depois que o intérprete verificar o valor da memória dessa variável Java real, ele desejará se familiarizar com as informações sobre sua infecção o mais rápido possível.

Se observarmos a operação de mudança de posição, notamos que nesses locais do código dst e src, quando o intérprete considera os valores, ele também considera as infecções de contaminação correspondentes.

Assim, colocando essas coisas o mais próximo possível um do outro, você está tentando garantir um uso mais eficiente do cache. Isso é bem simples. Se você observar o que os desenvolvedores fazem pelos argumentos dos métodos e variáveis ​​locais que vivem na pilha, poderá ver que eles destacam essencialmente os sinalizadores de contaminação ao lado de onde as variáveis ​​estão localizadas.

Suponha que tenhamos uma coisa favorita em nossas palestras, um diagrama de pilhas que você provavelmente odiará em breve por menções frequentes. Deixe que a variável local 0 esteja localizada em nossa pilha, o TaintDroid armazenará na memória uma tag sobre a infecção dessa variável logo abaixo dela. Se você tiver outra variável a seguir, sua tag também estará localizada diretamente abaixo dela, e assim por diante. É bem simples. Todas essas coisas estarão localizadas na mesma linha de cache, o que tornará o acesso à memória mais barato.



Aluno: Gostaria de saber como você pode ter um sinalizador para uma matriz inteira e sinalizadores diferentes para cada propriedade de um objeto. E se um dos métodos do objeto puder acessar os dados armazenados em suas propriedades? Isso seria ... você sabe o que eu quero dizer?

Professor: Você está perguntando sobre o motivo de aplicar exatamente essa política?

Aluno: sim, sobre o motivo do uso dessa política.

Professor: Eu acho que isso é feito para garantir a eficácia da implementação. Provavelmente, existem outras regras - por exemplo, elas não informam o comprimento da matriz de dados, porque é possível o vazamento de informações e, portanto, não estendem a infecção a esse indicador. Então, acho que algumas decisões são tomadas simplesmente por razões de eficiência. Em princípio, não há nada que atrapalhe ao dar acesso a cada elemento da matriz para indicar que a coisa à esquerda recebe manchas apenas de quaisquer elementos específicos.

No entanto, não está claro se isso será correto, porque, aparentemente, se você colocar alguma coisa na matriz, ela deve saber algo sobre essa matriz. Portanto, acho que os desenvolvedores usam uma combinação de ambas as políticas. Sendo excessivamente conservador, você não deve permitir o vazamento de dados que deseja proteger, mas, ao mesmo tempo, para ter acesso à matriz, você deve saber algo sobre isso. E quando você precisa aprender algo sobre algo, geralmente significa que você usa a mancha.

Portanto, este é o esquema básico que eles usam para armazenar todas essas informações próximas umas das outras. Pode-se imaginar que o mesmo é feito para os campos de classe e para os objetos. Ao declarar uma classe, você tem alguma memória de slot para uma variável específica e, ao lado desse slot, há informações de mácula para essa variável. Então eu acho que tudo isso é bastante razoável.

Este é o princípio do TaintDroid. Quando o sistema é inicializado ou em outras ocasiões durante a operação do sistema, o TaintDroid examina todas as fontes de informações potencialmente infectadas e atribui um sinalizador a cada uma dessas coisas - sensor de GPS, câmera e assim por diante. À medida que o programa é executado, ele extrai informações confidenciais dessas fontes, após as quais o intérprete considerará todos os tipos de funções, de acordo com a tabela fornecida no artigo, para descobrir como espalhar a infecção contaminada pelo sistema.

A coisa mais interessante acontece quando os dados tentam penetrar no sistema. O TaintDroid pode controlar as interfaces de rede e ver tudo o que tenta passar por elas. Ele procura por tags contaminadas e, se os dados que estão tentando penetrar na rede tiver um ou mais desses sinalizadores, eles serão proibidos de usar a rede. O que acontece neste momento depende realmente da aplicação.



Por exemplo, o TaintDroid pode mostrar ao usuário um aviso dizendo que alguém está tentando enviar dados sobre sua localização para o lado. É possível que o TaintDroid contenha políticas internas que permitam ao aplicativo acessar a rede, mas, ao mesmo tempo, redefinirá todos os dados confidenciais que ele tentará transferir e assim por diante. No artigo, esse mecanismo não é descrito em detalhes suficientes, uma vez que os autores estavam preocupados principalmente com a questão do “vazamento” de dados na rede.

Uma seção do artigo intitulada "Avaliação" discute algumas das coisas encontradas no processo de estudo do sistema. Portanto, os autores do artigo descobriram que os aplicativos Android tentarão extrair dados de maneiras invisíveis para o usuário. Suponha que eles tentem usar sua localização para publicidade, enviem seu número para um servidor remoto e assim por diante. É importante observar que esses aplicativos, como regra, não “quebram” o modelo de segurança do Android no sentido de que o usuário deve permitir que eles acessem a rede ou usar a lista de contatos. No entanto, os aplicativos não fornecem no contrato de licença do EULA que pretendem enviar um número de telefone para algum servidor Silk Road 8 ou algo parecido. Na verdade, trata-se de usuários fraudulentos e enganosos sobre as verdadeiras intenções do aplicativo, porque se eles vissem esses requisitos do EULA e soubessem com o que estavam preocupados, poderiam pensar em instalar ou não esse aplicativo em seu smartphone.

Aluno: pode-se supor que, mesmo que eles incluam esses requisitos no contrato de licença, ele não funcionaria, porque as pessoas geralmente não lêem o EULA.

Professor: essa é uma suposição bastante razoável, porque mesmo os cientistas da computação nem sempre verificam o contrato de licença. No entanto, essa honestidade no EULA ainda seria benéfica, porque há pessoas que realmente lêem o contrato de licença. Mas você está absolutamente certo ao supor que os usuários não leem muitas páginas escritas em letras pequenas, apenas clicam em "concordar" e instalam o aplicativo.

Então, acho que as regras para passar informações pelo sistema são bastante simples, como já dissemos, a contaminação simplesmente se move do lado direito para o esquerdo. No entanto, algumas vezes essas regras para o movimento do fluxo de informações podem ter resultados um tanto conflitantes.
Imagine que um aplicativo implemente sua própria classe de listas vinculadas. Temos uma classe simples chamada ListNode, que terá um campo de objeto para dados do objeto e um próximo objeto ListNode que representa a próxima lista.

Suponha que o aplicativo atribua dados infectados ao campo de dados do objeto - informações confidenciais recebidas de um sensor GPS ou algo mais. A questão é: quando calculamos o tamanho dessa lista, ela deve estar infectada? Você ficará surpreso ao saber que a resposta para a pergunta será "não", o que é explicado pela forma como o TaintDroid e alguns desses sistemas determinam o fluxo de informações. Vamos ver o que significa adicionar um nó a uma lista vinculada.

A adição de um nó consiste em 3 etapas. Portanto, a primeira coisa a fazer é selecionar um novo nó da lista que contenha os dados que você deseja adicionar - Alloc ListNode. A segunda etapa é atribuir um campo de dados a esse novo nó. E a terceira coisa que você faz é usar algum tipo de patch para o ListNode ao lado para mesclar os nós em uma lista - este é o "próximo" ponteiro ptr.



Curiosamente, o terceiro passo não está relacionado ao campo de dados, apenas considera o próximo valor. Assim que os dados do objeto são infectados, começamos a calcular o comprimento da lista, começando em algum nó principal, passando por todos os "próximos" ponteiros ptr e contando apenas quantos ponteiros passaram. Portanto, o algoritmo de contagem não toca nos dados infectados.

Curiosamente, se você tiver uma lista vinculada que é preenchida com dados infectados e calcula seu comprimento, isso não levará à geração de um valor infectado. Isso pode parecer um pouco ilógico, embora, ao considerar matrizes, já tenhamos dito que o comprimento da matriz também não contém manchas. Existe a mesma razão. No final da palestra, discutiremos como você pode usar uma linguagem que permita a você como programador determinar seus próprios tipos de infecção e, em seguida, você poderá desenvolver sua própria política para tais coisas.
Uma boa característica do TaintDroid é que você, como desenvolvedor, não precisa rotular nada, o TaintDroid faz isso por você. Ele observa todas as coisas confidenciais que podem ser uma fonte de informação e todas as coisas que podem ser "sumidouros" de informações, para que você, como desenvolvedor, esteja pronto para trabalhar. Mas se você deseja controlar a adição de nós, pode ser necessário criar algumas políticas.
Como o TaintDroid afeta o desempenho do sistema? As despesas gerais existentes realmente parecem bastante razoáveis. A sobrecarga de memória é armazenar todas as tags de infecção. A carga do processador consistirá principalmente no destino, distribuição e verificação dessas infecções, e deve-se observar que o uso da máquina virtual Dalvik é um trabalho adicional. Então, olhando a fonte, olhando essas informações de infecção de 32 bits, realizamos operações que já consideramos. Isso é sobrecarga computacional.

Essas despesas gerais parecem bastante moderadas. Segundo os autores do artigo, o armazenamento de tags contaminadas requer 3% a 5% de memória adicional, portanto, isso não é tão ruim. A carga do processador é um pouco maior e pode atingir de 3% a 29% da capacidade de computação. Isso se deve ao fato de que cada vez que o loop é executado, o intérprete precisa examinar esses tags e executar as operações correspondentes. Embora sejam apenas operações bit a bit, elas precisam ser executadas o tempo todo. Isso não é ruim, mesmo no caso de uma carga de 29%, porque os desenvolvedores do Vale do Silício estão constantemente falando sobre a necessidade de processadores quad-core para telefones modernos. O único problema pode surgir com a bateria, porque mesmo se você tiver núcleos de processador adicionais, é improvável que você tenha um telefone quente no bolso que comece a "explodir" ao tentar calcular essas coisas. Mas se a sua bateria não for particularmente afetada por esses cálculos, tudo não será tão ruim.



Portanto, esta foi uma visão geral do trabalho do TaintDroid. Tem uma pergunta?

Aluno: você etiqueta apenas o que existe o tempo todo? Ou cada variável está marcada?

Professor: tudo está marcado, portanto, teoricamente, nada impede você de fornecer informações sobre a infecção para coisas que não têm infecção. , - taint, - . - , , . taint, , , - , , . , , - . TaintDroid . Dalvik.

– taint x86 ARM? , , , , , , Java . ?

, , , . , , , , , Java- - . x86, , , , , , .
, taint , , , . .



, x86 — . . , - x86, . , , , P, , , !

, taint x86. , , , AD, , .
-, , . -, , . , , , .

, . , . , , , . , « » Taint Explosion.
, , . , Dungeons and Dragons, .

, , - - . , , , .
, - esp esb. , .



, x86, , esp. , , . , , , ebp, , , . , , , taint .

, Linux . , . , - .

: ? , .

: . x86, , . , . Bochs – IBM PC, 86. TaintBochs, x86 . x86, , . , . , , , , , , - .

54:10

Curso MIT "Segurança de sistemas de computadores". Aula 21: Rastreamento de Dados, Parte 3


A versão completa do curso está disponível aqui .

Obrigado por ficar conosco. Você gosta dos nossos artigos? Deseja ver materiais mais interessantes? Ajude-nos fazendo um pedido ou recomendando a seus amigos, um desconto de 30% para os usuários da Habr em um análogo exclusivo de servidores básicos que inventamos para você: Toda a verdade sobre o VPS (KVM) E5-2650 v4 (6 núcleos) 10GB DDR4 240GB SSD 1Gbps de US $ 20 ou como dividir o servidor? (as opções estão disponíveis com RAID1 e RAID10, até 24 núcleos e até 40GB DDR4).

VPS (KVM) E5-2650 v4 (6 núcleos) 10 GB DDR4 240 GB SSD de 1 Gbps até janeiro de graça quando pagar por um período de seis meses, você pode fazer o pedido aqui .

Dell R730xd 2 vezes mais barato? Somente nós temos 2 TVs Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 a partir de US $ 249 na Holanda e nos EUA! Leia sobre Como criar um prédio de infraestrutura. classe usando servidores Dell R730xd E5-2650 v4 custando 9.000 euros por um centavo?