mehrere Abfragen schöner und in weniger Zeilen schreiben

[habakug]

@goeb
Ich finde du hast dir eine Art Tunnelblick in dieser Angelegenheit zugelegt. Noch ein letzter Versuch dir meinen Shellcode zu übersetzen:

Code: Alles auswählen

user1:~$ pwd > temp.$$
user1:~$ cat temp.$$
/home/user1
user1:~$ echo -e `cat temp.$$`\/`basename temp.$$`
/home/user1/temp.4554

Die temporäre Datei befindet sich dort, wo das Skript ausgeführt wird und *nicht* in "/tmp". Alle Gefahren, die im "/tmp"-Verzeichnis drohen, treffen also nicht zu. Das du *überhaupt* nicht darauf eingehst, ist schade.
Im Gegensatz dazu tut "mktemp" genau das:

Code: Alles auswählen

user1:~$ mktemp
/tmp/tmp.08dYWiPvCj

Hier trifft also zu, was du hier an Gefahren siehst:

BUGS
Never use mktemp(). Some implementations follow 4.3BSD and replace
XXXXXX by the current process ID and a single letter, so that at most
26 different names can be returned. Since on the one hand the names
are easy to guess, and on the other hand there is a race between test‐
ing whether the name exists and opening the file, every use of mktemp()
is a security risk. The race is avoided by mkstemp(3).

Und ebenso:

— Function: char * mktemp (char *template)
[...]
Warning: Between the time the pathname is constructed and the file is created another process might have created a file with the same name using mktemp, leading to a possible security hole. The implementation generates names which can hardly be predicted, but when opening the file you should use the O_EXCL flag. Using mkstemp is a safe way to avoid this problem.

Du hättest wohl besser auch auf "mkstemp" hingewiesen und dich nicht darauf versteift, nachzuweisen, ich hätte dazu aufgefordert, irgendeine Datei im Verzeichnis "/tmp" anzulegen.

Gruß, habakug

$ man 3 mktemp
[1] http://www.gnu.org/software/libc/manual ... Files.html

[goeb]

Noch ein letzter Versuch dir meinen Shellcode zu übersetzen:

Code: Alles auswählen

user1:~$ pwd > temp.$$
user1:~$ cat temp.$$
/home/user1
user1:~$ echo -e `cat temp.$$`\/`basename temp.$$`
/home/user1/temp.4554

Die temporäre Datei befindet sich dort, wo das Skript ausgeführt wird und *nicht* in "/tmp". Alle Gefahren, die im "/tmp"-Verzeichnis drohen, treffen also nicht zu. Das du *überhaupt* nicht darauf eingehst, ist schade.

Dann lies doch nochmal meine erste Antwort. Ich schrieb nur, daß du darauf hinweisen sollst daß es keine gute Idee ist temporäre Dateien mit $$ in Verzeichnissen anzulegen in die noch andere Benutzer schreiben können. Warum du darauf hinweisen sollst? Deswegen:

Danke für den Hinweis, daß ich auch gleich /tmp/mtstatus_tmp.$$ nutzen kann.

Und du hast ja schon selbst erkannt daß das von dir gepostete Skript nicht ins Home-Verzeichnis schreibt, sondern ins aktuelle Verzeichnis (Tipp: das kann auch mal /tmp sein).

Im Gegensatz dazu tut "mktemp" genau das: [...]

Du hast aber bemerkt das es um Shellskripte geht und der Threadersteller kein C-Programm schreiben will? Sowohl das von dir angeführte (unsichere) mktemp() als auch mkstemp() sind C-Funktionen. Das Programm mktemp aus den coreutils wird wohl intern (ohne es nachgeprüft zu haben) nicht mktemp() verwenden. Und in dessen manpage (Sektion 1 übrigens, nicht 3) steht:

Create a temporary file or directory, safely, and print its name.

(Hervorhebung von mir.)

[habakug]

Hallo!

