Author Archives: admin

Gentoo Linux Security Weekend

Last weekend, Gentoo Linux developers a3li and keytoaster came around and with help from p-y and underling via IRC, we killed the huge backlog of open CVEs in our tracker, voted on about 100 security bugs, drafted several dozens of GLSAs and were hunting bugs on GLSAMaker2. We also had good company from (non-security) developer idl0r on saturday. 🙂

During the week, we polished up some GLSAs and since sunday, we send these (a lot more to come!):

OpenSSL: Multiple vulnerabilities
Wireshark: Multiple vulnerabilities
Bugzilla: Multiple vulnerabilities
Dovecot: Multiple vulnerabilities
GnuTLS: Multiple vulnerabilities
PHP: Multiple vulnerabilities
vsftpd: Denial of Service
feh: Multiple vulnerabilities
Conky: Privilege escalation
Wget: User-assisted file creation or overwrite
Adobe Flash Player: Multiple vulnerabilities

Thanks for helping out, everyone!

Here are some impressions:

 

 

 

 

 

byebye, SLES 9

Heute kam wenig überraschend eine Mail von Novell, dass der SLES 9 Support nun nach 7 Jahren zu Ende ist – außer man ist LTS Kunde – was wohl ziemlich teuer wird und nur für Großunternehmen Sinn macht. SLES9 ist so dermaßen angegraut, beim Blick auf die Paketversionen wird man schon leicht Nostalgisch… ;D

 

Interessant sind die Statistiken:

Gesamte Updates: 1565
Security: 767
Empfohlen: 718
Optional: 72
YaST: 8

Das CVE-Tracking war im ersten Jahr nicht vollständig, daher sind die Nummer eigentlich etwas höher.

Insgesamte CVE-Einträge: 1447

Top CVE-Kanidaten:

127 IBM Java 5
125 IBM Java 1.4.2
84 kernel
66 SUN Java 1.4.2
76 clamav
68 ethereal
58 mozilla
44 cups
32 mysql
31 libpng
28 freetype2
24 ruby
21 XFree86
20 libexif
18 mailman
18 horde
16 quagga
17 tomcat
16 apache2
15 openssh
15 gd
14 python
13 yast2-packagemanager-devel
13 km_nss
12 openssl
12 samba
11 tk
10 pcre

Interessant, dass der Kernel sogar schlimmer als Mozilla war…ich dachte das wäre unmöglich… :/ Clamav mit 76 Löchern finde ich aber auch eine ziemliche Katastrophe, zumal das ja auch oftmals auf Mailgateways läuft…

FreeDOS usb boot

Jeder kennt das Problem: immer wieder mal benötigt man einen USB Stick mit einem DOS wegen BIOS Updates, muss einen zickigen RAID-Controller flashen oder sonstiges… hier eine Kurzanleitung dazu, wie man einen bootbaren USB-Stick mit FreeDOS erstellt.

Vorbereiten der Umgebung

mkdir -p /tmp/usbboot/exec/file-system
mkdir -p /tmp/usbboot/build
cd /tmp/usbboot/build

Tool zum Schreiben der Daten auf USB-Stick herunterladen, entpacken, compilieren

wget "http://prdownloads.sourceforge.net/advancemame/makebootfat-1.4.tar.gz?download" -O - | tar -xvzf -
cd makebootfat*
./configure
make
cp makebootfat ../../exec
cd ..

Nötige FreeDOS-Binaries und MBR herunterladen

wget http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.0/pkgs/kernels.zip
wget http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.0/pkgs/commandx.zip
wget http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.0/pkgs/unstablx.zip
wget https://www.kernel.org/pub/linux/utils/boot/syslinux/syslinux-4.04.tar.gz
tar -xzvf syslinux-4.04.tar.gz syslinux-4.04/mbr/mbr.bin
mv syslinux-4.04/mbr/mbr.bin ../exec

Nun extrahiert man die relevanten Dateien aus den .zips und kopiert sie an die passende Stelle:

unzip kernels.zip
unzip commandx.zip 
unzip unstablx.zip
find ./ -name command.com -exec mv '{}' ../exec/file-system ';'
find ./ -name kernel.sys -exec mv '{}' ../exec/file-system ';'
 
