Selbstgeschriebenes Proggie - Sicherheitsluecke?
Hallo,
Ich habe hier ein paar Dateien (z.B. meine signature-Datei)
die ich gern in der Regel auf chattr +a setzen wuerde. Manchmal
will ich das dann aber wieder editieren und da ist ein 'su -'
dann doch nervig. Ich habe mir also ein kleines Proggie getipselt,
das soweit auch ganz zufriedenstellen tut und mit dem ein User bei
_seinen_ Dateien das append-only-flag an- und abschalten kann.
Problem ist: Das Proggie muss suid-root sein...
Und das wuerde ich gerne auf Risiken abklopfen lassen ;)
Ach so, sudo (selbst wenn man es auch chattr [+-]a einschraenken
koennte waere eine groesser Luecke:
# touch /root/test; chmod 440 /root/test
# lsattr /root/test
-------- /root/test
# su - user
$ sudo chattr +a /root/test
Password: <hier das _user_ passwort>
$ exit
# lsattr /root/test
-----a-- /root/test
Ach ja, Kompilieren mit
g++ -Wall -o toggle-a-attr toggle-a-attr.cc
und dann:
# chown root.users toggle-a-attr
# chmod 4750 toggle-a-attr
Das chown in dieser Form schrankt den Zugriff noch auf die Gruppe users
ein -- was ja nicht schaden kann ;)
Hier nun also mein Versuch:
/************************************************************
* toggle-a-attr.cc Toggles the append-only flag of files *
* (c)2000 David Haller
David Haller schrieb in 4,1K (154 Zeilen):
Ich habe hier ein paar Dateien (z.B. meine signature-Datei) die ich gern in der Regel auf chattr +a setzen wuerde. Manchmal
Wieso willst du an deine signature-Datei nur appenden koennen duerfen?
Problem ist: Das Proggie muss suid-root sein... Und das wuerde ich gerne auf Risiken abklopfen lassen ;)
Ich wuerde #! perl -Tw use strict; anfangen, dann mir ueber die Race-Problematik Gedanken machen: touch y # test ob mein file (ja). rm y, ln -s x y # chattr +a y (aber x ist nicht mein File) rm y; touch y # Nochmal test auf y (naja, kein +a, aber was war y... ?) ... da hilft vermutlich nichtmal ein chroot, wenn im gleichen Ast anderer Benutzer Files liegen (/var/spool/mail...). Vielleicht ein Test auf $HOME... aber nein, das kann der User ja faelschen, also euid --> /etc/passwd --> $HOME... Alles in allem unbefriedigend. -Wolfgang --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Hallo Wolfgang, Hab eigentlich schon nicht mehr mit nem Re: gerechnet... Danke! :) Und gleich am Anfang ein Hinweis auf die (verdammt gut passende) Sig *bg* On Don, 07 Dez 2000, Wolfgang Weisselberg wrote:
David Haller schrieb in 4,1K (154 Zeilen):
Ich habe hier ein paar Dateien (z.B. meine signature-Datei) die ich gern in der Regel auf chattr +a setzen wuerde. Manchmal
Wieso willst du an deine signature-Datei nur appenden koennen duerfen?
Als _User_ (s.u.) cat << EOF > signatures ... Ooooops statt cat << EOF >> signatures eingetipselt zu haben... Oder anderes in der Art (z.B. mit 'tee' statt 'tee -a'). Ist mir neulich mit meinem URLS-file passiert, war aber zum Glueck nix wichtiges drin, aber der Anlass das append_only Attribut zu setzen... Und dann vom staendigen su genervt zu sein... ;)
Problem ist: Das Proggie muss suid-root sein... Und das wuerde ich gerne auf Risiken abklopfen lassen ;)
Ich wuerde #! perl -Tw use strict; anfangen, dann mir ueber die Race-Problematik Gedanken machen:
?? Was hat das mit Perl zu tun? Kann Perl etwa die Rechte des FS umgehen!?! Und Race Problematik sagt mir (in dem Zusammenhang(!)) leider nix...
touch y # test ob mein file (ja). rm y, ln -s x y # chattr +a y (aber x ist nicht mein File)
Geht nicht! :)) dh@slarty[/4]:~ (1) $ touch x y dh@slarty[/4]:~ (0) $ ls -l x y -rw-r--r-- 1 dh users 0 Dec 7 07:28 x -rw-r--r-- 1 dh users 0 Dec 7 07:28 y dh@slarty[/4]:~ (0) $ lsattr x y -------- x -------- y dh@slarty[/4]:~ (0) $ rm y dh@slarty[/4]:~ (0) $ ln -s x y dh@slarty[/4]:~ (0) $ chattr +a y chattr: Operation not permitted while setting flags on y
rm y; touch y # Nochmal test auf y (naja, kein +a, aber was war y... ?)
Irrelevant (s.u.) dh@slarty[/4]:~ (0) $ rm y Entweder hab 'ich' hier die Rechte y zu loeschen oder eben nicht... dh@slarty[/4]:~ (0) $ touch y dh@slarty[/4]:~ (0) $ ls -l y -rw-r--r-- 1 dh users 0 Dec 7 07:30 y dh@slarty[/4]:~ (0) $ lsattr y -------- y
... da hilft vermutlich nichtmal ein chroot, wenn im gleichen Ast anderer Benutzer Files liegen (/var/spool/mail...).
Geht nicht! dh@slarty[/4]:~ (0) $ toggle-a-attr /var/spool/mail/<otheruser> toggle-a-attr Permission denied: /var/spool/mail/<otheruser> Scheint durch die Abfrage if ( uid != st.st_uid && uid != 0 ) erschlagen zu sein. Und dabei geb ich root/uid=0 sogar noch explizit die Rechte das a-flag zu aendern...
Vielleicht ein Test auf $HOME... aber nein, das kann der User ja faelschen, also euid --> /etc/passwd --> $HOME...
IMHO irrelevant[1]: dh@slarty[/4]:~ (0) $ toggle-a-attr /usr/bin/less toggle-a-attr Permission denied: /usr/bin/less Durch st_uid wird die _reale_ UID abgefragt und wenn die nicht passt => EACCESS... Die EUID wird ignoriert(!)... ;)
Alles in allem unbefriedigend.
Hmmm, mag trotz allem oben schon Gesagtem sein, aber mir geht's eigentlich nur um einen Ersatz von u - Password: <clickety-click> chattr [+-]a y exit Und _das_, scheint mir, scheint wie gewollt zu funktionieren... Andere Probleme (wie das angesprochene rm) sind mir ehrlich gesagt eher wurscht, da (AFAIK) ein rm bei passenden flags _immer_ geht, egal ob das Attribut +a nun durch root oder sonstwen gesetzt wurde oder nicht... root@slarty[/2]:~ (0) # chown root.root /home/dh/x root@slarty[/2]:~ (0) # chown root.root /home/dh/y dh@slarty[/4]:~ (255) $ rm x y rm: remove write-protected file `x'? y rm: remove write-protected file `y'? y Mal abgesehen davon das append_only ein eher "harmloses" Attribut zu sein scheint... Nett ist dabei: dh@slarty[/4]:~ (0) $ touch x dh@slarty[/4]:~ (0) $ toggle-a-attr x APPEND_ONLY flag set: x root@slarty[/2]:~ (0) # chown root.root /home/dh/x chown: /home/dh/x: Operation not permitted dh@slarty[/4]:~ (0) $ toggle-a-attr x APPEND_ONLY flag removed: x root@slarty[/2]:~ (1) # chown root.root /home/dh/x root@slarty[/2]:~ (0) # l -l /home/dh/x -rw-r--r-- 1 root root 0 Dec 7 07:59 /home/dh/x dh@slarty[/4]:~ (0) $ toggle-a-attr x toggle-a-attr Permission denied: x root@slarty[/2]:~ (0) # chown dh.users /home/dh/x dh@slarty[/4]:~ (13) $ toggle-a-attr x APPEND_ONLY flag set: x *g* Mich duenkt, toggle-a-attr ist 'sicherer' als chattr... (was ich auch erhoffte, da mit der code von chattr als Vorlage diente ;) root kann zwar mit chattr alles machen was mit chattr eben zu machen ist, aber dem User ermoeglicht es _nur_ das flag von eigenen Dateien zu aendern... Worum es mir also eigentlich geht sind evtl. root-Exploits (wg. dem suid-bit) die durch _meinen_ Code evtl. ermoeglicht werden... Weitere Kommentare bes. bzgl. Buffer-/Stack- und sonstigen 'Overflow's usw. sind ausdruecklich erwuenscht :) [1] less hab ich einfach so gewaehlt... ;) CU David, der sich auf konstruktive Kritik angewiesen fuehlt :) -- If you think, you're wrong, you might be right! --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
David Haller schrieb in 5,0K (178 Zeilen):
On Don, 07 Dez 2000, Wolfgang Weisselberg wrote:
David Haller schrieb in 4,1K (154 Zeilen):
Und gleich am Anfang ein Hinweis auf die (verdammt gut passende) Sig *bg*
Ja, die passt!
Wieso willst du an deine signature-Datei nur appenden koennen duerfen?
cat << EOF > signatures statt cat << EOF >> signatures eingetipselt zu haben...
app-sig << EOF where app-sig ein entsprechendes Scriptchen ist, z.B., ist einfacher.
Problem ist: Das Proggie muss suid-root sein... Und das wuerde ich gerne auf Risiken abklopfen lassen ;)
Ich wuerde #! perl -Tw use strict; anfangen, dann mir ueber die Race-Problematik Gedanken machen:
?? Was hat das mit Perl zu tun?
man perlrun --> -T man perlsec Deshalb perl (und suidperl) als wrapper. Allerdings gibt es in den aelteren Versionen einen Bug, der Root-Rechte vergeben kann; perl-5.005_03-182 von SuSE ist allerdings gefixed.
Kann Perl etwa die Rechte des FS umgehen!?!
Filesys-Ext2-0.08.tgz auf CPAN.org. Ein wrapper um lsattr/chattr.
Und Race Problematik sagt mir (in dem Zusammenhang(!)) leider nix...
Ok, du willst ja nicht, dass dein Programm die falschen Files 'chattr +a'ed oder 'chattr -a'ed. Oder? Also musst du testen, das machst du ja mit: fstat(fd, &st) und einem Test auf uid. *Spaeter* erst liest du die Flags des Files: ioctl (fd, EXT2_IOC_GETFLAGS, &flags) und NOCHMALS *spaeter* addierst du die Flags: flags &= ~EXT2_APPEND_FL und schreibst sie: ioctl (fd, EXT2_IOC_SETFLAGS, &f) Nun, bei genuegend Load und/uder einigen geschickten SIGSTOP/SIGCONT kann ich agieren... und zwar zwischen deinen atomarem Operationen. Die sind nach aussen eben: 1) fstat 2) EXT2_IOC_GETFLAGS 3) EXT2_IOC_SETFLAGS Wenn ich zwischen 1) und 2) auch nur sehr selten[2] ein rm meinfile; ln -s deinfile meinfile machen kann, dann toggelst du mir auf deinfile append-only. Wenn ich ein File: rw-rw-rw schreibt_mir_hier_rein (append-only) habe, dann ist das Malheur schon klar, oder? Schlimmer noch, wenn ich zwischen 2) und 3) handeln kann: Dann kann ich meinem File die gewuenschten attr's geben (nur append-only muss ich umdrehen) und in 3) schreibst du mir *beliebige* Attribute in deinfile! Dein Programm ist alles andere als sicher. Was ist mit einem +i auf dein /var/spool/mail/dein_username? Was ist mit einem +d auf alle deine Files?
touch y # test ob mein file (ja). rm y, ln -s x y # chattr +a y (aber x ist nicht mein File)
Geht nicht! :))
Aber ja, s.o. Muss natuerlich ein Script machen. Das nennt man Race Condition.
dh@slarty[/4]:~ (0) $ toggle-a-attr /usr/bin/less toggle-a-attr Permission denied: /usr/bin/less
Durch st_uid wird die _reale_ UID abgefragt und wenn die nicht passt => EACCESS... Die EUID wird ignoriert(!)... ;)
Nur die UID zum File passend. Das File aber kann wechsen :-)
eigentlich nur um einen Ersatz von
su - Password: <clickety-click> chattr [+-]a y exit
Und _das_, scheint mir, scheint wie gewollt zu funktionieren...
nicht jeder kann su. Jeder kann toggle-a-attr.
Andere Probleme (wie das angesprochene rm) sind mir ehrlich gesagt eher wurscht, da (AFAIK) ein rm bei passenden flags _immer_ geht, egal ob das Attribut +a nun durch root oder sonstwen gesetzt wurde oder nicht...
man chattr --> i
Mal abgesehen davon das append_only ein eher "harmloses" Attribut zu sein scheint...
... auch wenn man es entfernt?
*g* Mich duenkt, toggle-a-attr ist 'sicherer' als chattr... (was ich auch erhoffte, da mit der code von chattr als Vorlage diente ;)
nein. chattr braucht einen Admin. Der braucht keine File-Vertauschen-Tricks, um adminrechte zu bekommen, der kann auch einfach ein rm -rf / machen. Einfach so. User haben *keine* Adminrechte, von daher ist der Fall ein ganz anderer.
Worum es mir also eigentlich geht sind evtl. root-Exploits (wg. dem suid-bit) die durch _meinen_ Code evtl. ermoeglicht werden...
.o. Beliebige Attrs koennen auf beliebige Files gesetzt/entfernt werden. -Wolfgang [2] Was hindert ein Script, es einige Millionen Male zu probieren? --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Hallo Wolfgang, On Don, 07 Dez 2000, Wolfgang Weisselberg wrote:
David Haller schrieb in 5,0K (178 Zeilen):
On Don, 07 Dez 2000, Wolfgang Weisselberg wrote:
David Haller schrieb in 4,1K (154 Zeilen):
Und gleich am Anfang ein Hinweis auf die (verdammt gut passende) Sig *bg*
Ja, die passt!
Wieso willst du an deine signature-Datei nur appenden koennen duerfen?
cat << EOF > signatures statt cat << EOF >> signatures eingetipselt zu haben...
app-sig << EOF
where app-sig ein entsprechendes Scriptchen ist, z.B., ist einfacher.
Hab ich auch. Bzw. ein alias.
Problem ist: Das Proggie muss suid-root sein... Und das wuerde ich gerne auf Risiken abklopfen lassen ;)
Ich wuerde #! perl -Tw use strict; anfangen, dann mir ueber die Race-Problematik Gedanken machen:
?? Was hat das mit Perl zu tun?
man perlrun --> -T man perlsec
Deshalb perl (und suidperl) als wrapper.
Ah, so war das gemeint :)
Und Race Problematik sagt mir (in dem Zusammenhang(!)) leider nix...
Nun, bei genuegend Load und/uder einigen geschickten SIGSTOP/SIGCONT kann ich agieren... und zwar zwischen deinen atomarem Operationen. Die sind nach aussen eben: 1) fstat 2) EXT2_IOC_GETFLAGS 3) EXT2_IOC_SETFLAGS
Wenn ich zwischen 1) und 2) auch nur sehr selten[2] ein rm meinfile; ln -s deinfile meinfile machen kann, dann toggelst du mir auf deinfile append-only. Wenn ich ein File: rw-rw-rw schreibt_mir_hier_rein (append-only) habe, dann ist das Malheur schon klar, oder?
Ja. Glaub schon. Kann man die Operationen "zusammenfassen"? Nein oder?
Schlimmer noch, wenn ich zwischen 2) und 3) handeln kann: Dann kann ich meinem File die gewuenschten attr's geben (nur append-only muss ich umdrehen) und in 3) schreibst du mir *beliebige* Attribute in deinfile!
Naja, ausser i...
Dein Programm ist alles andere als sicher.
Ok.
Was ist mit einem +i auf dein /var/spool/mail/dein_username?
Wird nicht gehen, da ja 'meinfile' die entsprechenden Attribute haben muesste, und du kannst als nicht-root i eben auch bei 'meinfile' nicht setzen... und 'meinfile' liefert ja die Attribute die genommen werden.
nicht jeder kann su. Jeder kann toggle-a-attr.
Ok. Naja, ich werd's weiterverwenden, da ich der eine user und root in Personalunion bin.
nein. chattr braucht einen Admin.
Um a und i zu aendern... chattr wird als 755 root.root installiert.
Der braucht keine File-Vertauschen-Tricks, um adminrechte zu bekommen, der kann auch einfach ein rm -rf / machen. Einfach so. User haben *keine* Adminrechte, von daher ist der Fall ein ganz anderer.
Ack.
Worum es mir also eigentlich geht sind evtl. root-Exploits (wg. dem suid-bit) die durch _meinen_ Code evtl. ermoeglicht werden...
s.o. Beliebige Attrs koennen auf beliebige Files gesetzt/entfernt werden.
Naja, war ne gute Programmieruebung. Immerhin hab ich nix eingebaut, was es erlauben wuerde, beliebige Programme als root auszufuehren (oder doch? *g*)... Danke nochmal fuer dein 'Auseinandernehmen'... CU David -- 57: G-Punkt Abk. f. 'Graph. Benutzeroberfl.' (Peter Berlich nach Arbeiten von Matthias Bruestle und Stefan Nohl) --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
David Haller schrieb in 3,4K (126 Zeilen):
On Don, 07 Dez 2000, Wolfgang Weisselberg wrote:
David Haller schrieb in 5,0K (178 Zeilen):
atomarem Operationen. Die sind nach aussen eben: 1) fstat 2) EXT2_IOC_GETFLAGS 3) EXT2_IOC_SETFLAGS
Ja. Glaub schon. Kann man die Operationen "zusammenfassen"? Nein oder?
Nein, nicht so einfach. Mit locking & co koennte es allerdings vielleicht gehen.
Schlimmer noch, wenn ich zwischen 2) und 3) handeln kann: Dann kann ich meinem File die gewuenschten attr's geben (nur append-only muss ich umdrehen) und in 3) schreibst du mir *beliebige* Attribute in deinfile!
Naja, ausser i...
Doch, wenn nur ein File +i ist: MEIN file --> 1) --> Link auf +i-File --> 2) --> Link/file. welches jetzt +i gesetzt bekommt. Loeschen von -i ist natuerlich trivial :-)
Was ist mit einem +i auf dein /var/spool/mail/dein_username?
Wird nicht gehen, da ja 'meinfile' die entsprechenden Attribute haben muesste, und du kannst als nicht-root i eben auch bei 'meinfile' nicht setzen... und 'meinfile' liefert ja die Attribute die genommen werden.
.o.
Naja, war ne gute Programmieruebung. Immerhin hab ich nix eingebaut, was es erlauben wuerde, beliebige Programme als root auszufuehren (oder doch? *g*)...
Weiss ich noch nicht. :-) -Wolfgang --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
participants (2)
-
david@dhaller.de
-
weissel@netcologne.de