Neue Webseiten bei der Braunschweiger Landesbank

Die neuen Onlinebankingwebseiten der BLSK, der Braunschweiger Landessparkasse, einer Unterabteilung der NordLB, sind wie erwartet noch schlechter geworden, als sie vorher waren. Unglaublich, daß es noch schlechter geht, aber die Sparkassenentwickler haben es geschafft.

Man weiß gar nicht wo man anfangen soll, deswegen eine unsortierte, unbewertete Aufzählung:

  • – Layout wie in Windows 95 : 2/3 des Monitors sind weiße Leerflächen, dafür endloses Scrollen
  • – kein Einsatz von HTML Entitäten für Umlaute in HTML-Emails! => Zeichenfehler in Emails
  • – Fehler beim Layout der Usernamen/PAsswort Eingabeboxen. Der Inhalt überlappt mit dem gemerkten Inhalt des Formulars vom Browser, weil mit CSS in den Hintergrund gezeichnet. Endresultat: Unleserlicher Zeichenmüll
  • – Unsinnige/unwichtige Teile wie Umfagen tauchen prominent doppelt im layout auf. Nicht wegklickbar.
  • – Layout springt, beim Versuch der Kontaktaufname, obwohl 2/3 des Bildschirms leer sind, also genug Platz zum Einblenden wäre.
  • – riesige Bilder sliden in nervtötendem Tempo auf der Startseite, da komischerweise in voller Breite, was der Nutzanwendung nicht gelingt.
  • – insgesamt ist das Layout mit einem Monitor von 1995 gemacht worden.
  • – der Zeichensatz im Default ist für BLINDE vergrößert worden. Webseiten für Senioren sind cool, aber nur solange junge Menschen auch etwas erkennen können.
  • – wenn man einen Brief an die Bank schreibt, wird man ausgeloggt beim Tippen. Soviel Information ist bei der BLSK wohl nicht erwünscht.
  • – Kontaktformular künstlich auf 600 Zeichen begrenzt.
  • – Kontaktformular Eingabefelder sind mit absoluten Pixelzahlen auf eine Mikrogröße geschrumpft. Eingabekomfort ist
  • nicht erwünscht, da lange Passagen eh nicht reinpassen. Das nennt man wohl einen „dezenten Hinweis an den Kunden“ 😉
  • – Ab und zu kann man das Navigationmenü nicht mehr benutzen., da muß man erst einen anderen „Großnavigationspunkt“ ansteuern, bei dem das Menü wieder initialisiert wird.

und so geht das weiter und weiter und weiter..

Fazit: Wegschmeissen und von jemand anderem neu machen lassen !

Das Layout und die Navigation in der Seite sind unrettbar verwoben, weil es sich um einen monolithischen Block handelt, der naturgemäß unflexibel ist. Hier hilft nur Wegschmeissen und neu bauen. Dazu muß man natürlich jemand anderen daran lassen. Jemand der schon mal das Buzzword „Objekt-Orientiertes-Layout“ gehört hat.

Natürlich kann man mich in die Pflicht nehmen, bei dem Prozess zu helfen. Ich fürchte aber, daß falls überhaupt darüber nachgedacht wird, es nochmal neu zu machen, jemand ohne Visionen und ohne Software Architekturkenntnisse das Rennen machen wird. Was dann in einer neuen Email an die Bank enden wird 😉

JackD – Der Störenfried

Völlig überraschend kam heute für mich ein Ausfall des Hauptaudiodevices im Pulseaudio, nämlich das Interne Audio Device vom Mainboard. Das Mainboard ging aber noch und ansonsten gab es auch kaum interessantes zu melden, außer, daß die Programme die Audio benutzen wollten alle im Mixer festhingen.

Was konnte also die Ursache sein ?

In solchen Fällen wird es hilfreich sein,  also-info.sh zu starten und mal einen Blick in die Ausgabe zu werfen. Gedacht, getan:

!!Sound Servers on this system
!!----------------------------

Pulseaudio:
      Installed - Yes (/usr/bin/pulseaudio)
      Running - Yes

Jack:
      Installed - Yes (/usr/bin/jackd)
      Running - Yes

Was zum Geier ist Jack ?

Der Gedanke kam mir zwar nicht, aber wer es nicht weiß, unter Linux Audiosystemen gibt es die großen drei Alsa, Jack und Pulseaudio. Auf Fedorasystemen ist die Kombination aus Alsa und Pulseaudio im Desktopbereich normal. Jack führt eher so ein Nischendasein, was aber einige Tools nicht davon abhält auf Jackkomponenten zuzugreifen z.B. Calf , weswegen es auf einem Desktop durchaus vorhanden ist.

