Curso MIT "Segurança de sistemas de computadores". Palestra 20: Segurança de Telefonia Móvel, 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

Antes de iniciar uma revisão detalhada do sistema, vamos tentar descobrir uma coisa interessante: por que esses caras desenvolveram um design modular completamente novo para aplicativos Android? Existem aplicativos de desktop, aplicativos web, por que eles precisaram inventar uma maneira completamente nova de escrever software? De fato, de certa forma, isso é confuso para o desenvolvedor. Porque, digamos, estou acostumado a escrever meu pequeno programa em C com a função principal, e agora olho para ele e digo: “que diabos? O que vou fazer com tudo isso? Eu tenho que definir quatro tipos de componentes e enviar intenções, em vez de usar estruturas C e escrever código em linhas regulares? ”



Então, quais são os prós e os contras dos modelos de aplicativos existentes? Temos aplicativos de desktop e Internet, por que precisamos de um terceiro tipo de aplicativo?
Aluno: mas o modelo mudou completamente, certo? Eu acho que você não deve confiar tanto nos desenvolvedores de aplicativos de desktop quanto nos desenvolvedores de aplicativos para dispositivos móveis. Além disso, você possui usuários mais experientes em comparação com o número de usuários experientes de aplicativos de computador e deseja usar um monte de aplicativos isolados um do outro.

Professor: muito possivelmente. Então, você acha que, no caso de aplicativos de desktop, não devemos confiar muito em seus desenvolvedores?

Aluno: é claro, porque sempre existe um filho ou primo mais experiente que o ajudará a resolver problemas com programas de computador, mas as coisas são diferentes com o telefone.

Professor: é claro que é legal que os telefones não precisem de um primo para cuidar deles. Mas, do ponto de vista da segurança, os programas de computador têm uma propriedade característica - a instalação de um novo aplicativo em um computador pode ser um processo demorado. Talvez isso não seja totalmente verdade, porque você sempre pode clicar no arquivo executável e iniciar a instalação, mas não acho que as pessoas instalem aplicativos de área de trabalho regularmente. Afinal, como regra, você tem um conjunto fixo de software que executa.

Nesse sentido, um recurso distinto dos aplicativos da web é o seu fácil lançamento. Você acabou de acessar o site e não precisa fazer nada além de clicar no link e agora já está em um novo site, sob o controle de um novo aplicativo. Portanto, essa é uma propriedade muito boa de um aplicativo da web.



Uma característica ruim dos aplicativos de computador é a falta de isolamento de aplicativos. Talvez isso se deva ao fato de que, quando você instala esse aplicativo, confia totalmente em tudo o que está no seu computador. De fato, não há isolamento entre o aplicativo que você instala no laptop e qualquer outro programa ou dado que já esteja lá, enquanto no caso do aplicativo da Web existe um isolamento razoável. Desde que você confie na Política de mesma origem, você estará seguro. Portanto, é seguro o suficiente acessar um site arbitrário e começar a usar seu aplicativo. Se esse aplicativo não tirar proveito das vulnerabilidades do seu navegador, não interferirá na operação dos sites abertos em outras guias do navegador.



Os aplicativos da Web ainda parecem estar em uma posição melhor, pois são fáceis de usar e isolados. Por que esses caras não estão usando aplicativos da web para Android?

Aluno: os aplicativos da Web parecem conter um sistema operacional, ou seja, por exemplo, existe um Firefox OS, que é essencialmente um SO móvel da Internet.

Professor: com certeza. Você afirma que esses caras estão realmente errados. Eles não deveriam criar um novo sistema operacional Android, mas simplesmente criar um navegador gigante para o seu telefone.

Aluno: pelo menos o Mozilla mostrou que isso é possível.

Professor: bem, isso é bastante justo. No mínimo, é mais prudente criar aplicativos da Web do que sistemas de desktop, pelo menos para o telefone.

Aluno: como você está fazendo uma ligação a partir de um aplicativo da web, é necessário criar uma API completamente nova para comunicar a interface do aplicativo da web com o telefone.

