ubuntuusers.de

oder versucht es zumindest. Nachdem Ubuntu bereits in älteren Releasen durch Unterstützung von AppArmor und SELinux, der Integration des non-executable-stack Patches in GCC und dem Virtual Address Space Randomisation Patch des Kernels, bereits einiges für die Sicherheit seiner Nutzer getan hat, versucht es nun durch das standardmässige setzen der -Wformat=2 Flag in GCC Formatstring-Angriffen in Anwendungen vorzubeugen, indem die verursachenden Code-Segmente vom Compiler angemahnt werden.

Um das gesagte zu verdeutlichen ein Beispiel. Den folgenden Code speichert man in einer Datei test.c:

1 2 3 4 5 6 7 8

#include <stdio.h> int main(void){ char * test_string="Intrepid will warn you during compilation!" printf(test_string); return(0); }

und kompiliert sie mit:

gcc -o test test.c 

Unter Hardy kompiliert dies noch ohne Probleme. Unter Intrepid jedoch wird dies geschehen:

$ cat test.c 
#include <stdio.h>

int main(void){
	char *test_string="Intrepid will warn you during compilation!";
	printf(test_string);

	return(0);
}
$ gcc -o test test.c
test.c: In function ‘main’:
test.c:5: warning: format not a string literal and no format arguments
$

Das Programm wird zwar weiterhin kompilieren, jedoch wird der Kompiler einen warnen, dass man eine Format-String Funktion ohne Formatstring verwendet hat. Dies ist gefährlich sobald der Inhalt der Variable durch einen Nutzer veränderbar ist, da somit ein Formatstring-Angriff ausgeführt werden kann. Dies wieder kann dann schlimmsten Falls zur Kompromitierung eines Systems führen.

Viele Programme benutzen jedoch die -Werror Flag welche dafür sorgt, dass Warnungen als Fehler interpretiert werden und die Kompilierung abgebrochen wird. So zum Beispiel beim Madwifi-Treiber 🇬🇧 , SYSLINUX 🇬🇧 und vielen anderen Projekten 🇬🇧 der Fall.

Damit der Code weiterhin in Intrepid kompiliert, haben die Programmierer also zwei Möglichkeiten: Zum einen können sie diesen schlechten Programmierstil ablegen und die Fehler fixen. Zum anderen können sie jedoch auch einfach die -Werror Flags entfernen. Der Code würde zwar beim Kompilieren Warnung ausspucken aber trotzdem fertig kompilieren. Letzteres wäre für die User und den Sinn des ganzen jedoch weniger erträglich.

Dieser Artikel stammt von Rorschach.

---

Ikhaya-Artikel

Darstellungsfehler in Firefox 3:

Dasselbe mit Opera 9.60

Interessanter Artikel - danke!

cLinx schrieb:

Dasselbe mit Opera 9.60

Und Konqueror 3.5.

trotzdem ein gelungener und interessanter Artikel mit einem schönen und einfachen Beispiel. Mehr davon! ☺

Vllt ist es ja auch kein Darstellungesfehler, sondern einfach falscher Code? Kann doch jedem mal passieren :>

Typisch. Statt einfach die Ursachen, in diesem Fall das völlig bescheuerte IO-System von C, endlich auf dem Müllhaufen der Geschichte zu entsorgen, wird wieder drum herum gefrickelt.

Da fehlt in der 4. Zeile im oberen Codefeld am Ende noch ein ";" wenn ich mich nicht irre. ☺

Boerkel schrieb:

Da fehlt in der 4. Zeile im oberen Codefeld am Ende noch ein ";" wenn ich mich nicht irre. ☺

Jep da sieht man wieder was C für Krankheiten mit sich bringt ☹

Ein Codebeispiel das zeigt wie man es richtig macht wäre interessant.

Jetzt weiß ich endlich warum ich z.Z. kein WLan habe...

Ein Codebeispiel das zeigt wie man es richtig macht wäre interessant.

Ja, das wäre gut.
Ich weiß doch, warum ich C++ oder besser gar kein C nutze! Vielen Dank für das tolle Argument, das kann ich sicher benutzen, wenn sich mal wieder ein C-Programmierer über die anderen Sprachen (bei mir: Python,Pascal,Java) aufregt.

