Process Control

A transferência do controle de programas para uma transação ou um programa não confiável, ou em um ambiente não confiável, pode fazer com que um aplicativo execute comandos mal-intencionados em nome de um invasor.

Vulnerabilidades de controle de programas assumem duas formas:

- Um invasor pode alterar o nome do programa ou o código da transação que está sendo chamada: ele controla explicitamente qual é o nome do programa ou o código da transação.

- Um invasor pode mudar o ambiente no qual o programa ou a transação é invocado: ele controla implicitamente uma área de comunicação disponibilizada para a transação ou o programa invocado.

Nesse caso, estamos preocupados principalmente com o primeiro cenário, com a possibilidade de que um invasor seja capaz de controlar o nome do programa ou o código da transação que é invocado. Vulnerabilidades de controle de processos desse tipo ocorrem quando:

1. Os dados entram em um aplicativo por uma fonte não confiável.



2. Os dados são usados como uma string, ou parte de uma string, que representa um nome de programa ou um código de transação que é invocado.



3. Ao executar o código da transação ou do programa invocado, o aplicativo concede ao invasor um privilégio ou uma capacidade que ele não teria de outra forma.

Exemplo 1: O seguinte trecho de código de um utilitário de sistema privilegiado lê um valor de uma solicitação HTTP para determinar o código da transação a ser chamada.

...
tid = request->get_form_field( 'tid' ).

CALL TRANSACTION tid USING bdcdata  MODE 'N'
                         MESSAGES INTO messtab.
...

Esse trecho de código permite que um invasor chame qualquer transação e execute potencialmente um código arbitrário com o privilégio elevado do aplicativo. Como o programa não valida o valor lido da solicitação HTTP, se um invasor puder controlar esse valor, ele poderá enganar o aplicativo, fazendo com que este execute o código mal-intencionado, e assumir o controle do sistema.

O carregamento de bibliotecas ou executáveis de uma fonte não confiável ou em um ambiente não confiável pode fazer com que um aplicativo execute comandos mal-intencionados em nome de um invasor.

Vulnerabilidades de controle de programas assumem duas formas:

- Um invasor pode alterar o nome da biblioteca ou do executável carregado pelo programa: o invasor controla explicitamente qual é o nome dessa biblioteca ou desse executável.

- Um invasor pode alterar o ambiente no qual a biblioteca ou o executável é carregado: o invasor controla implicitamente o que o nome da biblioteca ou do o executável significa.

Nesse caso, estamos principalmente preocupados com o primeiro cenário, com a possibilidade de que um invasor seja capaz de controlar o nome da biblioteca que é carregada. Vulnerabilidades de controle de processos desse tipo ocorrem quando:

1. Os dados entram em um aplicativo por uma fonte não confiável.



2. Os dados são usados como uma cadeia de caracteres, ou parte de uma cadeia de caracteres, que representa uma biblioteca ou um executável carregado pelo aplicativo.



3. Ao executar o código da biblioteca ou do executável, o aplicativo concede ao invasor um privilégio ou uma capacidade que ele não teria de outra forma.

Exemplo 1: O código a seguir de um utilitário do sistema com privilégio elevado usa a propriedade APPHOME de configuração do aplicativo e, em seguida, carrega uma biblioteca nativa com base em um caminho relativo a partir do diretório especificado.

  ...
  string lib = ConfigurationManager.AppSettings["APPHOME"];
  Environment.ExitCode = AppDomain.CurrentDomain.ExecuteAssembly(lib);
  ...

Esse código permite que um invasor carregue uma biblioteca ou um executável e execute possivelmente um código arbitrário com o privilégio elevado do aplicativo, modificando a propriedade APPHOME de configuração desse aplicativo de forma que ela aponte para um caminho diferente contendo uma versão mal-intencionada de LIBNAME. Como o programa não valida o valor lido do ambiente, se um invasor puder controlar o valor da propriedade do sistema APPHOME, ele poderá enganar o aplicativo, fazendo com que este execute o código mal-intencionado, e assumir o controle do sistema.

