Forum: Knobelecke

In Teil 1 haben wir gelernt, wie man ein dämlich geschriebenes setuid root Programm dazu verwenden kann, die Rechte seines Besitzers zu erhalten.

In diesem Teil entfernen wir das verhängnisvolle "sleep(10);":

#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <unistd.h>

int main(int argc, char *argv[])
{
        FILE *fp;
        struct stat buf;

        /* if file already exists, abort */
        if (!stat("./file.txt", &buf))
                return -1;

        fp = fopen("./file.txt", "w");
        fprintf(fp, argv[1]);
        fclose(fp);

        return 0;
}

Der Rest ist unverändert. Die Race Condition besteht natürlich immer noch, aber sie ist ohne Weiteres verflucht schwer zu treffen.


Frage: wie können wir erreichen, dass wir die im ersten Teil beschriebene Lücke immer noch ausnutzen können?

Gruss,
Philip

--
The C Programming Quiz - bitte Fragen einreichen :)

 

Zitat:

Frage: wie können wir erreichen, dass wir die im ersten Teil beschriebene Lücke immer noch ausnutzen können?

Na umgekehrt arbeiten:

ln -sf /etc/passwd ./file.txt && pöser_pursche

Arghs, Unfug, der stat()-Aufruf verhinderts ja.
Also mit flockfile auf dem Verzeichnis darüber. Dannach das Programmstarten, ne sec warten, Link anlegen und unlock auf das Verzeichnis machen. stat müsste durchrutschen, der open kann aber nicht die Datei erstellen.

Bis denne

Martin

--
0xC0FFEE

 

Das Programm muss innerhalb eines Programmes gestartet werden, welches mir erlaubt, das Programm anzuhalten oder zu verlangsammen.
Das böse Skript muss nach der Prüfung das Programm suspendieren, den Link anlegen und das Programm fortfahren lassen.

--
To follow the path: look to the master, follow the master, walk with the master, see through the master, become the master.

 

Zitat:
Der Rest ist unverändert. Die Race Condition besteht natürlich immer noch, aber sie ist ohne Weiteres verflucht schwer zu treffen.

Sleep führte ja zwingend zu einer Scheduling-Entscheidung an dieser Stelle. Müssen wir was bauen um ebenfalls eine Scheduling-Entscheidung zu provozieren?

Falls ja, folgende Ideen:

*) nice
*) Viele Prozesse aufmachen, erhöht vielleicht die Chancen, dass einer von denen drankommt
*) Viele IRQs generieren, erhöht vielleicht die Chancen für eine Scheduling-Entscheidung

Oder bin ich komplett auf dem Holzweg?

mfg, Wolfgang

--
Hex, Bugs and Rock 'n Roll

 

Per Endlosschleife prüfen, ob file.txt existiert und wenn ja fix austauschen?
Wie Wolfgang schon sagte, per nice dafür sorgen, dass dieser Prozess entsprechend bevorzugt wird.

--
To follow the path: look to the master, follow the master, walk with the master, see through the master, become the master.