Proteção da estrutura de mídia

Para melhorar a segurança do dispositivo, o Android 7.0 divide o processo monolítico do servidor de mediaserver em vários processos com permissões e recursos restritos apenas aos exigidos por cada processo. Essas alterações mitigam as vulnerabilidades de segurança da estrutura de mídia:

  • Divisão de componentes de pipeline AV em processos de área restrita específicos do aplicativo.
  • Habilitando componentes de mídia atualizáveis ​​(extratores, codecs, etc.).

Essas mudanças também melhoram a segurança dos usuários finais, reduzindo significativamente a gravidade da maioria das vulnerabilidades de segurança relacionadas à mídia, mantendo os dispositivos e os dados do usuário final seguros.

OEMs e fornecedores de SoC precisam atualizar suas alterações de HAL e estrutura para torná-los compatíveis com a nova arquitetura. Especificamente, como o código Android fornecido pelo fornecedor geralmente assume que tudo é executado no mesmo processo, os fornecedores devem atualizar seu código para transmitir identificadores nativos ( native_handle ) que tenham significado entre os processos. Para uma implementação de referência de mudanças relacionadas ao fortalecimento de mídia, consulte frameworks/av e frameworks/native .

Mudanças arquitetônicas

As versões anteriores do Android usavam um único processo de servidor de mediaserver monolítico com muitas permissões (acesso à câmera, acesso ao áudio, acesso ao driver de vídeo, acesso a arquivos, acesso à rede, etc.). O Android 7.0 divide o processo mediaserver em vários novos processos, cada um exigindo um conjunto muito menor de permissões:

proteção do servidor de mídia

Figura 1. Mudanças de arquitetura para proteção do mediaserver

Essa nova arquitetura garante que, mesmo que um processo seja comprometido, o código malicioso não tenha acesso ao conjunto completo de permissões anteriormente mantidas pelo mediaserver. Os processos são restritos pelas políticas SElinux e secomp.

Observação: devido às dependências do fornecedor, alguns codecs ainda são executados no mediaserver e, consequentemente, concedem mediaserver mais permissões do que o necessário. Especificamente, Widevine Classic continua a ser executado no mediaserver para Android 7.0.

Alterações do MediaServer

No Android 7.0, o processo mediaserver existe para conduzir a reprodução e gravação, por exemplo, passando e sincronizando buffers entre componentes e processos. Os processos se comunicam por meio do mecanismo padrão do Binder.

Em uma sessão de reprodução de arquivo local padrão, o aplicativo passa um descritor de arquivo (FD) para o mediaserver (geralmente por meio da API Java do MediaPlayer) e o mediaserver :

  1. Agrupa o FD em um objeto Binder DataSource que é passado para o processo extrator, que o usa para ler o arquivo usando o Binder IPC. (O mediaextractor não obtém o FD, mas faz o Binder chamar de volta ao mediaserver para obter os dados.)
  2. Examina o arquivo, cria o extrator apropriado para o tipo de arquivo (por exemplo, MP3Extractor ou MPEG4Extractor) e retorna uma interface Binder do extrator para o processo mediaserver .
  3. Faz chamadas IPC do Binder para o extrator para determinar o tipo de dados no arquivo (por exemplo, dados MP3 ou H.264).
  4. Chama o processo mediacodec para criar codecs do tipo necessário; recebe interfaces do Binder para esses codecs.
  5. Faz chamadas repetidas do Binder IPC para o extrator para ler amostras codificadas, usa o Binder IPC para enviar dados codificados ao processo mediacodec para decodificação e recebe dados decodificados.

Em alguns casos de uso, nenhum codec está envolvido (como uma reprodução descarregada onde os dados codificados são enviados diretamente para o dispositivo de saída), ou o codec pode renderizar os dados decodificados diretamente em vez de retornar um buffer de dados decodificados (reprodução de vídeo).

Alterações no MediaCodecService

O serviço de codec é onde os codificadores e decodificadores vivem. Devido às dependências do fornecedor, nem todos os codecs ainda estão no processo de codecs. No Android 7.0:

  • Decodificadores e codificadores de software não seguros vivem no processo de codec.
  • Decodificadores seguros e codificadores de hardware vivem no servidor de mediaserver (inalterado).

Um aplicativo (ou servidor de mídia) chama o processo de codec para criar um codec do tipo necessário e, em seguida, chama esse codec para transmitir dados codificados e recuperar dados decodificados (para decodificação) ou para transmitir dados decodificados e recuperar dados codificados (para codificação) . A transferência de dados de e para codecs já usa memória compartilhada, de modo que o processo permanece inalterado.

Alterações do MediaDrmServer