O carregamento de bibliotecas de uma fonte não confiável ou em um ambiente não confiável pode fazer com que um aplicativo execute um código mal-intencionado em nome de um invasor.

Vulnerabilidades de controle de programas assumem duas formas:

- Um invasor pode alterar a biblioteca executada pelo programa: o invasor controla explicitamente qual é o nome dessa biblioteca.

- Um invasor pode alterar o ambiente no qual a biblioteca é carregada: o invasor controla implicitamente o que o nome da biblioteca significa.

Nesse caso, estamos principalmente preocupados com o primeiro cenário, com a possibilidade de que um invasor seja capaz de controlar o nome da biblioteca que é carregada. Vulnerabilidades de controle de processos desse tipo ocorrem quando:

1. Os dados entram em um aplicativo por uma fonte não confiável.

2. Os dados são usados como parte de uma cadeia de caracteres que representa um nome de biblioteca carregado pelo aplicativo.

3. Ao executar o código da biblioteca, o aplicativo concede ao invasor um privilégio ou uma capacidade que ele não teria de outra forma.

Exemplo 1: O código a seguir de um aplicativo com privilégio elevado usa uma entrada do registro para determinar o diretório no qual ele está instalado e carrega um arquivo de biblioteca com base em um caminho relativo a partir do diretório especificado.

	...
	RegQueryValueEx(hkey, "APPHOME",
                      0, 0, (BYTE*)home, &size);
	char* lib=(char*)malloc(strlen(home)+strlen(INITLIB));
	if (lib) {
		strcpy(lib,home);
		strcat(lib,INITCMD);
		LoadLibrary(lib);
	}
	...

O código nesse exemplo permite que um invasor carregue uma biblioteca arbitrária da qual o código será executado com o privilégio elevado do aplicativo, modificando uma chave do registro para especificar um caminho diferente que contém uma versão mal-intencionada de INITLIB. Como o programa não valida o valor lido do ambiente, se um invasor conseguir controlar o valor de APPHOME, ele poderá enganar o arquivo para que ele execute código mal-intencionado.

Exemplo 2: O código a seguir é de um utilitário de administração baseado na Web que permite aos usuários acessar uma interface através da qual eles podem atualizar seus perfis no sistema. O utilitário usa uma biblioteca chamada liberty.dll, que se destina a ser encontrada em um diretório padrão do sistema.

LoadLibrary("liberty.dll");

No entanto, o programa não especifica um caminho absoluto para liberty.dll. Se um invasor colocar uma biblioteca mal-intencionada chamada liberty.dll na ordem de pesquisa em uma posição superior à do arquivo pretendido e tiver uma maneira de executar o programa no respectivo ambiente, e não no ambiente de um servidor Web, o aplicativo carregará essa biblioteca mal-intencionada em vez da biblioteca confiável. Como esse tipo de aplicativo é executado com privilégios elevados, o conteúdo do arquivo liberty.dll do invasor é agora executado com privilégios elevados, possivelmente dando a ele controle total sobre o sistema.

Esse tipo de ataque é possível devido à ordem de pesquisa usada por LoadLibrary() quando um caminho absoluto não é especificado. Se o diretório atual for pesquisado antes dos diretórios do sistema, como era o caso até as versões mais recentes do Windows, esse tipo de ataque se tornará comum caso o invasor consiga executar o programa localmente. A ordem de pesquisa depende da versão do sistema operacional e é controlada em sistemas operacionais mais recentes pelo valor desta chave do registro:

HKLM\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode

Essa chave não é definida em sistemas Windows 2000/NT e Windows Me/98/95.

