CVE-2020-15999: Der Kelch, der an Euch vorbei ging

Nein, heute geht es nicht um Dichtung, eher um Undichtigkeiten in Betriebssystemen 😉

CVE-2020-15999: Der Kelch, der an Euch vorbei ging

Google’s Projekt Zero hat im Oktober eine Serie von kritischen Bugs offengelegt, mit deren Hilfe iOS, Android, Windows, Macs und Linuxsysteme ĂŒbernommen werden konnten. Die LĂŒcken sind so groß, daß Apple sogar noch Iphone 5s aktualisiert und die sind seit Jahren im End-of-Live.

Ein Blick auf eine dieser LĂŒcken zeigte, daß diese auch fĂŒr Linux vorhanden war, aber unter dem Radar bliebt: FreeType < 2.10.4

„Bug #1890210 – CVE-2020-15999 freetype: heap-based buffer overflow via malformed ttf files“

Red Hat hat dazu im Bugreport geschrieben:

„A flaw was found in freetype in the way it processes PNG images embedded into fonts. A crafted TTF file can lead to heap-based buffer overflow due to integer truncation in Load_SBit_Png function.“

Wer in den letzten Tagen die Updates verfolgt hat, weiß, daß es fĂŒr Chrome, FireFox, Thunderbird eine schere SicherheitslĂŒcke beim Webseitenaufruf gab. Über den Bug im FreeType, einer Font-Rendering-Engine, die auch und gerade in Webbrowsern genutzt wird, konnte mit Hilfe eines manipulierten Fontfiles, und da zĂ€hlen auch WebFonts zu, das komplette System ĂŒbernommen werden.

Diese LĂŒcke betraf uns alle, und mit alle meine ich wirklich ALLE auf dem Planeten.

Wie kann eine so simple Sache wie einen Fontrendern, zu einer SystemĂŒbernahme fĂŒhren? Das liegt daran, daß es sich hierbei wohl um den ersten Schritt in einer ganzen Exploitchain handelt. Hat man erstmal den Fuß im Chrome oder Firefox, muß man nur noch dort ausbrechen können und das war bei Chrome ĂŒber einen Sandbox-Escape möglich. Danach findet sich im Kernel schon eine Schwachstelle, gerade bei Handies.

Von der Tragweite der LĂŒcke mal abgesehen, rankt sich um die Google Veröffentlichung noch einiges andere. In der Szene munkelt man von „Spionagekram“, wozu auch paßt, daß keiner der Beteiligten dazu irgendwas sagen möchte. Nachdem der Exploit verbrannt ist, dĂŒrften die frĂŒheren Nutzer ziemlich sauer auf Google sein. Das Google uns aber nicht sagen kann, woher die Exploits stammen und wie Sie darauf aufmerksam wurden, spricht dafĂŒr, daß es ein „us-heimischer“ Dienst war, sonst wĂ€ren die Antworten vermutlich anders. Aber, genaueres weiß man nicht, da keiner reden will.

Also feiert, daß ein Angriff weniger auf Euch möglich ist und wer von Euch Software schreibt, denkt bitte daran, wirklich sauber zu arbeiten, weil auch die unbedeutendste Lib einen immensen Schaden anrichten kann!

Firefox & Thunderbird: neue Remote-Code-Execution Schwachstelle

Warnung vom BSI:

10.11.2020 – TW-T20-0194

Mozilla Firefox/Thunderbird: Schwachstelle ermöglicht AusfĂŒhren von beliebigem Programmcode mit Benutzerrechten

Firefox & Thunderbird: neue Remote-Code-Execution

Betroffen sind :

  • Mozilla Firefox < 82.0.3

  • Mozilla Firefox ESR < 78.4.1

  • Mozilla Thunderbird < 78.4.2

Bekannt wurde die Schwachstelle bei einem Hackingwettbewerb in China:

„CVE-2020-26950: Write side effects in MCallGetProperty opcode not accounted for

In certain circumstances, the MCallGetProperty opcode can be emitted with unmet assumptions resulting in an exploitable use-after-free condition.“

