Security des tages

Schwerwiegende sicherheitslücke in GnuPG

Es wird sogar empfohlen, auf die Kommunikation via PGP/GPG vorerst zu verzichten und Plugins in Thunderbird und Co. zu deaktivieren

Ich werde einen teufel tun! Ach ja, es gibt auch schon ein paar hinweise, wie man bis zum kommenden pätsch mit der sicherheitslücke halbwegs gefahrenfrei leben kann:

Don’t use HTML mails. Or if you really need to read them use a proper MIME parser and disallow any access to external links

Nun, HTML-mäjhl ist aus so vielen gründen keine gute idee (und deshalb bei verbrechern, werbern und anderen menschenfeinden hochbeliebt), dass ich mir die aufzählung hier einmal spare. Im thunderbird-menü auf ansicht ▷ nachrichteninhalt ▷ reiner text! Das macht die tägliche mäjhl auch viel angenehmer lesbar. Und es schützt die privatsfäre vor träcking-pixeln in HTML-mäjhls. Die idjoten, die auf die idee gekommen sind, dass man mäjhl in HTML formatieren könne und solle (und das beinahe überall zum standard gemacht haben, bei dem verdammt viele leute gar nicht mehr wissen, wie man die kackscheiße abschaltet), die hätte man auf die erste bemannte pluto-missjon der menschheit schicken sollen. Ohne rückfahrkarte. Wenn ich ein formatiertes dokument mit einer mäjhl versenden will, dann hänge ich das an.

Nachtrag: Die kompjuterbild mit schlips aus der karl-wiechert-allee in hannover schreibt den kwatsch mit „mäjhlverschlüsselung ist zurzeit ein sicherheitsrisiko“ ohne die geringste relativierung ab.

Nachtrag zwei: FUD?

Nachtrag drei: Die alarmschlagzeile des tages geht an die aktuelle kamera des BRD-parteienstaatsfernsehens ARD.

Digitale Kommunikation
Forscher knacken E-Mail-Verschlüsselung

GNU des tages

WARNING, CLUSTERFUCK AHEAD!

Programmiert hier jemand in C++ und benutzt die libstdc++ von GNU und hat komische speicherlecks? Oder benutzt hier jemand einen modernen desktop und wundert sich, dass das dingens immer langsamer und plattenkratziger wird, wenn man es mal ein paar tage laufen lässt? Oder verwendet hier jemand eine in C++ geschriebene anwendung mit ganz großem speicherhunger?

The GNU C++ Library is Broken

Es ist etwas länger, aber die lektüre lohnt sich… auch, weil jeder mal bemerken kann, wie viel kopfschmerz so eine scheiße verursachen kann. Das beschriebene problem mit dem speicherleck in der libstdc++ dürfte (in geringerem maße) beinahe jeden menschen betreffen, der eine gegen die GNU-biblioteken gelinkte, in C++ geschriebene softwäjhr verwendet.

Via Fefe

GNU-facepalm des tages

Dieses zitat mit einer anleitung, wie man die GNU-shell „bash“ kompiliert, dürfte für die meisten menschen eher uninteressant sein. Die, für die es interessant ist, werden vermutlich ein ähnliches gesicht ziehen wie ich…

Prepare Bash for compilation:

./configure --prefix=/tools --without-bash-malloc

The meaning of the configure options:

--without-bash-malloc
This option turns off the use of Bash’s memory allocation (malloc) function which is known to cause segmentation faults [sic!]. By turning this option off, Bash will use the malloc functions from Glibc which are more stable.

Ohne weitere worte. Eben gerade bei „linux from scratch“ gesehen.

Einsicht des tages

sNach einem beherzten…

# apt-get install vrms

… auf einem debian-system hat man einen „virtuellen Richard Stallman“ auf seinem rechner, der einem sagt, was man an unfreier softwäjhr in seinem debian installiert hat. Die ausgabe von vrms(1) ist dann aber schon sehr erheiternd:

$ vrms -s
abs-guide
bison-doc
bsdgames-nonfree
celestia-common-nonfree
doc-rfc
doc-rfc-fyi-bcp
doc-rfc-informational
doc-rfc-misc
doc-rfc-old-std
doc-rfc-others
doc-rfc-std
doc-rfc-std-proposed
emacs24-common-non-dfsg
fonts-larabie-deco
fonts-larabie-straight
fonts-larabie-uncommon
gawk-doc
glibc-doc-reference
gsl-doc-info
gsl-ref-html
gstreamer0.10-fluendo-plugins-mp3-partner
icc-profiles
libfaac0
make-doc
mame
mame-data
mame-tools
p7zip-rar
scribus-doc
selfhtml
texinfo-doc-nonfree
unrar
virtualbox-guest-additions-iso
wolf3d-data-wl1
xfractint

dosemu
flashplugin-installer
game-data-packager
quake
ttf-mscorefonts-installer
virtualbox
virtualbox-dkms
virtualbox-qt
winetricks
wolf4sdl

Wir merken uns: die dokumentazjon für GNU bison ist nicht Frei, die dokumentazjon für GNU awk ist nicht Frei, die dokumentazjon der libc des GNU-projektes ist nicht Frei, die dokumentazjon der „GNU scientific library“ (ein hervorragendes hilfsmittel zum zahlenfressen) ist nicht Frei, die dokumentazjon von GNU make ist nicht Frei — jeweils im sinne dessen, was das GNU-projekt für Frei hält. Vielleicht sollte das GNU-projekt mal damit beginnen, seine dokumentazjonen unter Freien lizenzen zu veröffentlichen… :mrgreen:

Ich glaube, ich starte zum aggressjonsabbau nach dieser ansage erstmal das zu recht als unfrei bezeichnete quake. 😀

bsdgames-nonfree enthält das olle rogue (die älteren werden es wohl noch kennen), das nur nichtkommerzjell verbreitet werden darf, was dem GNU-begriff von Freiheit widerspricht.

GNU des tages

Jetzt, wo mal eine rechenmaschine gegen einen guten spieler im go gewonnen hat, ist der hirnfurz von der künstlichen intelligenz mit neuronalen netzen ja wieder modern und es gibt prompt ein neues GNU-projekt für ein GNUronales netzwerk. Aus etischen gründen, damit diese wichtige „technologie“ nicht in den händen von geistigen eigentümern akkumuliert wird.

Ich empfehle übrigens, ebenfalls aus ethischen gründen, jedem menschen, öfter mal ein paar körperflüssigkeiten mit einem gegengeschlechtlichen anderen menschen auszutauschen, damit natürliche intelligenz entsteht — und alles dafür zu tun, dass diese natürliche intelligenz nicht mit der brachialen wucht der psychischen manipulazjon, angstmache und angebotenen bekwemlichkeit von staat, wirtschaft, contentindustrie und schule an der wurzel geknickt wird und verdorrt. Diese „technologie“ muss man (noch) nicht eigens „befreien“; aber der kampf darum, dass menschen Frei sind, er lohnt sich. Wenn ihr mich fragt, führt er in die einzig mögliche erträgliche zukunft sowohl für die menschheit als ganzes als auch für die einzelnen menschen. Wer wirklich alles dafür tut, dass seine kinder nicht hirnkastriert, geistverkrüppelt und zwangsinfantilisiert werden, steht leider zurzeit mit einem bein im knast und muss — neben den üblichen beschimpfungen durch fast jeden mitmenschen — damit rechnen, dass ihm seine kinder gewaltsam vom staat und seinen schergen weggenommen werden. Und nächsten sonntag in der nächsten sonntagsrede fettgefressener professjoneller lügner: die großartige „freiheit“ und die zukunft und die bambihafte geborgenheit der familje… 😦

„Not very useful“

--enarmor --dearmor  Pack or  unpack an arbitrary input into/from an OpenPGP ASCII armor. This is a GnuPG extension to OpenPGP and in general not very useful.

Kwelle: man 1 gpg (Die man-page gibts natürlich auch im web.)

Hej, GNU! Wenn mans zu nix gebrauchen kann und wenns zu keinem standard gehört, warum habt ihrs dann gekohdet?! Zu wenig gewaxenes gerümpel im kohd? Zu wenig für viele menschen echt abschreckende opzjonen? Oder hattet ihr einen guten grund dafür? So einen, den ihr jetzt nicht mehr kennt? Ach!

Hallo? Glibc-entwickler? Einschläge?