OK, es ist keine "gute Idee [...] temporäre Dateien mit $$ in Verzeichnissen anzulegen in die noch andere Benutzer schreiben können". Ich füge allerdings hinzu, daß die (hypothetischen) Gefahren auch für "mktemp" zutreffen.
Für Paranoiker ist es sicher am besten niemals eine temporäre Datei zu verwenden. An zweiter Stelle sehe ich die Möglichkeit selbst einen Dateinamen zu basteln:

Code: Alles auswählen

user1:~$ umask 077
user1:~$ statusmeldung=$( od -An -N48 -x /dev/urandom |tr -d "\n ")
user1:~$ echo "sumpting" > $statusmeldung
user1:~$ ls -lisa $statusmeldung 
251707 4 -rw------- 1 user1 user1 5 Aug  1 15:43 7483f0b2a434013fc546db997b6adaf567e3f4a9e4362eb23f4b76efa33d85b1b7dbf12d7249cc111a381e065707e56a
user1:~$ umask 022

Gruß, habakug

[linuxCowboy]

Ich bin nochmal über den tmp-Generator gestolpert...

sequenziere bis zur doppelten maximalen PID:

Code: Alles auswählen

seq "$((ps a | awk '{ print $1 }' | sort -rn | head -1 | tr -d '\n'; echo " * 2") | bc)"

wird zu:

Code: Alles auswählen

ruler
12345678_112345678_212345678_312345678
seq $(expr `ps axo pid=|tail -1` \* 2) # 38

das '=' kann wegfallen:

Code: Alles auswählen

seq $(expr `ps axo pid|tail -1` \* 2) # 37

und wenn man davon ausgeht dass die PIDs nur steigen(?):

Code: Alles auswählen

seq $(expr `ps o pid|tail -1` \* 2) # 35

@habakug:
Das

Code: Alles auswählen

echo $(od -An -N48 -x /dev/urandom | tr -d "\n ")

als random-generator gefällt mir richtig gut!
Ich hantiere sonst immer mit $RANDOM

[goeb]

Ich füge allerdings hinzu, daß die (hypothetischen) Gefahren auch für "mktemp" zutreffen.

Nein, eben nicht. mktemp (das Programm) generiert einen zufälligen Dateinamen und versucht die Datei zu öffnen. Wenn das fehlschlägt, und das tut es wenn eine Datei oder ein Link mit dem gewählten Namen bereits existiert (wegen O_CREAT | O_EXCL, s. [1]), wird ein neuer Name erzeugt. Das ist aber eine atomare Operation, die Race Condition kann dabei nicht auftreten. (Man könnte maximal einen DOS-Angriff probieren, indem man alle möglichen Dateinamen die für das verwendete Template in Frage kommen belegt. Aber bei hinreichend großem zufälligen Anteil wird da wohl eher das Dateisystem nicht mitmachen. Womit man aber auch das Ziel erreicht hätte. Bleibt die Frage wie lang es dauern würde…)

[1]: http://sources.debian.net/src/coreutils ... l=205#L260

[Cae]

Off-topic:

Das

Code: Alles auswählen

echo $(od -An -N48 -x /dev/urandom | tr -d "\n ")

als random-generator gefällt mir richtig gut!
Ich hantiere sonst immer mit $RANDOM

Dann koennte dir auch

Code: Alles auswählen

$ tr -cd a-zA-Z0-9 </dev/urandom | head -c 20; echo
492GqcsSsI8msYscG1Rs
$ 

gefallen... Da kann man nach Bedarf auch mehr Zeichen zulassen wie z.B. 'a-zA-Z0-9!@#$'.

Gruss Cae

[linuxCowboy]

Dann koennte dir auch gefallen:

Code: Alles auswählen

$ tr -cd a-zA-Z0-9 </dev/urandom | head -c 20; echo

Ich bin begeistert!!!

tr mit complement und delete, man gibt den Bereich an den man haben will und speist aus einer Quelle die alles liefert. Dann schneidet man die gewünschte Menge ab. Das ist genial!

Ich habe mir gleich eine Shell-Function gezimmert:

Code: Alles auswählen

Frandgen ()
{
	local range='a-zA-Z0-9_' # default

	[ -z "$1" ] && echo "usage: $FUNCNAME char_count [char_range{$range}]" && return

	tr -cd "${2-$range}" </dev/urandom | head -c $1
	echo
}