Also, Updaten, Updaten.

LUKS2: CVE-2020-14382 – out of bounds write

Zeit fĂŒr ein Update von CryptSetup: CVE-2020-14382

LUKS2: CVE-2020-14382 – out of bounds write

CryptSetup ist das Tool, daß Luks Container, egal ob als Datei oder Festplatte, einhĂ€ngt und/oder bearbeitet. Eine LĂŒcke im Speicherhandling von CryptSetup kann von einem Angreifer ausgenutzt werden, indem er einen manipulierten Container einer anfĂ€lligen Version von CryptSetup prĂ€sentiert, was z.B. durch das Einstecken eines USB Sticks ausgelöst wird.

Die LĂŒcke in CryptSetup sorgt dafĂŒr, daß weniger Speicher allokiert wird, als tatsĂ€chlich angegeben ist, aber von dem manipulierten Inhalt des Containers aufgrund mangelnder GrenzprĂŒfungen, ĂŒberschrieben werden kann. Damit gelangt ggf. Code an eine Stelle, die von einem anderen Prozess genutzt wird. Die LĂŒcke CVE-2020-14382 kann also ggf. zu Arbitrary-Code-Execution fĂŒhren, wenn es im System dumm lĂ€uft.

Daher empfehle ich Euch kurz mal nach dem Zustand Eures CryptSetup Befehls zu schauen und ggf. zu Updaten, denn auch wenn Ihr selbst keine FestplattenverschlĂŒsslung benutzt, es reicht, daß das Paket auf dem System installiert ist und jemand einen USB Stick einsteckt.

Kleine Anmerkung zur Lage

Falls Ihr die Red Hat Securityliste lest, ist Euch auch aufgefallen, daß da heute ein ganzes Rudel (70+) Sicherheitsadvisories gekommen sind und die Bugs grĂ¶ĂŸtenteils Nummern aus 2018 und 2019 tragen? Ich glaube, da ist etwas arg schief gelaufen bei Red Hat.

Fedora: Kernelupdates fĂŒr BleedingTooth verfĂŒgbar

Moin, wie ich gerade gesehen habe, sind die Patche fĂŒr die 5.8er Kernels bereits in Fedora eingepflegt und die Kernel bereitgestellt worden.

Fedora: Kernelupdates fĂŒr BleedingTooth verfĂŒgbar

This update contains patches for the BleedingTooth CVEs.
The 5.8.15 stable kernel update contains a number of important fixes across the tree.
The 5.8.14 stable kernel update contains a number of important fixes across the tree.

IN YOUR FACE, ANDROID. <24h, so geht das mit Kernelupdates bei SicherheitslĂŒcken!

Danke Justin.

FunFact: Einige Mirrors habe die Updates noch nicht im Programm. Das resultiert in einer langen Fehlermeldungskette beim DNF, wird aber am Ende niemanden stören 🙂

[MIRROR] kernel-5.8.15-101.fc31.x86_64.rpm: Status code: 404 for https://mirror.dogado.de/fedora/linux/updates/31/Everything/x86_64/Packages/k/kernel-5.8.15-101.fc31.x86_64.rpm (IP: 185.3.234.216)
[MIRROR] kernel-core-5.8.15-101.fc31.x86_64.rpm: Status code: 404 for https://mirror.dogado.de/fedora/linux/updates/31/Everything/x86_64/Packages/k/kernel-core-5.8.15-101.fc31.x86_64.rpm (IP: 185.3.234.216)
[MIRROR] kernel-5.8.15-101.fc31.x86_64.rpm: Status code: 404 for http://mirror.dogado.de/fedora/linux/updates/31/Everything/x86_64/Packages/k/kernel-5.8.15-101.fc31.x86_64.rpm (IP: 185.3.234.216)