Em sistemas nos quais a chave existe, LoadLibrary() se comporta da seguinte maneira:
Se SafeDllSearchMode for 1, a ordem de pesquisa será a seguinte:
(Configuração padrão para o Windows XP SP1 e versões posteriores, bem como para o Windows Server 2003.)
1. O diretório a partir do qual o aplicativo foi carregado.
2. O diretório do sistema.
3. O diretório do sistema de 16 bits, se existir.
4. O diretório do Windows.
5. O diretório atual.
6. Os diretórios listados na variável de ambiente PATH.
Se SafeDllSearchMode for 0, a ordem de pesquisa será a seguinte:
1. O diretório a partir do qual o aplicativo foi carregado.
2. O diretório atual.
3. O diretório do sistema.
4. O diretório do sistema de 16 bits, se existir.
5. O diretório do Windows.
6. Os diretórios listados na variável de ambiente PATH.

Transferir o controle do programa para um programa de aplicativo não confiável ou em um ambiente não confiável pode fazer com que um aplicativo execute comandos mal-intencionados em nome de um invasor.

Vulnerabilidades de controle de programas assumem duas formas:

- Um invasor pode alterar o nome do programa que está sendo chamado: o invasor controla explicitamente qual o nome do programa de aplicativo.

- Um invasor pode alterar o ambiente no qual o programa é invocado: o invasor controla implicitamente uma área de comunicação disponibilizada para o programa invocado.

Nesse caso, estamos preocupados principalmente com o primeiro cenário, a possibilidade de um invasor controlar o nome do programa que é invocado. Vulnerabilidades de controle de processo desse tipo ocorrem quando:

1. Os dados entram em um aplicativo por uma fonte não confiável.



2. Os dados são usados como parte da cadeia, ou como a cadeia inteira, que representa um programa que é invocado ou que determina um certo controle sobre o ambiente no qual o programa é invocado.



3. Ao executar o código do programa invocado, o aplicativo oferece ao invasor um privilégio ou uma capacidade que o invasor não teria de outra forma.

Exemplo 1: O código a seguir de um utilitário privilegiado do sistema lê um valor do terminal para determinar o nome do programa para o qual o controle deve ser transferido.

...
ACCEPT PROGNAME.
EXEC CICS
  LINK PROGRAM(PROGNAME)
  COMMAREA(COMA)
  LENGTH(LENA)
  DATALENGTH(LENI)
  SYSID('CONX')
END-EXEC.
...

Esse código permite que um invasor transfira o controle para um programa e potencialmente execute código arbitrário com o privilégio elevado do aplicativo. Como o programa não valida o valor lido do terminal, se um invasor puder controlar esse valor, ele poderá enganar o aplicativo para que ele execute código mal-intencionado e assuma o controle do sistema.

O carregamento de bibliotecas de uma fonte não confiável ou em um ambiente não confiável pode fazer com que um aplicativo execute comandos mal-intencionados em nome de um invasor.

Vulnerabilidades de controle de programas assumem duas formas:

- Um invasor pode alterar o nome da biblioteca carregada pelo programa: o invasor controla explicitamente qual é o nome dessa biblioteca.

- Um invasor pode alterar o ambiente no qual a biblioteca é carregada: o invasor controla implicitamente o que o nome da biblioteca significa.

Nesse caso, estamos principalmente preocupados com o primeiro cenário, com a possibilidade de que um invasor seja capaz de controlar o nome da biblioteca que é carregada. Vulnerabilidades de controle de processos desse tipo ocorrem quando:

1. Os dados entram em um aplicativo por uma fonte não confiável.



2. Os dados são usados como uma string, ou parte de uma string, que representa uma biblioteca carregada pelo aplicativo.



3. Ao executar o código da biblioteca, o aplicativo concede ao invasor um privilégio ou uma capacidade que ele não teria de outra forma.

Exemplo 1: O código a seguir usa um "recurso" atualmente não documentado do Express para carregar dinamicamente um arquivo de biblioteca. Em seguida, Node.js continua a pesquisar o respectivo caminho de carga de biblioteca normal em busca de um arquivo ou uma pasta que contenha essa biblioteca[1].