O servidor DRM é usado ao reproduzir conteúdo protegido por DRM, como filmes no Google Play Filmes. Ele lida com a descriptografia dos dados criptografados de maneira segura e, como tal, tem acesso ao armazenamento de certificados e chaves e outros componentes confidenciais. Devido às dependências do fornecedor, o processo DRM ainda não é usado em todos os casos.

Alterações do servidor de áudio

O processo AudioServer hospeda componentes relacionados ao áudio, como entrada e saída de áudio, o serviço policymanager que determina o roteamento de áudio e o serviço de rádio FM. Para obter detalhes sobre alterações de áudio e orientações de implementação, consulte Implementando áudio .

Alterações do CameraServer

O CameraServer controla a câmera e é usado na gravação de vídeo para obter quadros de vídeo da câmera e depois passá-los para o mediaserver para manuseio posterior. Para obter detalhes sobre alterações e orientações de implementação para alterações do CameraServer, consulte Camera Framework Hardening .

Alterações no ExtractorService

O serviço extrator hospeda os extratores , componentes que analisam os vários formatos de arquivo suportados pela estrutura de mídia. O serviço extrator é o menos privilegiado de todos os serviços - ele não pode ler FDs, então faz chamadas para uma interface Binder (fornecida a ele pelo mediaserver for cada sessão de reprodução) para acessar arquivos.

Um aplicativo (ou mediaserver ) faz uma chamada para o processo extrator para obter um IMediaExtractor , chama esse IMediaExtractor para obter IMediaSources para a faixa contida no arquivo e, em seguida, chama IMediaSources para ler os dados deles.

Para transferir os dados entre processos, o aplicativo (ou mediaserver ) inclui os dados no pacote de resposta como parte da transação Binder ou usa memória compartilhada:

  • O uso de memória compartilhada requer uma chamada extra do Binder para liberar a memória compartilhada, mas é mais rápido e usa menos energia para buffers grandes.
  • Usar in-Parcel requer cópia extra, mas é mais rápido e usa menos energia para buffers menores que 64 KB.

Implementação

Para oferecer suporte à movimentação dos componentes MediaDrm e MediaCrypto para o novo processo mediadrmserver , os fornecedores devem alterar o método de alocação de buffers seguros para permitir que os buffers sejam compartilhados entre os processos.

Nas versões anteriores do Android, os buffers seguros são alocados no mediaserver pelo OMX::allocateBuffer e usados ​​durante a descriptografia no mesmo processo, conforme mostrado abaixo:

Figura 2. Android 6.0 e alocação de buffer inferior no mediaserver.

No Android 7.0, o processo de alocação de buffer mudou para um novo mecanismo que oferece flexibilidade e minimiza o impacto nas implementações existentes. Com as pilhas MediaDrm e MediaCrypto no novo processo mediadrmserver , os buffers são alocados de maneira diferente e os fornecedores devem atualizar os identificadores de buffer seguros para que possam ser transportados pelo fichário quando o MediaCodec invocar uma operação de descriptografia no MediaCrypto .

Figura 3. Alocação de buffer do Android 7.0 e superior no mediaserver.

Usando identificadores nativos

O OMX::allocateBuffer deve retornar um ponteiro para uma estrutura native_handle , que contém descritores de arquivo (FDs) e dados inteiros adicionais. Um native_handle tem todas as vantagens de usar FDs, incluindo suporte de binder existente para serialização/desserialização, enquanto permite mais flexibilidade para fornecedores que não usam FDs atualmente.

Use native_handle_create() para alocar o identificador nativo. O código do framework se apropria da estrutura native_handle alocada e é responsável por liberar recursos no processo em que o native_handle é originalmente alocado e no processo em que é desserializado. A estrutura libera identificadores nativos com native_handle_close() seguido por native_handle_delete() e serializa/desserializa o native_handle usando Parcel::writeNativeHandle()/readNativeHandle() .

Os fornecedores de SoC que usam FDs para representar buffers seguros podem preencher o FD no native_handle com seu FD. Os fornecedores que não usam FDs podem representar buffers seguros usando campos adicionais no native_buffer .

Configurando o local de descriptografia

Os fornecedores devem atualizar o método de descriptografia OEMCrypto que opera no native_handle para executar quaisquer operações específicas do fornecedor necessárias para tornar o native_handle utilizável no novo espaço de processo (as alterações geralmente incluem atualizações nas bibliotecas OEMCrypto).

Como allocateBuffer é uma operação OMX padrão, o Android 7.0 inclui uma nova extensão OMX ( OMX.google.android.index.allocateNativeHandle ) para consultar esse suporte e uma chamada OMX_SetParameter que notifica a implementação OMX de que deve usar identificadores nativos.