Spectre/Meltdown Spec store bypass: vulnerable

[Xela69]

Hallo zusammen,

habe eine Frage an die Kernelgemeinde:

Ein VPS mit aktuellem Debian 11, Vanillakernel 5.17.13 (stable),

CONFIG_BLK_DEV_INITRD=y
CONFIG_MICROCODE=y
CONFIG_MICROCODE_INTEL=y

$ uname -a
Linux vps-xxxx 5.17.12 #1 SMP PREEMPT Fri Jun 3 18:10:10 UTC 2022 x86_64 GNU/Linux,

mit installiertem intel-microcode und ausgefuehrtem 'update-initramfs -u'.

$ dmesg | grep -i microcode

Zeigt leider nichts und

$ lscpu

zeigt weiterhin:
Vulnerability Spec store bypass: Vulnerable

Zur Info: Verwendet wird GRUB2, da das BIOS kein UEFI hat.

Habt Ihr eine Idee, was hier falsch laeuft?

[MSfree]

Was liefert

Code: Alles auswählen

lscpu | grep Model

?

[Xela69]

Model: 60
Model name: Intel Core Processor (Haswell, no TSX)

[eggy]

Virtualisierte Kiste? Dann würde mich sehr wundern, wenn Du da Microcode einspielen darfst.

[Xela69]

Soll laut dem Cloudanbieter gehen. Er gibt sogar an, wie im VPS mitigiert werden kann.

[MSfree]

Soll laut dem Cloudanbieter gehen.

Der Microcode muß aber meines Wissens im Hostsystem eingespielt werden, nicht auf den virtuellen Maschinen. Es sieht so aus, als ob das bisher nicht passiert ist. Auf die Hosts hat aber nur der Provider Zugriff. Vor allem müssen dazu alle laufenden VMs runtergefahren werden, mit entsprechender Vorwarnung für die Mieter dieser VMs.

[Xela69]

Laut seinen Aussagen (Support) ist dies geschehen.

From
Cloud Support

Hello,

it doesn't indicate any vulnerability patching as it is already patched on all of our hosts. Like we indicated earlier, this vulnerability is not a problem anymore even though you can't check it directly. The host is already patched, meaning the VPS located on the host is also patched.

Have a good day,

Date received
07/06/2022 11:06

[eggy]

Wünsche weiterhin viel Spaß mit der Salamitaktik.

[Xela69]

@MSfree: Laut den Anweisungen auch im VPS. Sicherlich muss der Microcode auch auf den Hosts installiert werden, was angeblich schon geschehen ist. Davon ausgegangen, dass die Hosts als Cluster laufen, da 99,9%, muss nicht heruntergefahren werden. Die Nodes koenn(t)en einzeln neu starten. Sicherlich muessen dann die VPS's neu gestartet werden.

[Xela69]

INCIDENCE REPORT OF 06/16/2022 - SPEC STORE BYPASS - VARIOUS CLOUD PROVIDERS

Meltdown and Spectre

Passwords and Sensitive Data Leaked Due to Vulnerabilities in Modern Computers

Meltdown and Spectre are known risks in modern processors for exploitation. Although programs are generally not allowed to read the data found on other programs, malicious programs can use the vulnerabilities in Meltdown and Spectre to access stored secrets. Programs are primed to exploit these two critical vulnerabilities in hardware to steal data being processed via the computer. An example of this might be the passwords kept in a password manager or browser, personal photos and messages, emails, and possibly even business-critical documents.

Meltdown and Spectre in action:
https://www.youtube.com/watch?v=RbHbFkh ... e=emb_logo
https://www.youtube.com/watch?v=bReA1dv ... e=emb_logo
https://www.youtube.com/watch?v=kwnh7q3 ... e=emb_logo
https://www.youtube.com/watch?v=L1N1P2z ... e=emb_logo

Incidence

