Wir haben den schwierig ausbeutbaren fehler in der glibc
gefixt, aber dafür leider einen viel leichter ausbeutbaren fehler neu reingemacht.
Menschen, die angst vor technik haben, hören am besten jetzt mit dem weiterlesen auf! ⚠️
Ich bin überhaupt nicht überrascht, denn die glibc
ist ein rottiger scheißhaufen voller überkomplexität, und damit das genaue gegenteil von sicherheit, robustheit und fehlerfreiheit. Wenn man das folgende C-programm mit gcc
kompiliert und gegen die glibc
linkt (das ist beim gcc
standard, das muss man nicht angeben)…
#include <stdio.h>
#include <stdlib.h>
int main (int argc, char **argv)
{
puts("Hallo Welt");
return EXIT_SUCCESS;
}
…um sich hinterher anzuschauen, was alles dazugelinkt wird, kommt man aus dem kopfschütteln gar nicht mehr raus. Nein, das ist nicht mit einem C++-kompeiler gemacht worden, der naturgemäß eine menge zusätzlichen kohd für C++-sprachelemente dazulinken muss. Das ist ein C-kompeiler. Der wust der sichtbaren symbole lässt mich vermuten, dass sie puts
nicht etwa als einfache schleife implementiert haben, die abbricht, sobald ein nullbyte im string kommt…
int puts (const char *str)
{
register int c;
while ((c = *str++) != 0)
if (putc (c, stdout) == EOF)
return EOF;
return putc ('\n', stdout);
}
(Dieses putc
ist ein makro, das typischerweise ein byte in einen buffer im FILE *
kopiert und diesen mit write
ausgibt, wenn er voll ist oder ein zeilenende '\n'
geschrieben wurde, also etwas sehr triviales, das nicht viel kohd benötigt.)
…sondern über eine glibc
-typische versjon eines fprintf
in einen dynamisch allozierten speicherbereich reinschreiben, den sie schließlich mit write
ausgeben. Das ist aber nur eine vermutung. Auf eine betrachtung der glibc
-kwältexte hatte ich nach meinem kurzen einblick schon keine lust mehr. Das ist ein unnötig verfrickelter scheißhaufen voller wexelseitiger abhängigkeiten, der überkomplex geworden ist. Solche fehler, die durch das beseitigen eines fehlers auftreten, werden wir da in zukunft noch häufiger sehen. 😦