Ok, es war da, aber was hat das mit dem Ausfall zu tun ?

Wie wir oben sehen können, liefen zwei SoundServer und das kann nicht klappen, wenn man nicht jedem der Server sagt, für welches Device er zuständig sein soll. Könnte ja sein, daß man eine SpezialSoundkarte im Einsatz hat mit der man professionell Musik machen will, da könnte das schon Sinn machen, diese von Jack verwalten zu lassen, besonders da Calf auf Jack aufbaut.

Durch ein ungünstiges Zusammenwirken vom „Dicken-Finger-Syndrom“, „Hast“, „Tippfehler“ und „Cinnamon“ wurde versehenlich Calf gestartet, was ich noch nie gesehen hatte und auch nie wieder sehen will, denn es hat einen lausigen ersten Eindruck gemacht 😉 Der Start von Calf führte zum Start von Jack und da Jack dumm wie Stroh zu sein scheint, griff sich der Soundserver die Interne Soundkarte von Mainboard und mein Sound war weg.

Abhilfe schafft …

einfach mit „killall jackd“ als Root töten und danach Calf und Flowblade deinstallieren. Problem solved 😉

Apache – Alles umleiten außer einem Pfad

Wer schon einmal eine Domain komplett z.b. auf https://domain.name umgeleitet hat, der kennt so einen Vhost Eintrag:

<VirtualHost *:80>
    ErrorLog /etc/httpd/logs/error_log
    CustomLog /etc/httpd/domlogs/domain_name.log combined
    LogLevel error
    ServerName domain.name
    ServerAlias *.domain.name
    Redirect 301 / https://domain.name
</VirtualHost>

Was aber wenn man einen Pfad nicht umleiten kann/darf/will, weil das zu Problemen führen würde z.b. mit Lets Encrypt ?

Im Falle von Let’s Encrypt ist die Lösung ein negativer Pfadausschluß :

<VirtualHost *:80>
    ErrorLog /etc/httpd/logs/error_log
    CustomLog /etc/httpd/domlogs/domain_name.log combined
    LogLevel error
    ServerName domain.name
    ServerAlias *.domain.name
    RedirectMatch 301 ^/((?!.well-known/acme-challenge).*)$ https://domain.name
</VirtualHost>

Damit wird alles, nur nicht der Pfad „/.well-kown/acme-challenge“ umgeleitet. Es ist für Lets Encrypt jetzt wieder möglich, die Challenges abzufragen.

Fedora, Wine-Staging und DX11

Wie bekommen man eigentlich DirectX 11 unter Linux zum Laufen ?

Das ist einfacher als man glaubt. zunächst installiert man mal wine-staging und Winetricks nach:

dnf install wine-staging winetricks

Danach sollte man, wenn man es noch nicht hat, mit winetricks die DLLs für DX10 und DX11 installieren. Das geht recht schnell:

 

 

 

Danach startet man winecfg für die Wine Umgebung die man mit DX11 laufen lassen will:(hier die normale .wine )

/opt/wine-staging/bin/winecfg

und aktiviert min. mal die obersten beiden Optionen im „Staging“ Tab :

Danach kann man dann schon das Spiel, im Beispiel Eve Online, starten:

env WINEPREFIX=“/home/username/.wine“ /opt/wine-staging/bin/wine C:\\Program\ Files\\CCP\\CCP\\Launcher\\evelauncher.exe

Das wars schon.  Es kann sein, daß unter DX11 die Einstellungen eines Spiels zu hoch sind, das liegt daran, daß DX11 noch keine 100% Umsetzung hat. Wenn Ihr ein schwarzes Bild bekommt, einfach mal die Einstellungen im Spiel auf den kleinsten Wert setzen, z.b. Anti-Aliasing ausmachen, Post-Processing oder Shader auf „low“ und dann sollte das klappen 😉

Manche Windowsgames werden vom Hersteller schon mit einer Wineinstallation ausgeliefert und dann als „Linux“ angeboten, so auch bei EVE Online. Wer DX11 haben will, braucht aber die Staging Version von Wine und die Optionen aktiviert, so daß die Hersteller Wineinstallationen meistens kein DX11 können. Da braucht es also dann wieder das Originalspiel.

 

 

Proftpd Bugfix macht Login unmöglich

