Lücke im FreeBSD Updateprozess (auch Linux betroffen?)

Smalltalk
Antworten
Benutzeravatar
stollenreiter
Beiträge: 402
Registriert: 10.08.2004 16:30:47
Wohnort: Bremen

Lücke im FreeBSD Updateprozess (auch Linux betroffen?)

Beitrag von stollenreiter » 09.08.2016 09:52:38

Moin.

Ich habe das mal hier in Smalltalk reingesetzt, weil es ja noch nicht ganz klar ist, ob es auch Linux betrifft.

http://www.golem.de/news/anonymes-dokum ... 1-rss.html

Wäre natürlich ziemlich übel, sollte der Updateprozess auch bei Debian betroffen sein.
Gruß Stollenreiter
wat mutt, dat mutt
Mein Jakobsweg heißt Darb al-Arba'in

Benutzeravatar
Meillo
Moderator
Beiträge: 8782
Registriert: 21.06.2005 14:55:06
Wohnort: Balmora
Kontaktdaten:

Re: Lücke im FreeBSD Updateprozess (auch Linux betroffen?)

Beitrag von Meillo » 09.08.2016 10:17:20

Ich habe in das Dokument nur kurz reingelesen. Da ich mich mit diesem Themenkomplex wenig auskenne, kann ich keine Aussage zum Problem als Ganzes machen, aber dies hier ist mir ins Auge gestochen:
https://gist.github.com/anonymous/e48209b03f1dd9625a992717e7b89c4f hat geschrieben: The problem is that ${F} expands to a file hash without any .gz suffix. As
documented in the gunzip(1) manual page, gunzip(1) will first try opening the
file snap/${F}. Failing that, it will automatically append a suffix and try
opening the file snap/${F}.gz.
Da faellt uns die Bequemlichkeit, die man den Usern bieten wollte (weil das Programm selber denkt statt genau das zu tun was der User ihm sagt), in den Ruecken. Man kann sich darueber kaum beklagen, weil das eben ein (hoffentlich bewusst) getroffener Kompromiss war, als man gunzip(1) angewiesen hat auch noch andere Dateien zu probieren, einfach aus einer Vermutung heraus. Jetzt hat man den Salat. Man wollte es ja so haben. (Die gleiche Art von Problem ist mir schonmal begegnet: http://marmaro.de/lue/txt/2015-05-31.txt )

Klar muss man das Problem loesen, aber man sollte dabei auch lernen, dass solche Designentscheidungen immer wieder zu solchen Problemen fuehren ... die man nicht haette wenn man es dem User nicht bequem machen wollen wuerde. Man oeffnet damit eben die Tuer fuer eine Menge Probleme, mit denen man spaeter zu kaempfen hat ... wie dieser Fall zeigt.

(Das ist aber nur ein kleiner Aspekt des beschriebenen Gesamtproblems, wie mir scheint.)
Use ed once in a while!

Benutzeravatar
hikaru
Moderator
Beiträge: 13559
Registriert: 09.04.2008 12:48:59

Re: Lücke im FreeBSD Updateprozess (auch Linux betroffen?)

Beitrag von hikaru » 09.08.2016 11:31:08

Meillo hat geschrieben:(Die gleiche Art von Problem ist mir schonmal begegnet: http://marmaro.de/lue/txt/2015-05-31.txt )
Im Licht des BSD-Problems würde ich es als Sicherheitslücke betrachten, wenn ein Programm selbstständig andere Dateien öffnet, als vom User gewünscht.
Ich müsste es nochmal überdenken, aber spontan würde ich sagen, das rechtfertigt einen "grave"-Bugreport ("introduces a security hole allowing access to the accounts of users who use the package").

Die potenziellen Kreise die das zieht (xpdf ist vermutlich nicht das einzige Programm, das sich so "intelligent" verhält) verstärken einerseits meine spontane Einschätzung, erzeugen beimir aber auch das Gefühl, dass der Umfang dieses "Features" viel zu groß ist, als dass ich ihn einschätzen könnte.

Benutzeravatar
catdog2
Beiträge: 5352
Registriert: 24.06.2006 16:50:03
Lizenz eigener Beiträge: MIT Lizenz

Re: Lücke im FreeBSD Updateprozess (auch Linux betroffen?)

Beitrag von catdog2 » 12.08.2016 09:30:24

Klar muss man das Problem loesen, aber man sollte dabei auch lernen, dass solche Designentscheidungen immer wieder zu solchen Problemen fuehren ... die man nicht haette wenn man es dem User nicht bequem machen wollen wuerde. Man oeffnet damit eben die Tuer fuer eine Menge Probleme, mit denen man spaeter zu kaempfen hat ... wie dieser Fall zeigt.
Man muss eben auch wissen welches tool man für was verwendet. Shells an sich und Programme die sich da einfügen haben unglaublich viel fuzziness eingebaut weil sie für interaktive Nutzung und kleinere, schnell gebastelte Automatisierungen gedacht sind. Sie sollen ohne großen Aufwand das liefern was der Nutzer vmtl wollte. Spätestens wenn man irgendwas auch nur ein bisschen Sicherheitskritisches schreibt fällt einem so eine Sprache/Umgebung auf die Füße weil kaum jemand überblickt an welchen Stellen einem irgendeine Bequemlichkeitsmagie in die Suppe spuckt.
Unix is user-friendly; it's just picky about who its friends are.

Benutzeravatar
hikaru
Moderator
Beiträge: 13559
Registriert: 09.04.2008 12:48:59

Re: Lücke im FreeBSD Updateprozess (auch Linux betroffen?)

Beitrag von hikaru » 12.08.2016 11:07:05

catdog2 hat geschrieben:Shells an sich und Programme die sich da einfügen haben unglaublich viel fuzziness eingebaut weil sie für interaktive Nutzung und kleinere, schnell gebastelte Automatisierungen gedacht sind. Sie sollen ohne großen Aufwand das liefern was der Nutzer vmtl wollte.
Ich halte das für einen Fehler. Gerade Shells und Programme die darauf laufen sollten nicht das tun. Sie sollten nicht das liefern, was der Nutzer vemutlch wollte, sondern das was der Nutzer definitiv befiehlt. Wenn er sich nicht klar ausdrücken kann, dann ist das seine eigene Schuld.
Diese Fuzzyness-Geschichte läuft irgendwie der Unix-Philosophie zuwider (mache eine Sache und mache sie gut). Wer Fuzzyness auf der Shell will, der kann sich ja irgendein makemefuzzy-Programm in die Pipe hängen.

Benutzeravatar
Meillo
Moderator
Beiträge: 8782
Registriert: 21.06.2005 14:55:06
Wohnort: Balmora
Kontaktdaten:

Re: Lücke im FreeBSD Updateprozess (auch Linux betroffen?)

Beitrag von Meillo » 12.08.2016 11:31:31

Fuer mich ist die Kernfrage: Kann der User verstehen was passiert oder vertraut er der Maschine, dass schon das richtige passieren wird? Wenn er es verstehen soll, dann darf die Gesamtkomplexitaet einen bestimmten Grad nicht uebersteigen, weil sich ein Mensch nur soundsoviel merken kann. Und wichtig ist hierbei, dass mit dem User ebenso der Programmierer gemeint ist, weil wenn der das Gesamtsystem nicht mehr versteht (Stichwort auch ``leaky abstractions''), dann passiert es, dass er Sicherheitsprobleme einbaut, weil er nicht mehr alle Folgen im Blick hatte (d.h. haben kann).

Darum: Je klarer ist, was passiert, desto eher ist der User/Programmierer sich dessen bewusst und desto eher schreibt er korrekte und damit sichere Software.


Ich verstehe, die Argumentation von catdog2, aber sie verhindert leider ein groses Potenzial, das man andernfalls nutzen koennte: Naemlich die Austauschbarkeit von Mensch-Computer- und Computer-Computer-Kommunikation. Wann immer Interfaces nur fuer Menschen oder nur fuer Computer gedacht/gemacht sind, beschneiden wir die moegliche Effektivitaet. Das geht in die Richtung, die hikaru anspricht, mit der Unix Philosphie.
Use ed once in a while!

Antworten