|
Diese Diskussion wurde archiviert.
Es können keine neuen Kommentare abgegeben werden.
|
 |
|
|
|
|
|
|
|
Wer sich vor Schwachstellen in Software schuetzen will, soll den Stecker rausziehen. Den Stromstecker am Besten.
Auch Distributorenkernel sind nicht 100% sicher, aber was ist das schon?
Ist doch alles kein Problem. Solange die Luecken nach bekanntwerden zeitnah gestopft werden koennen wir doch alle zufrieden sein.
|
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Tuesday 11. July 2006, 14:48 MEW (#4)
|
|
|
|
|
Gegen Denial-Of-Service-Attacken hilft aber auch kein Steckerziehen. Das ist eher ein Paradoxon.
|
|
|
|
|
|
|
|
|
|
|
|
|
Nein, aber gegen Remote-Root, gegen lokale Root-Exploits, gegen Viren, Wuermer und Spam.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Wednesday 12. July 2006, 13:08 MEW (#22)
|
|
|
|
|
Dann lass Dir die Idee patentieren und werde reich.
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Tuesday 11. July 2006, 20:02 MEW (#12)
|
|
|
|
|
Der Herr Zwiebelfisch hat aber teilweise recht merkwürdige Ansichten:
'Adolf Hitler wurde spöttisch auch als Gröfaz bezeichnet, als "größter Feldherr aller Zeiten".
Allein aus diesem Grunde sollte man mit dem "größten Superlativ aller Zeiten" weniger leichtfertig und verschwenderisch umgehen.'
Muss ich das jetzt verstehen? Das man vermeintliches Nazi-Speak nicht nutzen sollte, sehe ich gerade noch ein. Aber irgendwo hört es auf. Kein Wunder das wir alle nur noch Denglisch reden, wenn jede deutsche Redewendung politisch inkorrekt ist. Meiner Meinung nach ist das sowieso eher aus dem Englischen übernommen "of all times" und bierernst ist es meist auch nicht gemeint. Schließlich weiss man nie, was die Zukunft bringt und ja "aller *bisherigen* Zeiten" ist auch gar nicht gemeint. Das ist ja der Witz.
|
|
|
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Tuesday 11. July 2006, 23:08 MEW (#14)
|
|
|
|
|
Kiddy Proof? Meint das, dass Leute ohne Programmierkenntnise nichts mit den Exploits anfangen können?
|
|
|
|
|
|
|
|
|
|
|
|
|
Der Kerl ist einfach zu gut. Er findet zu viele Bugs.
Er scheint lesen zu können und kennt sich in den Kernel-Neuerungen aus.
prctl(5):
PR_SET_DUMPABLE
(Since Linux 2.4) Set the state of the flag determining whether
core dumps are produced for this process upon delivery of a sig-
nal whose default behaviour is to produce a core dump. (Nor-
mally this flag is set for a process by default, but it is
cleared when a set-user-ID or set-group-ID program is executed
and also by various system calls that manipulate process UIDs
and GIDs). In kernels up to and including 2.6.12, arg2 must be
either 0 (process is not dumpable) or 1 (process is dumpable).
Since kernel 2.6.13, the value 2 is also permitted; this causes
any binary which normally would not be dumped to be dumped read-
able by root only. (See also the description of
/proc/sys/fs/suid_dumpable in proc(5).)
Ist offensichtlich fuer SUID/GUID-Programme gedacht.
proc(5):
/proc/sys/fs/suid_dumpable (since Linux 2.6.13)
The value in this file determines whether core dump files are
produced for set-user-ID or otherwise protected/tainted bina-
ries. Three different integer values can be specified:
...
2 ("suidsafe") Any binary which normally would not be dumped
(see "0" above) is dumped readable by root only. This allows
the user to remove the core dump file but not to read it. For
security reasons core dumps in this mode will not overwrite one
another or other files. This mode is appropriate when adminis-
trators are attempting to debug problems in a normal environ-
ment.
Allerdings wird nur einmal ein core dump pro Ort wo der core hinkommt geschrieben. Was die Anzahl der Moeglichkeiten einschraenkt.
Das ganze toent mehr nach BAD (Broken as designed) als nach schlechtem Code.
Inwiefern man dies zu einem Backdoor ausbauen kann ist nicht klar.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Tuesday 11. July 2006, 23:56 MEW (#16)
|
|
|
|
|
Was ist daran BAD? Du vergisst außerdem eins: Das sind manpages und kein Code. Niemand sagt, dass der Code das tut, was die manpage behauptet. Die Befürchtung ist wohl, dass man damit Dateien in /etc/ überschreiben kann entgegen der Behauptung der manpage.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Wednesday 12. July 2006, 00:10 MEW (#17)
|
|
|
|
|
Was ich noch vergessen habe: Es gibt jede Menge Dateien, die nicht existieren, aber ausgeführt werden, sobald sie jemand anlegt z.B. ~/.logout ~/.bash_logout, ~/.bash_profile etc. Man kann aber auch einen Schritt weitergehen und PATH entsprechend eine ausführbare Datei anlegen, sodass meinetwegen Dein modifiziertes sed anstatt das normale sed in /usr/bin aufgerufen wird. Wenn das auch nicht geht, legst Du eben ein Bilder an und wartest darauf, dass sich jemand die Bilder mit Xv ansieht.
Bedenke auch, es gibt immer gerichtete und ungerichtete Angriffe. Letztere sind für gescheite Anwender weniger gefährlich und das Risiko zufällig in die Falle zu tappen eher gering. Bei ersteren hat der Angreifer aber oft genug wissen über die Umgebung und Anwender, um einen maßgeschneiderten Exploit anzufertigen.
|
|
|
|
|
|
|
|
|
|
|
|
|
Und was hat das mit dem Thema zu tun?
Es ist klar, dass wenn Du in einen User-Account Einbrechen kannst, Dir mehr Moeglichkeiten zur Verfuegung stehen. Dies ist seit Mitte der 1970er
in der Literatur beschrieben und seit den fruehen 1980ern von den Unix-Admins an die User weitergegeben worden. Heute kommt es langsam bei Microsoft an.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Wednesday 12. July 2006, 21:57 MEW (#28)
|
|
|
|
|
Bugs werden ständig heruntergespielt. Wenn nicht von den Distributionen, dann von den Anwendern. Der Unterschied zwischen remote- und locally-exploitable ist ziemlich unbedeutend. Wenn es nicht um Deinen Heimrechner geht, dann sowieso.
Was das mit Microsoft zu tun hat, erschließt sich mir nicht ganz. Corel gehört zwar mittlerweile Microsoft, aber Corel Linux gibt es doch nicht mehr, oder?
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Wednesday 12. July 2006, 21:46 MEW (#27)
|
|
|
|
|
Ich glaube Du verstehst gar nicht das Problem hinter dem Feature. Ein Prozess der setuid() aufgerufen hat, wirft keinen coredump. Das betrifft nicht nur executables mit set[ug]id-bit. Die Idee ist natürlich, dass nur root dies aktivieren kann. Das ist allemal sinnvoller als manuell im Kernelcode herumzufummeln.
Vielleicht probierst Du einfach mal den offiziellen
Exploit aus:
http://www.securityfocus.com/archive/1/439869/30/0
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Thursday 13. July 2006, 11:57 MEW (#30)
|
|
|
|
|
"Offizieller Exploit"? Du bist echt witzig, doch. Das ist einfach irgendein Exploit, den irgendein leetes Script-Kiddy auf Bugtraq gepostet hat, mehr nicht.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Thursday 13. July 2006, 13:12 MEW (#31)
|
|
|
|
|
Hmm, Clown gefrühstückt? "offiziell" war doch ziemlich offensichtlich ein Scherz. An Deiner Reaktion merkt man aber, dass Du hier ins Mark getroffen wurdest. Danke für das Feedback.
Übrigens, "ich hab's mal ausprobiert und der Exploit hat nicht funktioniert" ist immer eine sehr dämliche Art sich in Sicherheit zu wiegen.
|
|
|
|
|
|
|
|
|
|
|
|
|
Tja, jetzt wissen wir, daß und wie man es exploiten kann und daß es vermutlich auch schon exploitet wurde.
--
There is no place like $HOME
|
|
|
|
|
|
|
|
|
|
|
|
|
Offenbar funktioniert es. Nur nicht mit dem geposteten Exploit.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Tuesday 11. July 2006, 14:42 MEW (#3)
|
|
|
|
|
Ohne kqueue oder epoll geht's heutzutage nunmal nicht mehr. Letzteres gibt es bei 2.4 nicht und ersteres schon mal gar nicht. Solange es keine virtualisierten Server mit NetBSD oder FreeBSD gibt, die preislich mit Linux VServern mithalten können, werde ich wohl oder übel Linux (vorzugsweise eben mit 2.6 Kernel) nutzen.
Bezüglich Sicherheitslücken sollte man sowieso besser den Ball flach halten. Was da an ungefixten
Bugs bei *jedem* größeren Projekt herumlungert ist selten feierlich. Dass Linux aufgrund seiner Größe
als auch Verbreitung statistisch gesehen anfälliger als FreeBSD oder NetBSD ist, dürfte jedem klar sein.
Ein älterer Kernel mag ausgereifter sein, andererseits sind potentielle Angreifer auch vertrauter damit und hatten länger Zeit nach Lücken zu suchen. Man sollte nicht so blauäugig sein und glauben, jede gefundene Lücke werde gemeldet. Es gibt ja nicht nur Weißmützchen sondern auch Schwarzhelmchen.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Tuesday 11. July 2006, 15:12 MEW (#5)
|
|
|
|
|
also ich hab suid_dumpable und SCTP im Kernel deaktiviert, denke den meisten anderen geht es ähnlich, von der Seite her ist es eh nicht so wild. Denke wer nur die Features nutzt die im 2.4er existierten (aber von sachen wie 0(1) scheduler und co profitiert ) wird mit dem 2.6er gut fahren, selbst wenn die Code Qualität so schlecht wäre wie alle behaupten. Ich hab allerdings eher das Gefühl das mitlerweile mehr Möglichkeiten exisiteren Fehler zu finden und auch die verschiedenen Distri Maintainer mehr machen, so das es halt nach mehr Bugs aussieht. 2.6 läuft hier seit Anfang an komplett stabil auf mehreren Rechnern, und nur mit Gewalt ( fast allyesconfig Kernel booten ) seh ich mal nen oops
|
|
|
|
|
|
|
|
|
|
|
|
|
Mir wurde eine Kiste gerootet, weil ein Bug in OpenSSH (jep, der von den OpenBSD-Leuten) nicht als Sicherheitskritisch deklariert wurde. Obwohls die OpenBSDler vermutlich genau wussten. Aber die Debianis haben sich dann gedacht "ah, nicht kritisch, also nicht upgraden, schon gar nicht weil neue major release". Voila.
*BSD ist also nicht besser. Und diejenigen die es fertigbringen bekannte Sicherheitslöcher nach einem Jahr noch nicht gestopft zu haben (Sun) oder zu einem Feature zu erklären (Microsoft) kommen schon grundsätzlich nicht in Frage.
--
"The more prohibitions there are, The poorer the people will be"
-- Lao Tse
|
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Tuesday 11. July 2006, 17:05 MEW (#7)
|
|
|
|
|
Na ja, OpenBSD rühmt sich auch nur als non-remote-exploitable-by-default, was wohl auch für die letzten paar Jahre stimmt. Sobald man sich gegen lokale Nutzer schützen muss, wird es schon sehr viel härter. Wenn Bugs nur als "DoS-Problem" beschrieben werden, obwohl sie schwerwiegender sind, ist das sicherlich fragwürdig. Andererseits werden Bugs auch auf Anwenderseite, wobei ich nicht nur Endbenutzer meine, immer wieder verhamlost. Wenn man beispielsweise über mpg123 Code einschleusen kann, ist das extrem bedenklich, wird aber gern als "harmlos" abgetan. In Verbindung mit dem Coredump-Bug hat man so aber Ruckzuck root-Rechte. Allerdings braucht man dafür nicht einmal unbedingt einen Bug. Es beispielweise die .bashrc zu manipulieren, sodass ein modifiziertes "su" aufgerufen wird.
Zumindest im Desktop-Bereich sind Unix-Systeme sowieso nur wirklich sicher, wenn die Benutzer wissen was sie tun. Leider wird besonders Linux gern als 1:1 Windows-Alternative "vermarktet" und damit Nutzer angelockt, die weder Unix-Grundlagen kennen noch lernen wollen (unterstelle ich einfach mal).
Gut es wird etwas OT, aber ich wollte nur sagen, dass man sich um Sicherheit *immer* aktiv kümmern muss.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Tuesday 11. July 2006, 19:33 MEW (#10)
|
|
|
|
|
Welcher Bug war denn das ?
War das ein local - oder remote exploitable Bug ?
|
|
|
|
|
|
|
|
|
|
|
|
|
Der mit ssh? remote-root. Und wie gesagt, der wurde gefixt, OpenBSD hatte natürlich auch sofort die neue Version, nur hielt man es nicht für nötig den Rest der Welt darauf hinzuweisen dass der Bug sicherheitkritisch sein könnte..
--
"The more prohibitions there are, The poorer the people will be"
-- Lao Tse
|
|
|
|
|
|
|
|
|
|
|
|
|
Debian hat den auch gefixt, nur leider in stable viel zu spaet :(
|
|
|
|
|
|
|
|
|
|
|
|
|
Glaub ich gerne.
Die hatten ja sowieso in ihrem Security-Team mal eine ziemlich große Lücke, in der einfach niemand für irgendwas Zeit hatte, weil das Team zu klein war. (Effektiv damals zwei Personen: Joey und skx)
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Saturday 15. July 2006, 11:35 MEW (#39)
|
|
|
|
|
Was ist die Alternative deiner Ansicht nach?
Meine Sympathie gilt den Microkernels. Bei komplexer Software kann man davon ausgehen, dass es in 1000 Codezeilen immer einige unentdeckte Bugs hat. Es führt also kein Weg daran vorbei, die Anzahl Codezeilen wieder zu reduzieren bzw. den sicherheitskritischen Teil möglichst klein und überschaubar zu halten.
Linux ist als Monolith quasi die Antithese dazu. Mit bekanntem Ergebnis.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Saturday 15. July 2006, 18:17 MEW (#40)
|
|
|
|
|
Ein Micro-Kernel würde aber auch stabile dokumentierte Schnittstellen bedeuten. Dagegen streuben sich die Linux-Entwickler ja, weil Hardware-Hersteller dann leicht Closed-Source-Treiber schreiben könnten.
Allerdings handelt es sich in diesem Fall nicht um einen "klassischen" Bug. Es ist weder ein Buffer-Overrun, noch ein Integer-Overflow, sondern einfach ein Typo oder Braino. Die Gefährlichkeit ist auch erst klar, wenn man sich die Konsequenzen auf einem höheren Level ansieht. Ich denke, ein Microkernel hätte hier auch nichts gebracht.
Ich vermute, in Zukunft wird Virtualisierung in der einen oder anderen Form stärker eingesetzt, um Benutzer bzw. Anwendungen gegeneinander abzuschotten. Aber gewisse Fehler werden auf Multi-User-Systemen immer weitreichende Konsquenzen haben.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Tuesday 11. July 2006, 18:31 MEW (#8)
|
|
|
|
|
Naja.. remote-root ist natürlich nichts schönes, nur dürfte ein grossteil der kisten im internet sctp-conntrack garnicht geladen haben und damit auch nicht davon betroffen sein.
Auf jeden fall sollte man sich halt auch über solche Dinge gedanken machen:
http://bulk.fefe.de/scalability/
|
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Tuesday 11. July 2006, 19:12 MEW (#9)
|
|
|
|
|
So schön der Benchmark auch ist, die Ergebnisse dürften mittlerweile ziemlich veraltet sein.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Tuesday 11. July 2006, 22:36 MEW (#13)
|
|
|
|
|
Könnte man diese Behauptung etwas näher ausführen? Ich für meinen Teil nutze arbeite schon seit längerer Zeit mit einer Workstation, die mit Kerneln der 2.6er Serie läuft.
Ich kenne mich nicht allzusehr mit Kernel Internals aus, aber als ziemlich intensiver Computeruser muss ich feststellen, dass dieser Kernel von angeblich schlechter Qualität jeden Tag aufs neue kleine Wunder erbringt.
Und solange Bugs offen diskutiert und schnell korrigiert werden habe ich eigentlich keine Probleme. Gibt es denn eine bessere Alternative?
|
|
|
|
|
|
|
|
|
|
|
|
|
Seit kurzem kann nun 2.6/ iptables auch IPsec brauchbar... aber VPN-GWs mit Kernel 2.4?
Die Frage ist, was man auf !Mainstreamarchitekturen Nutzen (alles, was nicht i386, amd64 bzw. ppc64 ist) will... anscheinend ist da der 2.6er seit einiger Zeit kaputt (nicht mal mehr kompilierbar fuer powerpc und einige andere). Jedenfalls bin ich mit dem NetBSD auf dem G3 nicht wirklich gluecklich, kenne aber keine richtige Alternative...
|
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Wednesday 12. July 2006, 13:10 MEW (#23)
|
|
|
|
|
Was fehlt Dir denn bei NetBSD?
|
|
|
|
|
|
|
|
|
|
|
|
|
laeuft das wo sich XBSD und YBSD bedienen jetzt schon unter "sonstige"?! :-(
- Hubert
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Hätte ich 9 Spalten im Poll wäre es wohl drin gewesen. Aber da der Einsender was mit FreeBSD schrieb, OpenBSD bei sich immer dick fett "SICHER" draufklatscht und ich die anderen BSDs (Dragonfly, Mir, PC, Go und was es noch alles gibt) auch nicht ausschließen wollte, mußte halt eines der drei großen BSDs dran glauben. Leicht isses mir nicht gefallen, das darfst Du mir glauben. Und bei 10 Spalten wäre MirBSD auch noch drin gelandet...
--
There is no place like $HOME
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Thursday 13. July 2006, 23:31 MEW (#35)
|
|
|
|
|
OpenBSD benutzen doch sowieso alle nur als Firewall. Die beiden großen Allround-BSDs sind ganz klar FreeBSD und NetBSD. Warum letzteres immer im Windschatten der anderen genannt wird, ist mir eigentlich unverständlich. Zwar will bei NetBSD niemand einen Hype, aber das quasitotschweigen von NetBSD hier und anderenorts kommt mir desöfteren schon etwas unfair vor.
Dragonfly, MirBSD und PC-BSD spielen in einer ganz anderen Liga und sind verhältnismäßig bedeutungslose (das soll kein Flame werden) Forks
mit klaren Prioritäten.
Du hättest ja auch z.B. das völlig unnötige Kuriosum GNU kFreeBSD/Debian rausschmeissen können. Oder die einzelnen BSDs einfach gar nicht aufzählen, was in diesem Kontext sowieso relativ unwichtig ist.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Friday 14. July 2006, 07:05 MEW (#36)
|
|
|
|
|
da muss ich dir zustimmen, vorallem wenn man sich mal ansieht wieviele für GNU kFreeBSD/Debian gevoted haben ... da es um kernel geht hätte es wohl genügt FreeBSD und kFreeBSD zusammenzufassen (wenn überhaupt).
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Friday 14. July 2006, 08:37 MEW (#37)
|
|
|
|
|
Dafür ist doch eine Umfrage da: Man weiß vorher nicht, wieviele wofür voten werden, weil man genau das wissen will. Jetzt wissen wir, daß die Symlink-Leser kaum Debian GNU/kFreeBSD benutzen wollen, auch wenn manche es benutzen. Vorher wußten wir das nicht.
|
|
|
|
|
|