After Debian announced in 2019 that there were now sufficient mitigations against Spectre/Meltdown in the current versions (https://wiki.debian.org/DebianSecurity/SpectreMeltdown), several Virtual Private Servers (VPS) were set up in the cloud and tested for the aforementioned vulnerabilities. The same, of course, was tested previously on a Linux workstation. Amazement occurred when after over thirty years there was finally a solution and it was easy to get it out. On the console, a “$ lscpu” was enough. The workstation with an Intel Xeon(R) CPU E5-2690 v2 with 10 cores was mitigated against Spectre/Meltdown:

Code: Alles auswählen

Vulnerability Itlb multihit:     KVM: Mitigation: Split huge pages
Vulnerability L1tf:              Mitigation; PTE Inversion; VMX cache flushes, SMT disabled
Vulnerability Mds:               Mitigation; Clear CPU buffers; SMT disabled
Vulnerability Meltdown:          Mitigation; PTI
Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl and seccomp
Vulnerability Spectre v1:        Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2:        Mitigation; Retpolines, IBPB conditional, IBRS_FW, RSB filling
Vulnerability Srbds:             Not affected
Vulnerability Tsx async abort:   Not affected

The same was then immediately tested on multiple cloud instances, with the end result:

Code: Alles auswählen

Vulnerability Itlb multihit:     KVM: Mitigation: VMX disabled
Vulnerability L1tf:              Mitigation; PTE Inversion; VMX conditional cache flushes, SMT disabled
Vulnerability Mds:               Mitigation; Clear CPU buffers; SMT Host state unknown
Vulnerability Meltdown:          Mitigation; PTI
Vulnerability Spec store bypass: Vulnerable
Vulnerability Spectre v1:        Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2:        Mitigation; Retpolines, STIBP disabled, RSB filling
Vulnerability Srbds:             Unknown: Dependent on hypervisor status
Vulnerability Tsx async abort:   Not affected

It was immediately noticed that everything was mitigated except for the Spec store bypass. Immediately, cloud support was contacted, who pointed out that this was not in their area of responsibility and referred to a link:

Cloud Support:
„This issue is connected with server configuration, we do not support it within our scope. Our support provides technical support for hardware issues and the proper functioning of our network. The management of the server (i.e. the system / scripts / services and their configuration) lies with the client. We do not have access to customers’ operating systems or the ability to perform operations on your file system.“

The link received led to a table showing the Spectre/Meltdown vulnerabilities and the status of the mitigations of the cloud provider's instances. According to the table, all hosts had been mitigated by the cloud provider, which could be easily seen by a green highlighted “DONE.” The third column, titled “Spectre - Variant 2,” which also included the “Spec store bypass” vulnerability, showed mitigation options for Linux and Windows systems. These were marked with a yellow highlighted “IN PROGRESS.”

The mitigation options listed there were tested on various Virtual Private Servers, with a Debian 11, current stable kernel from kernel.org (5.17.12), and current Intel microcode (0x1), also with the kernel parameters required according to the documentation from kernel.org (https://docs.kernel.org/admin-guide/hw- ... ectre.html). Unfortunately, without positive success.

Then it was also tested with a plugin called “KernelCare,” which was offered for Plesk Server (https://www.plesk.com/extensions/kernelcare/). Again, without positive success. The Debian system still showed that it was vulnerable to “Spec store bypass.”

Code: Alles auswählen

Vulnerability Spec store bypass: Vulnerable

Why were all virtual instances mitigated except from “Spec store bypass?” Why couldn’t this be mitigated according to the instructions given in the table by the cloud provider? What was behind the “Spec store bypass” vulnerability?

A look at the “NIST Vulnerability Database” provided some clarification:

Link: https://nvd.nist.gov/vuln/detail/CVE-20 ... ptionTitle

„Unauthorized disclosure of information“ !

Analysis Description

Systems with microprocessors utilizing speculative execution and speculative execution of memory reads before the addresses of all prior memory writes are known may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis, aka Speculative Store Bypass (SSB), Variant 4.

“Attack Vector(AV)” is “Low”: this is only possible with physical access to the machine, the “Base Score” here is “Medium.”
The “Attack Complexity” is “Low”: this vulnerability is possible with just a little technical effort.
“Privileges Required” is “Low”: no or only local user rights are required to access information on the affected machine.
“Confidentiality” is classified as “High”: data confidentiality is not given.
“Integrity” and “Availability” is “Low”: not affected.

It turned out that the kernel parameters on the hosts, to which a VPS operator did not have access, were set in such a way that mitigation, especially against “Spec store bypass” on the cloud provider's Virtual Private Servers, was not intended, although it was possible with correctly set kernel parameters on the part of the cloud provider.

With the help of the engineers from Plesk Support, the cloud provider was informed about this. The cloud provider refused to change anything in this regard. The engineers from Plesk Support then withdrew, probably because of the explosive nature of the issue.

„From
Cloud Support

Hello,
it doesn't indicate any vulnerability patching as it is already patched on all of our hosts. Like we indicated earlier, this vulnerability is not a problem anymore even though you can't check it directly. The host is already patched, meaning the VPS located on the host is also patched.
Have a good day,
Date received 07/06/2022 11:06“

Conclusion

The confidentiality of the data stored in the Virtual Private Servers was not guaranteed. With little technical effort, this data could be viewed by the cloud provider.

Even with the mitigations against Spectre/Meltdown provided by Debian and Intel since 2019, Virtual Private Servers could not be fully mitigated against Spectre/Meltdown because the cloud provider refused to do so by unknowingly or even intentionally not setting kernel parameters correctly on the hosts. The “Spec store bypass” vulnerability was affected. It would be advisable to check whether there was intent because the privacy of others could be violated here.

From experience, this did not only affect a single cloud provider but also cloud providers that were already ISO 27001 certified.

The hosts had to be configured correctly so that the Virtual Private Servers could also be mitigated against Spectre/Meltdown, especially in the case of “Spec store bypass,” to ensure the confidentiality of the data in the Virtual Private Servers and to be compliant with the European Data Protection Regulation (GDPR).

In the event of any criminal investigations, the operators of the Virtual Private Servers are to be contacted with a court order. The cloud provider should be excluded from this process. This also ensures that no data are arbitrarily released or revealed by the cloud provider, which cannot be controlled. In the event of gross violations, the cloud provider has the option of shutting down the concerned Virtual Private Servers without violating the privacy of others.

Further informations:

NIST - National Institute of Standards and Technology: https://en.wikipedia.org/wiki/National_ ... Technology
NIST - National Vulnerability Database: https://nvd.nist.gov/general
Meltdown and Spectre: https://meltdownattack.com/
Debian: https://en.wikipedia.org/wiki/Debian
Debian Security Tracker: https://security-tracker.debian.org/tra ... -2017-5754

*************************************************
This incidence was reported to BSI (https://www.bsi.bund.de/) on 6/16/2022 and receipt was confirmed.
This incidence was reported to CERT-EU (https://cert.europa.eu/) on 7/12/2022 and delivery was confirmed.
This incidence was reported to enisa CERT community (https://www.enisa.europa.eu/) on 7/20/2022 and delivery was confirmed.
Special thanks for proof reading the English text to Chrissy Cutting: https://www.fiverr.com/ccutting
*************************************************

[Xela69]

Warum Demokratie Privatsphäre braucht

Je mehr jemand über uns weiß, desto mehr kann er uns beeinflussen. Wir können demokratische Macht nur ausüben, wenn unsere Privatsphäre geschützt ist.

von Carissa Véliz

Deutsche Uebersetzung:
https://bostonreview-net.translate.goog ... r_pto=wapp

[TRex]

Du vertraust deinem Provider nicht, dass er ne Lücke gepatcht hat. Und nun? Was soll uns der generische Aufruf sagen?

[Xela69]

Du vertraust deinem Provider nicht, dass er ne Lücke gepatcht hat. Und nun? Was soll uns der generische Aufruf sagen?

Um Dich zu korrigieren:
Du vertraust deinem Provider nicht, dass er ne Lücke NICHT gepatcht hat. Tipp: Lies den erwaehnten Artikel.

[TRex]

Nein, den lese ich nicht. Du hast jetzt doppelte Verneinung aus meiner Aussage gemacht. Da steht nicht ",weil", sondern ",dass".

Du hast Angst, dass dein Provider mittels Spectre/Meltdown deine Daten abgreift. Mein Fazit ist deswegen: wenn du deinem Provider nicht vertraust, nimm ein Angebot, wo dein Provider prinzipbedingt weniger Kontrolle hat oder stell dir ne eigene Kiste irgendwo hin.

[Xela69]

TRex, es geht hierbei nicht um meine privaten Belange. Als ISP betreut meine Firma Anwaelte, Hotels/Resorts und andere Firmen, deren Server nicht nur dediziert sind, sondern auch in der Cloud verwaltet werden. Mir ist eine Luecke in der Cloud aufgefallen, worauf ich oben lediglich hingewiesen habe, damit andere gewarnt werden und diese Luecke geschlossen wird. Ein Dritter hat nicht in deren Privatsphaere wie Firmendaten, Kreditkartenabrechnungen u.s.w. herumzuschnueffeln, was nach Jahrzehnten Vernachlaessigung nun endlich seit dem 27. April 2016 von der EU mit der General Data Protection Regulation (GDPR), zu Deutsch Datenschutzgrundverordnung (DSGVO), geregelt wird. Viele Cloud-Anbieter bewerben ihre Virtuellen Privaten Server mit eCommerce, Content, Medien und mehr. Sogar, dass sie ISO 27001 zertifiziert sind. Dann sollen sie sich auch daran halten. Gewisse Dienste haben sicherlich eigene Moeglichkeiten, um an ihre gewuenschten Daten heranzukommen. Weiter gehe ich nicht darauf ein.

[Blackbox]

Was ist das schon wieder für eine Pseudodiskussion?
Dir ist angeblich aufgefallen, dass virtualisierte Server möglicherweise ein Sicherheitsrisiko enthalten, weil ein Hoster vermeintlich keinen CPU-Microcode einspielt?
Allerdings bestreitet der Hoster genau dieses Versäumnis, was deine Darstellung wenig glaubhaft macht.

Und anstatt hier heiße Luft zu produzieren, könntest du deine Behauptung beweisen, oder Maßnahmen ergreifen, die diese Situation naheliegend bereinigt.

[Xela69]

Deine vermeintlichen, allerdings definitiv Pro Provider ausgerichteten Argumente gehen an der Sache vorbei. Sie haben eben diese Lücke nicht oder nur vermeintlich geschlossen, die Sicherheitslücke bleibt bestehen. Anstelle einer Verwässerung der Sachlage "Pseudodiskussion" hatte ich etwas mehr fachliche Tiefe erwartet.

Das Problem besteht darin, dass offensichtlich auf den Hosts die Kernelparameter so gesetzt sind, dass Itlb, L1tf, Mds, Meltdown, Spectre v1, Spectre v2 und Srbds in den VPS's mitigiert werden koennen, aber nicht Spec store bypass. Siehe Inzidenz-Report vom 16.06.2022 weiter oben.

Red Hat schreibt:

"Nach der Entdeckung dieser Schwachstellen haben sich führende Technologieunternehmen, darunter auch Red Hat, zusammengetan, um diese Probleme noch vor der öffentlichen Bekanntgabe durch eine Kombination aus Hardware- und Software-Updates zu entschärfen. .... Systemadministratoren, die Speculative Store Buffer Bypassing global deaktivieren möchten, können dies schnell und einfach über den neuen Kernel-Parameter "spec_store_bypass_disable" tun. .... Das Seccomp-Framework wurde in den letzten Linux-Kernel-Updates so verändert, dass seine Verwendung automatisch den Nebeneffekt hat, dass der Speculative Store Buffer Bypass deaktiviert wird, was einer explizit programmierten "prctl"-Anforderung durch Anwendungen entspricht. Systemadministratoren können den Entschärfungsstatus eines bestimmten Systems schnell feststellen, entweder global (in den Kernel-Boot-Protokollmeldungen und durch einen Eintrag für neue Sicherheitslücken in sysfs) oder auf Anwendungsebene, indem sie sich die "Status"-Datei in /proc für die laufende Anwendung ansehen. In vielen (aber nicht allen) Fällen ist für eine vollständige Entschärfung auch ein aktualisierter Mikrocode vom Hersteller des System-Mikroprozessors erforderlich. Red Hat und andere Anbieter haben mit der Upstream-Linux-Kernel-Community zusammengearbeitet, um Best Practices sowie neue Sicherheits-APIs zu entwickeln, einschließlich Abhilfemaßnahmen gegen die Ausnutzung des Speculative Store Buffer Bypass, die global oder prozessbezogen aktiviert werden können. Darüber hinaus stellen wir Updates für gängige Managed-Code-Umgebungen bereit, die Gegenstand von Angriffen sein könnten. Sie sollten diese Updates zusammen mit den erforderlichen Microcode-Updates so bald wie möglich anwenden."

Das auf dieser Seite befindliche Video von Red Hat erklaert, dass nicht nur Kreditkarteninformationen mittels Spec store bypass gestohlen werden koennen.

Quelle: https://www.redhat.com/en/blog/speculat ... w-it-works

Zu den Technologieunternehmen, anderen Anbietern, gehoert auch Debian. Und laut Debian ist auch dort diese Schwachstelle in der aktuellen Version bereits seit 2019 gefixed, siehe: https://security-tracker.debian.org/tra ... -2017-5754

Offensichtlich liegt hier eine falsche Konfiguration der Hosts vor. Hier einfach die durchsichtige und schwachen Ausführungen, Position des Providers zu übernehmen, ist definitiv kein hilfreicher Beitrag.

[TRex]

Als ISP betreut meine Firma [...]

Und jetzt nochmal zurück zu meinem Punkt: auf einem virtualisierten Server kannst du den Provider nicht ausschließen. Auf dem Level der Sicherheitslücke wärs einfacher, sich den Arbeitsspeicher der virtuellen Maschine anzuschauen, das kann er nämlich. Als ISP würde ich von dir erwarten, dass du sowas weißt, und bei Bedarf selbst Kisten anmietest, um das zu umgehen, oder dich damit abfindest. Ich hab durchaus verstanden, was dein Problem ist, dass der zwar was getan hat, aber seine Konfiguration eben die Vollständigkeit des Patchs versaut (oder das Testresultat verfälscht, keine Ahnung). Und ich sage dir, es ist egal, wegen der eingangs angeführten Gründe.

Es ist nett, dass du ein Problem identifiziert hast, und ohne den ganzen unnötigen Text drumrum wäre der Hinweis für einige Serverbetreiber sogar interessant, dass eine gewisse Konfiguration zur unvollständigen Mitigation führt. Aber der finale Rat an dich ist eben nicht, hier nach Leidensgenossen zu suchen, die dann mit Fackeln und Mistgabeln zu den Providern laufen, sondern zu überlegen, wie du dein eigenes Sicherheitsbedürfnis tatsächlich und nachhaltig erfüllen kannst.

[Blackbox]

Deine vermeintlichen, allerdings definitiv Pro Provider ausgerichteten Argumente gehen an der Sache vorbei. Sie haben eben diese Lücke nicht oder nur vermeintlich geschlossen, die Sicherheitslücke bleibt bestehen.

Verstehe, wenn ich dir du hast noch immer nicht verstanden, was nun richtigerweise zu tun wäre?
Weil die Ursache dieser Fehlentscheidung bei dir zu suchen ist, und noch immer vorgezogen wird, mit dem Finger auf andere zu zeigen, anstatt endlich die eigenen Versäumnisse aufzuräumen.

Anstelle einer Verwässerung der Sachlage "Pseudodiskussion" hatte ich etwas mehr fachliche Tiefe erwartet.

Sagen wir es einmal so, ich erwarte auch so einiges, zum Beispiel keine Multis und zumindest ein Grundverständnis von professioneller Serverinfrastruktur.
Wenn man überhaupt glauben soll, was da präsentiert wird.

[Xela69]

Die Zeiten sind gluecklicherweise vorbei. RAM ist mittlerweile verschluesselt. Seitenkanalinformationen, wo ein Oszilloskop zum Einsatz kam, sind auch verschluesselt. Warum hat die Industrie wohl solch einen riesengroßen Aufwand fuer die Mitigationen gegen Spectre/Meltdown in den vergangenen 5 Jahren erbracht? For nothing? Und warum artet das ueberhaupt so aus? Es geht um einen einzelnen Kernelparameter, welcher auf den Hosts richtig gesetzt werden muss, was definitiv moeglich ist, damit die Virtuellen Privaten Server auch mitigiert werden koennen. Wo liegt denn da das Problem? Wir stecken in den Anfaengen einer neuen Industriellen Revolution - Industrie 4.0. Da kommen soviele neue Sachen in den naechsten Jahrzehnten. Macht es doch einfach mal richtig!

[Blackbox]

Macht es doch einfach mal richtig!

Es wäre doch toll, wenn man selbst die eigenen Empfehlungen umsetzte.
Wenn das Paranoia-Level bereits sehr niedrig aufgehängt ist, wieso wird dann nicht von Anfang an, auf die in diesem Fall einzig richtige Lösung gesetzt?
Und schon sind wir wieder beim Verständnis professioneller Serverinfrastruktur.

Das mit wird auch nicht das Problem verharmlost, sondern die Form der Präsentation angeprangert.

[Xela69]

Wenn damit nicht das Problem, sondern nur die Präsentation angeprangert wird, dann lassen wir doch die Haarspalterei und konzentrieren uns auf das Problem.

Denn wie gesagt, ausser ... hatten wir schon ... Schuld auf andere schieben ... hast Du bis jetzt nichts mit Substanz beigetragen. Und ich benoetige auch keine Lektion in der Praesentation, das koennen dann die Oberlehrer machen, ich habe um echte Hilfe und fachgerechte Stellungnahme gebeten.

Klar, waehrend ich das Problem sehr konkret geschildert habe (siehe Inzidenz-Report oben), ergiesst Du Dich weiterhin in allgemeinen wischiwaschi Aeusserungen.

Ich bin der Meinung, ich habe da echt eine Sicherheitsluecke entdeckt.

Wenn ich Deiner Meinung nach etwas falsch mache, erwarte ich etwas Erleuchtung von einer Person, die ja offensichtlich erhaben über dem steht.

Da du es ja genau weisst...
Butter bei die Fische.

Was habe ich genau falsch gemacht und wann und wie zeige ich mit dem Finger auf andere?
Wie loest man das Problem?

Ansonsten sind weitere Beitraege nicht noetig. Wer so allgemein daher argumentiert, sollte es dann besser lassen.

[bluestar]

Was habe ich genau falsch gemacht

Du solltest die gefundene Sicherheitslücke cia Responsible Disclosure an die, deiner Meinung nach, betroffenen Anbieter senden und deren Rückmeldung abwarten, bevor du hier so einen Wirbel machst.

und wann und wie zeige ich mit dem Finger auf andere?

Gar nicht!

Wie loest man das Problem?

Durch Besonnenheit. Ich persönlich finde deinen Beitrag wirklich spannend und ich nehme ihn zur Bewertung mit in eine fachliche Runde.

[Blackbox]

Wenn damit nicht das Problem, sondern nur die Präsentation angeprangert wird, dann lassen wir doch die Haarspalterei und konzentrieren uns auf das Problem.

Richtig, du solltest aufhören, mir die Worte im Mund herumdrehen zu wollen, wenn du von mir ernst genommen werden möchtest.

Denn wie gesagt, ausser ... hatten wir schon ... Schuld auf andere schieben ... hast Du bis jetzt nichts mit Substanz beigetragen.

Ja, du schiebst die Schuld deiner Fehlentscheidungen, dich für virtualisierte Server entschieden zu haben auf den Hoster und .
Da dein Paranoia-Level aber sehr niedrig ist, war das wohl genau die erste Fehlentscheidung.

Du bist (wie du sagst) bereits einmal bei deinem angeblichen Hoster abgeblitzt.
Wieso wohl?

Die zweite Fehlentscheidung war es dein Problem mit deinem angeblichen Hoster hier diskutieren zu wollen, anstatt dein Problem noch einmal klar zu fassen und wiederholt mit deinem angeblichen Anbieter in Verbindung zu treten.

Und ich benoetige auch keine Lektion in der Praesentation, das koennen dann die Oberlehrer machen, ich habe um echte Hilfe und fachgerechte Stellungnahme gebeten.

Und was meinst du, wie könnten wir dir bei einem Problem mit deinem angeblichen Hoster helfen?
Im Moment gibst du hier den Oberlehrer.

Ich bin der Meinung, ich habe da echt eine Sicherheitsluecke entdeckt.

Nein, du berichtest hier von einem Implementierungsfehler, den bereits andere entdeckt und dokumentiert haben, unter anderem Red Hat.
Das ändert aber nichts an dem Fakt, dass du die angeblichen virtualisierten Server angemietet hast und darauf einen Business case aufbaust, den dein Paranoia-Level überhaupt nicht zulässt.

Da du es ja genau weisst...

Ich weiß gar nichts und beschränke mich darauf die Widersprüche in deiner Darstellung zu hinterfragen.
Außerdem gebe ich kommerziellen Anbietern grundsätzlich keinen Support.

Was habe ich genau falsch gemacht und wann und wie zeige ich mit dem Finger auf andere?

Das habe ich bereits weiter oben beschrieben und eine mögliche Lösung wurde dir auch bereits angeboten.

Wie loest man das Problem?

Von mir gibt es keinen Support für Fragende mit kommerziellem Interesse.
Bei mir gibt es auch keinen Denksupport, das wäre dann dein Part.

[Xela69]

Haha, erst ist es die Form meiner Praesentation, dann "weigerst" Du Dich "kommerziellen Anbietern" hier zu helfen oder sie zu supporten.

Und Fragen zu stellen und ein Thema zur Diskussion zu stellen ist ja wohl kaum in einen logischen Zusammenhang zu bringen mit oberlehrerhaftem Verhalten. Andere zu belehren, Formschoenheit zu bemaengeln und vorzugeben, helfen zu koennen, aber nicht zu wollen, das doch sehr wohl.

Deine Argumente auf der nicht sachlichen Ebene klingen wie bei einer Diskussion an einem Stammtisch in der Eckkneipe und wieder einmal extrem oberlehrerhaft.

Dein Versuch, mein Anliegen herabzusetzen oder zu diskreditieren, schadet sicher all denjenigen, die das gleiche Problem oder die gleiche Sorge haben.

Und Datenschutz oder Datensicherheit als Paranoia zu bezeichnen, entlarvt ganz sicher Deine Motive.

Es ist kein falscher Schritt, wenn diese Anfaelligkeit geloest ist. Dann sind auch virtuelle Server sicher! Einen fetten dedizierten Server sich leisten koennen, mag hier vor Ort wie ein Statussymbol normal zu sein. Und nun kommt die Cloud, und jeder System-Ingenieur, von denen es mittlerweile weltweit viele gibt, digitale Nomaden, kann nun Provider werden.

Du vergisst die kleinen Geschäftsprojekte auf der ganzen Welt. Da sind zahlreiche europaeisch gefuehrte Unternehmen da draussen, welche es gilt, am Ueberleben zu helfen! Die meisten können sich eben nicht einen eigenen Server leisten. Das hat nichts mit Paranoia zu tun!

Argumentiere mal schoen weiter im Sinne der grossen Anbieter und helfe keinem.

"Niemand hat die Absicht, eine Mauer zu bauen."

Wenn ein Thema bereits behandelt wurde, kann man wenigstens so hoeflich sein und auf den entsprechenden Threat hinweisen, anstelle sich in so arroganter Form zu ergiessen. Aber es soll ja Leute geben, die daran Spass haben oder ansonsten Langeweile.

Das sollte es jetzt gewesen sein auf der persoenlichen Ebene. Und wie gesagt, bitte konzentriere Dich doch einfach auf die Sachebene.

Und wenn Du nicht helfen willst, dann schweige doch einfach.

Ich denke, dass mein Thema ernstzunehmen ist und bitte andere Teilnehmer, die etwas beizutragen haben, Hilfestellungen oder Ideen beizubringen.