ROOT SECURITY Root exploit on Exynos

Oi, recentemente descobrir uma maneira de obter root em S3 sem piscar Odin. a falha de segurança é no kernel, mesmo com o dispositivo / dev / Exynos-mem. Este dispositivo é de R / W por todos os usuários e dar acesso a toda a memória física . .. ? que há de errado com a Samsung . Sua como / dev / mem, mas para todas as três bibliotecas parece usar / dev / Exynos-mem:

/ System/lib/hw/camera.smdk4x12.so

• / System/lib/hw/gralloc.smdk4x12.so
• / Sistema / lib / libhdmi.so

Muitos dispositivos são causa:

• Samsung Galaxy S2
• Samsung GalAxy Note  2
• MEIZU MX
• potencialmente todos os dispositivos que incorporar Exynos processador (4210 e 4412) que utilizam fontes do kernel Samsung.

A boa notícia é que podemos facilmente obter raiz sobre esses dispositivos e os maus é que não há controle sobre ele. Ram despejo, a injeção de código do kernel e outros poderiam ser possível através de instalação de aplicativo da loja Play. Certamente existe muitas maneiras de fazer isso, mas a Samsung dar um jeito fácil de explorar. Esta falha de segurança é perigoso e expor telefone para aplicativos maliciosos. Exploração com nativa C e JNI poderia ser facilmente exequível. Editado Alguns detalhes: . / dev / Exynos-mem parece ser usado para uso gráfico, como câmera de alocação de memória, gráfico, hdmi Por ativando exibição pid em kmsg, SurfaceFlinger fazer mmap no dispositivo (através de uma das três bibliotecas compartilhadas acima? eu não ver referência em binário para estes libraires) As operações permitidas no dispositivo são (de char / linux / drivers / mem . c):

Código:

static const struct file_operations exynos_mem_fops = {

    . Aberto = exynos_mem_open,

    . Release = exynos_mem_release,

    . Unlocked_ioctl = exynos_mem_ioctl,

    . Mmap = exynos_mem_mmap,

}

 as permissões padrão (de linux / drivers / char / mem.c):

    #ifdef CONFIG_EXYNOS_MEM

[14] = {"exynos-mem", S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | S_IROTH            | S_IWOTH, &exynos_mem_fops}, #endif

ioctl pedido em / dev / Exynos-mem permitir limpar / flush cache L1 e L2, definir a memória página não cacheable e definir o endereço de memória física para uso com mmap. 

Agora a parte interessante:. operação mmap 

O único limite é restringir o acesso a lowmem (de linux / drivers / char / Exynos-mem.c):

Código:

/ * TODO: atualmente lowmem é apenas disponíveis * /

if ((phys_to_virt (início) 

    (Phys_to_virt (início)> = high_memory)) {

    pr_err ("[% s] paddr inválido (0x% 08x) \ n", __ func__, de início);

    EINVAL retorno;

}

O comentário no código acima poderia ser assustador. e um olho em Documentação / braço / memory.txt dizer:

Código:

Comece Uso Final

PAGE_OFFSET high_memory-1 Kernel região RAM direta mapeada.
                            Isso mapeia a memória RAM plataformas, e tipicamente
                            mapas de toda a RAM plataforma em uma relação de 1:1.

Em outras palavras, este dispositivo só permite a possuir a memória física, incluindo o código do kernel. 

A pergunta é por que as permissões são definidas para ler / escrever para todos no kernel e no ueventd.smdk4x12.rc:

• samsung developper responsável por este iria perder o emprego
• alguns aplicativos Samsung com direitos básicos precisar acessá-lo (eu duvido)
• um grande erro

Um patch simples poderia ser a de definir as permissões para 0660 ou 0600 em ueventd.smdk4x12.rc, mas eu não sei como isso afetaria aplicativos Samsung / serviços. Em binário anexo, e fonte para a obtenção de shell de root. 

DOWNLOAD