[MIRROR] kernel-modules-5.8.15-101.fc31.x86_64.rpm: Status code: 404 for http://ftp.icm.edu.pl/pub/Linux/fedora/linux/updates/31/Everything/x86_64/Packages/k/kernel-modules-5.8.15-101.fc31.x86_64.rpm (IP: 2001:6a0:0:31::2)
[MIRROR] kernel-core-5.8.15-101.fc31.x86_64.rpm: Status code: 404 for https://ftp.icm.edu.pl/pub/Linux/fedora/linux/updates/31/Everything/x86_64/Packages/k/kernel-core-5.8.15-101.fc31.x86_64.rpm (IP: 2001:6a0:0:31::2)
[MIRROR] kernel-modules-5.8.15-101.fc31.x86_64.rpm: Status code: 404 for https://ftp.icm.edu.pl/pub/Linux/fedora/linux/updates/31/Everything/x86_64/Packages/k/kernel-modules-5.8.15-101.fc31.x86_64.rpm (IP: 2001:6a0:0:31::2)

Ein anderer Mirror hatte das Paket dann doch schon, er ist nur nicht der schnellste.

BleedingTooth: Remote Code Execution in BlueZ Kernelstack

Kritische SicherheitslĂŒcke im Bluetooth-Stack von Linux und Android entdeckt. Bluetooth eingeschaltet zu haben, reicht aus um angreifbar zu sein.

BleedingTooth: Remote Code Execution in BlueZ Kernelstack

Kritische SicherheitslĂŒcke im Bluetooth-Stack von Linux vor Kernel 5.9 entdeckt. Der Fix wurde am 29.9. bereits heimlich in einen Kernel Branch eingepflegt und wartet seitdem auf den Merge in den Hauptkernel. Erst fĂŒr Kernel 5.9 war das der Fall, so daß derzeit alle GerĂ€te die mit Linux angreifbar sind, bis auch dort Backportpatche verfĂŒgbar sind.

Gefunden hatten diese LĂŒcken Intel ( „Intel – wie konnte das passieren, die finden doch sonst nichts“ )  und Google. Bei Google kann ich das verstehen, die verdienen damit Geld, aber Intel? 😉

Also RCE, Remote Code Execution, und das auch noch ohne Anmeldung. Meint: Jedes GerĂ€t mit aktiviertem Bluetooth in der NĂ€he ist angreifbar, nur weil es da ist. BleedingTooth ist dabei nicht nur eine LĂŒcke, sondern ein ganzes Sammelsurium an Schwachstellen, die kombiniert, den RCE mit Privilegien Eskalation erlauben.

Bis auf weiteres: BlueTooth abschalten!

Quellen:

https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00435.html

https://github.com/google/security-research/security/advisories/GHSA-h637-c88j-47wq  ( Die erlaubt die Code AusfĂŒhrung )

 

WOW: Battle.net Client erlaubt Privilegien Eskalation

Der Battle.net Client von Blizzard hat ein kleines Problem..nein, nein, nicht die Maskenpflicht im Spiel. Das hier:

WOW: Battle.net Client erlaubt Privilegien Eskalation

Local Privilege Escalation wegen Insecure File Permissions:

https://packetstormsecurity.com/files/159533/battlenet127112428-insecure.txt

Meint, ein „Angreifer“ kann das Battle.net.exe durch etwas anderes ersetzen und dann durch einen Neustart, so es denn automatisch beim Start von Windows mitstarten soll, wird das ersetzte Programm mit erweiterten Rechten ausgefĂŒhrt und dann passiert, was immer der Angreifer wollte.

Zitat aus der Exploitmeldung:

#6. Reboot the Computer

C:\Program Files (x86)\Battle.net> shutdown /r

#7. Login & look at that new Admin

C:\Users\lowpriv>net user placebo | findstr /i „Membership Name“ | findstr /v „Full“

User name placebo
Local Group Memberships *Administrators *Users
Global Group memberships *None

So macht angreifen Spaß, wenn man ohne Absturz des Systems einfach Admin werden kann 🙂