for file in fat12.bin fat16.bin fat32lba.bin
do
	find ./ -name $file -exec mv '{}' ../exec ';'
done
 
cd ..
rm -fr build
cd exec

An dieser Stelle kopiert man alle Dateien, die nachher auf dem Stick liegen sollen nach ./file-system. Daraufhin befüllt man den USB-Stick per makebootfat und räumt auf.

./makebootfat -o /dev/sdb -E 255 -1 fat12.bin -2 fat16.bin -3 fat32lba.bin -m mbr.bin ./file-system
cd ../../
rm -fr usbboot

Getestet zuletzt am 17.09.2017 – sofern es nicht mehr funktioniert, bitte kurz kommentiere, dann aktualisiere ich ggfs. den Blogeintrag.

LD_PRELOAD magic

Wenn man z.B. ein Programm hat, dass prüft, ob man eine bestimmte CPU hat – z.B. weil es nicht unter qemu verwendet werden soll – kann es sinnvoll sein, den Check zu umgehen, bzw. dem Programm vorzugaukeln, dass alles OK ist. Hierfür kann man idealerweise LD_PRELOAD nutzen, welches einen bestehenden Library Call überlädt. Im Detail läuft das wie folgt ab:

– man findet die Adresse des originalen Library Calls per dlsym()
– man deklariert die Funktion, sie überlädt die originale Funktion (hier: open())
– man schreibt in der Funktion je nach übergebenem Parameter um, zurückliefert wird
– oder man führt die Originalfunktion aus

/*
* open_preload.c
*/
 
#define _GNU_SOURCE
#include <sys/syscall.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <dlfcn.h>
#include <dirent.h>
 
static void init (void) __attribute__ ((constructor));
 
int (*real_open)(__const char *name, int flags, mode_t mode);
 
static void init (void)
{
        real_open = dlsym(RTLD_NEXT,"open");
}
 
int open(const char *pathname, int flags, mode_t mode)
{
	if (strcmp(pathname,"/proc/cpuinfo") == 0)
	{
		return(real_open("/tmp/cpuinfo",flags,mode));
	}
	else
	{
        	return(real_open(pathname,flags,mode));
	}
 
}

Das Ganze compiliert und testet man dann wie folgt:

[sb@machine ~]$ echo test > /tmp/cpuinfo
[sb@machine ~]$ gcc -g -fpic -shared -ldl -o open_preload.so open_preload.c
[sb@machine ~]$ LD_PRELOAD="./open_preload.so" cat /proc/cpuinfo 
test
[sb@machine ~]$

Das fühlt sich schon ein wenig nach RootKit-Programmierung an. 😉

Paketverlust mit D-Link DGS-1210-48

Beim Testen von zwei brandneuen D-Link DGS-1210-48 fiel auf, dass auf dem Gerät Paketverlust auftritt. Je größer die Pakete, desto höher war auch der Verlust – bis zu 7%. Das ist natürlich nicht akzeptabel. Nach einigem Überlegen hatte ich eine Idee woran es lag:


Tatsächlich behob das Umstellen dann auch das Problem. Offensichtlich gibt es hier ein Problem damit, dass der Switch die Sendeleistung bei kurzen Kabeln (wie sie im Rechenzentrum im Access-Layer üblich sind) herunterschraubt. Eigentlich schade, denn grade die Stromsparfeatures machen den Switch interessant. Ansonsten machen die Geräte bisher aber einen ganz soliden Eindruck. 🙂

EDIT 21.08.2016: ich habe alle DGS nun gegen etwas solideres ausgetauscht – die DGS hatten über 3 Jahre eine Ausfallrate von ~75%! Sample size: 20 Switches.

awesome: Laptop Batteriestatus anzeigen

Hier ein weiterer Tipp für awesome: der Laptop Batteriestatus soll angezeigt werden. Zuerst kopiert man das von mir gestern programmierte Tool cbatt nach /home/name/cbatt.sh, dann trägt man folgendes in der rc.lua ein:

mybattmon = widget({ type = "textbox", name = "mybattmon", align = "right" })
function battery_status ()
        local fd=io.popen("/home/name/cbatt.sh", "r")
        local line=fd:read()
        return line