var express = require('express');
var app = express();

app.get('/', function(req, res, next) {
  res.render('tutorial/' + req.params.page);
});

No Express, a página transmitida para Response.render() carregará uma biblioteca da extensão quando for anteriormente desconhecida. Isso geralmente não apresenta prolemas para entradas, como "foo.pug", pois significará o carregamento da biblioteca pug, um notório mecanismo de modelo. No entanto, se um invasor puder controlar a página e, portanto, a extensão, ele poderá optar por carregar qualquer biblioteca nos caminhos de carregamento de módulo Node.js. Como o programa não valida as informações recebidas do parâmetro de URL, o invasor pode enganar o aplicativo, fazendo com que ele execute código mal-intencionado, e assumir o controle do sistema.

O carregamento de bibliotecas de uma fonte não confiável ou em um ambiente não confiável pode fazer com que um aplicativo execute comandos mal-intencionados em nome de um invasor.

Vulnerabilidades de controle de programas assumem duas formas:

- Um invasor pode alterar o nome da biblioteca carregada pelo programa: o invasor controla explicitamente qual é o nome dessa biblioteca.

- Um invasor pode alterar o ambiente no qual a biblioteca é carregada: o invasor controla implicitamente o que o nome da biblioteca significa.

Nesse caso, estamos principalmente preocupados com o primeiro cenário, com a possibilidade de que um invasor seja capaz de controlar o nome da biblioteca que é carregada. Vulnerabilidades de controle de processos desse tipo ocorrem quando:

1. Os dados entram em um aplicativo por uma fonte não confiável.



2. Os dados são usados como uma string, ou parte de uma string, que representa uma biblioteca carregada pelo aplicativo.



3. Ao executar o código da biblioteca, o aplicativo concede ao invasor um privilégio ou uma capacidade que ele não teria de outra forma.

Exemplo 1: O código a seguir de um utilitário do sistema com privilégio elevado usa a propriedade do sistema APPHOME para determinar o diretório no qual ele está instalado e, em seguida, carrega uma biblioteca nativa com base em um caminho relativo a partir do diretório especificado.

	...
	$home = getenv("APPHOME");
	$lib = $home + $LIBNAME;
	dl($lib);
	...

Esse código permite que um invasor carregue uma biblioteca e execute possivelmente um código arbitrário com o privilégio elevado do aplicativo, modificando a propriedade do sistema APPHOME de forma que ela aponte para um caminho diferente contendo uma versão mal-intencionada de LIBNAME. Como o programa não valida o valor lido do ambiente, se um invasor puder controlar o valor da propriedade do sistema APPHOME, ele poderá enganar o aplicativo, fazendo com que este execute o código mal-intencionado, e assumir o controle do sistema.

Exemplo 2: O código a seguir usa dl() para carregar o código de uma biblioteca chamada sockets.dll, que pode ser carregada de vários locais, dependendo da sua instalação e da sua configuração.

	...
	dl("sockets");
	...

O problema aqui é que dl() aceita um nome de biblioteca, mas não um caminho, para a biblioteca a ser carregada.

Se um invasor for capaz de colocar uma cópia mal-intencionada de sockets.dll em uma posição na ordem de pesquisa superior à do arquivo que o aplicativo pretende carregar, este carregará a cópia mal-intencionada em vez do arquivo pretendido. Por causa da natureza do aplicativo, ele é executado com privilégios elevados, o que significa que o conteúdo do arquivo sockets.dll do invasor será agora executado com privilégios elevados, possivelmente concedendo a ele controle total sobre o sistema.

O carregamento de bibliotecas de uma fonte não confiável ou em um ambiente não confiável pode fazer com que um aplicativo execute comandos mal-intencionados em nome de um invasor. No Ruby há lugares comuns em que pode haver ataques de Controle de processo e Injeção de comando.