Die späte Rache ereilte vermutlich die Entwickler vom allseits beliebten FTP-Server Proftpd. Um das Problem zu verstehen muß man etwas ausholen und in die Vergangenheit des Servers zurückgehen:

Spätestens im Jahr 1999 wurde mit der Version 1.2.0pre9 die Funktion eingebaut, daß FTP-Benutzer die einloggen, in einer Chroot gefangen werden, damit sie nur auf ihr Homeverzeichnis zugreifen können. Die Option hies „DefaultRoot“. In der Doku zu der Option findet sich folgender Hinweis:

When the specified chroot directory is a symlink this will be resolved to it’s parent
first before setting up the chroot. This can have unwanted side effects. For example if
a user has write access to the symlink he could modify it so that it points to ‚/‘

Meint auf Deutsch in Kurzform, daß wenn das Homeverzeichnis eigentlich ein Symlink ist, diesem gefolgt wird und das, wo der rauskommt, das neue „/“ von der Chroot ist.

Im Klartext: wenn  /home/testuser ein Symlink auf  „/“  ist, dann ist der User nicht in /home/testuser gefangen, sondern kann sich frei im normalen „/“ Verzeichnis rumtreiben. Ein Sicherheitsloch, daß locker mal 20 Jahre existiert hat.

Die FAQ von Proftpd meint zu dem Thema Chroot, daß man als Admin gefälligst dafür Sorgen soll, daß User das nicht anlegen/ändern können und halt kein Sicherheitsloch entstehen soll. Die schoben die Verantwortung also an die Admins weiter, was zu einem bestimmten grad ok war, aber dann darf man andere Sachen gar icht erst erlauben.

Mein Teil an der Story

In 2012 habe ich den Entwicklern von Proftpd einen Patch für proftpd geschickt, der genau dies Problem adressiert hat und keine Nebenwirkungen hatte. Der Patch prüft bei jedem Zugriff, ob sich in dem Pfad ein Symlink eingenistet hatte. So konnte es keine RACE Condition geben, bei der der Benutzer durch schnelles löschen und SymLink anlegen, die Sicherungsmaßnahmen umgehen konnte. Kurzfassung: Der Patch wurde mit : „Nicht unser Problem, siehe FAQ “ abgelehnt. Was sich jetzt als tragisch herausstellt. Besonders tragisch, da für den 29C3 in 2012 ein Vortrag zu dem Thema von mir eingereicht wurde.

Das Jahr 2016

In 2016 hat es dann endlich jemand geschafft, die Entwickler zu einer Option zum Checken von Symlinks im Pfad zu nötigen. Herzlichen Dank dafür, keine Ahnung wie Du das geschafft hast! Klasse!

Das Jahr 2017

Nun konnte ja nicht sein, was nicht sein durfte, in der Routine zum Checken der Symlinks wurde ein Sicherheitsloch entdeckt ( Hämischer Kommentar: Told you so ! ) und diesem wurde die CVE-2017-7418 zugeteilt.

Nun gabs es dieser Tage den Patch zu dieser Lücke im Server und damit das obligatorische Update auf den Produktivsystemen. Keine große Sache, sollte man denken. Tja, wer hat es geraten ? Auch diese Routine failed. Die hat das Sicherheitsproblem auf einer völlig neuen Ebene gelöst: Es kann sich kein Virtueller FTP-User mehr einloggen 😀

Ursache ist das hier:

[pid 32571] setresgid(-1, 99, -1)       = 0
[pid 32571] setresuid(-1, 99, -1)       = 0
[pid 32571] setresuid(-1, 0, -1)        = 0
[pid 32571] setresgid(-1, 1001, -1)     = 0
[pid 32571] setresuid(-1, 1000, -1)     = 0
[pid 32571] lstat("/", {st_mode=S_IFDIR|0555, st_size=4096, ...}) = 0
[pid 32571] lstat("/opt", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
[pid 32571] lstat("/opt/root", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
[pid 32571] lstat("/opt/root/home", {st_mode=S_IFDIR|0755, st_size=20480, ...}) = 0
[pid 32571] lstat("/opt/root/home/testuser", {st_mode=S_IFDIR|0750, st_size=4096, ...}) = 0
[pid 32571] lstat("/opt/root/home/testuser/public_html", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
...
[pid 32571] geteuid()                   = 1000
[pid 32571] setresuid(-1, 0, -1)        = 0
[pid 32571] setresgid(-1, 99, -1)       = 0
[pid 32571] setresuid(-1, 99, -1)       = 0
[pid 32571] setresuid(-1, 0, -1)        = 0
[pid 32571] setresgid(-1, 0, -1)        = 0
[pid 32571] setgid(1001)                = 0
[pid 32571] geteuid()                   = 0
[pid 32571] setresgid(-1, 99, -1)       = 0
[pid 32571] setresuid(-1, 99, -1)       = 0
[pid 32571] lstat("/opt/root/home/testuser/public_html", 0x7ffee3d84dd0) = -1 EACCES (Permission denied)

Für die Laien unter Euch, das ist der Auszug eines STRACE Logfiles. Darin finden wir alle Befehle die der Prozess ausgeführt hat ( API-Calls , nicht Bashkommandos 😉 ) . Man sieht deutlich das im ersten Block mit einer UID/GID von 1000/1001 auf das Homeverzeichnis des Benutzers zugegriffen wird, weil der Prozess entsprechend seine UID/GID ändert. Das ist RICHTIG so.

Was falsch ist, daß er das nicht auch beim zweiten Block tut. Hier ist die UID des Prozesses (proftpd) statt 1000, nur 99, was dem User NOBODY entspricht. Das ist der User, zu dem Prozesse werden sollen um Ihre Rechte zu verlieren um im Falle eines Sicherheitsbruches den Schaden zu begrenzen. (@Team: Der Teil hat 1a funktionert. Ohne Logins keine Bedrohung mehr) . Natürlich müßte auch hier die UID/GID auf 1000/1001 gesetzt werden, damit man an seine Dateien rankommt, denn normalerweise haben Verzeichnisse wie „/home/testuser“ einen chmod von 700, damit nur der User drankommt.

20 Jahre bis Problem akzeptiert. 4 Jahre bis zum Fix und nur 6 Monate bis zum Totalausfall der Server. Eine Glanzleistung sonders gleichen. Hätte man meinen Patch in 2012 nicht todgeredet, wäre uns das erspart geblieben 🙂 Da der Vortrag abgelehnt wurde, ging das Thema am 29C3 leider unter und so könnten die Jungs und Mädels vom CCC unabsichtlich auch dran beteiligt gewesen sein 😉  Tja, so ist das Leben.

Kleiner Disclaimer:

Es hängt ein bisschen von der Serverkonfiguration ab. Wer keine Datenbank benutzt, sondern nur reale User, der hat das Problem den bisherigen Infos nach nicht. Wer „AllowChrootSymlinks on“ aktiviert hat ( was der Default ist) hat auch kein Problem mit dem Login, wohl aber mit dem Umstand, daß er/sie ein angreifbares System hat ( siehe oben ) das ganz schnell gehackt werden kann.

 

Der GAU – Festplattenausfall und wie man Ihn behebt

„Wenn die Hardware versagt,und das Filesystem mit in den Abgrund zieht.“

Es war ein lauer Sonntagmittag, der Stream des Chaosradios ergoß sich von Radio Fritz, der Frachter in EVE flog seine Route, als plötzlich …  „can’t create tempfile in /tmp/gluster-x34234.tmp“ auf der Konsole  erschien. Das Ende vom Lied, die Festplatte hatte versagt:

 

 

 

 

 

 

Beim Rebooten startete das System nicht mehr mit dem Hinweis, daß die Superblöcke der Partionen/Filesysteme beschädigt wären.

/var/log/messages-20170402:Apr  2 15:05:32 eve kernel: EXT4-fs (sdc1): filesystem has both journal and inode journals!
/var/log/messages-20170402:Apr  2 15:08:10 eve kernel: EXT4-fs (sdc1): filesystem has both journal and inode journals!
/var/log/messages-20170402:Apr  2 15:08:29 eve kernel: EXT4-fs (sdc1): filesystem has both journal and inode journals!
/var/log/messages-20170402:Apr  2 15:08:30 eve kernel: EXT4-fs (sdc1): filesystem has both journal and inode journals!
/var/log/messages-20170402:Apr  2 15:08:34 eve kernel: EXT4-fs (sdc1): filesystem has both journal and inode journals!
/var/log/messages-20170402:Apr  2 15:08:44 eve kernel: EXT4-fs (sdc1): filesystem has both journal and inode journals!
/var/log/messages-20170402:Apr  2 15:08:47 eve kernel: EXT4-fs (sdc1): filesystem has both journal and inode journals!
/var/log/messages-20170402:Apr  2 15:08:49 eve kernel: EXT4-fs (sdc1): filesystem has both journal and inode journals!
/var/log/messages-20170402:Apr  2 15:08:49 eve kernel: EXT4-fs (sdc1): filesystem has both journal and inode journals!
/var/log/messages-20170402:Apr  2 15:09:46 eve kernel: EXT4-fs (sdc1): filesystem has both journal and inode journals!
/var/log/messages-20170402:Apr  2 15:09:58 eve kernel: EXT4-fs (sdc1): filesystem has both journal and inode journals!
/var/log/messages-20170402:Apr  2 15:11:34 eve kernel: EXT4-fs (sdc1): filesystem has both journal and inode journals!
/var/log/messages-20170402:Apr  2 15:21:39 eve kernel: EXT4-fs (sdc1): filesystem has both journal and inode journals!
/var/log/messages-20170402:Apr  2 15:25:56 eve kernel: EXT4-fs (sdc1): filesystem has both journal and inode journals!

Ein Mounten der Bootpartition war nicht mehr möglich, weil der Superblock defekt war. Im Endergebnis waren zwei Filesysteme der SSD defekt.

Wie konnte das passieren ?

Wenn man Google nach den im Screenshot gezeigten Fehlern befragt, zeichnet sich sehr schnell ab, daß die meisten auf ein Versagen der Stromzufuhr tippen. Das kann man aber wohl ausschliessen, da dabei als erstes die Grafikkarte ausgegangen wäre.

Da ich einige Tage vorher von Fedora 24 auf Fedora 25 umgestiegen bin, und damit auch ein neuer 4.10er Kernel zum Einsatz kam, ist es viel wahrscheinlicher, daß eine Treiber-HW-Kernel-Inkompatibilität vorlag. Das gabs bei Kernel 3.11 und 3.18 schon einmal.

Wie komme ich jetzt darauf ?

Das kommt daher, daß ich an dem besagten 2. April  das Stromversagen akzeptiert habe und daher die Stromverbindungen erneuert hatte. Einige Tage später, knallte die gleiche Platte wieder weg, ohne das jemand auch nur in  die Nähe der Stecker gekommen wäre. Seit Kernel 4.10.8-200 tritt das Problem nicht mehr auf. Es lag also vermutlich nicht am Strom, sondern an der Kernel-Treiber-HW Kombination.

Filesystem läßt sich nicht mounten

Es waren also zwei Filesysteme defekt. Dummerweise System-Root und die Bootpartition, wobei es die Bootpartition besonders schwer getroffen hatte:

kernel: EXT4-fs (sdc1): filesystem has both journal and inode journals!

Der den Fehler sieht, spart sich am besten gleich den Reperaturversuch und mountet die Platte mit der NOCHECK Option im Readonlymodus und kopiert die noch vorhandenen Files auf ein Backupmedium. Danach dann die Platte frisch formatieren und Daten wieder drauf spielen. Alles andere dürfte Zeitverschwendung sein. (siehe PDF)

Die Systempartition ließ sich im Gegensatz zur Bootplatte recht einfach mit fsck.ext4 reparieren. Daher liegt das Augenmerk des Beitrags auch auf dem Thema: Wie man eine neue Bootpartition aufbaut.

Da ich aus dem Problem und seiner Lösung gleich einen Vortrag für unsere LUG gemacht habe, könnt Ihr Euch jetzt alle nötigen Schritte in einem PDF herunterladen. Ich werde daher auch nur grob auf die einzelnen Lösungswege eingehen. Im PDF sind auch Reparaturanweisungen mit fsck, dumpefs, mke2fs  enthalten. Ich empfehle dringend das PDF an einem zugänglichen Ort aufzubewahren, ggf. auch als Offlinekopie 😉

Wie man eine Bootpartition neu aufbaut

Wir nehmen einfach mal an, daß die Bootpartition komplett hinüber ist, was bei dem oben aufgeführten Bug wohl auch der Fall ist. Mein Rettungsversuch mit fsck führte zum totalen Datenverlust, weil einige Inodes doppelt und dreifach belegt waren( vermute ich mal).

Deswegen ist oftmals nur eine neue Partition bzw. ein Reformatieren der Partition der letzte Ausweg.

Da das Formatieren die UUIDs einer Partition ändert, stimmen die Daten auf der Systemplatte nicht mehr.

Um der Sache jetzt folgen zu können, müßt Ihr zwei Dinge wissen:

  1. Was UUIDs und BLKIDs  sind
  2. Wie die im System benutzt werden um Partition zu referenzieren.

zu 1)

UUIDs werden von LUKS verschlüsselten Festplatten benutzt und sind ziemlich lange, aber eindeutige IDs.

$ lsblk
NAME                                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sr0                                            11:0    1  1024M  0 rom   
sdc                                             8:32   0 111,8G  0 disk  
├─sdc2                                          8:34   0 103,7G  0 part  
│ └─luks-ffbd61f2-4c1e-4dc8-b12b-c89e9f69c9fa 253:0    0 103,7G  0 crypt /
├─sdc3                                          8:35   0   7,6G  0 part  
│ └─luks-ca1f019d-39ce-4cf8-b522-f6d3e63ebe2a 253:1    0   7,6G  0 crypt [SWAP]
└─sdc1                                          8:33   0 525,5M  0 part  /boot
sda                                             8:0    0   1,8T  0 disk  
├─sda4                                          8:4    0     1K  0 part  
├─sda2                                          8:2    0  78,1G  0 part  
│ └─luks-6d45b281-c56c-40f0-acf7-c3058d4d6913 253:3    0  78,1G  0 crypt 
├─sda5                                          8:5    0   1,8T  0 part  
│ └─luks-7881f602-9462-497d-810a-7d6111ad6085 253:2    0   1,8T  0 crypt /sata_home
├─sda3                                          8:3    0   7,8G  0 part  
│ └─luks-384d6b27-6263-4d53-bfce-e7e5bcd221b9 253:4    0   7,8G  0 crypt 
└─sda1

BLKid sind die IDs der Filesystem selbst, also von / , von /home oder /boot . Ein Ext3/4, BTRS usw. Filesystem erzeugt beim Formatieren eine BLKID für sich dieses Filesystem. Jedesmal, wenn die Partition neu formatiert wird, gibt es eine neue Nummer.

$ blkid
/dev/sda1: UUID="aee1b027-ebd7-4ad9-a0ea-0fc881193708" TYPE="ext4" PARTUUID="000c4469-01"
/dev/sda2: UUID="6d45b281-c56c-40f0-acf7-c3058d4d6913" TYPE="crypto_LUKS" PARTUUID="000c4469-02"
/dev/sda3: UUID="384d6b27-6263-4d53-bfce-e7e5bcd221b9" TYPE="crypto_LUKS" PARTUUID="000c4469-03"
/dev/sda5: UUID="7881f602-9462-497d-810a-7d6111ad6085" TYPE="crypto_LUKS" PARTUUID="000c4469-05"
/dev/sdc1: LABEL="Boot" UUID="221608f2-5914-4619-9ef7-6dfddf233fd4" TYPE="ext4" PARTUUID="0000a3dd-01"
/dev/sdc2: UUID="ffbd61f2-4c1e-4dc8-b12b-c89e9f69c9fa" TYPE="crypto_LUKS" PARTUUID="0000a3dd-02"
/dev/sdc3: UUID="ca1f019d-39ce-4cf8-b522-f6d3e63ebe2a" TYPE="crypto_LUKS" PARTUUID="0000a3dd-03"
/dev/mapper/luks-ffbd61f2-4c1e-4dc8-b12b-c89e9f69c9fa: UUID="e62edbbe-a1ae-4242-bca5-1249d6f2df67" TYPE="ext4"
/dev/mapper/luks-ca1f019d-39ce-4cf8-b522-f6d3e63ebe2a: UUID="46da0d80-21fb-45b7-8567-ba047de66cb6" TYPE="swap"
/dev/mapper/luks-7881f602-9462-497d-810a-7d6111ad6085: UUID="196a4455-7ccb-40e4-bc71-7b2929f29225" TYPE="ext4"
/dev/mapper/luks-6d45b281-c56c-40f0-acf7-c3058d4d6913: UUID="0fd1b33c-5a2e-421a-a872-7bfc784ea2cf" TYPE="ext4"
/dev/mapper/luks-384d6b27-6263-4d53-bfce-e7e5bcd221b9: UUID="0bb5a502-f854-4e40-a3bd-08c3a2e6bf22" TYPE="swap"

zu 2)
Jetzt schauen wir uns mal /etc/fstab und den Bootentry im Grub an :

$ cat /etc/fstab 

/dev/mapper/luks-ffbd61f2-4c1e-4dc8-b12b-c89e9f69c9fa /           ext4    defaults,x-systemd.device-timeout=0 1 1
UUID=221608f2-5914-4619-9ef7-6dfddf233fd4 /boot                   ext4    defaults        1 2
/dev/mapper/luks-7881f602-9462-497d-810a-7d6111ad6085 /sata_home  ext4    defaults,x-systemd.device-timeout=0 1 2
/dev/mapper/luks-ca1f019d-39ce-4cf8-b522-f6d3e63ebe2a swap        swap    defaults,x-systemd.device-timeout=0 0 0

Wie man in der FSTAB sehen kann, soll /boot über die BLKID eingebunden werden.

Warum macht man das ?

Ganz einfach, weil die BLKID ( BlockID ) eindeutig ist, egal an welchem Port eines Controllers die Platte angebunden ist. Selbst wenn die per USB ins System eingehängt ist, kann man diese Partition referenzieren. Das alt bekannte Problem von früher, wenn sich die Plattenreihenfolge geändert hat, daß dann eine andere Platte das Bootdevice war, entfällt damit.

Wieso ist /boot über BLK referenziert und / mit einer LUKS ID ?

Weil Boot nicht verschlüsselt ist. Das geht zwar auch, aber dann wird es haarig 😉

Da in der FSTAB die BLKID enthalten ist und sich nach erneuten Anlegen des Filesystems eine neue BLKID ergibt, muß man also vor dem ersten Boot die /etc/fstab anpassen, sonst bootet der Rechner nicht mehr.

Der Grub-Booteintrag:

menuentry 'Fedora (4.10.6-200.fc25.x86_64) 25 (Twenty Five)' --class fedora --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-4.10.6-200.fc25.x86_64-advanced-e62edbbe-a1ae-4242-bca5-1249d6f2df67' {
        load_video
        set gfxpayload=keep
        insmod gzio
        insmod part_msdos
        insmod ext2
        set root='hd2,msdos1'
        if [ x$feature_platform_search_hint = xy ]; then
          search --no-floppy --fs-uuid --set=root --hint-bios=hd2,msdos1 --hint-efi=hd2,msdos1 --hint-baremetal=ahci2,msdos1  221608f2-5914-4619-9ef7-6dfddf233fd4
        else
          search --no-floppy --fs-uuid --set=root 221608f2-5914-4619-9ef7-6dfddf233fd4
        fi
        linux /vmlinuz-4.10.6-200.fc25.x86_64 root=UUID=e62edbbe-a1ae-4242-bca5-1249d6f2df67 ro vconsole.font=latarcyrheb-sun16 rd.luks.uuid=luks-ca1f019d-39ce-4cf8-b522-f6d3e63ebe2a rd.luks.uuid=luks-ffbd61f2-4c1e-4dc8-b12b-c89e9f69c9fa  rhgb quiet splash audit=0 rd.driver.blacklist=nouveau nouveau.modeset=0 
        initrd /initramfs-4.10.6-200.fc25.x86_64.img
}