Professor: com certeza. Assim, os aplicativos da web têm uma limitação que pode ser corrigida: a falta de uma API para alguns dispositivos móveis. Mas existem menos aplicativos desse tipo. Por exemplo, para uma câmera ou para um navegador GPS, eles lentamente, mas ainda adicionam a interface apropriada aos aplicativos da web. Mas lá, em aplicativos da web, provavelmente ainda não existe uma API para fazer chamadas, enviar mensagens SMS e afins.

Outra desvantagem dos aplicativos da Web é a incapacidade de estabelecer acesso limitado a outros aplicativos. Conversamos sobre intenções implícitas no Android, onde você poderia dizer: “Quero ver esta imagem JPEG, mas quem sabe qual aplicativo a abrirá? Quero visualizar esse arquivo PDF ou compartilhar esta foto com meu amigo que acabei de tirar com minha câmera, mas não sei qual aplicativo de email será usado. ” Então, vamos apenas pedir ao monitor de link para me encontrar um programa de e-mail que enviará esta foto. Em um dispositivo Android, isso é fácil, mas no caso de aplicativos da web causará grandes dificuldades, pois cada interação deve ser vinculada a um URL específico.



Portanto, se você não souber qual visualizador de PDF alguém está usando, não saberá qual URL pode usar para visualizar seu arquivo.

Aluno: talvez uma desvantagem dos aplicativos da Web seja que o JavaScript é muito difícil de ler?

Professor: sim, outro inconveniente é que todos eles são escritos em JavaScript. Então, potencialmente, isso pode não ser muito bom em termos de desempenho, pode ser difícil entender o que o programa está fazendo, pode ser difícil compilar com eficiência e assim por diante.

Vamos voltar aos programas de computador. Um recurso útil dos aplicativos da área de trabalho é a capacidade de compartilhar arquivos. Todos os seus arquivos estão disponíveis em todos os aplicativos porque você os compartilha. Assim, você tem acesso fácil a todos os dados disponíveis no computador.



O que é um pouco difícil de implementar no Android é fácil de fazer em aplicativos de computador. No caso de sistemas operacionais de desktop, se eu quiser compilar um software, executarei MAKE, GCC e, possivelmente, alguns outros programas, e todos eles funcionarão no mesmo código-fonte C no mesmo diretório. Isso é muito mais difícil de fazer no Android, onde os dados estão associados ao aplicativo principal, que é armazenado pelo provedor de conteúdo. Então você precisa mexer com ele, primeiro usando o repositório de código-fonte e depois instalando o compilador C, o programa MAKE, o assembler e muito mais. É muito mais difícil fazê-los trabalhar juntos.

Isso pode ser feito ignorando algumas das limitações do Android, mas em qualquer caso mais complicado do que nos sistemas de desktop.

Aluno: Eu acho que otimizar aplicativos da Web é bastante difícil, eles são limitados pelo uso da RAM e pelo poder de processamento.

Professor: sim, os princípios de otimização de aplicativos da Web e aplicativos de desktop são diferentes. Acredito que a desvantagem dos aplicativos Web, pelo menos no momento em que eles estavam projetando o Android, era que o lançamento offline do aplicativo Web era muito difícil. Se o seu telefone captar um sinal de rede fraco, será difícil iniciar alguns aplicativos, principalmente se algumas partes estiverem fora do cache. No entanto, acho que, como você notou, os aplicativos da Web, embora lentamente, "alcançam" o Android, eliminando as restrições atuais. Portanto, é perfeitamente possível que os aplicativos da Web sirvam como um modelo razoável para o lançamento de uma nova plataforma operacional de telefone. Mas cinco anos atrás eles não eram bons o suficiente para isso.

Mas, apesar das deficiências existentes, agora será muito mais fácil "empurrar" aplicativos da Web para o nicho ocupado pelo Android, em vez de começar a desenvolver um novo sistema operacional móvel do zero. Portanto, acho que ainda podemos falar sobre os sucessos do que o Android fez, embora talvez hoje você prefira não fazer dessa maneira.
Eu acho que em termos de isolamento, a segurança do sistema Android é muito maior. Como mencionei, o Android conta com o kernel do Linux para isolar aplicativos um do outro. A plataforma Android realmente define IDs de usuário, portanto, este App1 terá UID 1001, App 2 terá UID 1002 e o monitor de link, que geralmente possui privilégios de root, terá UID 0. Portanto, o kernel do Linux é amplamente responsável por Separação de aplicações uma da outra.



