Playing with Sandbox: An analysis of Capsicum

Introduction

In this post, we will talk about sandbox. Researchers who work and study software exploitation probably know the concept. When properly implemented on a system, this kind of feature makes it harder to compromise the system. On Wikipedia, we have a good description of the concept:

“In computer security, a sandbox is a security mechanism for separating running programs. It is often used to execute untested code, or untrusted programs from unverified third parties, suppliers, untrusted users and untrusted websites. A sandbox typically provides a tightly controlled set of resources for guest programs to run in, such as scratch space on disk and memory. Network access, the ability to inspect the host system or read from input devices are usually disallowed or heavily restricted.”

The sandbox is a security mechanism that separates processes. Basically, we have a process with least privileges (target) and another process with greater privileges (broker). If the process with least privileges needs to execute an operation that is not allowed, a request is sent to the broker. Then, the broker checks whether the operation is allowed to be executed. If so, it executes, acknowledges the execution and returns a value to the target when needed. Sandboxes is used to protect the application and can also be used to provide a restricted and safe environment for execution and testing of malicious binaries. As an example, the Cuckoo Sandbox that is used for malware analysis.

In this post, we will talk about Capsicum [1]. It is a sandbox technology developed by the University of Cambridge. Capsicum support has already being implemented for several popular commands in the FreeBSD operating system, such as tcpdump [2], hastd, dhclient, kdump and sshd [3]. The experimental version was developed for FreeBSD [5] and was available since version 9.0. This sandbox adds two new features to the system, capability mode and capabilities.

Uma análise do CVE-2012-0217

Introdução

Em junho desse ano (2012) o time de segurança do sistema operacional FreeBSD publicou um alerta de segurança sobre uma vulnerabilidade descoberta por Rafal Wojtczuk que afeta todas as versões 64 bits.

Essa vulnerabilidade não só afeta o sistema operacional FreeBSD mas também vários sistemas operacionais e sistemas de virtualização[1] disponíveis, com exceção do OpenBSD 5.0 e o Linux que já tinham corrigido a vulnerabilidade desde 2006[3].

Nesse post será explicado a natureza da vulnerabilidade e como ela pode ser utilizada para obter execução de códigos no kernel. Apesar de já existir exploits públicos para Windows [4] e para FreeBSD[5] [6], um exploit para FreeBSD também será apresentado nesse artigo.

Assume-se que o leitor saiba como funciona exploração de vulnerabilidades em kernel, sistemas operacionais e suas estruturas, principalmente IDT[7] e como realizar debugging do kernel.

Os experimentos realizados nesse artigo foram realizados utilizando a versão 9.0 RELEASE do FreeBSD.

Continue reading “Uma análise do CVE-2012-0217”

Entendendo e explorando o CVE-2012-4576 para o kernel do FreeBSD

Introdução

Dando continuidade a exploração de vulnerabilidades em kernel-land [1], neste artigo serão analisados os detalhes da vulnerabilidade registrada no CVE-2012-4576 e como podemos utilizá-la para obter execução de código no kernel do FreeBSD.

Esta vulnerabilidade foi reportada por Mateusz Guzik e o advisory [2] oficial do time de segurança do FreeBSD foi publicado no dia 22 de Novembro de 2012.

A falha ocorre devido a falta de validação em uma chamada de sistema. Como resultado, regiões de memória podem ser sobrescritas. A vulnerabilidade existe no módulo que adiciona a compatibilidade de execução de arquivos binários nativos do Linux no FreeBSD, então apenas sistemas que usam este recurso podem estar vulneráveis.

Todos os experimentos neste artigo foram realizados no sistema operacional FreeBSD 7.0, 8.2 e 9.0 arquitetura 32 bits (i386).

An almost perfect vulnerability for kernel rootkits – Uma quase perfeita vulnerabilidade para carregar rootkits em kernel

English / Português

English:

Access to the kernel of a system means to get access to one of the most interesting part of a computer. When accessing the kernel, an attacker gets privilege to do many things one could not do in user space. Therefore, I started to think about vulnerabilities that allow to load kernel modules without proper permissions. After browsing a bit, I found out that similar vulnerabilities were found in the Linux kernel. The vulnerabilities identified by CVE-2013-7421 [1] and CVE-2014-9644 [2]. In fact these two CVEs are about the same vulnerability and they could be considered as duplicated CVEs. The first patch [3] did not really fix the problem and even so allowed exploitation. After a few days since the first patch, a new one [4] appeared and fixed the problem. This post was written based on my understanding of the information and references available on [5].

Português:

Acesso ao kernel de um sistema significa ganhar acesso a uma das partes mais interessantes de um computador. Ao acessar o kernel, um atacante ganha privilégio para fazer muitas coisas que não poderia ser feito no espaço de usuário. Sendo assim, comecei a pensar em vulnerabilidades que permitissem carregar módulos no kernel sem os privilégios necessários. Depois de pesquisar um pouco, descobri que vulnerabilidades similares foram encontradas no kernel do Linux. As vulnerabilidades identificadas por CVE-2013-7421 [1] e CVE-2014-9644 [2]. Na verdade, estes dois CVEs representam a mesma vulnerabilidade, podendo ser considerados como CVEs duplicados. A primeira correção [3] não eliminava o problema por completo e ainda assim permitia a exploração. Após alguns poucos dias desde a primeira correção, uma nova [4] apareceu e corrigiu o problema. Este post foi escrito baseado na minha interpretação das informações e referências disponíveis em [5].

Continue reading “An almost perfect vulnerability for kernel rootkits – Uma quase perfeita vulnerabilidade para carregar rootkits em kernel”

The role of hypothesis and a (old) way to escalate privileges on FreeBSD – O papel da hipótese e um modo de escalar privilégios no FreeBSD

English / Português

English:

I do not remember when, but certain day I decided to look for vulnerabilities in the FreeBSD kernel. As it was a long time ago, I do not remember almost any detail of the process, I just remember I found one NULL pointer dereference without reading the source code or using fuzzing techniques. Nowadays that is not one of the most interesting vulnerabilities because is necessary some tweaks to be vulnerable and to allow exploitation but my goal with this post is also to write a bit about the discovery process.

Português:

Não lembro exatamente quando, mas um certo dia, decidi começar a procurar vulnerabilidades no kernel do FreeBSD. Como faz muito tempo, não lembro de quase nenhum detalhe do processo, apenas lembro, que sem ler o código-fonte e sem usar técnicas de fuzzing, acabei descobrindo um NULL pointer dereference. Nos dias atuais essa não é uma das vulnerabilidade mais interessantes porque precisa de alguns ajustes para estar vulnerável e permitir a exploração, mas meu objetivo nesse post é também escrever um pouco sobre o processo de descoberta.