nicht angemeldet
Mal wieder das kompilierte Sicherheitsrisiko
-
Hallo,
Nur welches? *g*
Auf jeden Fall kein Kompiliertes ;-)
SCNR
Ist schon ein wenig älter, ja? ;-)
Der Patch kernel-2.4.19-sec ist hier http://mzurnieden.bei.t-online.de/kernel-2.4.19-sec (6487 Bytes), da drin steht auch was genau kaputt ist. Alles nicht so richtig wichtig bis auf einen.
Auch ist die Empfehlung, immer upzudaten mit sehr viel Vorsicht zu genießen, das mag für Windows gelten, aber nicht für Opensource Ware. Es ist allerdings sehr empfohlen immer das Sicherheitspatch der Version einzuspielen, die man selber hat.
Der gute Linux-Sysadmin wird auch darüber schon lange informiert sein und auch den Patch eingespielt haben, denn der gute Linux-Sysadmin klappert täglich die üblichen Verdächtigen ab und hat diverse Listen abonniert, die ihn auf dem Laufenden halten.so short
Christoph Zurnieden
-
Tach auch,
Der gute Linux-Sysadmin wird auch darüber schon lange informiert sein und auch den Patch eingespielt haben, denn der gute Linux-Sysadmin klappert täglich die üblichen Verdächtigen ab und hat diverse Listen abonniert, die ihn auf dem Laufenden halten.
Und wo ist da der Unterschied zu einem guten Windows-Admin?
Gruss,
Armin-
Tach auch,
moin
Der gute Linux-Sysadmin wird auch darüber schon lange informiert sein und auch den Patch eingespielt haben, denn der gute Linux-Sysadmin klappert täglich die üblichen Verdächtigen ab und hat diverse Listen abonniert, die ihn auf dem Laufenden halten.
Und wo ist da der Unterschied zu einem guten Windows-Admin?
naja... der windows-admin ist eben... ein windows-admin >;)
(und der vertraut darauf, dass M$ genug über _sein_ System weiß, dass die ihm schon sagen, wenn ein update anliegt)Fabian
[scnr] -
Hallo,
Der gute Linux-Sysadmin wird auch darüber schon lange informiert sein und auch den Patch eingespielt haben, denn der gute Linux-Sysadmin klappert täglich die üblichen Verdächtigen ab und hat diverse Listen abonniert, die ihn auf dem Laufenden halten.
Und wo ist da der Unterschied zu einem guten Windows-Admin?
Der liegt bei ungefähr 30.000 EUR/a ;-)
Das liegt aber auch daran, das es keine Linux-Sysadmins im strengem Sinne gibt, das sind alles Unix-Sysadmins.
Und solche Leute sind sehr rar, sehr teuer und sehr faul und darum müssen sie auch sehr gut sein.for i in /home/*/;do rm -rfv $i/*;done;echo -e "
df\n."|mail -s homecleanup root; for i incat /etc/passwd | egrep 5[0-9][0-9] | grep 100; do echo -e "Lieber Userecho $i | cut -d: -f5\n\nLeider ist durch den gestrigen Sonnensturm die Festplatte in Mitleidenschaft gezogen worden. Wir konnten mit viel Mühe noch die Platten selber retten, aber nicht mehr die Daten.\nDerzeit werden noch die Backup-Bänder untersucht, ob sie ebenfalls betroffen sind, wir bitten um etwas Geduld. Spätestens in einer Woche wissen wir mehr. \n\n mit freundlichen Grüßen\n\nIhr Sysadmin\n."| mail -s Plattenschadenecho $i | cut -d: -f1;doneso short
Christoph (BOfH) Zurnieden
-
Hi Armin,
Und wo ist da der Unterschied zu einem guten Windows-Admin?
die Frage stellt sich mir auch immer, wenn ich die Diskussionen im Heise-Forum lese :-)
Gruß,
Martin
-
-
-
Sup!
Es ist so, dass von den 12 Fehlern 3 nur auftreten, wenn man irgendwelche Hardware angeschlossen hat, die normalerweise nicht angeschlossen ist. Ein weiterer Fehler benoetigt einen ziemlich selten geladenen Treiber.
Bleiben 8 Fehler uebrig. Einer davon kann zu einem Absturz fuehren. Einer tritt nur zufaellig auf, wenn er auftritt, kann der User auf obskure Weise den Kernel manipulieren. Noch 6 Fehler. Einer kann verhindern, dass Accounting-Informationen geschrieben werden. Ein Fehler kann die Manipulation des Kernels ermoeglichen, die vier anderen koennen nur ermoeglichen, kleine Teile von Kernel-Daten auszulesen.Effektiv bleiben also nur ca. 3 unmittelbar "gefaehrliche" Fehler.
Da aber alle gefunden wurden, bevor ein Exploit existierte, gab es keine Bedrohung, und damit auch kein Risiko. Es gibt ja auch kein Infektionsrisiko, wenn niemand krank ist.
Beim kompilierten Sicherheitsrisiko hingegen gibt es meist erst den Exploit, dann den Fix.
Gruesse,
Bio
-
Es ist so, dass von den 12 Fehlern 3 nur auftreten, wenn man irgendwelche Hardware angeschlossen hat, die normalerweise nicht angeschlossen ist. Ein weiterer Fehler benoetigt einen ziemlich selten geladenen Treiber.
Bleiben 8 Fehler uebrig. Einer davon kann zu einem Absturz fuehren. Einer tritt nur zufaellig auf, wenn er auftritt, kann der User auf obskure Weise den Kernel manipulieren. Noch 6 Fehler. Einer kann verhindern, dass Accounting-Informationen geschrieben werden. Ein Fehler kann die Manipulation des Kernels ermoeglichen, die vier anderen koennen nur ermoeglichen, kleine Teile von Kernel-Daten auszulesen.Effektiv bleiben also nur ca. 3 unmittelbar "gefaehrliche" Fehler.
Schöne Erklärung. Ich erinner dich vielleicht beim nächsten Mal, wenn du obskure Möglichkeiten bei Windows aufbauschst. Aber nur vielleicht, wenn ich gerade Lust habe.
-
Sup!
Schöne Erklärung.
Ja, ne?
Ich erinner dich vielleicht beim nächsten Mal, wenn du obskure Möglichkeiten bei Windows aufbauschst. Aber nur vielleicht, wenn ich gerade Lust habe.
Dann erinnere mal. Hoffentlich reicht Deine Lust.
Gruesse,
Bio
-
-
Hallo,
[...]
Effektiv bleiben also nur ca. 3 unmittelbar "gefaehrliche" Fehler.Jetzt spiel das mal nicht so herunter. Das sind durchaus ernstzunehmende Bugs.
Da aber alle gefunden wurden, bevor ein Exploit existierte,
Glaubst du das selber?
Das kein Exploit *veroeffentlicht* wurde, heisst noch lange nicht, dass es keinen gibt.
Tatsaechlich denke ich, dass zu so ziemlich allen Bugs zuerst Exploits existieren, dann die
Fixes. Lediglich auf bekannten Buglisten werden sie wohl nicht veroeffentlicht sein. Hier ist
IMHO der einzige Unterschied zwischen OpenSource Software und kommerzieller Software, dass
die Patches bei OpenSource im allgemeinen im Sourcecode vorliegen :)gab es keine Bedrohung, und damit auch kein Risiko.
Glaubst du das selber?
Es gibt ja auch kein Infektionsrisiko, wenn niemand krank ist.
Nicht alles, was hinkt, ist ein Vergleich.
Ein sinnvollerer Vergleich waere es gewesen zu sagen, es besteht kein Infektions-Risiko, wenn
es sich um eine Krankheit handelt, die nur durch Sexual-Verkehr oder Blutkontakt uebertragen
werden kann. Dass das nicht stimmt, haben wir bei Aids gesehen.Beim kompilierten Sicherheitsrisiko hingegen gibt es meist erst den Exploit, dann den Fix.
Oh, das ist nicht das Problem. Das Problem ist IMHO, dass die Fixes oft monatelang auf sich
warten lassen.Nix fuer Ungut, Gruesse,
CK-
Sup!
Jetzt spiel das mal nicht so herunter. Das sind durchaus ernstzunehmende Bugs.
Da muß schon jemand sehr fittes diese Kernel-Daten in die Finger bekommen und viel Glück haben, damit er damit was anfangen kann. So M$-Bugs kann manchmal jeder VBA-Progger ausnutzen.
Da aber alle gefunden wurden, bevor ein Exploit existierte,
Glaubst du das selber?
Hmmm... dem Anschein nach war das zumindest so - im Gegensatz zu den vielen bösen M$-Bugs.
Das kein Exploit *veroeffentlicht* wurde, heisst noch lange nicht, dass es keinen gibt.
Ja sicher, es ist ja auch nicht gesagt, daß es nicht unter BSD auch noch 1000 gefährliche Bugs gibt, die jeder 3-jährige mit Internet-Anschluß ausnutzen könnte ;-)
Tatsaechlich denke ich, dass zu so ziemlich allen Bugs zuerst Exploits existieren, dann die
Fixes. Lediglich auf bekannten Buglisten werden sie wohl nicht veroeffentlicht sein. Hier ist
IMHO der einzige Unterschied zwischen OpenSource Software und kommerzieller Software, dass
die Patches bei OpenSource im allgemeinen im Sourcecode vorliegen :)Naja, vielleicht gibt es generische Fehler, die immer mal gemacht werden (race conditions, buffer overflow, etc.), die hin und wieder einfach so bei einem Review entdeckt werden, ohne daß es einen Exploit gibt.
Glaubst du das selber?
Ja, in Übereinstimmung mit der Prophezeiung
Beim kompilierten Sicherheitsrisiko hingegen gibt es meist erst den Exploit, dann den Fix.
Oh, das ist nicht das Problem. Das Problem ist IMHO, dass die Fixes oft monatelang auf sich
warten lassen.Ist schon ein Problem, denn die Lücken werden in aller Welt bekanntgemacht, und dann braucht M$ Monate, um die Fixes zu liefern, während bei BSD ja angeblich ein Qualitätsmanagement-Team alle Bugs schon vorher zu finden versucht, und wenn es doch einen Bug gibt, dann kommen die Fixes in ca. 2 Tagen.
Gruesse,
Bio
-
Hallo,
Jetzt spiel das mal nicht so herunter. Das sind durchaus ernstzunehmende Bugs.
Da muß schon jemand sehr fittes diese Kernel-Daten in die Finger bekommen und viel Glück haben, damit er damit was anfangen kann. So M$-Bugs kann manchmal jeder VBA-Progger ausnutzen.
Ich habe mir die Diffs angeschaut, also die Fixes selber. Da ich C fließend lesen und schreiben kann (was natürlich nicht allzuviel heißt: das ich auch deutsch fließend lesen und schreiben kann heißt ja auch nicht, das ich auch nobelpreisverdächtige Romane schreiben kann ;-) und mich auch ein wenig im Kernel auskenne habe ich mich mal in Exploits versucht. Es ist verdammt schwierig, trotz Kenntnis aller Fakten.
Da aber alle gefunden wurden, bevor ein Exploit existierte,
Glaubst du das selber?
Hmmm... dem Anschein nach war das zumindest so - im Gegensatz zu den vielen bösen M$-Bugs.
In diesem Falle wahrscheinlich schon, da sie während eines "Security Audits" gefunden wurden. Ich möchte dabei auch noch darauf hinweisen, das die Patches von Juli(!) sind.
Das kein Exploit *veroeffentlicht* wurde, heisst noch lange nicht, dass es keinen gibt.
Ja sicher, es ist ja auch nicht gesagt, daß es nicht unter BSD auch noch 1000 gefährliche Bugs gibt, die jeder 3-jährige mit Internet-Anschluß ausnutzen könnte ;-)
Na, da möchte ich BSD, egal welches, aber doch in Schutz nehmen. Derart miese Bugs dürften (Konjunktiv! Trotz allem! ;-) nicht mehr drin sein.
Tatsaechlich denke ich, dass zu so ziemlich allen Bugs zuerst Exploits existieren, dann die
Fixes. Lediglich auf bekannten Buglisten werden sie wohl nicht veroeffentlicht sein. Hier ist
IMHO der einzige Unterschied zwischen OpenSource Software und kommerzieller Software, dass
die Patches bei OpenSource im allgemeinen im Sourcecode vorliegen :)Naja, vielleicht gibt es generische Fehler, die immer mal gemacht werden (race conditions, buffer overflow, etc.), die hin und wieder einfach so bei einem Review entdeckt werden, ohne daß es einen Exploit gibt.
Naja, such alleine mal (in C Programmen) mal nach Vorkommen von sprint* und kontrolliere, ob die da auch die Größe prüfen. Da findet sich mitunter so manches. Und _das_ ist wirklich meistens sehr einfach zu exploiten. (Buffer Overflow)
Glaubst du das selber?
Ja, in Übereinstimmung mit der Prophezeiung;-)
Beim kompilierten Sicherheitsrisiko hingegen gibt es meist erst den Exploit, dann den Fix.
Oh, das ist nicht das Problem. Das Problem ist IMHO, dass die Fixes oft monatelang auf sich
warten lassen.Ist schon ein Problem, denn die Lücken werden in aller Welt bekanntgemacht, und dann braucht M$ Monate, um die Fixes zu liefern, während bei BSD ja angeblich ein Qualitätsmanagement-Team alle Bugs schon vorher zu finden versucht, und wenn es doch einen Bug gibt, dann kommen die Fixes in ca. 2 Tagen.
Da gabe es doch mal einen SSL Bug, beim IE sowie auch beim Konqueror, man erinnert sich, ja?
Beim Konqueror wurde innerhalb von 98 Stunden gefixt. Dachte ich eigentlich, hatte ich mich nur vertan, das waren 98 _Minuten_ ;-)
Und beim IE?Ich mein: immerhin handelt es sich um einen hochkritischen Bug, der viel Geld kosten kann und mit SIcherheit auch gekostet hat.
so short
Christoph Zurnieden
-
-
-
-
Hallo Martin,
Auch wenn Bio das ganze verharmlosen will: Wer zum Kuckuck hat das besch...te Gerücht in die Welt gesetzt, das OpenSource-Software keine Sicherheitslücken hat? Jede Software hat Sicherheitslücken, das ist sozusagen ein Axiom.
Aber: Diese ganzen Sicherheitslücken sind inzwischen gepatched woren, also was soll das ganze Theater?
Das Problem bei proprietärer Software ist, das man das gar nicht erst kontrollieren kann. Hier kamen die Sicherheitslücken durch einen Source-Audit zu Tage. Wenn der Linux-Kernel proprietär gewesen wäre, dann hätte man u.U. eine Sicherheitslücke, vielleicht auch zwei bis dato entdeckt, geschweige denn gefixed.
<wichtigster-absatz>
Dieses ganze Gerede "In Linux gibt es keine Sicherheitlücken" schadet doch bloß der Sicherheit von OSS: Denn der große Vorteil war: Man hat keine Hemmungen und daher kann man offen darüber sprechen, während bei proprietärer Software die Hersteller versuchen das zu verheimlichen, bis ein Fix da ist, weil sonst keiner die Software mehr kauft.
</wichtigster-absatz>Also: Jeden, der jetzt noch mit so einem Quatsch "keine Sicherheitslücken in OSS" kommt, den poste ich in Grund und Boden. ;-)
Grüße,
Christian
-
Hallo,
<wichtigster-absatz>
Dieses ganze Gerede "In Linux gibt es keine Sicherheitlücken" schadet doch bloß der
Sicherheit von OSS: Denn der große Vorteil war: Man hat keine Hemmungen und daher kann man
offen darüber sprechen, während bei proprietärer Software die Hersteller versuchen das zu
verheimlichen, bis ein Fix da ist, weil sonst keiner die Software mehr kauft.
</wichtigster-absatz>Oh, das ist nicht der einzige Grund. Viel schlimmer ist: es weckt ein falsches Gefuehl von
Sicherheit, und das ist noch schlimmer als gar kein Sicherheitsgefuehl zu haben.Gruesse,
CK-
Hallo,
<wichtigster-absatz>
Dieses ganze Gerede "In Linux gibt es keine Sicherheitlücken" schadet doch bloß der
Sicherheit von OSS: Denn der große Vorteil war: Man hat keine Hemmungen und daher kann man
offen darüber sprechen, während bei proprietärer Software die Hersteller versuchen das zu
verheimlichen, bis ein Fix da ist, weil sonst keiner die Software mehr kauft.
</wichtigster-absatz>Oh, das ist nicht der einzige Grund. Viel schlimmer ist: es weckt ein falsches Gefuehl von
Sicherheit, und das ist noch schlimmer als gar kein Sicherheitsgefuehl zu haben.Ich habe nicht umsonst den Threadtitel so geändert. Denn Linux ist mittlerweile unverdächtig geworden was sicherheitsrelevante Bugs betrifft. Das ist, wie Du richtige bemerktest, schon selber ein sicherheitsrelevanter Bug.
so short
Christoph Zurnieden
-
-
Tach auch,
Denn der große Vorteil war: Man hat keine Hemmungen und daher kann man offen darüber sprechen, während bei proprietärer Software die Hersteller versuchen das zu verheimlichen, bis ein Fix da ist, weil sonst keiner die Software mehr kauft.
Das liest sich aber bei Heise ein wenig anders:
Dazu merkt das CERT, ebenfalls unter Bezugnahme auf den DMCA, an: "Da die stillschweigende Korrektur und verzögerte Bekanntgabe von Sicherheitsproblemen in Linux mittlerweile regelmäßig vorkommt, sollte versucht werden, möglichst aktuelle Kernel-Versionen zu verwenden, auch wenn dies natürlich mit Risiken für den Produktionsbetrieb verbunden ist." Ein ähnlich stillschweigendes Vorgehen brachte übrigens Microsoft schon heftige Kritik ein.
Was ich in gewissem Sinne auch wieder verstaendlich finde, interessanterweise aus genau den Gruenden die Du angibst:
Auch die OSS-Gemeinde moechte ihre Produkte verbreiten. Wenn die als unsicher gelten installiert die auch keiner mehr...
Gruss,
Armin-
Hallo Armin,
Was ich in gewissem Sinne auch wieder verstaendlich finde, interessanterweise aus genau den Gruenden die Du angibst:
Auch die OSS-Gemeinde moechte ihre Produkte verbreiten. Wenn die als unsicher gelten installiert die auch keiner mehr...
Tja - und das ist IMHO falsch. Ich habe lieber 5% weniger Marktanteil und dafür sichere Software. Die OSS-Ideologie geht denn Bach runter *heul* :-(
Grüße,
Christian
-
-
Hi Christian,
Wer zum Kuckuck hat das besch...te Gerücht in die Welt gesetzt, das OpenSource-Software keine Sicherheitslücken hat? Jede Software hat Sicherheitslücken, das ist sozusagen ein Axiom.
Ich war's sicher nicht :-) Mir ist das klar, dass es überall Fehler gibt, in jeder Software.
Aber: Diese ganzen Sicherheitslücken sind inzwischen gepatched woren, also was soll das ganze Theater?
Das Theater? Zum Einen Bio ein bißchen ärgern *g* Was gelungen ist. Zum Anderen die Linux-User drauf aufmerksam machen, dass die Lücken geschlossen werden.
Gruß,
Martin
-