Es ist ja viel zu mühsam, bei so einem aufruf von malloc() an den als parameter übergebenen ausdruck den schlichten term + 1 anzuhängen! Deshalb habt ihr das auch dann nicht gemacht, als ihr auf diesen fehler hingewiesen wurdet und als euch gesagt wurde, dass man damit einen buffer overflow von einem byte hinbekommt, der möglicherweise sogar ausbeutbar ist. Nee, das habt einfach so gelassen. Das ist halt ein fehler, und warum sollte man den denn korrigieren, so richtig umständlich mit einem checkout, dem öffnen der datei im editor, dem hinzufügen von drei zeichen an der stelle mit dem fehler und einem anschließenden checkin. Selbst, wenn man die änderung geschwätzig beschreibt, statt einfach nur die nummer aus dem bugträcker zu nehmen, gehen dafür volle fünf minuten lebenszeit drauf. Da sagt man dann lieber: Nee, das ist doch gar kein problem, wir lassen den fehler einfach drin…

Und so habt ihr das fast ein volles jahrzehnt lang gehandhabt. Bis es dann ein problem geworden ist, weil euer gut ein jahrzehnt lang aufrechterhaltener „fehler“ — wenn auch mit einem gewissen aufwand und unter ausnutzung anderer schwachstellen — ausbeutbar ist.

Hallo?! Entwickler?! Seid ihr dafür etwa von der NSA bezahlt worden? Habt ihr das dingens nicht rausgenommen, weil es eine völlig beabsichtigte hintertür war? Ich habe jedenfalls keine bessere erklärung dafür.

Und wer an der glibc mitarbeitet und etwas anstand hat, ist vermutlich gut beraten, sich auch mal den ganzen anderen kohd von diesem Florian Weimer anzuschauen. Es würde mich nicht wundern, wenn der sein geld nicht nur von red hat bekommt…

Warum ich die libc hasse!

Nachtrag: ja, die überschrift ist ein „bisschen“ irreführend, und ich meine die glibc. Aber die hasse ich wirklich jeden tag ein bisschen mehr.

Ja, ich weiß, das ist jetzt ein ziemliches friek-tema. Aber ich hasse die normale libc (und könnte Fefe unentwegt für seine dietlibc küssen) und möchte mir unbedingt mal das bisschen luft verschaffen.

Das ich die glibc hasse, liegt daran, dass ich mein eigenes c-gehäcksel manchmal statisch binde, also keine shared libraries verwende, sondern ein binary haben möchte, das ich „einfach so“ auf einem anderen rechner verwenden kann. Ich sitze an ständig wexelnden geräten, und ich habe auch nicht überall eine entwicklungsumgebung zur verfügung oder die erforderlichen rechte, nach belieben softwäjhr nachzuinstallieren — einmal ganz davon abgesehen, dass ich die installazjon eines laufenden sörvers nur anfasse, wenn es gar nicht anders geht. Da ist es für mich oft das günstigste — meine eigenen, unentbehrlichen tuhls habe ich auf einer speicherkarte ständig bei mir — wenn ich ein binary habe, dass ich auch starten kann, selbst wenn bestimmte shared libraries nicht installiert sind. Die meisten libraries, die ich verwende, sind relativ klein, so dass dieses „vergnügen“ nicht zu „teuer“ wird.

Bis auf diese verdammte libc! Machen sich heutige programmierer eigentlich gar keine mühe mehr, bloatware zu vermeiden?

Nehmen wir einmal ein beispiel. Der folgende, sehr schlichte „programm“ ist eine kleine abwandlung eines klassischen lehrbuchbeispiels.

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

int
main (int argc, char **argv)
{
  const char *s = "Hallo Welt";
  puts (s);
  return EXIT_SUCCESS;
}

Speichern wir es einmal unter dem namen hello.c. Wenn dieses programm mit der anweisung…

cc -s -Os hello.c -o hello

…kompiliert wird (-Os optimiert den erzeugten kohd auf geringe dateigröße, und -s entfernt die symboltabelle und andere für die lauffähigkeit nicht benötigte verwaltungsinformationen vom erzeugten binary), denn ist das ergebnis ja noch durchaus plausibel, wie ein anschließender ls -l verrät:

-rwxr-xr-x 1 elias elias 5652 2010-11-05 18:51 hello
-rw-r--r-- 1 elias elias  145 2010-11-05 18:29 hello.c

Fünfeinhalb kilobyte für eine schlichte textausgabe ist zwar ein bisschen mehr, als man von „einfachen“ betriebssystemen gewohnt ist, aber der startup code für so einen aufgeplusterten pinguin ist ja auch nicht trivial.

Die für die ausgabe verwendete funkzjon puts — ich habe für dieses beispiel mit absicht nicht printf verwendet, weil printf eine menge weiteren kohd benötigt, um die im formatstring angegebenen formate zu interpretieren — sollte relativ einfach implementiert sein, vielleicht ungefähr so¹:

/* Einfache beispielimplentazjon der standard-funkzjon puts */
int
puts (const char *s)
{
  register int c, n;
  for (n = 0; putchar ((c = *s) == 0 ? '\n' : c) >= 0 && c != 0; ++s, ++n)
    ;
  return ferror (stdout) ? EOF : n;
}

Nichts ist darin, was ehrfurchtgebietende komplexität erwarten lässt. Dieses ferror sollte einfach nur ein fehlerbit im FILE *stdout prüfen und im fehlerfall eventuell errno setzen und einen wert ungleich 0 zurückgeben; und dieses putchar ist ein makro, das ein zeichen an einen ausgabebuffer anfügt, einen index für die näxste bufferposizjon erhöht und gegebenenfalls den buffer mit write wegschreibt und anschließend den index für die näxte zeichenposizjon zurücksetzt. Ich könnte hier jetzt auf die schnelle ein beispiel angeben, wie man so etwas als makro implementieren kann, aber das würde durch die schwer lesbare verschachtelung einiger ?-operatoren (buffer voll? zeilenbufferung?) nicht gerade deutlicher als die verbale beschreibung, und deshalb lasse ich es.

Kurz gesagt: Es ist zu erwarten, dass diese puts-funkzjon nicht wesentlich mehr als — sagen wir einmal — 1000 bytes objektkohd erzeugt. Sie ist völlig trivial. Eine dereferenzierung, ein test auf das nullbyte am stringende und ein verhältnismäßig einfaches makro bilden die innere schleife, am ende wird der rückgabewert durch einen bit-test ermittelt, damit fehler an den aufrufenden kontext gemeldet werden können. Als zusätzlicher kohd kommen die vier bytes für die globale variable int errno hinzu und natürlich die funkzjon write für die native, ungebufferte ausgabe, die direkt an den kernel weitergeleitet werden sollte (natürlich wird auch hier anschließend errno gesetzt, wenn ein fehler auftrat — aber auch das sind auch nur eine handvoll bedingungen).

Nun, bei der libc, die mit einem normalen GNU/linux-system (in diesem fall eine debian-distribution) daher kommt, sieht das offenbar ein bisschen anders aus. Mit dem folgenden aufruf…

cc -s -Os -static hello.c -o hello

…kann man eine statisch gebundene versjon dieses schlichten hallo-welt-programmes erzeugen, das völlig bewusst so formuliert wurde, dass es nur eine triviale und den kohd nicht aufblähende funkzjion verwendet. Ein anschließendes ls -lh lässt einem die kinnlade herunterklappen und bei empfindlichem magen den mageninhalt nach oben steigen:

-rwxr-xr-x 1 elias elias  510K 2010-11-05 21:34 hello
-rw-r--r-- 1 elias elias   145 2010-11-05 18:29 hello.c

WTHF! 510 KiB für das dazulinken von ansich völlig trivialem kohd ist doch eine menge holz. 😦

Den blick in die (nicht gerade schnell erfassbaren) kwelltexte der libc, um diesem bloat auf die spur zu kommen, erspare ich mir mal. Stattdessen hier eine schnellere und schlampigere analyse, die auch schon erschüttert:

Lässt man die opzjon -s beim kompeiler-aufruf einmal weg, um die symboltabelle im binary zu belassen, kann man sich hinterher mit nm -g hello | awk '$2 == "T"' anschauen, welche symbole in der kohd-sekzjon des kompilates enthalten sind; und das zeigt wiederum, welche funkzjonen der linker dazugebunden hat, weil sie von der einzigen verwendeten funkzjon puts verwendet werden. Wer jetzt meint, dass sich seit den siebziger jahren doch einiges in sachen komplexität einer standard-ein-ausgabe getan haben könnte und dass die implementazjon von puts vor allem deshalb „ein bisschen“ fett geworden ist, der kann mir bitte einmal erklären, warum (unter anderem, denn ich nenne hier nur einige besonders absurde beispiele) die folgenden funkzjonen für die schlichte ausgabe einer nullterminierten zeichenkette benötigt werden sollten:

  • bsearch
    Wozu zum abgehackten pimmel nochmal benötigt die libc dafür eine binäre suche? Selbst beim wildesten spekulieren fällt mir kein grund ein, warum die benötigt werden sollte.
  • dprintf
    Hui, den printf für die direkte ausgabe in dateideskriptoren, den sieht man wirklich selten in „echtem“ kohd…
  • fprintf
    Haben die beim häcken der libc etwa die triviale standardfunkzjon puts (s) mit einem printf ("%s\n", s) implementiert? Das würde den ganzen bloat ja erklären. Aber es wäre auch so gnadenlos dumm, dass einem nichts mehr dazu einfällt.
  • localtime
    Was zum schwefelkackenden höllenhund?!?!
  • open_memstream
    Wozu soll hier eine ein-/ausgabe in einen speicherbereich benötigt werden? Die puts-funkzjon ist trivial und bedarf derartiger abstrakzjonen des stream-konzeptes nicht.
  • qsort
    OMFG! Was soll bei diesem einfachen vorgang bitte durchsortiert werden!?
  • setlocale
    Soll da etwa die ausgabe von einzelzeichen in einem stream an die landeseinstellungen angepasst werden?
  • sscanf
    Mir fehlen die passenden derben worte, um dazu noch etwas sagen zu können. m(

Wie gesagt, dass alles für die ausgabe einer nulltermierten Zeichenkette nach stdout.

Diese allgemein bekannten funkzjonen werden natürlich ergänzt um einen wust von internen funkzjonen, mit denen diese standards implementiert werden. Es ist einfach unfassbar. Wer immer an der libc herumprogrammiert hat, er schien sich gesagt zu haben, dass ruhig ein anständiger bloat entstehen kann, sein kompjuter hat ja kein problem damit. Und deshalb wurde jede disziplin abgelegt und man hat sich allgemein einen dreck darum geschert, ob bloat entsteht oder nicht. Und die meisten programmierer, die so einen dreckskohd nutzen, merken es niemals, weil ja der ganze bloat schön in einer dynamischen bibliotek versteckt bleibt und nicht die größe des binary aufbläht. Dass es speicher frisst und auf die performanz geht, drauf geschissen! Dass bei einer zentralen bibliotek wie der libc jedes einzelne programm von diesem bloat betroffen ist, dass es also eine last für das gesamte system wird, drauf geschissen! Sorgfalt und sparsamkeit waren gestern, lasset uns gewaltige mengen RAM voraussetzen und überall, wo dieses nicht wie vorausgesetzt vorhanden ist die platten auf die auslagerungspartizjon kratzen und gebet der CPU extrafette brocken kohd für die erfüllung noch der simpelsten und elementarsten aufgaben! Denn das ist die neue zeit, sie ist schäbig, verantwortungslos und schlecht und „erfreut“ zum ausgleich für die kwalitativen missstände im kernsystem mit polierten und effektheischenden benutzerschnittstellen zur verpackung dieser scheiße. So hat man doch etwas zum „freuen“, wenn man von ein paar billigen effekten unterhalten wird, während man sich fragt, warum trotz aller technischen fortschritte der letzten zehn jahre die trägheit der anwendungen gleich geblieben oder gar schlimmer geworden ist.

Und das — so viel noch zum ende — ist leider auch im bereich der freien softwäjhr symptomatisch für die entwicklung in den letzten anderthalb jahrzehnten. Früher einmal habe ich linux geschätzt, weil kompjuter — auch etwas betagtere — viel zu schade zum wegwerfen sind und weil ich eine menge guter softwäjhr auch auf „uralten trümmern“ einsetzen konnte. Inzwischen ist dort in der softwäjhr-entwicklung allerdings der gleiche gleichgültige irrsinn eingekehrt, der auch so prägend für alle anderen plattformen ist. Manchmal hasse ich das alles nur noch!

Die verwendung „moderner konzepte“ macht das ganze noch schlimmer. Wenn man das oben gegebene beispielprogramm einmal zeile für zeile in die hochgejubelte und für beinahe alle „modernen“ projekte verwendete bloatware-sprache c++ überträgt…

#include <iostream>
#include <cstdlib>

int
main (int argc, char **argv)
{
  std::string s("Hallo Welt!");
  std::cout << s << std::endl;
  return EXIT_SUCCESS;
}

…unter dem namen hello.c++ speichert und schnell mit…

c++ -Os -s -static hello.c++ -o hello++

…kompiliert, denn zeigt einem nicht nur die sehr spürbar gewordene wartezeit, die der kompeiler nun benötigt, um sich von diesen recht lächerlichen neun eingabezeilen zu „erholen“, dass hier noch etwas viel schlimmeres geschieht. Auch das anschließende ls -lh ist erschröcklich:

-rwxr-xr-x 1 elias elias 1006K 2010-11-05 21:05 hello++
-rw-r--r-- 1 elias elias   163 2010-11-05 21:09 hello.c++

Dass nach der übersetzung eines lehrbuchmäßig einfachen nullprogrammes nahezu ein MiB kohd benötigt werden soll, nur, um eine kurze zeichenkette in einer std::string-instanz abzulegen und diese zur standardausgabe zu schreiben, das ist wirklich pathologisch. Hier ist der bloat fest ins grundsystem und in die entwicklungswerkzeuge eingebaut, und er „vererbt“ sich von dort auf das gesamte system. Wer sich beim starten eines anwendungsprogrammes wie etwa des beliebten brausers firefox darüber wundert, warum so eine anwendung, die eigentlich nur ein bisschen netzwerkverkehr macht und HTML-dokumente in ein fenster rendert (eventuell ergänzt um den start von plugins, wenn die dargestellte webseit derartige objekte enthält), dafür so viele megabyte speicher belegt, der hat hier einen teil der antwort.

Und wer einen alten, ansich noch funkzjonsfähigen und dienstbaren rechner hat, auf dem sich die „moderneren“ anwendungen gar nicht mehr verwenden lassen; wer sich mit einem derartigen gerät im internetz bewegen will (was ja keine absurde anforderung ist, und was ansich auch keine riesigen ressorßen erfordert)², der ist genötigt, entweder alte, unsichere und in allen ihren bekannten fehlern ausbeutbare softwäjhr zu verwenden (Bog bewahre!), oder aber seinen alten, ansich noch funkzjonfähigen und dienstbaren rechner als sondermüll zu entsorgen und sich einen neuen rechner zu verschaffen.

Und draußen, vor den städten, wäxt das eigentliche monument unserer „zivilisation“: der müllberg. Was die kompjuter darin zu müll gemacht hat, ist allerdings müllsoftwäjhr.

Ach ja, bevor ich es vergesse: das kompilat der hallo.c gegen die dietlibc gelinkt hat bei mir eine dateigröße von 1004 bytes. Es tut das gleiche wie der megabytefette c++-kohd.

¹In wirklichkeit wird puts (s) wohl meist ein makro sein, das fputs (s, stdin) aufruft, aber die implementazjon von fputs ist auch nicht schwieriger. Ich habe das beispiel einfach gehalten, damit die primitivität einer derartigen funkzjon besser sichtbar wird, in einer realen implementazjon einer derartigen library wird ein gewisses augenmerk darauf gelegt werden, keinen kohd zu duplizieren, um sich keine alpträume bei der pflege zu bereiten. Die gleiche betrachtung gilt auch für das putchar-makro, das im regelfall mithilfe des fputc-makros implementiert werden wird.

²Natürlich gibt es immernoch pine und lynx

Die ironie vergessener ideale

GNU/Linux bekommt in letzter Zeit mehr Anhänger. Das System wird aus praktischen Gründen populär. Es ist ein gutes System. Die Gefahr dabei ist, dass Leute Linux eben wegen dieser praktischen Gründe mögen und keine Ahnung haben von den Idealen, die dem System zugrunde liegen. Das wäre schon eine ironische Art, zu scheitern.

Richard Stallman