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. 😦
Schwerdtfegr (beta) 