Wie man hier unschwer erkennen kann, kommt die BLKID auch im Bootentry vom Bootloader vor, was verständlich ist, weil der sonst nicht weiß welche Platte er booten sollte 😉

Zudem sind hier die zum Systemstart zu entschlüsselnden  LUKS Partitionen enthalten. Zudem ist die ROOT Partition mit angegeben, die auch über die BLKID referenziert wird.

Wie stellen wir jetzt aber die Bootpartition wieder her ?

Am einfachsten mit einer LiveCD vom gleichen Distributor . Dann formatieren wir die Bootpartition, so daß diese leer ist und legen uns die BLKID bereit. Folgende Schritte führen dann zum Ziel:

  1. Systempartition mounten
  2. DEV und PROC in die Systempartition mounten
  3. BOOT in die Systemplatte mounten
  4. CHROOT in die Systemplatte machen
  5. Bisherige Kernel finden
  6. Kernel neu installieren

Das sieht dann so aus ( natürlich haben Sie andere Partitionen als ich: SDC2 ist Root, SDC1 ist Boot ). Vorher zum Rootuser werden ( su root ) :

mount /dev/sdc2 /media
mount -t devtempfs devtempfs   /media/dev
mount -t procfs procfs /media/proc
mount -t ext4 /dev/sdc1 /media/boot
chroot /media/