No Ruby, pode haver ataques de Controle de processo normalmente durante a execução de um comando, o que possibilita dois ataques diferentes:

1. Controle de processo
As vulnerabilidades de Controle de processo assumem duas formas:

- Um invasor pode alterar o nome da biblioteca carregada pelo programa: o invasor controla explicitamente qual é o nome dessa biblioteca.

- Um invasor pode alterar o ambiente no qual a biblioteca é carregada: o invasor controla implicitamente o que o nome da biblioteca significa.

Nesse caso, estamos preocupados principalmente com o segundo cenário, com a possibilidade de que um invasor seja capaz de controlar o ambiente a ponto de fazer com que o programa carregue uma versão mal-intencionada da biblioteca nomeada.

1. Um invasor fornece uma biblioteca mal-intencionada para um aplicativo.

2. O aplicativo carrega a biblioteca mal-intencionada porque não consegue especificar um caminho absoluto ou verificar o arquivo que está sendo carregado.

3. Ao executar o código da biblioteca, o aplicativo concede ao invasor um privilégio ou uma capacidade que ele não teria de outra forma.

Observe que o ataque de Controle de processo pode ocorrer em plataformas Windows ao executar um programa externo, uma vez que o shell usado para executar os comandos é escolhido por meio das variáveis de ambiente RUBYSHELL ou COMSPEC. Se um invasor for capaz de modificar qualquer uma dessas variáveis de ambiente dentro do ambiente atual, isso significará que o programa apontado por tais variáveis de ambiente será executado com a permissão ou o programa do Ruby em execução.

2. Injeção de comandos
As vulnerabilidades de injeção de comando assumem duas formas:

- Um invasor pode alterar o comando executado pelo programa: o invasor controla explicitamente qual é esse comando.

- Um invasor pode alterar o ambiente no qual o comando é executado: o invasor controla implicitamente o que esse comando significa.

Nesse caso, estamos preocupados principalmente com o segundo cenário, com a possibilidade de que um invasor seja capaz de modificar o significado do comando alterando uma variável de ambiente ou colocando um executável mal-intencionado no início do caminho de pesquisa. Vulnerabilidades de injeção de comandos desse tipo ocorrem quando:

1. Um invasor modifica o ambiente de um aplicativo.

2. O aplicativo executa um comando sem especificar um caminho absoluto ou sem verificar o binário que está sendo executado.

3. Ao executar o comando, o aplicativo concede ao invasor um privilégio ou uma capacidade que ele não teria de outra forma.

Exemplo 1: O código a seguir executa Kernel.system() para executar um executável chamado program.exe, que normalmente é encontrado em um diretório de sistema padrão.

...
system("program.exe")
...

Este problema tem dois lados:
1. Em plataformas do Windows, Kernel.system() executa algo por meio de um shell. Se um invasor puder manipular as variáveis de ambiente RUBYSHELL ou COMSPEC, ele poderá apontar para um executável malicioso que será chamado com o comando dado a Kernel.system(). Por causa da natureza do aplicativo, ele é executado com os privilégios necessários para realizar operações do sistema, o que significa que, agora, o program.exe do invasor será executado com esses privilégios, possivelmente concedendo a ele controle total sobre o sistema.
2. Em todas as plataformas nesta situação, o problema é que o programa não especifica um caminho absoluto e não consegue limpar o ambiente antes de executar a chamada de Kernel.system(). Se um invasor puder modificar a variável $PATH a fim de que aponte para um binário malicioso chamado program.exe e executar o aplicativo no ambiente dele, o binário malicioso será carregado ao invés do binário pretendido. Por causa da natureza do aplicativo, ele é executado com os privilégios necessários para realizar operações do sistema, o que significa que, agora, o program.exe do invasor será executado com esses privilégios, possivelmente concedendo a ele controle total sobre o sistema.