Basicamente, a interação entre identificadores de usuário ocorre através de intenções de intenção. Existem muitas outras nuances sobre como o kernel do Linux controla aplicativos usando o UID, falaremos sobre isso um pouco mais tarde.

Uma pergunta interessante: por que esses caras escolheram o Java? Qual é o papel do Java no Android? Por que é necessário? Se escrevermos todos os aplicativos em C, em vez de Java, ou, por exemplo, Assembler, algo pode quebrar?

Aluno: se você tem vulnerabilidades, o uso dessas linguagens pode levar a uma distorção dos indicadores importantes para o sistema.

Professor: sim, isso pode acontecer, por exemplo, um estouro de buffer pode ocorrer no aplicativo. O que mais?

Aluno: pode ocorrer confusão com permissões.

Professor: com que permissões?

Aluno: com latência, latência.

Professor: vamos dar uma olhada nisso. Portanto, como dissemos, o monitor de link verifica as tags para nós e, na verdade, armazena no sistema Android uma lista de todos os aplicativos instalados, além de tags que correspondem a todos esses aplicativos. Portanto, você provavelmente não deseja que o monitor de link cometa erros, independentemente do idioma em que está escrito. Portanto, ter um monitor de link escrito em uma linguagem de segurança de tipo é uma boa solução. Eu gosto de Java porque é uma linguagem de tipo seguro com bons recursos. Porém, mesmo se o aplicativo fosse gravado em C e ocorressem estouros de buffer, ele ainda não poderia danificar os rótulos no monitor de link. Portanto, isso não seria um grande problema.

Aluno: talvez haja algum tipo de sistema que possa danificar o código escrito em C?

Professor: sim, portanto, em princípio, seria bom evitar aplicativos que falem diretamente com o kernel do Linux. No Android, esse não é o caso. Os aplicativos Android podem fazer chamadas arbitrárias ao sistema, se quiserem. De fato, por razões de desempenho, os aplicativos não podem afetar componentes arbitrários escritos em C ou Assembler, e é por isso que alguns jogos "falam" em Java.

Aluno: Eu acho que, de alguma forma, é uma oportunidade de usar todo o material escrito para Java, ou seja, os criadores do Android queriam simplificar a criação de aplicativos para desenvolvedores. E uma das maneiras mais fáceis de fazer isso é possibilitar o aproveitamento das volumosas bibliotecas Java.

Professor: muito possivelmente. Eu acho que uma das principais razões para usar Java é a usabilidade. Eles provavelmente estavam mais preocupados com a programação e a facilidade de desenvolvimento, pois o Java tem pouco a ver com segurança.

Outra coisa que tem um lugar aqui, ao contrário do iPnone. O sistema operacional do iPhone também tem facilidade de desenvolvimento, mas usa C e, se você tentar, poderá causar um estouro de buffer. Além disso, há uma especificidade para um equipamento específico, portanto, nem todos podem ter as mesmas bibliotecas. Eu acho que a principal razão pela qual os desenvolvedores do Android escolheram o Java é porque eles inicialmente não conheciam as características dos dispositivos nos quais esse sistema operacional funcionaria. Por exemplo, os criadores do iPhone sabiam com certeza que teriam um processador ARM no telefone, então pré-compilaram o software com esse modelo em particular. E essa abordagem é mais eficaz, porque o consumo de bateria é de grande importância para o telefone.



O fato de o pessoal do Android usar Java é provavelmente menos eficiente em termos de economia de energia ou desempenho do processador, porque está relacionado ao JRE e assim por diante. Mas há a vantagem de portar o sistema operacional para dispositivos com arquiteturas diferentes. Portanto, se você tiver telefones com processadores MIPS, ARM ou x86, o aplicativo Java poderá ser executado nos três dispositivos. Os desenvolvedores do Android queriam que sua plataforma fosse usada em qualquer tipo de equipamento ou telefone. Portanto, essa é provavelmente a principal razão pela qual eles sacrificaram a segurança pelo uso do Java.

Acontece que o Java Runtime Environment não fornece nenhum benefício especial de segurança para aplicativos, é apenas uma coisa conveniente para desenvolvedores e usuários. Mas, do ponto de vista do isolamento, tudo depende basicamente do kernel e do monitor de link que controla o aplicativo.