Jetzt befinden wir uns im System des normalen Rechners, so daß wir alles so tun können, als wenn er normal gebootet hätte ( ohne Desktop natürlich ) . Wir bekommen die Kernel raus die drauf waren :

rpm -qa | grep kernel-core

und installieren die neu:

dnf reinstall kernel-core-*

Das sind natürlich Anweisungen für Fedora/RedHat Systeme, hier bitte die passenden für Eure Distribution wählen. Natürlich kann man das Raussuchen der Kernels auch weglassen, da ist ja nur eine Info für Euch, damit Ihr seht, ob es stimmt. Nun noch die GRUB Boot Konfiguration neu erzeugen und der Rechner sollte wieder starten:

grub2-install /dev/sdc
grub2-mkconfig -o /boot/grub2/grub.cfg

Das Anpassen von /etc/fstab sollte man natürlich jetzt auch machen, sonst gehts nicht 😉

Wer unerfindliche Probleme mit seinem GRUB Bootentry hat, dem könnte der Beitrag helfen. Ich mußte auch Linux16 durch Linux ersetzen, damit es wieder funktioniert.

Ich kann allen nur nochmal nahe legen, das PDF unten auf einem USB Stick zu sichern, damit Ihr das im Notfall parat habt. Außerdem sind in dem PDF noch viele andere Infos zum Thema aufgeführt und einige intensiver heraus gearbeitet.