und sie in meine Sammlung aufgenommen...

Das gibt den "Coreutils-Nutzungs-Award" der Woche!

[linuxCowboy]

Code: Alles auswählen

~# cat /tmp/testfile
cat: /tmp/testfile: Keine Berechtigung

Sollte root nicht immer Zugriff haben?!

In dem Fall eben nicht, sonst wäre die Änderung sinnlos...

Der Sache sollte man weiter auf den Grund gehen...

Es gibt den kernel parameter fs.protected_symlinks:

When set to "0", symlink following behavior is unrestricted.

When set to "1" symlinks are permitted to be followed only when outside
a sticky world-writable directory, or when the uid of the symlink and
follower match, or when the directory owner matches the symlink's owner.

Code: Alles auswählen

47 0 /tmp # ls -ln userfile 
lrwxrwxrwx 1 1000 1000 19 05.08. 2013 18:47:49 userfile -> /home/user/userfile
48 0 /tmp # cat userfile
cat: userfile: Permission denied
49 0 /tmp[1] # sysctl fs.protected_symlinks 
fs.protected_symlinks = 1
50 0 /tmp # sysctl -w fs.protected_symlinks=0
fs.protected_symlinks = 0
51 0 /tmp # cat userfile
3.2.0-4-486
52 0 /tmp # sysctl -w fs.protected_symlinks=1
fs.protected_symlinks = 1
53 0 /tmp # cat userfile
cat: userfile: Permission denied

root müßte bei aktiviertem Flag das Ziel direkt lesen:

Code: Alles auswählen

54 0 /tmp # cat userfile || cat `readlink userfile`
cat: userfile: Permission denied
3.2.0-4-486
55 0 /tmp # cat userfile 2>/dev/null || cat `readlink userfile`
3.2.0-4-486

Es gefällt mir nicht, mich als root einschränken zu lassen und ein "Permission denied" zu kriegen.

Wundert mich nicht, dass die Sache 16 Jahre gedauert hat!

[goeb]

Es gibt den kernel parameter fs.protected_symlinks:

Gut zu wissen. Laut [1] seit Kernel 3.6 dabei, also wahrscheinlich in den Debian-Kernel (Wheezy, 3.2) zurückportiert. Ich hab allerdings nen selbstgebauten Kernel (aus den Debian-Quellen) laufen, vielleicht ist das im Original-Debian-Kernel auch garnicht per default an (upstream ist es deaktiviert by default, s. [2]).

Code: Alles auswählen

54 0 /tmp # cat userfile || cat `readlink userfile`
cat: userfile: Permission denied
3.2.0-4-486
55 0 /tmp # cat userfile 2>/dev/null || cat `readlink userfile`
3.2.0-4-486

Wohl doch nicht.

...aber da würde doch kein Angreifer drauf kommen :lol:

Was? Worauf soll der Angreifer nicht kommen? Der Angreifer hat keine Kontrolle über die Befehle die root ausführt, er kann nur den Link anlegen. Und root kann das Ziel eben nicht einfach überschreiben.

[1] http://kernelnewbies.org/Linux_3.7
[2] http://git.kernel.org/cgit/linux/kernel ... 955edfd415

[rendegast]

(Zum off-topic)

$ tr -cd a-zA-Z0-9 </dev/urandom | head -c 20; echo
Ich bin begeistert!!!
tr mit complement und delete, man gibt den Bereich an den man haben will und speist aus einer Quelle die alles liefert. Dann schneidet man die gewünschte Menge ab. Das ist genial!
Ich habe mir gleich eine Shell-Function gezimmert:
....
und sie in meine Sammlung aufgenommen...

Code: Alles auswählen

$ pwgen 20 1
naiPohf0shohjanohGee 

Zur Güte von /dev/*random den haveged laufen lassen?

[linuxCowboy]

Code: Alles auswählen

$ pwgen 20 1
naiPohf0shohjanohGee 

pwgen ist ganz okay. Wie man es von einem spezialisierten C-Programm erwarten kann.

Aber nicht so cool wie das Shellscript!