https://www.n-tv.de/wirtschaft/Riesige-Sicherheitsluecke-in-Linux-Betriebssystem-entdeckt-article24853309.html Heute gelesen ... Unfug oder muss man sich Sorgen machen?
:
Gesperrt durch Moderator
Herbert Z. schrieb: > muss man sich Sorgen machen? Wenn man Zeit für so etwas hat (und nichts Besseres zu tun)…
"Nun kommen auf die Systemadministratoren Hausaufgaben zu." Aber nur für die, die ihre Hausaufgaben nicht gemacht haben.
Hier gehts weiter: Beitrag "CVE-2024-3094: Backdoor in Linux Tool XZ" Alles, was auf Debian 'Stable' beruht, ist nicht betroffen. Also Devuan und auch Ubuntu.
Hab mich schon gefragt, was die Mainstreammedien bar jeder Ahnung von der Materie aus der Sache machen würden. Das Ergebnis war einigermaßen vorhersehbar – incl. der Suggestion, dass es ein Linuxproblem ansich wäre. Traurige Sache, aber was willst machen? Allerdings zeigt das mal wieder, auf welchem Niveau diese Läden so sind. Sollte man sich vor Augen halten, wenn man dort irgendwelche Meldungen über Sachen sieht, mit denen man sich nicht auskennt. Manche Leute glauben das ja … Matthias S. schrieb: > Also Devuan > und auch Ubuntu. Devuan war eh nicht betroffen, da sie den sshd nicht für systemd gepatched haben.
:
Bearbeitet durch User
Jack V. schrieb: > Sollte man sich vor Augen halten, wenn man dort irgendwelche Meldungen > über Sachen sieht, mit denen man sich nicht auskennt. Manche Leute > glauben das ja … Wie mit der Secure Boot Geschichte... Gleiche Panikmache. Meine Rechner / Server laufen alle auf Debian stable... Aber wie gefährlich wäre diese Lücke tatsächlich im realen Alltag?!
Rene K. schrieb: > Aber wie gefährlich wäre diese Lücke tatsächlich im realen Alltag?! Das kommt darauf an, welche Inhalte auf dem Rechner abgegrast werden koennen. Viele ph.com Videos, wenig gefaehrlich. Viele Daten ueber Personen und Firmenentwicklungen, deutlich gefaehrlicher, ...
Rene K. schrieb: > Aber wie > gefährlich wäre diese Lücke tatsächlich im realen Alltag? Keine Lücke, sondern eine handfeste Backdoor wäre es geworden. Die hätte genau von dem ausgenutzt werden können, der sie vor Jahren in Auftrag gegeben hat. Im realen Alltag hätte der Aufraggeber nach dem Release des nächsten Debians Zugriff auf alle dann aktuellen Debian-Server, sowie auf Server mit darauf basierenden Systemen und systemd (weswegen Devuan hier rausfällt) haben können, auf denen ein sshd von außen erreichbar läuft. Meine persönliche Einschätzung: eine solche Lücke wird nicht verbrannt, indem wild irgendwelche Server aufgemacht und Daten rausgetragen werden.
:
Bearbeitet durch User
Irgendwie bereitet es mir ja Genugtuung, das ich systemd abgelehnt habe, als es bei Debian zur Pflicht wurde und ich mit dem Server deswegen auf Devuan gewechselt bin. Aber sshd (oder telnetd, Gott bewahre) sollte man auch nicht laufen lassen, wenn man es nicht unbedingt braucht.
Matthias S. schrieb: > Irgendwie bereitet es mir ja Genugtuung, das ich systemd abgelehnt habe, > als es bei Debian zur Pflicht wurde und ich mit dem Server deswegen auf > Devuan gewechselt bin. Siehst du dann vielleicht anders, wenn dir die Kisten mal aufgemacht werden, weil du ohne systemd einige der aktuellen Sicherheitsmechanismen von Linux nicht nutzen kannst. Allerdings: systemd selbst ist hier nichts anzulasten – wem gegenüber empfindest du diese Genugtuung eigentlich?
Jack V. schrieb: > wem gegenüber > empfindest du diese Genugtuung eigentlich? Natürlich gegenüber 'Jia Tian' oder wie der Typ sich nennt.
Hallo Rene K. Rene K. schrieb: > Meine Rechner / Server laufen alle auf Debian stable... Aber wie > gefährlich wäre diese Lücke tatsächlich im realen Alltag?! Etwas gefährlicher als jemand, der "Testing" bzw. "Unstable" für kritischen Kram einsetzt. ;O) Genau dafür ist sind ja unstable und testing da, damit sowas auffällt, bevor es zu "stable" wird. Die Sicherheitsupdates laufen übrigens schon seit gut einer Woche. ;O) Ich habe zu Ostern ein Uraltlaptop mit einem Debian-Testing aufgesetzt, und da war der Patch schon drin. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
:
Bearbeitet durch User
Hadmut F. schrieb: > https://www.danisch.de/blog/[…] → „Wer mal gucken will: Auf einem Linux-System ldd /usr/sbin/sshd aufrufen, da taucht liblzma.so auf […] Und hier haben wir nun den Vorfall, dass einfach irgendjemand, jemand, den keine Sau kennt und überprüft hat, ob es den überhaupt gibt, ohne Historie, mit Phantasienamen einfach auftauchen und eine Backdoor in eine Programmbibliothek drücken kann, mit der er – wenn das nicht rein zufällig jemand entdeckt hätte – alle Linux-Server dieser Welt (Windows ausnahmsweise mal nicht, aber besser ist das da auch nicht) kompromittiert hätte.“ … na, der schreibt ja auch einen ganz schönen Bullshit zusammen …
:
Bearbeitet durch User
Es scheint eine richtige Katastrophe zu sein, nicht so stark für Desktopanwendungen daheim, sondern für die professionelle IT- Infrastruktur wo Linux eben dominant ist. Das haben Profis eingefädelt die einen politischen Auftraggeber haben. China oder Russland fallen mir zuerst ein. War schon richtig, zb. den Chinesen das 5G Netz nicht zu überlassen. Es kommen sehr schwierige Zeiten auf die Vernetzung dieser Welt zu.
:
Bearbeitet durch User
Hallo Jack. Jack V. schrieb: > Siehst du dann vielleicht anders, wenn dir die Kisten mal aufgemacht > werden, weil du ohne systemd einige der aktuellen Sicherheitsmechanismen > von Linux nicht nutzen kannst. > > Allerdings: systemd selbst ist hier nichts anzulasten Was ich vor allem sehe, ist, das eine gewisse Heterogenität in den OS von Vorteil ist. Das mag lästig sein, aber an genau solchen Stellen kommen oft Angriffe zum stolpern, weil gut gesicherte Systeme brauchen schon sehr spezialisierte Angriffsmethoden, die eine große Chance haben, beim Nachbarsystem, das anders aufgebaut ist, schon nicht mehr zu funktionieren. IT-Sicherheit lebt also auch von dem Durcheinander von Windows, Apple, BSD, den diversen Linux Distributionen, Unix ec. Ist wie in der Biologie: Genetische Diversität schützt dageben, das ein Erreger alles ausrottet. ;O) Bei allem Hickhack für und gegen systemd: Es ist gut, das es verschiedene Systeme gibt. SystemD, SysVinit, Upstart ec. Auch wenn das eine "besser" sein sollte als das andere, aus welchen Gründen auch immer, es ist wichtig, dass es sie alle gibt. Mittlerweile scheinen auch die Personen hinter den Programmen anfälliger für "soziales Hacken" zu sein als die Programme selber......das gilt aber dann auch für alle OS, Windows, Apple, BSD, den diversen Linux Distributionen, Unix ec. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
:
Bearbeitet durch User
Jack V. schrieb: > … na, der schreibt ja auch einen ganz schönen Bullshit zusammen … Die englischsprachigen Blogs als Quelle weisen auf so ein Vorgehen hin, auch wenn Dir das nicht gefaellt.
Herbert Z. schrieb: > sondern für die professionelle IT- > Infrastruktur > wo Linux eben dominant ist. Peinlich finde ich das eher für die Herrschaften bei SuSE (ok, das benutzt eh niemand - hoffe ich zumindest) und bei IBM/Redhat, die ja vor allem Server im Auge haben. Die konservative Debian Gemeinde hat Recht behalten und die angeblichen Spezialisten bei Redhat habens nicht gemerkt. Bei ucLinux, bei dem ich damals mal beigetragen habe, kenne ich Patches übrigens als DIFF, wo eine Manipulation schnell aufgefallen wäre. Aber der Maintainer von XZ war wohl völlig überlastet und dazu noch genervt von den dauernden Forderungen der Ghost Accounts.
:
Bearbeitet durch User
Bernd W. schrieb: > Was ich vor allem sehe, ist, das eine gewisse Heterogenität in den OS > von Vorteil ist. Das mag lästig sein, aber an genau solchen Stellen > kommen oft Angriffe zum stolpern, weil gut gesicherte Systeme brauchen > schon sehr spezialisierte Angriffsmethoden, die eine große Chance haben, > beim Nachbarsystem, das anders aufgebaut ist, schon nicht mehr zu > funktionieren. > > IT-Sicherheit lebt also auch von dem Durcheinander von Windows, Apple, > BSD, den diversen Linux Distributionen, Unix ec. Ist wie in der > Biologie: Genetische Diversität schützt dageben, das ein Erreger alles > ausrottet. ;O) Jein. Heterogenität mag degegen helfen, dass die gleiche Lücke alle Systeme kompromittiert. Aber prinzipiell sind homogene Umgebung leichter sauber zu halten (weniger Wartungsaufwand, mehr Möglichkeiten, Ausreißer zu erkennen). Und immer dran denken, der Angreifer muss nur ein System knacken (und kann sich dann von dort die anderen Systeme angreifen), während du bei der Abwehr alle Lücken aller eingesetzten Systeme finden und schließen musst.
Dieter D. schrieb: > Die englischsprachigen Blogs als Quelle weisen auf so ein Vorgehen hin, > auch wenn Dir das nicht gefaellt. Nein. Nichts von dem, was ich zitiert habe, steht in seriösen Quellen. Lass es mich zeigen: Seine Behauptung: > → „Wer mal gucken will: Auf einem Linux-System ldd /usr/sbin/sshd > aufrufen, da taucht liblzma.so auf > […]“ Realität auf den meisten meiner Maschinen:
1 | user@host ~ % ldd /usr/bin/sshd | grep liblzma |
2 | user@host ~ % |
Entsprechend kann der zweite Teil des Zitierten auch nicht wahr sein, es ist also Bullshit. Auch, wenn dir das nicht gefällt – warum auch immer.
Jack V. schrieb: > Hadmut F. schrieb: >> https://www.danisch.de/blog/[…] > [...] > … na, der schreibt ja auch einen ganz schönen Bullshit zusammen … Verglichen mit dem Unsinn, den dieser Mensch schreibt, finde ich den Artikel bei n-tv sogar noch richtig seriös und informativ.
Jack V. schrieb: > Realität auf den meisten meiner Maschinen:user@host ~ > % ldd /usr/bin/sshd | grep liblzma > user@host ~ % Liegt ja normalerweise auch in /usr/sbin. Und damit kommt bei mir auf allen Systemen, die ich getestet habe, sowas wie das raus: liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f0435bf8000) Vielleicht ist die Lib ja bei dir statisch gelinkt, was dich aber vor der Lücke auch nicht schützt. Ganz im Gegenteil.
Ich muss gestehen, das ich einigermaßen verblüfft bin. Wie viele Firmen da draußen setzen von außen erreichbare wichtige/kritische Systeme ein, ohne ein vernünftig konfiguriertes Sicherheitsmodell (MAC) etabliert zu haben? Ist ja anscheinend ein Tollhaus! Oder sagt man jetzt Irrenhaus?
Rolf M. schrieb: > Liegt ja normalerweise auch in /usr/sbin. Und damit kommt bei mir auf > allen Systemen, die ich getestet habe, sowas wie das raus: > […] /usr/sbin ist ein Link:
1 | user@host ~ % stat /usr/sbin |
2 | Datei: /usr/sbin -> bin |
3 | Größe: 3 Blöcke: 0 EA Block: 4096 symbolische Verknüpfung |
Wenn sshd nicht an der Stelle gewesen wäre, hätte die Ausgabe auch in etwa so ausgesehen:
1 | user@host ~ % ldd /bin/some_nonexistent_file | grep liblzma |
2 | ldd: /bin/some_nonexistent_file: Datei oder Verzeichnis nicht gefunden |
Rolf M. schrieb: > Vielleicht ist die Lib ja bei dir statisch gelinkt, was dich aber vor > der Lücke auch nicht schützt. Ganz im Gegenteil. Nicht jede Distribution hat den sshd für systemd-notify so gepatched, dass es gegen die Lib gelinkt wird. Denn genau das ist die Stelle, an der die Lib dort reinkommt, sshd vom Upstream bindet die nicht ein. Auch und erst recht nicht statisch.
:
Bearbeitet durch User
Bernd W. schrieb: > Etwas gefährlicher als jemand, der "Testing" bzw. "Unstable" für > kritischen Kram einsetzt. ;O) Nicht ganz. Wenn das nicht zufällig gefunden wird wandert das nach stable und bald hat das jeder linux server drauf.
Hadmut F. schrieb: > Wenn das nicht zufällig gefunden wird wandert das nach stable und bald > hat das jeder linux server drauf. Meine Güte, nun verbreite den Bullshit doch nicht auch noch weiter. Es gibt nicht nur Debian.
:
Bearbeitet durch User
Jack V. schrieb: > Rolf M. schrieb: >> Vielleicht ist die Lib ja bei dir statisch gelinkt, was dich aber vor >> der Lücke auch nicht schützt. Ganz im Gegenteil. > > Nicht jede Distribution hat den sshd für systemd-notify so gepatched, > dass es gegen die Lib gelinkt wird. Denn genau das ist die Stelle, an > der die Lib dort reinkommt, sshd vom Upstream bindet die nicht ein. Auch > und erst recht nicht statisch. Ok, nicht alle. Aber systemd ist ja durchaus weit verbreitet. Ich würde vermuten, mehr als upstart und SysV-Init zusammen. Daher habe ich so meine Zweifel, dass die Systeme, auf denen du geschaut has, repräsentativ sind. Jack V. schrieb: > … na, der schreibt ja auch einen ganz schönen Bullshit zusammen … Wie's weitergeht, ist ja noch viel besser: "Was aber auch belegt, was ich schon vor Jahren prophezeit habe: Dass Linke, Queere, Woke, deren „Code of Conduct“, die IT zerstören. Denn deren zentrales und mit dreckigsten Methoden durchgesetzes Weltbild ist ja, dass man – Quality is a myth – wirklich jeden an jedem Code mitschreiben lassen muss und niemanden ausgrenzen darf. Und jetzt hat man das Ergebnis." Wo habt ihr den denn ausgegraben?
Rolf M. schrieb: > Ok, nicht alle. Aber systemd ist ja durchaus weit verbreitet. Ich glaube, die betreffende Distri nutzte systemd schon lange, bevor die Debianer sich dazu entschlossen haben. Ich nutze Arch, btw. … dort wurde der sshd nur nicht so gepatched, wie bei Debian.
:
Bearbeitet durch User
Herbert Z. schrieb: > Es scheint eine richtige Katastrophe zu sein, nicht so stark für > Desktopanwendungen daheim, sondern für die professionelle IT- > Infrastruktur wo Linux eben dominant ist. Nunja, immerhin beweist die zeitnahe Entdeckung, daß auch im OpenSource-Umfeld immer wieder Menschen genau hinschauen und sogar solche langfristig angelegten und sehr geschickt ausgeführte Angriffe wie diesen entdecken. Dies dürfte wohl die beste Erkenntnis aus der Geschichte sein. Dabei stellt sich mir dann auch die Frage, viele ähnliche Sicherheitslücken sich in proprietärem Code befinden könnten? Ein Geheimdienst, der es nicht schafft, einen Softwarehersteller zu infiltrieren, ist sein Geld nicht wert. Für kriminelle Organisation dürfte Ähnliches gelten, befürchte ich. Seit Anfang der 2000er sehen wir, daß das Phänomen der Skriptkiddies abnimmt und die Angreifer sich zunehmend professionalisieren. Und jetzt wundern wir uns, daß jemand auf das gute alte Social Engineering kommt? Auch Backdoors, insbesondere in Authentifizierungsmechanismen, sind nichts Neues. Bereits in einigen Versionen des guten alten Sendmail-Daemons mußte ein Angreifer nur "wiz" eingeben, um die Meldung "200 Please pass, oh mighty wizard" und volle Root-Rechte auf dem System zu erhalten... > Das haben Profis eingefädelt die einen > politischen Auftraggeber haben. China oder Russland fallen mir zuerst > ein. Ach, im Endeffekt kann das jede/r gewesen sein, sogar ein privater Akteur. Da würde ich mich mit Spekulationen lieber zurückhalten.
Jack V. schrieb: > nun verbreite den Bullshit doch nicht auch noch weiter. Bist du die authoritative domain? Lol. Ich frage mich WER das reingepackt hat. BillGates zur promotion von windose-server oder dann die bösen chinesen?
Hadmut F. schrieb: > Bist du die authoritative domain? Nein, aber ich hab den Schwachsinn, dass jeder Linuxsserver betroffen wäre, doch eindeutig widerlegt? Was ist dein Problem, dass du trotzdem munter weiter fantasierst, dass jeder Linuxserver betroffen gewesen wäre?
:
Bearbeitet durch User
Bei der Kritik ist klar zu erkennen, es kommt darauf an, wer das geschrieben hat. Wenn es fefe so geschrieben hätte, sähe das anders aus. Der Code mit der Backdor war noch nicht bei vielen Distros in der finalen Version, weil es auf einigen Systemen zu Performanceproblemen kam. Die konnte sich keiner erklären. Die schadcodeeinbringende Person, half dann erst mal einen Teil des Codes auszublenden so dass das Problem erst mal weg war. Wegen diesem kleinen Problem hatten viele Distris das noch nicht in die stable-Version übernommen. Wenn aber die Person das Performanceproblem in der Zwischenzeit gelöst hätte, ware beim nächsten größeren Update die Backdoor groß ausgerollt worden.
Dieter D. schrieb: > Wenn aber die Person das > Performanceproblem in der Zwischenzeit gelöst hätte, ware beim nächsten > größeren Update die Backdoor groß ausgerollt worden. … und dann wäre immer noch lange nicht jeder Server mit Linux betroffen gewesen.
Norbert schrieb: > Wie viele Firmen da draußen setzen von außen erreichbare > wichtige/kritische Systeme ein, ohne ein vernünftig konfiguriertes > Sicherheitsmodell (MAC) etabliert zu haben? Das tun sie ja, deshalb setzen sie Linux ein! Ist leider recht verbreitet der Aberglaube das man sich bei Linux um nichts kümmern muss weil das ja von Hause aus schon so super Sicher ist. Je höher die Chefetage bzw. je kleiner die Firma, um so verbreiteterer ist meiner Erfahrung nach dieser (gefährliche) Irrglaube. Entsprechend gering ist das Zeitbudget das den Leuten für die Pfleger der Systeme zugestanden wird, bzw. es gibt erst garkeins. > Ist ja anscheinend ein Tollhaus! Oder sagt man jetzt Irrenhaus? Wennschon, dann: Toll:innen*haus der Irr:innen*haus oder wie auch immer das heutzutage politisch korrekt bezeichnet. Solch eine Frage im Bundestag eingereicht, würde vermutlich zu umfangreicheren Ausschüssen führen als wegen so ein kleines Sicherheitsproblemchen mit dem man eventuell einen Großteil der Server auf der Welt übernehmen könnte.
Hallo Rolf M. Rolf M. schrieb: > "Was aber auch belegt, was ich schon vor Jahren prophezeit habe: Dass > Linke, Queere, Woke, deren „Code of Conduct“, die IT zerstören. Denn > deren zentrales und mit dreckigsten Methoden durchgesetzes Weltbild ist > ja, dass man – Quality is a myth – wirklich jeden an jedem Code > mitschreiben lassen muss und niemanden ausgrenzen darf. Und jetzt hat > man das Ergebnis." > > Wo habt ihr den denn ausgegraben? Das ist ein rechtsradikaler Manipulateur mit einem Framing Versuch. Das man genau hinschauen sollte, hat natürlich nichts mit den sexuellen Präferenz oder der ethnischen Zugehörigkeit des Softwareschreibers zu tun, er will das ganze nur in einem Zusammenhang schreiben, damit eine entsprechende Stimmung geschürt wird. Wenn jemand mit Framing Versuchen daherkommt, hat es eigentlich schon fast keinen Sinn mehr, mit ihm zu diskutieren, weil seine Agenda eigentlich eine ganz andere ist, als die es in der Unterhaltung eigentlich geht. Die Argumente die er bringt, mögen richtig oder falsch sein, ihm geht es nicht wirklich um die Argumente, sondern nur um damit zu Hetzen. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Mario M. schrieb: > Nun kommen auf die Systemadministratoren Hausaufgaben zu." > Aber nur für die, die ihre Hausaufgaben nicht gemacht haben. Keines der von mir betreuten Systeme ist betroffen.
Jack V. schrieb: > Siehst du dann vielleicht anders, wenn dir die Kisten mal aufgemacht > werden, weil du ohne systemd einige der aktuellen Sicherheitsmechanismen > von Linux nicht nutzen kannst. Sämtliche Sicherheitsmechanismen von Linux, inklusive Selinux, Seccomp, Namespaces, CGroups, etc. funktionieren auch ohne Systemd einwandfrei. Jack V. schrieb: > Hab mich schon gefragt, was die Mainstreammedien bar jeder Ahnung von > der Materie aus der Sache machen würden. Das Ergebnis war einigermaßen > vorhersehbar – incl. der Suggestion, dass es ein Linuxproblem ansich > wäre. Traurige Sache, aber was willst machen? In der tat. Ich habe gehört, auch Microsoft nutzt in einigen Windows Programmen diese liblzma ein. Die hatten nur Glück, das man halt einmal ausnahmsweise nicht Windows als Ziel hatte. Wobei, wer weiss wie viele Backdoors dort schon unentdeckt schlummern, ohne die Werkzeuge, womit man diese hier entdecken konnte.
Im Jahre 2015 flog Lücke in Verbindung mit libc/libc6 auf. Davon betroffen waren alle Distros und Virtualisierungen, die Teile von Linux verwendeteten. Aufgeflogen war das dadurch, dass jemand mit unterschiedlichen Architekturen in chroot-Umgebungen etwas ausprobierte und feststellte, dass es Durchgriffe auf das andere System gab.
:
Bearbeitet durch User
Hallo Dieter D. Dieter D. schrieb: > Bei der Kritik ist klar zu erkennen, es kommt darauf an, wer das > geschrieben hat. Wenn es fefe so geschrieben hätte, sähe das anders aus. Es kommt vor allem darauf an, WIE er es schreibt. :C > > Der Code mit der Backdor war noch nicht bei vielen Distros in der > finalen Version, weil es auf einigen Systemen zu Performanceproblemen > kam. Die konnte sich keiner erklären. Die schadcodeeinbringende Person, > half dann erst mal einen Teil des Codes auszublenden so dass das Problem > erst mal weg war. Wegen diesem kleinen Problem hatten viele Distris das > noch nicht in die stable-Version übernommen. Wenn aber die Person das > Performanceproblem in der Zwischenzeit gelöst hätte, ware beim nächsten > größeren Update die Backdoor groß ausgerollt worden. Wie stellst Du Dir denn nun eine Überwachung von Quellcode vor, die ein solches Vorgehen verhindern soll? Die meisten Firmen hätten ja nicht die Breite an unterschiedlichen Leuten, die über den Code sehen, wodurch die Wahrscheinlichkeit groß würde, die Manipulation zu erkennen. Eigentlich müssten sie nach einem Zig-Augen Prinzip vorgehen, und den Quellcode mit ihrer Konkurenz (weil da ist die größte Expertiese) und der Öffentlichkeit (da ist die breiteste Erfahrung) austauschen, um solche Gefärdungen zu vermeiden. Wenn openSource da an Grenzen kommt, dann eine Firma erst recht. Interessant wäre, sich einmal Gedanken darüber zu machen, ob so eine Revision nicht zumindest teilweise automatisiert werden könnte. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Daniel A. schrieb: > Ich habe gehört, auch Microsoft nutzt in einigen Windows > Programmen diese liblzma ein. Aufgeflogen ist die Hintertür durch einen Mikrosoft-Mitarbeiter, dem etwas auffiel und nachforschte. Das war übrigens ein Mitarbeiter, der durch seine aktive Mitarbeit in der OSS-Community generell viel lernte über alle Betriebsysteme, was nur von Vorteil des Konzerns war. Jemand der 6J aktiv in der OSS-Szene programmierte ist in der Regel nach zwei Jahren der Einarbeitung so weit, wie ein anderer guter Absolvent, der so etwas nicht machte, nach vier bis sechs Jahren Einarbeitung wäre, hieß es.
Jack V. schrieb: > … und dann wäre immer noch lange nicht jeder Server mit Linux betroffen > gewesen. Klar, weil nicht jeder auf die neue Version hochgegangen wäre. So wie es noch viele mit XP und Win 7 auf den PC-Kisten gibt. Ausserdem reicht es doch, wenn nur ein gewisser Prozentsatz an Servern betroffen ist über den Du rein kommst. Wenn Du als Einbrecher den Einstieg vorbereitest im Spiegelbürohaus, dann würdest Du auch nicht per Bug alle Fenster des Gebäudes spät abends per Motor sperrangelweit aufmachen. In dem Falle reicht doch eines und noch eine Reserve irgendwo.
Dieter D. schrieb: > Klar, weil nicht jeder auf die neue Version hochgegangen wäre. Nein, weil nicht jede Distri ihren sshd so patched, dass es gegen die Lib linkt, wie hier bereits mehrfach zu lesen ist. Liest du nicht mit, oder was? Warum schreibst du dann hier, wenn du nicht mitliest?
Jack V. schrieb: > Nicht jede Distribution hat den sshd für systemd-notify so gepatched, a> dass es gegen die Lib gelinkt wird. Das war bereits bekannt, weil unter dem Link hatte ich das schon gelesen: "war wohl eine vorcompilierte Bibliothek versteckt, die man dann eingebunden hat, weshalb die Backdoor nirgends im Quelltext auftauchte." Dieter D. schrieb: > Klar, weil nicht jeder auf die neue Version hochgegangen wäre. So wie es > noch viele mit XP und Win 7 auf den PC-Kisten gibt. Das war etwas spitzfindig, auch wenn Du falsch liegen solltest, wäre Dein Satz nicht falsch. > Ausserdem reicht es > doch, wenn nur ein gewisser Prozentsatz an Servern betroffen ist über > den Du rein kommst. Genau die wenigen sind bereits zuviel, weil die Liste der Distros, die solche vorcompelierten Libs verwenden, war nicht gerade klein. Außerdem könnte eine der VM auf einem Server eine andere Version der libs haben.
Diverse Stable Distros bleiben zumindest in wesentlichen Teilen für etliche Jahre auf der gleichen Version eines Pakets. Fixes werden darin eingepflegt, oft als Backports, oft aber keine Modernisierungen und Feature-Änderungen. Distros wie Red Hat bleiben so 10 Jahre stabil und unterstützt. Das dieses Jahr aus dem Support laufende Red Hat 7 hat unverändert einen Kernel 3.10 und ein PHP 5.4.
:
Bearbeitet durch User
Bernd W. schrieb: > Das ist ein rechtsradikaler Manipulateur mit einem Framing Versuch. Was soll dieser hass im netz? Wie hiess doch gleich diese meldestelle ?
Herbert Z. schrieb: > Das haben Profis eingefädelt die einen politischen Auftraggeber haben. > China oder Russland fallen mir zuerst ein. Mir scheint, die Hetze gegen China/Russland funktioniert. Warum fehlt bei dir z.B. die USA (Weil das die Guten sind?). Außerdem, fast jeder Geheimdienst (egal welchen Landes), hat Zugriff auf (oder betreibt) mind eine der Root-CAs, die in den Systemen hinterlegt ist - das bietet auch einige Möglichkeiten (s. Facebooks Root-CA). Dieter schrieb: >Jack V. schrieb: >> Nicht jede Distribution hat den sshd für systemd-notify so gepatched, >> dass es gegen die Lib gelinkt wird. > > Das war bereits bekannt, weil unter dem Link hatte ich das schon > gelesen: > > "war wohl eine vorcompilierte Bibliothek versteckt, die man dann > eingebunden hat, weshalb die Backdoor nirgends im Quelltext auftauchte." Ich denke, du verstehst das falsch: die Backdoor wurde (über den genannten versteckten Code) in liblzma eingebaut. sshd benutzt kein liblzma. libsystemd benutzt das. sshd benutzt aber auch kein libsystemd. Einige Distros (i.e. Debian) fanden, sshd sollte das Logging aber per systemd machen und haben den sshd (distro-spezifisch) gepatched. Und erst dadurch landete das infizierte liblzma (indirekt, über libsystemd) im sshd. Btw, die Backdoor überprüft per Public-Key, wen sie reinlässt. Es kommt nur der rein, der den passenden Private-Key hat. Wenn man den Private Key findet, hat man den Täter gefunden. Easy ;-)
:
Bearbeitet durch User
Jack V. schrieb: > incl. der Suggestion, dass es ein Linuxproblem ansich > wäre. Steckt vielleicht MS dahinter?
A. F. schrieb: > Steckt vielleicht MS dahinter? Auf der Suche nach der Verschwörung hinter der Verschwörung? :)
Hadmut F. schrieb: > https://www.danisch.de/blog/2024/03/31/it-sicherheitskatastrophe-durch-code-of-conduct/ Schreibt dieser erbärmliche verbitterte Typ immer noch diesen ideologischen Mist?
Hallo Foobar. Foobar schrieb: > Mir scheint, die Hetze gegen China/Russland funktioniert. Warum fehlt > bei dir z.B. die USA (Weil das die Guten sind?). Dabei gibt es keinen Guten oder Bösen, nur das geringere Übel. ;O) > Außerdem, fast jeder > Geheimdienst (egal welchen Landes), hat Zugriff auf (oder betreibt) mind > eine der Root-CAs, die in den Systemen hinterlegt ist - das bietet auch > einige Möglichkeiten (s. Facebooks Root-CA). Wie soll ein "Bundestrojaner" eigentlich auf einem System landen, so ganz ohne Backdoor? ;O) Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Hallo (prx) A. K. (prx) A. K. schrieb: >> Steckt vielleicht MS dahinter? > > Auf der Suche nach der Verschwörung hinter der Verschwörung? :) Bei MS fehlt zur Verschwörung das Merkmal des klandestinen. ;O) Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Herbert Z. schrieb: > Das haben Profis eingefädelt die einen > politischen Auftraggeber haben. China oder Russland fallen mir zuerst > ein. Und der Dritte um Bunde zählt zu den Guten und wäre nicht so schlimm?
Bernd W. schrieb: > Die Argumente die er bringt, mögen richtig oder falsch sein,... Das Stilmittel ist Polemik und Glosse, was nicht jedem gefällt. Wobei er hier einen blinden Fleck im Johari-Fenster anreißt, der durchaus zutreffend sein könnte. Hineingedrängt zu haben scheint sich durchaus die Person über die Welle des Code of Conduct auf Grund dessen überall aus dem Coding Master und Slave entfernt wird. Den Zusatzaufwand haben einige abgelehnt, die dann mehr oder weniger so nett wie A K in der Kommunikation in internen Chats bedacht wurden. Das scheint diese Person ausgenutzt zu haben um den Fuß in die Community und in diesen Entwicklungszweig zu bekommen.
Thomas schrieb: > Und der Dritte um Bunde zählt zu den Guten und wäre nicht so schlimm? Wenn du den Unterschied nicht kennst, dann fahre mal hin und schimpfe auf die dortige Regierung. Fange aber in Amerika an denn sonst kommst du nie dort hin. In China und Russland buchten sie dich ein.
:
Bearbeitet durch User
die Argumentation hinkt aber gewaltig nur weil Sie mich nicht gleich einbuchten würden, lasse ich mich am liebsten von denen ausspionieren. Bin hier nicht pro oder contra eines Vereins, meinte nur das jeder ein Interesse daran hätte, auch sind da auch viel mehr als nur die großen 3 daran interessiert.
Dieter D. schrieb: > Hineingedrängt zu haben scheint sich durchaus die Person über die Welle > des Code of Conduct auf Grund dessen überall aus dem Coding Master und > Slave entfernt wird. Ähm … nein? Meine Güte, die Story ist doch öffentlich – wie kommt man da auf die Idee, das da reininterpretieren zu wollen? Der ursprüngliche Autor hat aus persönlichen Gründen nicht viel an dem Projekt gemacht, und der später als Bösling erkannte User mit dem Pseudonym „Jia Tan“ hat Hilfe angeboten und auch tatsächlich recht tatkräftig geholfen – und sich damit das Vertrauen des ursprünglichen Autors erschlichen; außerdem hat ihn manipuliert und auch unter Druck gesetzt. CoC und solchen Sachen spielten da absolut keine Rolle. Was also soll der Stuss?
:
Bearbeitet durch User
Foobar schrieb: > Btw, die Backdoor überprüft per Public-Key, wen sie reinlässt. Es kommt > nur der rein, der den passenden Private-Key hat. Wenn man den Private > Key findet, hat man den Täter gefunden. Easy ;-) Deswegen ist es keine "riesige Sicherheitslücke", ganz im Gegensatz zu einem gewöhnlichen Buffer Overflow, der von jedem Spielkind ausgenutzt werden kann. In diesem Fall gibt es nur einen Angreifer, der sicher nicht wahllos alles angreifen will. Dafür war diese Backdoor viel zu schade und viel zu teuer. Zwecks Spionage wäre sie allerdings unbezahlbar gewesen. Wenn man die "Downloads" technisch genauso perfekt geplant und ausgeführt hätte, wäre das nur durch einen ähnlich extremen Zufall nach langer Zeit entdeckt worden. Zwecks Sabotage hätte man sie wohl nicht lange oder oft nutzen können, aber wie findet man so ein Loch auf einem Produktivsystem? Praktisch tauchen aus dem Nichts root-Prozesse auf, selbst wenn du sie auf frischer Tat ertappst, weißt du nicht, wo die her kommen. Würden die überhaupt irgendwo Spuren hinterlassen? Der sshd wird ja nicht angegriffen, es gibt ja nicht einmal einen Fehler wegen falschem Key oder so. Ein T. schrieb: > Nunja, immerhin beweist die zeitnahe Entdeckung, daß auch im > OpenSource-Umfeld immer wieder Menschen genau hinschauen und sogar > solche langfristig angelegten und sehr geschickt ausgeführte Angriffe > wie diesen entdecken. Dies dürfte wohl die beste Erkenntnis aus der > Geschichte sein. Eher die schlechteste, weil es so eben nicht funktioniert hat! Das Ding ist nur zufällig durch Bauchgefühl kombiniert mit großer Neugier entdeckt worden. Und das auch nur, weil der Angreifer es mit der Tarnung an einer Stelle übertrieben hat. Es hätte vielleicht indirekt wegen einem unleserlichen Script auffallen können, oder wegen penetranter Versuche, die neue Version in die Distributionen zu pushen. Das hat alles wenig mit genauem Hinschauen zu tun. Jack V. schrieb: > user@host ~ % ldd /usr/bin/sshd | grep liblzma > user@host ~ % Gut für Arch und Devuan. Aber auch, wenn man auf Debian den systemd garnicht installiert, lädt der sshd die liblzma. Leider kann man nicht sagen "ohne systemd wäre das nicht passiert", dann wäre eben eine andere lib missbraucht worden. Am besten libselinux ;)
Jack V. schrieb: > hat Hilfe angeboten und auch tatsächlich recht tatkräftig geholfen > ..... manipuliert und auch unter Druck gesetzt. Widerspricht alles nicht den Ausführungen, denen Du damit begegnen wolltest. Wenn Du einen Fuß in die Tür setzen willst, wird die aktuelle Situation ausgenutzt und diese bot gerade einen einfacheren Einstieg.
Dieter D. schrieb: > Widerspricht alles nicht den Ausführungen, denen Du damit begegnen > wolltest. Nein. Deine Behauptung (und die von diesem ominösen Herrn Danisch, der zu allem eine Meinung zu haben, aber kaum etwas zu wissen scheint) war, dass CoC und Co. in irgendeiner Form eine Rolle gespielt hätten. Haben sie nicht. Alleine diesem Stuss entgegnete ich. Warum also versuchst du, zu gaslighten? Das funktioniert in Foren nicht gut, weil der Verlauf für jeden sichtbar ist, und lässt dich nicht gut dastehen …
:
Bearbeitet durch User
Jack V. schrieb: > dass CoC und Co. in irgendeiner Form eine Rolle gespielt hätten. > Haben sie nicht. Wenn Du sachlich wärst, dann würdest Du schreiben, dass das nicht gänzlich ausgeschlossen werden kann, aber Du glaubst, dass das keine Rolle spielte. Weil ich das als Möglichkeit nicht gänzlich ausschließe, habe ich auch im Konjunktiv geschrieben. Ausserdem ist Dein weitere Text voller Rhetorik zu Diskreditierung mit dem Ziel nur eine Zustimmung ist möglich. Überlege mal, welche Änderungen im Sourcecode durchgeführt wurden, als sich diese Person hineindrängte? Ist es schwieriger in der Einarbeitung zu feindlichen Übernahme echte neue Features (hier ist nicht die Backdoor gemeint) in Code einzubringen oder einen Code nach (nichttechnischen CoC) Vorgaben zu überarbeiten? Nein, gänzlich auszuschließen kann das hier keiner aus dem Forum. Das kann nur der betroffene Maintainer und dessen engster Kreis in der OSS-Szene. Alles andere ist einfach nur Anmaßung die Wahrheit (als Außenstehender!) mit der großen Schneeschaufel gefressen zu haben. Bauform B. schrieb: > Eher die schlechteste, weil es so eben nicht funktioniert hat! Das > Ding ist nur zufällig durch Bauchgefühl kombiniert mit großer Neugier > entdeckt worden. Das trifft schon mal den Kern. Im Rahmen der Softwareprüfung gibt ein paar Entwicklungsprojekte, die schon mal im Forum erwähnt wurden, die damit auch etwas zu tun haben.
Dieter D. schrieb: > Wenn Du sachlich wärst, dann würdest Du schreiben, dass das nicht > gänzlich ausgeschlossen werden kann, aber Du glaubst, dass das keine > Rolle spielte. Und du willst mir rhetorische Spitzfindigkeiten andichten? Aber gut, ich führ’s aus: Das war ein Einmann-Projekt; es gab dort nicht einmal CoC, über den sich der Akteur „hineingedrängt“ haben könnte, wie du schreibst: Dieter D. schrieb: > Hineingedrängt zu haben scheint sich durchaus die Person über die Welle > des Code of Conduct auf Grund dessen überall aus dem Coding Master und > Slave entfernt wird. Die Geschichte ist öffentlich nachlesbar, incl. der Commits des Users, in denen man deiner Behauptung nach ja einen Bezug zu einem CoC o.Ä. finden müsste: etwa, dass Master und Slave ersetzt wurden, was du ja selbst als Beispiel angeführt hast. Wenn solche Sachen dort nicht enthalten sind, dann kann man ganz sachlich schreiben, dass es gänzlich ausgeschlossen werden kann. Warum ist’s dir eigentlich so wichtig, irgendwie auf CoC oder so zeigen zu können? Oder andersrum: was ist dein Problem damit, dass man es nicht auf sowas wie einen CoC schieben kann?
:
Bearbeitet durch User
Ich bin erleichtert, dass der Hack rechtzeitig enttarnt wurde und dass die Sache offen kommuniziert wurde. Bei Microsoft und Apple wäre es wahrscheinlich anders gelaufen.
:
Bearbeitet durch User
Steve van de Grens schrieb: > Bei Microsoft und Apple wäre es wahrscheinlich anders gelaufen. Yep. Die hätten einen NSL (Geheimhaltungsanordnung) bekommen und die NSA hätte nach dem Key gesucht. Kann sie ja selber brauchen.
:
Bearbeitet durch User
Jack V. schrieb: > Warum ist’s dir eigentlich so wichtig, irgendwie auf CoC oder so zeigen > zu können? Es gab einen Katalog CoC, auf was Code alles geprüft werden muss, nicht nur das genannte Beispiel. Wenn ich als Maintainer tatsächlich keine Zeit habe aus privaten Gründen und mir das jemand abnimmt, dann ist der mit dabei. Übrigens ist alles was auch als CoC-Bashing verwendet werden kann in der OSS-Szene ein no-go. So stellst Du das dar, dass ich meine, das muss so gewesen sein. Es ist ein Unterschied, ob man darauf zeigt, es müsse unbedingt so gewesen sein, oder fairerweise zugeben muss, dass es nicht gänzlich ausgeschlossen werden kann. Das ist, was Du nicht akzeptieren kannst. Dabei ist das genau die Methode um systematisch Abgrenzungen aufzubauen. Einen Grund mit anzuführen, den keine dritte Person wirklich ausschließen kann, ist schon immer ein Nährboden gewesen. Am meisten helfen dabei einem die Personen, die das über diskreditieren so etwas aus Welt schaffen wollen. Im Gegensatz zu Dir kann ich jemanden, indem ich nicht wie ein Papst was mir nicht gefällt ganz ausschließe, betonen wie viel in der langen Zeit dazwischen war. Wenn was anderes gerade "in" gewesen wäre, womit man den gleichen Maintainer ähnlich viel Arbeit hätte abnehmen können, dann hätte der Eindringling das analog genutzt oder eine überschaubare Zahl von Tagen länger gebraucht. Und damit landet der Aspekt dann bei der Person recht schnell unter den gering wahrscheinlichen Beihilfe leistenden Ursachen. Somit wäre ein wichtiges Ziel erreicht, sich kritisch mit etwas auseinander zu setzen.
Steve van de Grens schrieb: > Ich bin erleichtert, dass der Hack rechtzeitig enttarnt wurde und dass > die Sache offen kommuniziert wurde. Das ist das wichtigste, dass die SW bereinigt wird. Ausserdem wird die Community die nächste Zeit kritischer auf solche Elemente in den Distros schauen.
Dieter D. schrieb: > Es gab einen Katalog CoC, auf was Code alles geprüft werden muss, nicht > nur das genannte Beispiel. Wenn ich als Maintainer tatsächlich keine > Zeit habe aus privaten Gründen und mir das jemand abnimmt, dann ist der > mit dabei. Übrigens ist alles was auch als CoC-Bashing verwendet werden > kann in der OSS-Szene ein no-go. Vielleicht solltest du wirklich erstmal lesen, worum es sich bei einem CoC überhaupt handelt? Das ist kein Gesetz, und es gibt auch keine Pflicht, einen zu haben – er erleichtert schlicht die Zusammenarbeit, wenn mehrere an einem Projekt arbeiten, indem er ein paar Eckpunkte absteckt. Hier gibt es keinen – nicht zuletzt weil’s weitgehend ein Einmannprojekt war und ein CoC daher eher sinnlos wäre. Entsprechend kann der auch nicht „dabei“ gewesen sein. Kann’s sein, dass du doch nie an einem OSS-Projekt mitgewirkt hast? In dem Fall kann ich dich nur ermuntern – dann würdest du sehen, wie es tatsächlich funktioniert, und warum deine kruden Thesen eben nur genau das sind – und nicht etwa die Realität.
:
Bearbeitet durch User
Jack V. schrieb: > er erleichtert schlicht die Zusammenarbeit LOL. Nein. Der COC zerstört die kompetenzhierarchie. Boeing hat das problem auch.
Hadmut F. schrieb: > Der COC zerstört die kompetenzhierarchie. Noch einer, der erstmal nachlesen sollte, was ein „Code of Conduct“ überhaupt ist. Inwiefern würde denn ein CoC, in dem z.B. steht, dass man sich keine Schimpfwörter an den Kopf werfen soll, etwas zerstören, und was genau wäre das dann, Hadmut [FD]?
Jack schrieb: > Hadmut schrieb: >> Der COC zerstört die kompetenzhierarchie. > > Noch einer, der erstmal nachlesen sollte, was ein „Code of Conduct“ > überhaupt ist. Inwiefern würde denn ein CoC, in dem z.B. steht, dass man > sich keine Schimpfwörter an den Kopf werfen soll, etwas zerstören, und > was genau wäre das dann, Hadmut [FD]? Ich sehe einen CoC auch kritisch und eher als Instrument zur Unterwanderung der Hierarchien denn als Harmonisierungsmittel. Viele Punkte eines CoC sind mMn eine Selbstverständlichkeit[1]. Diese allerdings schriftlich niederzulegen (und dann deren buchstabengetreue Befolgung einzufordern) gibt Leuten einen Hebel, gegeben andere Vorzugehen, den sie ansonst nicht hätten ("Der ist bei Rot über die Straße gegangen, der muß bestraft/rausgeschmissen werden! Steht so im CoC!"). Dadurch können (und werden) gewachsene Gruppen auseinandergerissen oder gar zerstört. Und das nur, um der Ideologie einer fachfremden Gruppierung zu genügen, der das Projekt selbst oft ziemlich egal ist. Besser nicht. [1] Btw, sowas wie "Der Kode ist scheiße! [Begründung] Den nehm ich so nicht." sehe ich als legitim an, auch wenn da evtl eine Schneeflocke schmilzt.
Hadmut F. schrieb: > CoC verhindert das bewährte rausekeln der unfähigen. Das wirst du ja bestimmt in deinem nächsten Beitrag anhand eines Beispiels belegen, oder? Gleich nachdem du erläutert hast, inwiefern „rausekeln“ eine Methode ist, die ein geistig gesunder Mensch überhaupt anwenden wollen würde – ich denke, dass ich nicht ganz alleine bin, wenn ich meine: Solche verachtenswerten Methoden sorgen dafür, dass Situationen wie bei xz überhaupt erst entstehen können. Denn es macht keinen Spaß, so ein Projekt zu fahren, wenn alle Nase lang irgendein Psychopath vom Typ „Hadmut“ ankommt, der meint, alles besser zu wissen (und tatsächlich nicht mal eine Ahnung hat, worum’s überhaupt geht), und versucht, die Leute mit Ahnung rauszuekeln – weil er nämlich selbst zu blöd ist, zu erkennen, ob jemand Ahnung hat, denn er selbst hat ja nunmal keine. Nicht zu vergessen ist, dass im Kontext des Themas dieses Threads ein CoC absolut keine Rolle gespielt hat, btw. On-Topic: Falls da noch jemand Bedarf an einer Zusammenstellung der Information für weniger computeraffine Leute hat: ich fand https://dnip.ch/2024/04/02/xz-open-source-ostern-welt-retten/?utm_source=pocket-newtab-de-de für den Zweck ziemlich gut – das sollte auch ohne große Vorkenntnisse gut verständlich sein.
:
Bearbeitet durch User
:
Bearbeitet durch User
Jack V. schrieb: > CoC Das ist durchaus bekannt. Vieles ist an sich nicht verkehrt. Es gab aber in der OSS über dem großen Teich einige Unruhe, als jedem nachgeschnüffelt wurde, ob dieser nicht eine negative Meinung zum damaligen Präsidenten Trump habe. Das ist leider Politik, kann aber hier nicht ganz außen vor gelassen werden. Dann die Prüfung des Codes auf PC tat sich auch nicht von selber. Wenn dann jemand meint, diese Phase könnte jemanden den Einstieg erleichtert haben, der unlautere Absichten hatte, dann kann niemand das ganz ausschließen. Wo Licht ist, ist auch Schatten, wie ein Sprichwort so schön sagt. Dieses geflügelte Wort geht übrigens auf Goethe zurück. Ein Kritik zu akzeptieren, dass etwas nicht ganz ausgeschlossen werden kann, setzt auch Maßstäbe an Toleranz zu anderen Meinungen. Jack V. schrieb: > dann würdest du sehen, wie es tatsächlich funktioniert, Früher hatte ich klein wenig dazu beigetragen, allerdings war für mehr zu wenig Programmiererfahrung und Zeit vorhanden. Es ergab sich auch, dass die Szene mit im Zug mitführ über viele Stunden und Unterhaltung. Daher rührt auch das Verständnis dafür, wie mühsam und Ressourcen an Personenstunden in OSS gehen, weil die notwendigen HW-Informationen nicht zu Verfügung gestellt werden. Das geht dann zu Lasten der Bedienungsergonomie für einfacher gestrickte Nutzer und Anwendungskompatibilität.
Hadmut F. schrieb: > LOL. Nein. Wieso verlinkst du schon wieder den Sermon von diesem abgedrehten Schwurbler? Sollte sich doch wohl rumgesprochen haben, dass das ’ne Seite von ’nem verbitterten alten Troll ist, der im RL nix mehr zu sagen hat, und seinen Frust auf diese Weise kundtun will? Oder ist das am Ende deine eigene Seite, und die Gleichheit der Vornamen doch kein Zufall?
:
Bearbeitet durch User
Beitrag #7640192 wurde von einem Moderator gelöscht.
Hallo Hadmut F. > LOL. Nein. > Der COC zerstört die kompetenzhierarchie. > Boeing hat das problem auch. Airbus hat, wie jeder europäische Konzern, auch einen CoC, aber ein erheblich geringeres Problem als Boing. :O) Boing hat den Ertrag auf Kosten der Sicherheit steigern wollen. Das ging halt in die Hose. Aber vielleicht stand ja in deren CoC, das der Ertrag so wichtig ist, dass man die Sicherheitskultur vernachlässigen kann. Sicherheitskultur funktioniert aber nicht per diktatorischer Führung. Das Führerprinzip hat ausgedient. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Beitrag #7640217 wurde von einem Moderator gelöscht.
Hallo Jack V. Jack V. schrieb: > Hadmut F. schrieb: > Wieso verlinkst du schon wieder den Sermon von diesem abgedrehten > Schwurbler? ~~~~ ~~~ ~~ ~ > Oder ist das am Ende > deine eigene Seite, und die Gleichheit der Vornamen doch kein Zufall? Vom Stil her könnte das gut passen, dass es seine eigene Seite ist. Und: Die Verlinkung mit dem Hack passte ja zumindest noch zum Thema, aber die letzte Verlinkung ist nur ein Geheule über Rechtschreibung und Grammatik...:O) Ich habe vor gut 40 Jahren schon ein Knöllchen von der Polizei bekommen, wo der Polizist etwas von "Miesachtung der roden Ambel" geschrieben hatte, und trotzdem ist die Welt bis heute nicht untergegangen. ;O) Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Foobar schrieb: > Mir scheint, die Hetze gegen China/Russland funktioniert. Wo soll denn da "Hetze" betrieben werden? Oder nötig sein? Die diskreditieren sich doch selbst schon richtig gut.
Bauform B. schrieb: > Ein T. schrieb: >> Nunja, immerhin beweist die zeitnahe Entdeckung, daß auch im >> OpenSource-Umfeld immer wieder Menschen genau hinschauen und sogar >> solche langfristig angelegten und sehr geschickt ausgeführte Angriffe >> wie diesen entdecken. Dies dürfte wohl die beste Erkenntnis aus der >> Geschichte sein. > > Eher die schlechteste, weil es so eben nicht funktioniert hat! Das > Ding ist nur zufällig durch Bauchgefühl kombiniert mit großer Neugier > entdeckt worden. Entscheidend ist: sie ist rechtzeitig entdeckt worden, bevor sie weitere Verbreitung gefunden hat und bevor größerer Schaden damit angerichtet werden konnte. Und das ist eine gute Nachricht -- ob Dir das gefällt oder nicht.
Dieter D. schrieb: > So stellst Du das dar, dass ich meine, das muss so gewesen sein. Der rechtsextreme Schwurbler tut das, und Du verteidigst sein Geschwurbel -- während du dich darauf zurückziehst, es könne "nicht ausgeschlossen" werden, um Dein Geschwurbel gefühlt unangreifbar zu machen. Dann kannst du aber auch nicht ausschließen, daß du auch so ein rechter Schwurbler bist und dieselben Framing-Versuche betreibst wie der verbitterte Pöbler.
Ein T. schrieb: > dieselben Framing-Versuche Übrigens es lautet "nicht gänzlich ausgeschlossen", weil "nicht ausgeschlossen" ist in Deinem Post. Ein Framing betreibst Du auch. Jeder der von einem Autor etwas aufgreift, den Du ablehnst, muss auch zu dem Personenkreis gehören, ist nichts neues. Das Unangreifbare zu erkennen, setzt voraus die Fähigkeit der Sichtweise zu akzeptieren, denn sonst kann man nicht die Architektur erkennen.
Ein T. schrieb: > Entscheidend ist: sie ist rechtzeitig entdeckt worden (...) > Und das ist eine gute Nachricht -- ob Dir das gefällt oder nicht. Natürlich ist das eine gute Nachricht und die gefällt mir sehr gut. Nur die Erkenntnis aus der Geschichte sollte eher sein: "Es gibt Angriffe, die man nur durch Zufall entdecken kann". Diese Backdoor wurde auch deshalb gefunden, weil ssh weit verbreitet ist und ständig benutzt wird. Deshalb braucht man einen noch extremeren Zufall, um einen entsprechenden Angriff auf z.B. die Netzleittechnik zu entdecken.
Hallo Bauform B. Bauform B. schrieb: > Natürlich ist das eine gute Nachricht und die gefällt mir sehr gut. Nur > die Erkenntnis aus der Geschichte sollte eher sein: "Es gibt Angriffe, > die man nur durch Zufall entdecken kann". Das Problem ist nicht nur "Zufall". Die Beobachtungsgabe, die macht, dass jemand etwas ungewöhnliches Bemerkt kommt wohl häufiger vor. Aber in den meisten Unternehmen hat der Betreffende nicht die Zeit, hinter der Beobachtung herzulaufen. Da gilt: Entspricht offensichtlich den Anforderungen und hat Deadline und Kostenrahmen gehalten. Also Augen zu und durch. Nicht umsonst ist das ganze einem openSource Programmierer aufgefallen, auch wenn dieser für Microsoft arbeitete. > Diese Backdoor wurde auch deshalb gefunden, weil ssh weit verbreitet ist > und ständig benutzt wird. Deshalb braucht man einen noch extremeren > Zufall, um einen entsprechenden Angriff auf z.B. die Netzleittechnik zu > entdecken. Verschiedene Grundsätze formulieren, damit soet was leichter auffallen kann? 1) Es dürfen nirgendwo vor dem Compilieren schon Binary Abschnitte vorhanden sein. Eventuell auch kein Assembler oder Assembler nur in wenigen grundlegenden Bibliotheken. 2) Die Anzahl der Ebenen, mit denen Bibliotheken andere Bibliotheken nach sich ziehen muss limitiert sein. Am besten auf unter drei. 3) Die kompleten Quellen inklusive der Bibliotheken muss für jeden offen einsehbar sein. Der Grund für letzteres ist, dass in einem kommerziellen Umfeld kaum Resourcen für eine solche Revision bestehen. Du könntest Algorithmen als Vorhut darüberjagen, und nur die Stellen untersuchen, wo die Alarm geschlagen haben. Wenn Du jemanden für das Nachlesen bezahlst, hast Du erstens ein Motivationsproblem und zweitens das Problem, dass Du jemanden für etwas Bezahlst, was möglicherweise nicht da ist. Qualitätskontrolle der Revision ist damit dann Glückssache. Besser, Du bezahlst nichts und nimmst dafür die Hilfe von Leuten mit intrinsischer Motivation in Anspruch. Aber die haben auch nicht immer Zeit und Lust. Also muss das offen sein, damit sich jeder Dahergelaufene dahinter klemmen kann wenn er Lust hat. Bezahlen würde die Leute dazu drängen, verstärkt Probleme zu sehen, wo keine sind. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
:
Bearbeitet durch User
Bernd W. schrieb: > 1) Es dürfen nirgendwo vor dem Compilieren schon Binary Abschnitte > vorhanden sein. Eventuell auch kein Assembler oder Assembler nur in > wenigen grundlegenden Bibliotheken. In diesem Fall waren’s binäre Testdaten, die halt auch zum Testen genutzt werden. Das ist nicht ungewöhnlich. Wie möchtest du diese ersetzen? Bernd W. schrieb: > 2) Die Anzahl der Ebenen, mit denen Bibliotheken andere Bibliotheken > nach sich ziehen muss limitiert sein. Am besten auf unter drei. [Edit: hatte falsch gelesen, daher neue Frage:] Wenn eine Lib mit Funktionalität, die ich benötige, eine Lib einbindet, die ihrerseits eine Lib einbindet, die ihrerseits eine andere Lib einbindet – muss ich dann auf diese Lib verzichten und mein Projekt dann begraben? Ich habe schließlich keinen Einfluss darauf, was der Entwickler der Lib macht, die ich benötige. Und der nicht auf darauf, was der Entwickler der Lib macht, die er benötigt. Und so weiter. Bernd W. schrieb: > 3) Die kompleten Quellen inklusive der Bibliotheken muss für jeden offen > einsehbar sein. War hier der Fall, hat ja offensichtlich nichts gebracht. In diesem Fall wär’s vielleicht gut gewesen, wenn beim Deaktivieren der Tests irgendwo ein fettes rotes Icon eingeblendet worden wäre, sodass da direkt jemand drauf aufmerksam geworden wäre (denn es wurden ja im Vorfeld Tests deaktiviert, die das Problem aufgezeigt hätten). Außerdem wär’s gut gewesen, wenn es einen Mechanismus gegeben hätte, der sicherstellt, dass der Release-Tarball exakt dem Stand im Repo zum Zeitpunkt der Erstellung hat (denn dass es nicht so war, war hier einer der Mechanismen zum Verstecken der Manipulationen)
:
Bearbeitet durch User
Hallo Jack V. Jack V. schrieb: >> 1) Es dürfen nirgendwo vor dem Compilieren schon Binary Abschnitte >> vorhanden sein. Eventuell auch kein Assembler oder Assembler nur in >> wenigen grundlegenden Bibliotheken. > > In diesem Fall waren’s binäre Testdaten, die halt auch zum Testen > genutzt werden. Das ist nicht ungewöhnlich. Wie möchtest du diese > ersetzen? So wie Compilieren und Testen unterschiedliche Handlungen sind, und eigentlich von separaten Programmen vorgenommen werden sollten, so sollten auch Quellcode und Testdaten auseinander gehalten werden. Testdaten sind ja zum Testen auch ok, aber zum Compilieren darf dann nicht darauf zugegriffen werden. Darum Testdaten in eine andere Datei packen, und wenn der Compiler danach greift, kommt zumindest eine Warnung. Genauso wie Warnungen kommen sollten, wenn Tests abgeschaltet sind. Das ist kein Allheilmittel, macht es aber für Angreifer komplizierter. >> 2) Die Anzahl der Ebenen, mit denen Bibliotheken andere Bibliotheken >> nach sich ziehen muss limitiert sein. Am besten auf unter drei. > > [Edit: hatte falsch gelesen, daher neue Frage:] > Wenn eine Lib mit Funktionalität, die ich benötige, eine Lib einbindet, > die ihrerseits eine Lib einbindet, die ihrerseits eine andere Lib > einbindet – muss ich dann auf diese Lib verzichten und mein Projekt dann > begraben? Ich habe schließlich keinen Einfluss darauf, was der > Entwickler der Lib macht, die ich benötige. Und der nicht auf darauf, > was der Entwickler der Lib macht, die er benötigt. Und so weiter. Ja, das ist ein Problem. Complecity kills. Hier ist die Komplexität das System aus ineinander verschachtelten Bibliotheken und an zu viel Komplexität werden wir alle noch mal zu Grunde gehen. Im konkreten Falle müsstest Du dann aus zwei aufeinander beruhenden Bibliotheken nicht erst per Compilation etwas neues machen, sondern schon vorher daraus revisionierbarer Quelltext erzeugen. Das ist eine Herausforderung das maschinell so zu machen, dass "lesbarer" (im Sinne von verstehbarer) Quelltext entsteht. Disassembler liefern ja auch immer Kraut und Rüben ab. Das ganze läuft also auf eine Automatisierung der Strukturierung hinaus, und zwar so Strukturiert, das Menschen den Code warten können. Vielleicht haben wir dort das Ende unserer Intelligenz und der sinnvollen Machbarkeit erreicht. >> 3) Die kompleten Quellen inklusive der Bibliotheken muss für jeden offen >> einsehbar sein. > > War hier der Fall, hat ja offensichtlich nichts gebracht. Offensichtlich schon. Sonst hätte er vermutlich überhaupt nicht hinein gesehen. Oder das ganze auf sich beruhen lassen. Es hätte schon vermutlich Überredungskünste gebraucht, einen Chef dazu zu überreden, Zeit dafür bereitzustellen. Und in dem eher wahrscheinlichen Fall, das eine Untersuchung ergebnislos verlaufen wäre, hätte er beim nächsten mal noch mehr Überredungskunst gebraucht. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Bernd W. schrieb: > So wie Compilieren und Testen unterschiedliche Handlungen sind, und > eigentlich von separaten Programmen vorgenommen werden sollten, so > sollten auch Quellcode und Testdaten auseinander gehalten werden. Ganz so einfach ist es ja nun auch nicht mehr: beim Bauen werden im Anschluss häufig eine ganze Reihe Tests aufgerufen, um sicherzustellen, dass alles in Ordnung ist. Tatsächlich sehe ich beim Paketbau aus dem AUR häufiger mal, dass die Tests deutlich mehr Zeit in Anspruch nehmen, als das eigentliche Bauen. Bernd W. schrieb: > Offensichtlich schon. Sonst hätte er vermutlich überhaupt nicht hinein > gesehen. Ja, ich hab’s falsch ausgedrückt. Was ich sagen wollte: das Problem ist hier trotz bereits offenliegender Libs aufgetreten, insofern sehe ich bei deiner Forderung nach offenen Libs keinen Unterschied zum Status quo. Bernd W. schrieb: > Vielleicht haben wir dort das Ende unserer Intelligenz und der > sinnvollen Machbarkeit erreicht. … KI wird uns erlösen! [scnr]
Bernd W. schrieb: > Die Anzahl der Ebenen, mit denen Bibliotheken andere Bibliotheken nach > sich ziehen muss limitiert sein. Am besten auf unter drei. Dann hast du kein Internet mehr.
Ich finde ja auch krass wie der Code da reingekommen ist.. Der einzige langjährige Maintainer war in einem Burnout, wurde quasi längere Zeit von einer Gruppe untergründig dazu gemobbt / unter Druck gesetzt jemanden mit ins Boot zu nehmen, der aber auch zu der Gruppe gehörte. Wie das dann letztendlich geendet wäre kann man nicht wissen. Es wurde zum Glück erkannt.
Na so ganz neu sind solche Probleme, die die Distributoren ja eigentlich schon seit Jahrzehnten haben, jetzt ja nun auch wieder nicht. Man hat halt bei Microsoft was bei Linux gefunden und baut das ja auch selber fleißig ins WSL mit ein. Ist doch gut, besser als Security by Obscurity. Über die Entstehung des Problems und der Abhängigkeitskette - na ja, das ist halt irgendwo ein grundsätzliches Problem, was nicht nur bei OpenSource ist, sondern überall. Niemand hat ne Garantie dafür, dass er aus nicht selbstgeschriebenen Code auch Sicherheitslücken mit integriert. Und wenn's ne Lib von nem Fremdanbieter ist, für die er einst löhnen musste. Deswegen wird heutzutage glaube auch gern mit diversen Tools gescannt, welche Library-Versionen bekannte Sicherheitsprobleme haben. Und jede selbstgeschriebene Software zu fuzzen - doof wärs nicht, macht bzw. kann auch nicht jeder. Im Endeffekt find ich das Thema sehr hochgespielt. Wie oben schon angedeutet, theoretisch ärgert sich ja jeder Admin vermutlich seit x Jahren damit rum, wie er die Schotten dicht gemacht kriegt - und solches Zeug wie AppArmor/SELinux, GrSecurity bzw. bereits Codeanalyse beim Bauen gibt's auch schon ewig. Müsst halt jemand mal die ganzen Warnungen ausm Code rausmachen... was bei prominenten OpenSource-Libs auch mitunter so eine Sache ist, wenn da der einzelne Entwickler wie die Henne aufm Ei hockt. Was nicht heißen soll, dass nicht auch ein einzelner Entwickler qualitativ sauberen Code schreiben kann - gäbe genug Gegen-Beispiele dafür. Wenn der ganze Kram über das xz-Thema zu irgendwas gut sein soll, dann höchstens dafür, ne Diskussion anzurühren, welche Qualitäten öffentlich entwickelter Code haben sollte und welche Mittel und Methoden dafür nützlich sind. Mehr ist da nicht rauszuholen, glaub ich. meine 2cents dazu...
:
Bearbeitet durch User
Steve van de Grens schrieb: > Bernd W. schrieb: >> Die Anzahl der Ebenen, mit denen Bibliotheken andere Bibliotheken nach >> sich ziehen muss limitiert sein. Am besten auf unter drei. > > Dann hast du kein Internet mehr. Bei ihm wäre das wirklich schade.
Hallo Steve van de Grens. Steve van de Grens schrieb: >> Die Anzahl der Ebenen, mit denen Bibliotheken andere Bibliotheken nach >> sich ziehen muss limitiert sein. Am besten auf unter drei. > > Dann hast du kein Internet mehr. Richtig. Aber ich schrieb ja auch "am besten". Mir ist klar, das es jede Menge Fälle gibt, wo das so nicht funktioniert und trotzdem ist es ein erstrebenswertes Ziel. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Hallo Jack V. Jack V. schrieb: >> So wie Compilieren und Testen unterschiedliche Handlungen sind, und >> eigentlich von separaten Programmen vorgenommen werden sollten, so >> sollten auch Quellcode und Testdaten auseinander gehalten werden. > > Ganz so einfach ist es ja nun auch nicht mehr: beim Bauen werden im > Anschluss häufig eine ganze Reihe Tests aufgerufen, um sicherzustellen, > dass alles in Ordnung ist. Tatsächlich sehe ich beim Paketbau aus dem > AUR häufiger mal, dass die Tests deutlich mehr Zeit in Anspruch nehmen, > als das eigentliche Bauen. Das widerspricht dem nicht, dass man Bauen und Testen auf verschiedene Programme verteilt. Und das man Quelltext und Testdaten auch getrennt hält. Ist nur so eine Idee von mir. Jedenfalls könnte so vielleicht einfacher Überprüft werden, ob beim Bauen vielleicht irgendwo binäre Testdaten lauffähig eingebunden werden.... Routinemäßig die für das Compilieren benötigte Zeit für die Einzelkomponenten loggen. Ebenso die Zeit, die für das Testen benötigt wird. Diese Zeiten ins Verhältnis zu den Zeiten für andere Komponenten setzten (als vage Kalibrierung). Wenn sich was verschiebt, hätte man eine Warnung. >> Offensichtlich schon. Sonst hätte er vermutlich überhaupt nicht hinein >> gesehen. > > Ja, ich hab’s falsch ausgedrückt. Was ich sagen wollte: das Problem ist > hier trotz bereits offenliegender Libs aufgetreten, insofern sehe ich > bei deiner Forderung nach offenen Libs keinen Unterschied zum Status > quo. Es gibt aber eben auch geschlossene Libs, und die kann sie halt keiner aus einer Laune heraus greifen und durchsuchen. ;O) Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Ohne dir zu nahe treten zu wollen, Bernd: ich denke, du hast da eine zu stark vereinfachte Vorstellung von der Situation heute. Deine Ideen ansich mögen im Einzelnen für sich stehend gut erscheinen – nur sind sie nicht (mehr) umsetzbar, und die Komplexität nachträglich rauszunehmen, wird sich keiner antun – dabei würden zuviele Dinge, die voneinander abhängen, Gefahr laufen, kaputtzugehen. Der Fluch gewachsener Sachen … Abgesehen davon sollte man nicht vergessen, dass viele Leute in dem Umfeld freiwillig an den Sachen arbeiten – ihnen vorzuschreiben zu wollen, wie sie ihren Kram zu machen haben, erschiene mir da ein wenig anmaßend. Hindert dich aber keiner daran, ein Projekt zu forken und es deinen Vorstellungen gemäß umzubauen ;)
> und die Komplexität nachträglich rauszunehmen, > wird sich keiner antun – dabei würden zuviele Dinge, die voneinander > abhängen, Gefahr laufen, kaputtzugehen. Ich denke auch das wird nicht so einfach. Vermutlich wird man das erst nach Butlers Jihad so machen. .-) Vanye
Bernd W. schrieb: > Das widerspricht dem nicht, dass man Bauen und Testen auf verschiedene > Programme verteilt. Und das man Quelltext und Testdaten auch getrennt > hält. > Ist nur so eine Idee von mir. Das widerspricht nur Ansätzen wie test driven design und anderen vernünftigen Praktiken, bei denen eben Quelltext und Testdaten im Repository atomar synchron gehalten werden sollen. Zu einem bestimmten Versionsstand gehören eben ein bestimmter Quelltext und die dazu passenden Tests inkl. Testdaten. Wenn du davon abweichst, dann beseitigst du zwar evtl. den bei xz benutzte Angriffsvektor, machst dafür aber andere Baustellen auf, die heute eigentlich niemand mehr haben will (RCS/SCCS waren zwar ganz nett, aber atomare Commits sind doch erheblich angenehmer für die Softwarepflege).
Bernd W. schrieb: > Es gibt aber eben auch geschlossene Libs, und die kann sie halt keiner > aus einer Laune heraus greifen und durchsuchen. ;O) Guter Punkt.
Hadmut F. schrieb: > https://www.danisch.de/blog/2024/03/31/it-sicherheitskatastrophe-durch-code-of-conduct/ Und da lesen wir: [...] Was aber auch belegt, was ich schon vor Jahren prophezeit habe: Dass Linke, Queere, Woke, deren „Code of Conduct“, die IT zerstören. Denn deren zentrales und mit dreckigsten Methoden durchgesetzes Weltbild ist ja, dass man – Quality is a myth – wirklich jeden an jedem Code mitschreiben lassen muss und niemanden ausgrenzen darf. Und jetzt hat man das Ergebnis. [...] Wahrhaftig ein Superburschie mit einem "von dreckigsten Methoden durchsetzen Weltbild". Warum gibt man sowas als Quelle an?
Axel G. schrieb: > Warum gibt man sowas als Quelle an? Er mag nicht deinem weltbild entsprechen, aber er ist gut. IT-sicherheitschef bei grosser DE bude. Bis er dann vom bloggen leben konnte. Millionen leser.
Hadmut F. schrieb: > Er mag nicht deinem weltbild entsprechen, aber er ist gut. Er schreibt zu weiten Teilen reinen Stuss, aus dem man seinen Frust auf „die“ richtig rauslesen kann. Technisches Hintergrundwissen ist in einem ziemlich oberflächlichen Maß vorhanden, Meinung dafür umso mehr. Sowas gibt man nicht als Quelle an, wenn man ernst genommen werden möchte. Kannst du doch gerade beim nun mehrfach zitierten Ausschnitt selbst sehen: in diesem Fall war an keiner Stelle irgendein CoC auch nur in Sichtweite. Dennoch will der verbitterte Troll das auf Biegen und Brechen irgendwie verantwortlich machen …
:
Bearbeitet durch User
Ein Trauerspiel war sein offizieller Beitrag zu einer politischen Anhörung von ein paar Monaten. Fing gut an, bis er es dann aber nicht lassen konnte, darin seine persönliche Lebenstragödie auszubreiten. Damit war das Papier effektiv völlig entwertet.
:
Bearbeitet durch User
Angehängte Dateien:
Hadmut F. schrieb: > aber er ist gut. Sagt wer? Du? Hadmut F. schrieb: > IT-sicherheitschef bei grosser DE bude. Das sagt rein gar nix. Wer leute verteidigt, die meinen BILD wäre die Wahrheit (siehe Screenshots), dem ist nicht zu helfen. Damit ist alles über die Personalie gesagt was man wissen muss.
:
Bearbeitet durch User
Hat schon seine Gründe warum ich die BILD Zeitung nicht mal als Klopapier haben will. Ich finde das völlig ok und angebracht, dass man nicht mit jedem traurigen Ereignis gerne und vorsätzlich die Rechten triggert.
:
Bearbeitet durch User
Ich gucke kein Fernsehen außer mal Fußball. Ohne das Forum wäre ich nicht auf diese bescheuerte Interpretation gekommen.
Kaj G. schrieb: > Wer leute verteidigt, die meinen BILD wäre die Wahrheit (siehe > Screenshots), dem ist nicht zu helfen. Vor allem in diesem Zusammenhang, nachdem die BILD schon dabei erwischt (und vom Presserat dafür gerügt) wurde, die Vornamen von Tatverdächtigen so zu ändern, dass die Rechten sich freuen: https://bildblog.de/1419/der-moerder-ist-immer-der-tuerke/
Hallo Jack V. Jack V. schrieb: > Ohne dir zu nahe treten zu wollen, Bernd: Kein Problem. siehe weiter unten.... > ich denke, du hast da eine zu > stark vereinfachte Vorstellung von der Situation heute. Das mag wohl so sein, ich habe vor ca. 20 Jahren meinen dritten und letzten Versuch C zu erlernen erfolglos abgebrochen. Mein Kurzzeitgedächnis und mein Konzentrationsvermögen waren nicht gut genug. Abgesehen, das meine Art zu Denken dabei auch stört. Mann könnte auch sagen, ich bin zu doof. > Deine Ideen > ansich mögen im Einzelnen für sich stehend gut erscheinen – nur sind sie > nicht (mehr) umsetzbar, und die Komplexität nachträglich rauszunehmen, > wird sich keiner antun – dabei würden zuviele Dinge, die voneinander > abhängen, Gefahr laufen, kaputtzugehen. Der Fluch gewachsener Sachen … Der Fluch gewachsener Sachen......ja, das gibt es oft. Und sehr oft endet das fatal, wenn es nicht möglich ist, das erfolgreich zu überarbeiten. > Abgesehen davon sollte man nicht vergessen, dass viele Leute in dem > Umfeld freiwillig an den Sachen arbeiten – ihnen vorzuschreiben zu > wollen, wie sie ihren Kram zu machen haben, erschiene mir da ein wenig > anmaßend. Nicht nur anmaßend, sondern auch sinnlos, weil im Zweifel würden sie das ignorieren. ;O) > Hindert dich aber keiner daran, ein Projekt zu forken und es > deinen Vorstellungen gemäß umzubauen ;) Nein, das traue ich mir nicht zu, siehe oben. Ich gebe aber zu, dass ich mich bei meinen Python Gehversuchen auch öfters daran gestört habe, das ich keinen Überblick darüber bekam, welche Bibliotheken dort im Untergrund alle verwendet wurden, und aus denen gelegentlich kryptische Fehlermeldungen aufstiegen. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
A. F. schrieb: > Steckt vielleicht MS dahinter? Haben die eigentlich inzw. ihre löchrige Cloud wieder im Griff? Das war ja noch viel peinlicher als diese xz/lzma-Geschichte. Signing Keys geleaked. DAS ist der MegaGAU schlechthin. Die ganzen armen Schweine die in die MS-Cloud migrierten. Vor ein paar Wochen dann Russen die Zugriff auf Sourcecode von MS hatten, wieder so eine MegaGAU-Nummer. Ausgenutzt wurde der dauerlöchrige Exchangemüllhaufen.
Franko S. schrieb: > Schweine ... müllhaufen das Forum für Dein Wohlbefinden wartet auf Dich: https://www.landtreff.de/was-ist-schweinemist-wert-t5695.html
Franko S. schrieb: > Haben die eigentlich inzw. ihre löchrige Cloud wieder im Griff? Hoffen wir mal nicht. Sonst muss ich noch ein Sieb fuer die Spaggetties besorgen. Marke Cloud vom Euro-Shop.
Und schon wieder MS-Windows: Bitlocker, Defender und das "sichere" Smartscreenfilter kaputt: https://www.heise.de/news/Patchday-Angreifer-umgehen-erneut-Sicherheitsfunktion-und-attackieren-Windows-9679989.html Ach und am Ende wieder Azure angreifbar, über den dollen KI-Müll: Was für ein Kernschrott.
:
Bearbeitet durch User
Franko S. schrieb: > Und schon wieder MS-Windows Hat aber nichts mit diesem Thread zu tun, also bitte einen eigenen dafür eröffnen. Hier geht's immer noch um die lzma-Backdoor.
Jörg W. schrieb: > Hat aber nichts mit diesem Thread zu tun, also bitte einen eigenen dafür > eröffnen. Wir können doch jetzt nicht für Jeden einen eigenen Thread aufmachen. Da findet man ja bald gar nichts mehr…
Norbert schrieb: > Wir können doch jetzt nicht für Jeden einen eigenen Thread aufmachen. Wir können auch nicht alles in einen schmeißen.
Jörg W. schrieb: > Wir können auch nicht alles in einen schmeißen. Wäre dann der erste echte MS-Mega-Thread ;-)
:
Bearbeitet durch User
Jörg W. schrieb: > Hier geht's immer noch um die lzma-Backdoor. Nach der Titelüberschrift geht es um Linux. Wir haengen noch an der lzma-Backdoor fest. Durch die Komplexitaet und der vielen unterschiedlichen Zusammenstellungen der Distros ist es echt schwerer eine Backdoor einzupflegen ohne Probleme mit der Performance bei irgendwelchen Distros. Ohne eine Referenzanlage von 50 bis 100 Rechnern im Hintergrund plus dem Personal dazu, schwer.
Dieter D. schrieb: >> Hier geht's immer noch um die lzma-Backdoor. > > Nach der Titelüberschrift geht es um Linux. Der Eröffnungsbeitrag bezog sich aber letztlich genau auf die lzma-Geschichte. Da muss jetzt niemand herkommen, und sich über Windows ausk*en. Sonst könnte man auch gleich einen live-Thread machen und alle CVEs reinwerfen, die da täglich so angeflogen kommen.
Beitrag #7643581 wurde von einem Moderator gelöscht.
Beitrag #7643585 wurde von einem Moderator gelöscht.
Beitrag #7643592 wurde von einem Moderator gelöscht.
Beitrag #7643602 wurde von einem Moderator gelöscht.
Beitrag #7643606 wurde von einem Moderator gelöscht.
Jörg W. schrieb: > könnte man auch gleich einen live-Thread machen und alle CVEs ... Es wird sich schon immer ein neuer CVE im letzten Monat finden lassen, damit die 6 Monate nie ablaufen, wie bei zwei Handvoll an Threads hier im Forum. ;)
:
Bearbeitet durch User
Es wurde wohl alles zum Thema gesagt.
Thread beobachten
Seitenaufteilung abschalten