PDF zum Download: LUGBS-Filesystemmeltdown

CVE lesen und verstehen: am Beispiel von Gimp

Wenn Euch jemand den Ihr nicht kennt, eine ICO Datei schickt ( u.a. zusammen mit anderen Bilddaten z.b. ),
dann stellt sicher, daß Ihr die neueste GIMP Version habt/benutzt :

 
Schwachstelle CVE-2007-3126 :

 <http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2007-3126>


CVE-2007-3126: Schwachstelle in Gimp ermöglicht Denial-of-Service-Angriff

  Gimp kann in Version 2.3.14 durch eine ICO-Datei mit einem InfoHeader, der
  'Height' mit Null angibt, zum Absturz gebracht werden.

Wer sich jetzt mit CVE Nummern auskennt, wird merken, daß da immer die Jahreszahl drinsteht, wo die Schwachstelle gemeldet wurde, hier ist das 2007 ! Also 10 Jahre her.

Ich hab jetzt mal geprüft, was fürn Gimp ich habe, und das ist 2.8.20-1 🙂 Also irgendwas ist komisch :=)

Die Meldung kam im original von Suse :

Security Bulletin von Suse April 2017

und die haben das hier behoben:

   - bsc#1025717: Prefer lcms2 over lcms1 if both are available
   - bgo#593576: Preven crash in PDF Import filter when importing large image
     PDF or specifying high resolution