Aluno: A facilidade de desenvolvimento não leva a alguma segurança de aplicativo? De fato, ao escrever um monitor de referências C, há muitas outras maneiras de cometer erros.

Professor: sim, você está absolutamente certo! De fato, eu não deveria ter dito que a facilidade de desenvolvimento não tem nada a ver com segurança. Isso é completamente estúpido, porque você quer fazer isso tão facilmente quanto escrever o código certo. Portanto, de certa forma, um sistema para o qual você pode escrever facilmente o código correto sozinho oferece mais segurança. De certa forma, você está certo ao supor que os desenvolvedores do Android queriam evitar erros ao escrever código, então não queria escrevê-lo na complexa linguagem C. E não sei por que a Apple escolheu C como a linguagem de programação ao desenvolver seu sistema operacional.

Como essa escolha cria um problema de estouro de buffer no aplicativo, e se esse aplicativo é de grande importância, ele é potencialmente vulnerável. Não em relação a comprometer outros aplicativos, mas você ainda não deseja que seu aplicativo bancário seja escrito em C.



Aluno: Link Monitor escrito em Java ou C?

Professor: No Android, o monitor de link é principalmente escrito em Java. No entanto, existem alguns "ganchos" nele para se comunicar com interfaces e aplicativos externos usando código nativo. Mas a maior parte da lógica é escrita em Java. Portanto, este é realmente um plano bastante seguro.

Agora vamos tentar descobrir para que mais os UIDs de aplicativos são usados, exceto para separar aplicativos entre si em termos dos processos que eles iniciam. O principal motivo para usar o UID é criar a capacidade de compartilhar o acesso a recursos compartilhados e trocar dados no sistema.

Já vimos um mecanismo para isso - enviando intenções para o monitor de link. Mas no Android, há muitas coisas que não estão sendo feitas através da intenção do monitor de link. Provavelmente nem tudo é enviado via Intent por motivos de desempenho. Você não deseja chamar o monitor de link para todas as operações realizadas no sistema, antes de tudo, diz respeito ao acesso à Internet. Se você deseja acessar a Internet em um dispositivo com Android, basta abrir o soquete, como em qualquer aplicativo Linux padrão. Um aplicativo pode simplesmente perguntar ao kernel: “Preciso de um soquete porque quero conectar-me a esta máquina”, é assim que a Internet é acessada.

Em seguida, o acesso à mídia removível deve ser observado. SD-, . , , , , , . , . , , Android . , , GPS-, .



«» Android, Linux, /dev/camera. Linux, , , . , - , , Java. C Assembler, Linux, . Java , Java-.

: , , - , ?

: , ! , . ? , №2, ID . Android UID GID , . , . , , , - «android.permission.internet», , .



, . , , , . — Linux Android. , - , - , , Linux. Android GID 3003, . , , . , - . Android - , . , GID UID .

SD-. GID, SD-, , . , . , SD- GID SD-.
, , Android.



, , , . , SQL -, , . — UID , , .

, , , GPS, . GID, . , , dev/camera - GID, , , GID .

, , №2, , UID GID , - .

, SD-? , SD-? , SD- , , . ?

: , , , , .

: . , Android , . , SD- . , , SD- . , Android , , , FAT, - . , , - .

: , ?

: , . , , . , , , , . , .



— , , ? , , DIALPERM, INTERNET, FRIENDVIEW?

: , , ?

: , , , . , , . , . Android , iOS, , iPhone , , , SMS-, JPEG . .

– , , . . , Android , , . , - «», , , , , OK. , , .

, , , Android , — , . , , , . Android, 4.3, , , . , . , , , , . , , API, , .

55:10

MIT « ». 20: « », 3


.

, . ? ? , 30% entry-level , : VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps $20 ? ( RAID1 RAID10, 24 40GB DDR4).

VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps , .

Dell R730xd 2 ? 2 x TV Intel Dodeca-Core Xeon E5-2650v4 de 128 GB DDR4 de 6x480 GB SSD de 1 Gbps 100 a partir de US $ 249 na Holanda e nos EUA! Leia sobre Como criar um prédio de infraestrutura. classe c usando servidores Dell R730xd E5-2650 v4 que custam 9.000 euros por um centavo?