end
 
mybattmon.text = " " .. battery_status() .. " "
my_battmon_timer=timer({timeout=30})
my_battmon_timer:add_signal("timeout", function()
    mybattmon.text = " " .. battery_status() .. " "
end)
my_battmon_timer:start()

Unter mywibox[s].widgets = { … } fügt man dann noch an der gewünschten Stelle mybattmon hinzu, und fertig ist die Chose. Der Timeout legt fest, wie oft das Script aufgerufen wird; jede Sekunde wäre m.A. arg übertrieben und verkürzt die Akkulaufzeit sicherlich.

Wer wie im Vorpost mehrere Rechner hat, und die Batterieanzeige z.B. nur auf dem Laptop anzeigen will, nutzt folgenden Schnippsel um das Ganze zu erweitern:

    -- hostname auslesen
    a=io.popen("uname -n");
    io.input(a)
    if io.read() == "laptop" then
    	batt=1
    end
 
    -- Add widgets to the wibox - order matters
    mywibox[s].widgets = {
        {
            mylauncher,
            mytaglist[s],
            mypromptbox[s],
            layout = awful.widget.layout.horizontal.leftright
        },
        mylayoutbox[s],
        mytextclock,
	batt == 1 and mybattmon,		-- Batterie nur beim richtigen Host hinzufügen
        s == 1 and mysystray or nil,
        mytasklist[s],
        layout = awful.widget.layout.horizontal.rightleft
    }

awesome: individuelle Hintergrundbilder pro Host

Wer sein ~ in einem Versionskontrollsystem wie z.B. git pflegt, trackt damit seine gesamten Daten, um z.B. auf verschiedenen Rechnern immer gleiche Datenbestände incl. Versionierung zu haben. Das Problem dabei ist, dass der Windowmanager (hier: awesome) für die verschiedenen Geräte ggfs. auch andere Einstellungen braucht, z.B. für das Hintergrundbild. Über den uname des Systems kann man einfach unterscheiden, wo das Script grade aktuell ausgeführt wird und erspart sich das Pflegen von 2 Konfigurationen. Hierzu erstellt man z.B. unter Gentoo die ~/.config/awesome/theme.lua wie folgt:

theme_path = "/usr/share/awesome/themes/default/theme.lua"
theme = dofile(theme_path)
a=io.popen("uname -n");
io.input(a)
 
if io.read() == "laptop" then
theme.wallpaper_cmd = { "awsetbg /home/user/real_1280x800.jpg" }
else
theme.wallpaper_cmd = { "awsetbg /home/user/real_1920x1280.jpg" }
end
 
return theme

Voila – es wird immer das korrekt dimensionierte Wallpaper geladen.

Linuxtag

Linux Tag LogoMittwoch ist es soweit: der Linuxtag beginnt! Das Programm kann sich meiner Meinung nach wie immer sehen lassen, persönlich finde ich Donnerstag und Freitag am Interessantesten und werde dann auch mit einem Kollegen vor Ort sein.

Hoffentlich ist zwischen den ganzen Vorträgen auch genügend Zeit dafür, etwas am Gentoo-Stand vorbeizuschauen…

Linux Kernel Regression mit git finden

Falls man nach einem Kernel Upgrade plötzlich Probleme bekommt und googlen nicht mehr hilft, muss man ggfs. selbst herausfinden, warum nun etwas nicht mehr funktioniert. Herzlichen Glückwunsch: eine typische Kernel Regression. Zuerst laden wir einmal die neuste Kernelversion aus dem git Repository von kernel.org ins passende Verzeichnis:

cd /usr/src
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6

Zeit für einen Kaffee! Nachdem wir die etwa 600MB runtergeladen haben, sagen wir git nun, dass wir einen Fehler “bisect”-en wollen. Hierbei wird eine Binäre Suche durchgeführt, denn mehrere hundert bis tausend Kernel-Commits wollen effizient ausgetestet werden. Dafür sagt man dem Kernel, welche Version noch gut war und welche schlecht:

git bisect start
git bisect good v2.6.36
git bisect bad v2.6.37

Continue reading