und im Zuge dieser Änderung haben die dann auch endlich die obige Schwachstelle behoben und daher wurde das zum Aufmacher der Meldung 🙂

Wie man setTimeout mit Parametern aufruft

Wer in Javascript programmiert, kennt das Problem vielleicht:

Man möchte  „window.setTimeout( function, timems )“ benutzen, um eine eigene Routine aufzurufen, aber man müßte da mal einen Parameter mitgeben, weil das ganze nicht statisch programmiert ist.

Das geht so :

function Klasse () {
        ...        
       this.timerCheck = function(self) {
            console.debug("timerCheck: "+ Date.now() +" "+ self.timer );
            if ( ( Date.now() - self.timer  ) / 1000 > 20 ) {
                self.close(); 
                return true;;
            }
            window.setTimeout( self.timerCheck.bind(null, self), 1000);
            return false;
        }
       this.andereFunktion = function() {
            ...
            this.timerCheck(this);
            ...
       }
}

Der entscheidende Teil ist das self.timerCheck.bind(null, parameter) . Es ruft die Funktion so auf timerCheck(parameter), statt blanko, wie es jahrelang nötig war.

Damit kann man endlich in Objekten, die Instanziiert werden, mehrere Instanzen einer Timerroutine laufen lassen.

IoT: Dildo mit WLAN Accesspoint , Default Root und WebCam

Ja, richtig gelesen, das IoT Desaster geht in die nächste Runde. Wie Heise auf seiner Webseite berichtet, wurde der Hersteller eines WLAN fähigen und mit WebCam ausgerüsteten Dildos bereits 2016 über die mannigfaltigen Schwachstellen seines Produkts informiert. Vor lauter Brumm-Brumm muß er den Hinweis wohl überhört haben, denn passiert ist nichts.

Den ganzen Spaß lest Ihr im Link unten.

Quelle: www.heise.de