@Roger1993: Wer es als Krankheit bezeichnet, dass Statements in C mit einem Semikolon beendet werden, der hat IMO keine Ahnung, wovon er spricht. Mit 15 Jahren (ich nehme an, 1993 bezeichnet Dein Geburtsjahr?) ist das nichts schlimmes, aber man sollte dann auch bitte das Maul nicht so weit aufreißen.

Was das Beispiel angeht: das ist in zweierlei Hinsicht schlecht. Erstens wird eine Umwandlung von einem string-Literal in einen char* durchgeführt, was u. U. zu undefiniertem Verhalten führt. String-Literale sind in C vom Typ const char[], daher kann man string-Literale in einem schreibgeschützten Speichersegment ablegen, und wenn man versucht, darauf zu schreiben (was, da test_string vom Typ char* und nicht const char* ist, eigentlich gehen sollte), stürzt das Programm ab. g++ warnt vor solchen Fehlern, gcc unverständlicherweise nicht.

Zweitens enthält es die Schwachstelle gar nicht, die demonstriert werden soll. Ein triviales Programm, das die Schwachstelle präsentiert, sähe z. B. so aus:

1
2
3
4
5
6
7

#include <stdio.h>
int main(void) {
        char str[101];
        scanf("%100s",str);
        printf(str);
        return 0;
}

Das Programm liest bis zu 100 Zeichen ein und gibt sie dann wieder aus. Es stürzt aber ab, wenn man z. B. %s%s%s%s%s%s%s%s%s%s%s%s%s%s eingibt, und in komplexerer Software kann das noch viel unangenehmere Folgen haben. Ein korrektes Programm sieht so aus:

1
2
3
4
5
6
7

#include <stdio.h>
int main(void) {
        char str[101];
        scanf("%100s",str);
        printf("%s",str);
        return 0;
}

@Hello World: Ich finde die Aussage von Roger1993, die sich - so weit ich erkennen kann - auf die Semikola am Ende eines C-Ausdrucks bezieht, vollkommen korrekt. Ich selbst habe Erfahrung mit diesen blöden Dingern (PHP, Java, C[++]) und mit Programmiersprachen, die diese weglassen (Python, Ruby etc) und kann berichten, dass zweitere sich leichter bedienen lassen.

In der (allen?) menschlichen Sprache(n) gibt es kein "Mein-Ausdruck-ist-jetzt-zu-Ende"-Signal, man hört einfach auf, wenn man fertig ist mit dem Sagen. Und da sich Programmiersprachen meiner Ansicht nach an menschlichen Sprachen orientieren sollten (sie sind ja dazu da, menschliche Befehle in für Computer lesbare Befehle zu übersetzen), stören mich solche das Ende eines Ausdruck signalisierenden Semikolons gewaltig (ebenso geschweifte Klammern, eckige Klammern o.ä. zur Einleitung einer Schleife o.ä.).

Was ist schöner:

1
2
3
4
5

<?
    if ($variable_a == $variable_b) {
        print $foo;
    }
?>

oder

1
2

if variable_a == variable_b:
    print foo

?

Genau das Selbe mit Datentypen: Geben wir als Menschen denn an, ob wir eine Zahl sagen, einen Satz, oder nur ein Wort. Wir lassen doch das ganze Metazeugs auch weg (oder kündigst du an, dass du gleich was fragen wirst/etwas sagen wirst/eine Zahl sagen wirst?), was hat das dann in einer für Menschen geschaffenen Sprache zu suchen? Was ist schöner:

1
2

int a = 1;
double b = 5.09;

oder

1
2

a = 1;
b = 5.09;

Klar kommt dann das Argument mit der Vermischung von Datentypen - aber wer halbwegs sauberen, übersichtlichen, dokumentieren/kommentierten Code schreibt, dir wird damit auch keine Probleme haben ☺

In der (allen?) menschlichen Sprache(n) gibt es kein "Mein-Ausdruck-ist-jetzt-zu-Ende"-Signal, man hört einfach auf, wenn man fertig ist mit dem Sagen.

Wir reden hier aber vom Schreiben. Oder sprichst du C++? Ich mache einen Punkt am Ende des Satzes.