Nvidia: Applaus *klatsch* :(

Nvidia hat mal wieder den IT-Security Vogel abgeschossen: CVE‑2020‑5979 – Privilege Escalation im Configtool

Nvidia: Applaus *klatsch* 🙁

Nvidia Entwickler geben in Ihrem September Patch bekannt, daß sie es mal wieder geschafft haben: CVE Score 7.8

CVE‑2020‑5979:

NVIDIA Display Driver contains a vulnerability in the Control Panel component in which a user is presented with a dialog box for input by a high-privilege process, which may lead to escalation of privileges.

Neben einem Dutzend anderer Schwachstellen fĂŒr verschiedene Windows Komponenten von Nvidia, sticht die obige Schwachstelle heraus. Da hat der Entwickler, der die Funktion eingebaut hat, aber mal so richtig geschlafen. Muß man sich ungefĂ€hr so vorstellen (rein vom Prinzip her):

uibutton.onclick() {

System.shell.exec(„setuidprocess –commonopts=whatyoulike –target=“ + ui.getUserInputByTextRequest(„Pls enter the target type of you gpu“) );

}

Wenn ich einen Prozess der privilegiert ist, Argumente ĂŒbergeben muß, dann in einer Art und Weise, daß ein „Angreifer“ nicht einfach seine Wunsch Argumente eingeben kann und die dann ungefiltert z.B. in einer Shell ĂŒbernommen werden. In der RealitĂ€t dieses Bugs wird es vermutlich nicht sooo trivial sein. Leider ist noch nichts ĂŒber die Schwachstelle zu finden, außer dem, was Nvidia da schreibt, deswegen ist es der Phantasie des Lesers ĂŒberlassen, sich ein beliebiges passendes Horrorszenario auszudenken 😉

Im Beispiel oben könnte das so aussehen:

System.shell.exec(„setuidprocess –commonopts=whatyoulike –target=vgpu;rm -rf /“);

BerĂŒhmt sind solche Injection Attacken im Zusammenhang mit SQL Datenbanken. Wenn Argumente aus dem Netz einfach ungefiltert ĂŒbernommen werden ist das per se eine schlechte Idee. Da man eh derzeit nur spekulieren kann, wie und was da ablĂ€uft, sei Euch hiermit geraten ein Update fĂŒr Nvidia-Komponenten zu starten, sobald Ihr mit Lesen fertig sein 😉

CoronaChroniken: CVE fĂŒr die Corona API von iOS und Android

Liebe Maskierte,

die meisten Leser, die wegen Corona hier sind, werden CVE-Nummern nicht kennen. Diese werden in der IT vergeben, wenn eine SicherheitslĂŒcke gefunden wurde. Zu der Nummer gehört dann auch eine RisikoeinschĂ€tzung. FĂŒr die Corona-Melde-Api in iOS und Android wurde so eine Nummer beantragt, vergeben und bewertet.

CoronaChroniken: CVE fĂŒr die Corona API von iOS und Android

Letzte Nacht erreichte uns auf der Full-Disclosure Mailingliste eine entsprechende Meldung von Dirk-Wilhelm van Gulik:

CVE-2020-24721: (Corona) Exposure Notifications API for Apple iOS and Google Android risk of coercion/data leakage post notification  / CVSS v3.1 score: 5.9

Die Schwachstellen wurden als „Mangel zum Schutz gegen Zwang“ und ein Informationsleck beschrieben, kurz zusammen gefasst: Selbst wenn die App gelöscht wird, wird in dem Teil des Betriebssystems in dem die ganze Technik fĂŒr das Senden und Empfangen der Bluetooth untergebracht ist, der letzte Zustand gespeichert, weil die Anwendung darauf keinen Zugriff hat. Das bedeutet, ist die App einmal drauf und hat aktiv Daten gesendet oder empfangen, kann man das letzte Ergebnis nicht mehr vom Handy löschen. Damit kann ich nicht verhindern, daß jemand z.b. meine Aussendung „Ich bin ein Coronainfizierter“ aus dem (beschlagnahmten) Handy auslesen kann. Gleiches gilt fĂŒr den Umstand, das man einen Hinweis eingeblendet bekommen hat, daß man einem Infizierten begegnet ist. Das widerspricht natĂŒrlich dem Gedanken, daß man seinem Handy trauen kann.

Bei Android und iOS gibt es implementierungsabhĂ€ngige Abweichungen, aber im Prinzip leiden beide unter dem gleichen Problem. Eine Lösung, außer niemals die Apps zu benutzen, gibt es leider fĂŒr Euch nicht, denn nur Google und Apple können das Problem lösen.

An die 16 Millionen die es schon installiert haben: Ihr seid gewarnt worden! Selbst Schuld.

Verursacht wird dies, weil das Handy immer die gleichen Identifikationsmerkmale erzeugt, die mĂŒssen ja schliesslich eindeutig sein, und dies natĂŒrlich auch dann tut, wenn jemand anders die App wieder installiert. Die Datensammlung scheint ~30 Tage lang zu laufen, also erst nach dieser Zeit kann man sicher sein, daß zumindest keine „Sie sind einem Coronainfizierten begegnet“ Meldungen mehr kommen. Das andere Problem ist nicht lösbar, außer die Daten werden im internen Speicher des OS gelöscht. Da hilft dann nur der Factory-Reset.

Nun ist das bereits im Januar bekannt geworden, weil es ein Systemimmanentes Problem ist (sieht Zeitstrahl unten). Warum die Apps trotzdem gemacht wurden und Google und Apple nichts dagegen getan haben, ĂŒberlasse ich mal Eurer Fantasie, sofern Ihr welche habt. Auch wenn die Hinweise aus Holland kommen, die in den Handies verbauten Frameworks sind immer die gleichen, also gilt das auch fĂŒr unsere deutsche App.

GlĂŒcklicherweise, wurde die App ist ja laut AmtsĂ€rzten derzeit als zweckfrei angesehen, also löscht die jetzt einfach und hofft darauf, daß Ihr in den nĂ€chsten 30 Tagen nicht von jemandem gezwungen werdet, sie erneut zu installieren.

FĂŒr Interessierte:

Variations of this flaw have been documented by the DP3T team in their academic paper. It was found it the Apple/Google implementations during the build of the dutch ‚Corona Melder‘ app (https://github.com/minvws).

2020-01-18 first known description of this class of issues
2020-04-03 first paper by DP3T team published.
2020-05-06 confirmation of this issue with Google
2020-05-07 confirmation of this issue with Apple
2020-08-13 final written/formal questions sent on request (#115 and 115.bis) as a vulnerability report.
2020-08-13 confirmation vendor. 2020-08-27 CVE issues by MITRE
2020-09-13 Request vendor to provide CVE/start FD.
2020-09-15 Versions under embargo sent to google/apple. Confirmation of receipt and reference # for both received.
2020-09-15 Full disclosure timeline setting process started.
2020-09-22 Reminder to google/apple & request to submit their preferred timeline/disclosure approach.
2020-09-25 Deadline to provide timeline preferences and feedback passed.
2020-09-29 Vendor informed that public disclosure is imminent.

 

 

Fedora: Die DNS Geschichte trĂ€gt FrĂŒchte

Wer die Mailingliste von Fedora-Devel gelesen hat, wird es mit bekommen haben: Das Thema systemd-resolved & DNS trenden enorm.

Fedora: Die DNS Geschichte trĂ€gt FrĂŒchte

Als eine Konsequenz der Diskussion wurde ein Änderungsvorschlag der DNS Gruppe von Michael Catanzaro eingereicht, daß systemd-resolved ab sofort mit einem optimistischen DoT aktiviert wird, also DNS-over-TLS, dem Ă€lteren Bruder von DNS-over-HTTPS ( DoH ).

Das meint fĂŒr den Benutzer, wenn ein eingestellter DNS Server DoT unterstĂŒtzt, und das findet man leicht mit einem Connectversuch auf den passenden Port 853 heraus, soll automatisch die VerschlĂŒsselung benutzt werden. Das ist natĂŒrlich aus DatenschutzgrĂŒnden zu bevorzugen.

Der Nachteil der Sache ist leider, daß die DNS Anfragen nicht ganz so schnell kommen, wie man das gewohnt ist, weil ja mehr Daten und VerschlĂŒsselung im Spiel sind. Es ist aber ein Weg in die richtige Richtung.

Ein bisschen laut Lachen mußte ich allerdings bei der Passage:

== Benefit to Fedora ==

DNS queries are encrypted and private by default, if the user’s ISP supports DoT. Most probably don’t, but users who manually configure a custom DNS server (e.g. Cloudflare or Google) will automatically benefit from DNS over TLS.

Ausgerechnet die beiden DNS Server zu empfehlen, die das PrivatsspĂ€hrenproblem im systemd-resolved sind, ist schon eine Farce 😀

 

Systemd: resolved verkauft User u.U. an Google und Cloudflare

Was so alles ans Licht kommt, wenn man Mailinglisten verfolgt. Quasi in einem Nebensatz hat Herr Pöttering kurz mal erklĂ€rt, daß systemd gegen die DSGVO verstĂ¶ĂŸt.

Systemd: resolved verkauft User u.U. an Google und Cloudflare

Die DSGVO legt fest, daß alle Systeme die zum Einsatz kommen, in einer datenschutzfreundlichen Voreinstellung daher kommen mĂŒssen. Merkt Euch das mal fĂŒr spĂ€ter.

Hier erstmal ein Auszug aus dem Posting von Herrn Pöttering:

„Also, people would react very allergic if we’d start sending all DNS traffic to google or so. I mean, you can’t believe how pissed people are that we have a fallback in place that if no DNS servers have been configured at all or acquired via DHCP we fall back to Cloudflare + Google DNS servers. Downstream distros (Debian
) tend to patch that fallback out even…“ (Fedora ML, 29.9. 10:19)

Meint auf deutsch:

„Außerdem wĂŒrden Menschen sehr allergisch reagieren, wenn wir anfangen wĂŒrden, alle DNS Verkehr zu googlen oder so. Ich meine, Sie werden es nicht glauben, wie sauer die Leute sind, dass wir einen Fallback haben, der, wenn ĂŒberhaupt keine DNS-Server konfiguriert sind oder ĂŒber DHCP erworben werden, greifen wir auf Cloudflare + Google DNS-Server zurĂŒck. Downstream-Distributionen (Debian…) neigen dazu, das sogar raus zupatchen …“

Oh, ja, da reagieren wir Menschen allergisch drauf, weil das einen Verstoß gegen den Datenschutz darstellt. Die Debinaleute sehen das ganz richtig. Man kann nicht einfach heimlich am Benutzerwunsch oder Adminunvermögen hinweg Daten an Google oder Cloudflare schicken. Wenn das in einer Firma, einem Verein oder einer Behörde passieren wĂŒrde, dann wĂ€re das ein DSGVO Verstoß der bestraft wĂŒrde! Scheinbar hat hier jemand die Jahre 2016-2019 verschlafen, als die EU Gerichte mit so etwas aufgerĂ€umt haben. Zur Erinnerung: US Privacy Shield .. zusammengebrochen, Facebook droht mit RĂŒckzug aus der EU, Google & MS verlegen Ressourcen in die EU, damit sie weiter im Spiel bleiben können und dann kommt ein Systemd daher, der die DSGVO unterminiert.

Man stelle sich mal vor, eine grĂ¶ĂŸere Firma in der auch Linux als Desktop zum Einsatz kommt und dann steht in irgendsoeiner hart gecodeten .so drin, sie soll Google kontaktieren. FĂŒr alle die nicht wissen, was Datenschutz in Firmen heutzutage bedeutet:

  1. Zuerst muß man mal ermitteln wohin was fĂŒr Daten abfließenund wen das genau betrifft
  2. Dann muß man eine DatenschutzfolgeabschĂ€tzung dafĂŒr machen
  3. Dann muß man geeignete Schutzmaßnahmen ergreifen.
  4. Das muß als Vorgang mit laufender Nummer in die Datenschutzmappe eingetragen werden.

Jetzt habe ich als Admin also einen DNS Cache fĂŒr die Firma hingestellt und per DHCP teile ich dieses DNSCache allen PCs mit. Die PCs fragen also meinen DNS Cache und der fragt dann wen auch immer.Das DNS Cache wird also schon eine Reihe von meinen Abfragen so beantworten können, was den Datenschutzvorteil hat, daß der DNS, den das Cache wiederum fragt, nur einen Bruchteil davon sieht und so kein vollstĂ€ndiges Profil erstellen kann. Den DNS Cache ( z.b. nscd ) kann man auch per Round-Robin mehrere andere Server fragen lassen um die Profilbildung weiter zu erschweren.

Der Problemfall

Jetzt funktioniert der lokale DNS aber nicht, weil es ein Update gab, oder die VM abgestĂŒrzt ist. Systemd wĂŒrde jetzt keine gĂŒltigen DNS bekommen und Google+Cloudflare fragen. Damit wĂ€re meine komplette DatenschutzabschĂ€tzung fĂŒrn Arsch. Schlimmer noch ist der Umstand, daß diese Art Datenfluß als Vorgang ĂŒberhaupt gar nicht in meiner Datenschutzmappe vorkommt. Zum GlĂŒck ist das ein minder schwerer Fall, den der Datenschutzbeauftragte selbst regeln kann, indem er den Vorfall in die Mappe eintrĂ€gt und Maßnahmen ergriffen werden, dies zukĂŒnftig zu verhindern.

Sollte aber ein Datenschutzaudit ergeben, daß es diesen Abfluß gibt ohne das das intern gefunden wurde, sieht die Sache schon anders aus. Je nach Umfang könnte die Datenschutzbehörde ein Bußgeld verhĂ€ngen und das nur weil einer, den keiner in der Firma kennt, meinte schlauer sein zu mĂŒssen, als alle anderen. Na danke!

Jetzt kommt der nĂ€chste Oberschlaue mit dem Hinweis, daß bei DSL ja eh alle die gleiche IP von der Firma haben und individuelle Profile gar nicht erstellt werden können und außerdem wĂ€ren das ja keine privaten Domainanfragen. Das fĂ€llt bei grĂ¶ĂŸeren Firmennetzen seit IPv6 unter „Es war einmal..“ . Wenn ich einen Businesszugang mit einem reinen IPv6 Netz bekommen, habe ich einen ganzen Block zur VerfĂŒgung. Dies Netz kann ich direkt an alle Pcs durchreichen, denn dann habe ich kein NAT Problem mehr. Per Firewall kann ich den Direktzugang zu den Pcs sperren, kein Problem und wenn doch mal jemand von außen drauf muß, wĂ€ren individuelle Freigaben möglich. Das muß man als Admin natĂŒrlich auch mit IPv6 nicht so machen, aber es wurde mal so vermarktet, als fĂŒr IPv6 geworben wurde.

Das die meisten am Arbeitsplatz auch privat surfen, braucht man wohl kaum noch erwÀhnen.

Die Technisch -Organisatorischen Maßnahmen zum Datenschutz einer Firma ( TOM ) beinhalten alle Maßnahmen die man so als Firma macht und wenn da steht, wir leiten DNS ĂŒber ein Cache zum minimieren von Profilbildungen, dann kann man da schlecht ein Linux betreiben, daß sich da nicht dran hĂ€lt, oder seht Ihr das anders? Linux muß also auch in der Datenschutz freundlichen Einstellung daher kommen, was damit einen Einsatz von systemd-resolved ausschließt, da man sich da ja nicht drauf verlassen kann wie man oben sieht.

Update

Ein Leserbrief erreichte mich vorhin. Hier ist der Link, in dem das Fallbackfeature bei Systemd besprochen wird: https://github.com/systemd/systemd/pull/11666

Und gleich noch die Diskussion, wieso CloudFlare DNS besser wÀren: https://github.com/systemd/systemd/issues/8899

So richtig viel Gegenwind gabs aus der Peergruppe anscheinend nicht.