Kryptographie nach Snowden Die Verwendung von mittelmäßiger Kryptographie scheint gegen Angreifer mit Milliarden-Etat komplett versagt zu haben. Namentlich RC4, MD5 und SHA1 scheinen praxisrelevant brechbar. Der Vortrag beschreibt die aktuelle Bedrohungslage, gibt praktische Ratschläge für sichere Kryptographie und wagt einen Ausblick auf zwei kommende Kryptodesaster insbesondere im Bereiche "Trusted Computing". Redner: ruedi
Kryptographie nach Snowden [30C3[preview]] - Vortrag
http://www.youtube.com/watch?v=LkrZSPpUFu0
by
Online-Aktivismus
2 days ago
23
[Less]
Was tun nach der mittelmäßigen Kryptographie-Apokalypse?
EventID: 5337
Event: 30. Chaos Communication Congress [30c3] des Chaos Computer Club [CCC]
Ort: Congress Centrum Hamburg (CCH); Am Dammtor; Marseiller Straße; 20355 Hamburg; Deutschland
Sprache: deutsch
Beginn: 27.12.2013 17:15:00 +01:00
Lizenz: CC-by
Comments
Eine gerade zu beängstigende Analyse der von vielen noch als sicher geglaubten Verfahren und explizit bei Verwendung von Microsoft Chips und Windows 8 basierten Geräten tut sich da auf. Mein Vertrauen geht langsam gegen 0, nicht das ich selbst betroffen wäre gehen mir unsere „Freunde“ wie man genervt sagt langsam mächtig auf den für die NSA offenen Schnürsenkel.
uff, viel stoff.
In der QC-Einschätzung sehe ich mich bestätigt:
Noch nix gegen LANGE Schlüssel, aber in 4,5 Jahren will man bei DWAVE ja bei 4096 QBit-Länge sein ...
(heute 512)
___________________________________
Crypt & Server/Cloud
Und was Cryp angeht, steht sie eben zunächst der weiteren, auch zentral automatisierten und Daten-ÜBERGREIFENDEN Verarbeitung im Wege. Die wird aber gewünscht. Und aus Wort- & Fragment- u. a. Indizes (google) für Such- und Gruppierungsfunktionen (Tags) mit ihren Fundstellenlisten, kann man (encr. File-) Inhalte rekonstruieren, dabei müsste der Index clientseitig "gepflegt" und der Server/die Cloud damit je up-to-date gehalten werden, sonst gäbe es zur Erstellungs-/Pflegezeit des Index für ein Dok., Mail o. ä. ja Klarinstanzen auf dem Server, den wir als kompromittiert unterstellen müssen, weil er über einfach-offene Methoden, "Tach, wir sind vom Ghd" ganz leicht zur, z. T. auch retrograden (Vorratsdatenseicherung!), "Kooperation" gebracht werden kann.
Eine solche kryptografische Strategie, Netz/Cloud/Server nur verschlüsselt anzugehen, scheint mir daher irreal/unrealistisch.
Und bei weniger als "nur" kommt eben die Frage: welche Info gehen denn "uv"? Und da ist dann auch der banale Seitenaufruf (oder die primäre Torverbindung, wobei Tor als Cloudsystem eben auch per "Tach wir sind vom Ghd" zugänglich ist, wenn schon nicht längst V-Leute drinsitzen) eine hundertfach lesbare "Postkarte", bei verschlüsseltem Paket (tor, https etc.) ist die Empfänger -IPA notwendig sichtbar, sonst kann das nicht zugestellt werden. Damit wird klar, was dann da läuft, ob eine Tor-, eine Bank- oder sonst eine Kommunikation läuft. Der Ghd stellt sich als watchdog vor diese IPA und liest mit was da so rein/raus geht.
Hat er Absender decodieren können, die ja i. d. R. Antwort erwarten, wenn auch nicht zwingend vom Server unter dieser IPA, stellt er sich noch vor dem Absender auf usw.
Vereinbarungen mit dem eigenen Provider über den richtigen Transport von Paketen mit verschlüsseltem Empfänger-Feld sind sinnlos, weil er in jedem Fall die richtige Destination kennen muß, aber mit der "Tach..."-Methode kompromittierbar ist.
Es ist politisch damit umzugehen, daß Leute aus den Rationalvorteilen der Cloud-Inanspruchnahme heraus jede Menge Daten von sich preisgeben, - vom einfachsten Seitenaufruf mit ca. 5-10 relevanten Infos bis zur Identifizierung fürs Online-Banking, - oder fürs SN, womöglich noch ein gesinnungsorientiertes oder parteiliches, oder mit einem Internet-Telefonat.
Das gelingt dem sonst bestimmt guten Kryptografen hier (noch) nicht.
Wo Gesetzestext, erscheint dieser als reines Tool- u. Verfahrens-/Architektur-Picking. Das ist GANZ GEWIß CRUCIAL, aber nur ein sehr kleiner Teil der Probleme wie auch der Lösungsmöglichkeiten - u. Notwendigkeiten, und darf den mathezistisch-technischen approach nicht zur im Ende einzigen Speerspitze machen. Vorschriften, wer was wie einzusetzen hat, kann man wie gezeigt für sowas wie den Bereich der Bundesbehörden u. ä. "verordnen", wobei ich da skeptisch bin: Haltbarkeitsende/Renovierungsbedarf dürfte sich massiv mit der der Einführungszeit überlappen ..., DAS WIRD dann SEHR teuer, und eher unsicher, viele Leute, viel Kompromittierbarkeit, letztlich bis in die HW.
Für einem guten Vortrag dieser Art in dieser "Cloud" hätte ich mir die gute (Abgrenz-)Übung gewünscht,
aufzuzeigen, was das jeweilige Fach des Vortragenden, hier die Kryptografie, per se/im Allgemeinen und im Besonderen (hier/heute, zur Fragestellung) NICHT kann.
Backdoors,
= CLIENT- u. /o. Server-Kompromittierungen, ist ganz gewiß nicht mit FreeOpen-SW beizukommen.
Sie können
1. in HW vorliegen, die je nach Chip-Fabrik sowieso undok.-irrelevante Logik-Reste enthalten kann, manchmal auch Spökskes der Entwickler/Layouter,
2. kann niemand, auch keine Truppe, solche FreeOpen Projekte wie z. B. Firefox en detail überprüfen, man legt sich immer in die Betten anderer, - selbst wenn man auf Assembler runtergeht. (Moz.FF: Erst Adobe, dann google als Bettgenossen in der Netscape-usw.-Welt..)
Von den Compile-/Build-Tools bis zu den Systemen auf denen z. B. FF-Builds generiert werden,
das Netscape-Material und weitere 20 kernmäßige Modulbereiche wie Gecko, MIDAS, XPATH, XUL usf. zeugen von extremer Verzweigung, denn die basieren wieder auf Tools & Lib., die längst nicht alle gecheckt sicnd, auch nicht immer free-open waren/sind.
3. Kann FreeOpen-SW längst nicht alle Programmwünsche erfüllen, selbst wenn sie wollte, so daß immer irgendwer sich SW was kosten läßt, die dann oft nicht open & free ist. Und WAS diese IT-Condottieri dann da hinterlassen können, ohne daß es über lange Zeit aufffallen würde ..., nun ja.
Daher plädiere ich hinsichtlich backdoors für einen Sniffing-Approach über TÜV, Verbraucherzentralen usw. für standardausgerüstete Client- & Kleinserver-Systeme mit Cert-Vergabe.
Eine backdoor, über die nix rein oder rausgeht, ist keine, - vielleicht eine Malware, die Dateien zerstört oder über die WinCC-Steuerungen einer Zentrifugenanlage alle Dinger mal so richtig hochdrehen lässt ...
Und in einem System mit aktiviertem Netzanschluß ohne weitere gewollte Netzaktivität sollte nur genau zuordungsfähige Kommunikation zur Aufrechterhaltung der Verbindung zum Internet im sniff zu sehen sein. Auch wenn reichlich netzfreie Arbeiten dann hinzutreten. Jeder Kinderroller wird skeptischen Destruktiv-Tests und Bewertungen zur Funktionalität u. Sicherheit unterzogen, bloß unser Nervensystem, die Netzssphäre, ist uns offenbar wurscht.
Da gibts kaum/keine Forschung zu, wie so ein Endprodukttestfeld aufzubauen ist. Höherwertigere Systeme müssten ihren Netzverkehr eh ständig stichprobenweise kontrollieren. Gewiß kann sich die bd-Kommunikation im Ausgang unter gewolltem https- o. ä. -verschlüsseltem Verkehr prima verbergen, - crypt schützt auch SPY-Inhalte vor ihrem Erkennen -, aber durch die Ausführung von wechselnden Standardrequests, deren IP-Traffic-Profil bekannt ist, dürfte ein outgoing-bd-traffic im Vergleich zum StandardProfil auffallen. Grundsätzlich kann im Untersuchungsbetrieb auch durch Verschlucken bloß verdächtiger Pakete bzw. Inhaltsteile auf ihre Rolle im GEWOLLTEN Verkehr geschlossen werden.
Port- und Socketkontrolle, möglichst aus der Ring-0-Position des/eines Prozessor(kerne?)s, ist notwendig, um die nicht im anwendungsinduzierten Hauptstrom versteckten sondern in Side-Traffic gelagerten Übermittlungen zu blockieren.
MS/Windows
will schon länger sowas wie im Vortrag angedeutet. siehe DRM-Qual.
OPT-IN/OUT ist dann keine gute Lösung, wenn gegen Abgabe des prinzip. Vollbesitzes am Rechner, ein Teil wandert zu MS, MASSIV BILLIGERE PREISE/Gestehungskosten oder sonstwie EXKLUSIV VORTEILIGE FEATURES mit dieser Lösung verknüpft werden.
Als Mono-/Oligopolplayer kann dann dabei durch Preispolitik ein oberes Feigenblatt erhalten werden, das man sich nur mit der ganz dicken Brieftasche leisten kann, - und 80 bis 99 % aller Leute sind letztlich auf die Vorteile/Features der Shared-Unit-Lösung angewiesen, wenn sie im kompetitiv/aktiv/reaktiv aufgestellten Leben nicht massive Nachteile in Kauf nehmen müssen.
Soweit ich gehört zu haben glaube, gibt es es Win8 schon, auch ohne obligaten Chip im Rechner. Bei Win 7 (HoPre) kann eine kopierte OEM durchaus auch online aktiviert werden, - sofern die nicht per Brennvorgang/Imageänderung aus dem gekauften "Bulk" des Distributors spezifiziert wurde, und der Bulk-Zähler für den Distributor-Bulk online bei MS-Activation noch nicht erschöpft ist.
Der Teilhabeanspruch von MS ist bisher weitgehend gescheitert, weil nicht mit Vorteilen für User verknüpft. Rechtlich gab es wohl Erfolge, was den Weiterverkauf von OEMs angeht. Praktisch ist eine umständliche "Migration" von einem Rechner zum Anderen notwendig, da reicht zum Teil das Ersetzen einer Platte, um das als "anderen Rechner" zu klassifizieren.
Die Formeln am Anfang sind natürlich geil.
Freie Software ist nicht gleich Open source und Open Source hat natürlich einen Sicherheitsvorteil gegenüber geschlossene Systeme wie Windows. Ich lese von den Windoows verteidiger immer sowas:
Ich lese natürlich nicht den Quellcode, aber es haben schon Tausende vor mir gemacht und das können Sie immer wieder tun. Bei MS bekomme ich eine oder mehrere "dll"´s und was die macht und für was die gut ist weis kein mensch. Und jetzt kommt das entscheidente, es kann keiner Kontrollieren.
Z.b. der Cryptoteil von MS wurde von der NSA entwickelt. Der Berühmte NSAKEY ist schon über 15 Jahre alt.
In den letzten Wochen haben wir von Skype, Outllook erfahren.
Ich habe noch nie von Hintzertüren der NSA gehört die in Quelloffener Software gefunden wurden.
Letzteres mit Sicherheit nicht.
Ich meine, die letzte PGP Vers. enthält einen nicht quelloffenen Nucleus, die Adobe Sachen, mit denen die quelloffenen Sachen ja dealen müssen u. v. a. NICHT QUELLOFFENE Libs/DLLs SIND TEIL der Funktionalität quelloffener Projekte, auch auf Linux-Maschinen.
Und selbst komplette und völlig kontrollierte Quelloffenheit garantiert noch lange keine Backdoorfreiheit, denn was in die ausführbaren Formate übersetzt wurde, kann sehr wohl Module enthalten, die mit dem Quellcode nix zu tun haben und die man folglich durch dessen Studium auch nicht ermitteln kann. Für die entspr. Infizierung der make-Tools reicht es notfalls, einmal den falschen USB-Stick angesteckt zu haben.
Das stimmt im Win-Standard nur sehr zum Teil: bis auf einen kleinen Rest innerhalb von kernel u. gdi liegen sie als (teure) "Foundation Classes" u. ä. quelloffen zur statischen Einbindung zur Übersetzungszeit vor (VS-Enterprise/Develop-Editions). Das ist auch geboten, denn sowas kann vor kompromittiertem DDL-Code schützen, vor allem aber auch vor inkompatiblen Updates/Änderungen von dlls. Auch kann damit Einzel-DLL-Code einer originären Windows-DLL erzeugt werden, z. B. um nach Quellcode-Änderung/Ergänzung Teil eines "Unternehmens-Windows" zu werden.
Doch nicht nur der Quellcode ist zugänglich, auch sind standardmäßig VS-compilierte DLLs sowohl sehr inspektionsfähig, so daß man sich zumindest über die standardmäßig exportierte/verfügbare Funktionalität sehr einfach informieren kann (Inspect-Tools u. Netz, VS-Enterprise-Doku.), als auch sehr INJEKTIONSBEREIT, um zusätzlichen Code außerhalb des make/build-Prozesses nachträglich einzuschleusen.
Deshalb hat z. B. FF seine DLLs schon vor solcher Einsichtnahme geschützt, um auch von dieser Seite (Injection) her sicher zu sein. Lägen die alle so quelloffen vor, wie ausgelobt, wäre das sinnlos gegenüber milliardenschweren Angreifern, und wenig sinnvoll über die Zeit gegenüber Kleinspyern (die ihr Zeug ja auch mal Ghden anbieten, bzw. das in deren Besitz gelangt). Vermutlich auch deshalb hat man sich bei FF für hohe Schlagzahlen bei den Vers.-Releases statt patches entschieden, kann man doch damit die Struktur der DLLs oft ändern, auch wenn die eigentliche Funktionalität gleichgeblieben ist.
Damit aber geht wieder ein Transparenzfaktor zu Bruch, ebenso wie bei der Detektierbarkeit von ungewollten pw- o. Schlüssel-Übertragungen in verschlüsselten Haupt-/Anwendungsströmen.
Der Gedanke, Quelloffenheit könne MASSIV vor Backdoors schützen, konterkariert sich zu guter Letzt selbst, indem er der nicht über Quellcode eingeschleußten Backdoor die innere Struktur potentieller Angriffsziele offenlegt.
Logisch kann unter der Prämisse "alles (außer crime) ist quelloffen" auch alles im Prinzip ggfls. zurückverfolgt werden (der kleine crime-Rest fällt dann irgendwann auf, wenn gegebene Binaries nicht "genauso" mit dem angeblich zugehörigen Quellcode-Tool-Paar erzeugt werden können).
Nur gilt die Prämisse halt nicht, und kann kaum praktisch durchgesetzt werden.
Ich habe noch nie von Hintzertüren der NSA gehört die in Quelloffener Software gefunden wurden.
Ich schon, wenn auch nicht im OFFENEN Quellcode selbst, das wäre ja auch aus Sicht der bd-Macher Blödsinn, sondern in den Binaries, seien sie in den undok. Outputteil während eines originären Makes/Builds oder später da reingekommen (While download? = see the net-section before the following cited from: http://www.theguardian.com/world/2013/sep/05/nsa-how-to-remain-secure-surveillance):
The NSA also devotes considerable resources to attacking endpoint computers. This kind of thing is done by its TAO – Tailored Access Operations – group. TAO has a menu of exploits it can serve up against your computer – whether you're running Windows, Mac OS, Linux, iOS, or something else – and a variety of tricks to get them on to your computer.
http://en.wikipedia.org/wiki/NSAKEY:
... this was for Windows software in 1999...
Since the NSA key is easily replaced, it means that non-US companies are free to install "strong" crypto services into Windows, without Microsoft's or the NSA's approval. Thus the NSA has effectively removed export control of "strong" crypto from Windows. A demonstration program that replaces the NSA key can be found on Cryptonym's website.[8]
http://web.archive.org/web/20001001163609/http://www.cryptonym.com/hottopics/msft-nsa/AdvApi32dll-3.gif
http://web.archive.org/web/20001109204800/http://www.cryptonym.com/hottopics/msft-nsa/msft-nsa.html
Schade, daß diese Möglichkeit, sich prinzipieller Decodierungsmöglichkeiten durch die NSA zu entledigen, wohl Vergangenheit ist.
Outlook fällt wie vieles andere schon mit ungewollten Verkehr auf (AVM FritzProtect), wenn man es gar benutzt, sodaß es gekillt, mindestens deaktiviert werden sollte.
http://www.neues-deutschland.de/artikel/919457.hackertreffen-30c3-hacker-rufen-zum-widerstand-auf.html#c45845
Also bei den ersten Absatz komme ich schon inbs stottern und kann dir nicht mehr richtig folgen ....
Erstens was hat jetzt das PGP mit deinem Schlussvolgerung im ersten Text zu tun das "Quell offene Software auch nicht sicherrer wäre. Und was hat Adobe damit zu tun. Und mit welchen Adobe sachen muss die Quelloffenen dealen ? Weiter habe ich deinen Text noch gar nicht gelesen ...
Nein, aber es kann kontrolliert werden, was bei Windows so nicht mehr möglich ist. Wenn ich Admin wäre und was zum absichern hätte würde ich ein System wählen wo ich wenigstens die möglichkeit habe es zu konztollieren. Das ist doch der entscheidende punkt.
Das würde ich gerne mal sehen wo MS sinen Code offenlegt, das wäre mit neu. Kannst mir bestimmt einen Link geben und wir reden hier jetzt hoffentlich nicht von einer Doku soindern vom Quelltext.
Ker, watt' ne Wühlerei!
Das ist Riesenpaket, wir ham das bei Siemens Erlangen für den Abwasserverband Saar benutzt u. statisch eingebunden, 1999. Das war vor 3 Rechnern und ich habe dazu keine Copy weil zuviel/zu schnell veraltet, weil ich damals keinen hinreichenden Rechner dafür zu Hause hatte etc..
Weil teuer, liegen die nicht offen im Netz rum (-> kein direkter link). Daß es das heute auch noch gibt,
zeigt dieser Link:
http://msdn.microsoft.com/en-us/library/bs046sh0.aspx
Ich habe damals sämtliche dll- u. ä. -Namen aus C:\windows\system u. system32 hergenommen und für nahezu jede ein MFC-Source-Verzeichnis mit .h, . cpp, z. T. makefile gleichen Namens gefunden, insg. gab es etwa 2000 Einzel-MFC und beileibe nicht nur API-Kram bzw. App-/UI-Entwicklung darunter wie der Wikieintrag zu MFC suggeriert, sondern Marshalling-Code, die named-pipes- oder WinSock-Implementation usw., wohlgemerkt Implementationen wesentlicher, tiefgehender Win-Klassen usw. bis hin zu MS-generischen TREIBERN (potentiell Ring-0), im Treiber-Zusatz-Paket. Die grobe MFC-Übersicht auf einem A0-Blatt zeigte das auch klar an, daher kein Fehler.
"Writing Windows NT Server Applications in MFC Using I/O Completion Ports, Ruediger Asche, September 1996"
stützt sich laut Text auf die dort so annoncierten "MFC"-Sourcen NPIPE.CPP u. NPIPE.h.
Über google find ich die (jetzt?) nicht, aber:
In meinem I:\vsCDs\cd2\SAMPLES\MSDN\TECHART\4081\COMMON\-Folder finden sich die Zwäner:
Mit vollständiger Implementation (cpp) der zwei, Client u. Server, NamedPipe-Klassen, siehe ganz unten den paste der cpp-source.
NIX billiges API-Wrapping um ein paar Parameter nach oben zu verbergen, Aufrufe zu vereinfachen oder ein GUI auf lediglich benutzte, nicht selbst implementierte Funktionalität, draufzusetzen, wie Wikipedia und ALLE anderen der 1. google Seite einem weißmachen wollen.
Das geht vererbungstechnisch per Sourcecode verfolgbar über 3 bis 20 Stufen bis auf CObject und eine (heute vermutlich: doppelte) Handvoll weniger genutzer Basisendklassen runter. Hab ich bei Fujitsu-Siemens München beim CRM-Project so in den Händen gehabt.
Damals gab's die in einer Debug-Version, in jeder 2. Zeile eine "assert"-Anweisung, und in einer Produktiv-Variante.
Windows besteht eigentlich aus OFFEN definierten Prototypen, also Vordefinitionen, sowohl via Doku, z. T. auch mit Implementationen, als auch in den .h-Files der MFC nachvollziehbar, die verbindlich sind, - wer die einhält, hat die, nicht immer eingehaltene Gewähr, sein Modul in den Windows-OS-Ordnern und der Registry als Funktionsanbieter von Crypt über Sockets bis sonstwas zu verankern, als Zusatz/neuer Anbieter oder auch als ERSATZ ausgelieferter Parts. Nicht immer erreicht die Prototypie-Ebene hinreichende Präzision, - dann sind genauere Verhaltens(erwartungs)- bzw. Implementations-Kenntnisse nicht schlecht, die letztlich auch immer erhältlich waren.
Die heutige, schlechte Situation ist eben auch ein Folge der Dominanz allerlei Großsprecher, die gaaanz genau wusten wissen, was Sache ist. Daß 98 % der Windows-OS-Software in Quellcode vorliegt, mit dessen selbst erstellten Compilaten die ausgelieferten, lauffähigen Module gut bewährt ersetzt werden können, ist einfach was anderes als die Proprietär-Klappe fallen zu lassen und die technik-politische Arbeit einzustellen, wie das die Hackerszene, CCC u. v. a. bis Stefan Meretz & Co. ja getan hat. Schon an der NSAKEY-Sache kann man ja sehen, wie MS bei Windows in seinen Optionen für "Enterprises" aufgestellt ist, - sonst hätten die es auch nie SOOO verbreitet in die Konzernstandards (bzw. iranische Urananreicherungsanlagen) geschafft, wenn sie nicht die BIG-OPTION anbieten könnten, to make Your widely own enterprise-windows usw.
Daß die Konzerne/Institutionen das dann nicht umsetz(t)en, steht auf dem Blatt "Haben" (auch: Möglichkeiten, die man u. U. mal gebrauchen könnte) geht vor "Sein".
90 % der für Win & Maximal-VS "mit allem" (um die 12.000 Euro, Liz. f. einen Entw.-Platz) getroffenen Entscheidungen folg(t)en aus Prestigebedarf & Unsicherheit.
Sicher: ein NICHT offener PGP-Teil/Nucleus mag vielleicht 99,9 % seines Codes offenlassen und Win womöglich nur 98%. Aber das heißt nix, letztlich kann man von nicht-offenen Codes auch ihren Umfang NICHT abschätzen.
Die Erfahrung zeigt, daß bei allen größeren Open-Projekten, der drill-down selten über über die 3. SourceCode-/Tool-Stufe hinaus erfolgreich ist. Irgendwann hat man eine/n am Telefon/in der Mail, der/die, ja, noch dieses oder jenes haben müsste, aber er/sie kann beim besten Willen nicht mehr sagen, ob und wenn ja, was in welche Builds davon geflossen ist, oder wie sauber die Build-Tools da wirklich waren.
Darauf zu hoffen/davon auszugehen, daß Open-Hacker (->Proprietäres) bzw. die IT-Gemeinde als solche (für mehr oder weniger Offenes), sich um die Sicherheit von Billionen an Source-Codezeilen UND deren Binaries kümmern könnten bzw. wollten ist irreal, - und demzufolge seit 20 Jahren auch ausgeblieben.
Ausgeblieben ist auch die Sozialisierung von Windows, angefangen bei den Kenntnissen.
Auf diesem Gebiet unbedarfte Lautsprecher haben die Oberhand gewonnen, Gegner wurden gesucht, und legitime Gegener auch gefunden. Das entlastete von wirklicher Politik. Mit der Forderung nach einer bis auf crime offenen IT-Welt und der gnadenlosen Selbstüberschätzung, prop. & high-commercial an die Wand drücken zu können - man kann ja sooo billig sein -, hängte man die Trauben absehbar zu hoch
(vergl. Radikalisierung/Sektifizierung).
Lästig-unproduktiver Kram, z. B. eigene Traffic-Kontrollen zu machen und womöglich noch politisch für die wiss.-technischen, marktlichen (TÜV, Zulassungen/Zert., z. T. gesetzl. Standardisierung) und gerätemäßigen und vor allem INFRASTRUKTURELLEN, - incl. massiven Rechtsrahmens für Infra- Kompartimente -, Grundlagen solcher Kontrollen zu kämpfen, wenigstens Konzepte für sowas zu machen und einzubringen, das stand nicht auf dem Programm der Lautsprecher u. Eigentums-Ideologen. Statt dessen verquaste Verquickungen fragwürdiger Mensch- u. Gesellschaftsheoreme wie Krit. Psychologie und Teilen der Commons-Theoreme oder Marx mit der IT. Gegenüber der herrscht daher fast 0-Politik. Da sind Staat u. Gesellschaft die berühmten NACHTWÄCHTER, denen beide Augen schon zugefallen sind.
Wenn man mit einem Teil in der Proprietarität leben muss, gerade auch bei HW, sind konkrete Implementationen darin i. d. R. nicht bekannt, so daß darin z. b. eine bd verborgen werden kann. Wie oben angestreift, hilft in so einem Fall die Verhaltensanalyse via Durchtesten, - vom Win-Modul über Chips bis zu ganzen (PC?-)Systemen aus HW & SW.
Hätte man letztere technisch & rechtlich standardisiert, wäre es ein Leichte(re)s, deviant-unerwünscht-unbeabsichtigtes VERHALTEN auf Netz- und anderen Schnittstellen, z. B. zu USB-Sticks, durch STELLVERTRETENDE, institutionalisierte Checks mit geringem Aufwand je verkauft/betriebenen Systems durchzuführen. Auch freiwillige, wechselnde Stichprobengruppen in der Nutzerschaft könnten dafür in Frage kommen.
*******************************************************************
NPIPE.CPP - implementiert Client- u. Server-Side named-pipes, Version von 1998
#include "stdafx.h"
#include "comclass.h"
#include <windows.h>
#ifdef SECURITY
#include "sec.h"
#endif
#include "npipe.h"
// Buffers and pipe symbolic constants.
#define IN_BUF_SIZE 4096
#define OUT_BUF_SIZE 4096
#define TIME_OUT INFINITE
CClientNamedPipe::CClientNamedPipe() : CClientCommunication()
{
strcpy(m_szPipeEndNameIn,DEFAULTINPIPENAME);
strcpy(m_szPipeEndNameOut,DEFAULTOUTPIPENAME);
strcpy(m_szPipeEndNameBoth,DEFAULTBIPIPENAME);
m_iStatusPending = STATUS_NOT_CONNECTED;
m_hEvent = CreateEvent(NULL,TRUE,TRUE,NULL); // error ???
};
CClientNamedPipe::CClientNamedPipe(PSTR pIn, PSTR pOut, PSTR pBiDir) : CClientCommunication()
{
strcpy(m_szPipeEndNameIn,pIn);
strcpy(m_szPipeEndNameOut,pOut);
strcpy(m_szPipeEndNameBoth,pBiDir);
m_iStatusPending = STATUS_NOT_CONNECTED;
m_hEvent = CreateEvent(NULL,TRUE,TRUE,NULL); // error ???
};
CClientNamedPipe::~CClientNamedPipe()
{
CloseHandle(m_hEvent);
};
BOOL CClientNamedPipe::Open(const char* pszFileName, UINT nOpenFlags,
CFileException* pError)
// currently we only support the READ and WRITE open flags...
{
DWORD dwModeTypeClient = NULL;
PSTR pName;
if (nOpenFlags == modeReadWrite) // bidirectional pipe
{
dwModeTypeClient = GENERIC_READ|GENERIC_WRITE;
pName = m_szPipeEndNameBoth;
}
else
if (nOpenFlags == modeRead)
{
dwModeTypeClient = GENERIC_READ;
pName = m_szPipeEndNameIn;
}
else
if (nOpenFlags == modeWrite)
{
dwModeTypeClient = GENERIC_WRITE;
pName = m_szPipeEndNameOut;
}
else return FALSE; // bad flags passed in
if (!pszFileName) return FALSE; // NULL means we want to be the server
{
sprintf (m_szPipeName, "\\\\%s\\PIPE\\%s", pszFileName,pName);
// Do CreateFile() to connect to the
// named pipe.
m_hFile = (UINT)CreateFile (m_szPipeName, // Pipe name.
dwModeTypeClient,
FILE_SHARE_READ // Share both read and write.
| FILE_SHARE_WRITE ,
NULL, // No security.
OPEN_EXISTING, // Fail if not existing.
FILE_ATTRIBUTE_NORMAL, //
NULL); // No template.
// Do some error checking.
if ((HANDLE)m_hFile == INVALID_HANDLE_VALUE)
{
m_iErrorCode=GetLastError();
return FALSE;
};
m_bWeAreServer = FALSE;
};
return TRUE;
};
void CClientNamedPipe::Close(void)
{
if (m_iStatusPending & STATUS_CONNECTED)
{
if (m_bWeAreServer)
{
FlushFileBuffers((HANDLE)m_hFile);
DisconnectNamedPipe((HANDLE)m_hFile);
};
};
m_iStatusPending = STATUS_NOT_CONNECTED;
CloseHandle((HANDLE)m_hFile);
};
void CClientNamedPipe::Write(const void FAR* pBuf, UINT iCount)
{
unsigned long bytesSent;
if (!WriteFile ((HANDLE)m_hFile, pBuf, iCount,&bytesSent, NULL))
{ DWORD dwErrorCode = GetLastError();
// if (dwErrorCode != ERROR_PIPE_NOT_CONNECTED)
RaiseException(dwErrorCode,0,0,NULL);
};
};
UINT CClientNamedPipe::Read(void FAR* pBuf, UINT iCount)
{
unsigned long uReturn;
BOOL bRetCode;
bRetCode = ReadFile((HANDLE)m_hFile,pBuf,iCount,&uReturn,NULL);
if (!bRetCode)
{
DWORD dwErrorCode = GetLastError();
// if (dwErrorCode != ERROR_PIPE_NOT_CONNECTED)
RaiseException(dwErrorCode,0,0,NULL);
return 0; // to shut the compiler up
}
else return uReturn;
};
BOOL CClientNamedPipe::ReConnect(void)
{
return FALSE;
};
// server end definition
CServerNamedPipe::CServerNamedPipe() : CClientNamedPipe()
{
};
CServerNamedPipe::CServerNamedPipe(PSTR pIn, PSTR pOut, PSTR pBiDir) : CClientNamedPipe(pIn,pOut,pBiDir)
{
};
BOOL CServerNamedPipe::Open(const char* pszFileName, UINT nOpenFlags,
CFileException* pError)
// currently we only support the READ and WRITE open flags...
{
DWORD dwModeType = NULL;
PSTR pName;
if (nOpenFlags == modeReadWrite) // bidirectional pipe
{
dwModeType = PIPE_ACCESS_DUPLEX;
pName = m_szPipeEndNameBoth;
}
else
if (nOpenFlags == modeRead)
{
dwModeType = PIPE_ACCESS_DUPLEX; // we need this for SetNamedPipeHandleState!!!
pName = m_szPipeEndNameOut;
}
else
if (nOpenFlags == modeWrite)
{
dwModeType = PIPE_ACCESS_DUPLEX; // we need this for GetNamedPipeHandleState!!!
pName = m_szPipeEndNameIn;
}
else return FALSE; // bad flags passed in
if (pszFileName) return FALSE; // NULL means we want to be the server
sprintf(m_szPipeName,"\\\\.\\PIPE\\%s",pName);
m_hFile = (UINT)CreateNamedPipe (m_szPipeName,
WRITE_DAC| ACCESS_SYSTEM_SECURITY|
dwModeType,
PIPE_WAIT // Wait on messages.
| PIPE_READMODE_MESSAGE // Specify byte pipe.
| PIPE_TYPE_MESSAGE,
PIPE_UNLIMITED_INSTANCES, // Maximum instance limit.
OUT_BUF_SIZE, // Buffer sizes.
IN_BUF_SIZE,
TIME_OUT, // Specify time out.
NULL);
GetLastError();
if ((HANDLE)m_hFile == INVALID_HANDLE_VALUE)
{
m_iErrorCode=GetLastError();
return FALSE; // flag is not set here.
};
m_bWeAreServer = TRUE;
return TRUE;
};
void CServerNamedPipe::Close(void)
{
if (m_iStatusPending & STATUS_CONNECTED)
{
FlushFileBuffers((HANDLE)m_hFile);
DisconnectNamedPipe((HANDLE)m_hFile);
};
m_iStatusPending = STATUS_NOT_CONNECTED;
CloseHandle((HANDLE)m_hFile);
};
BOOL CServerNamedPipe::AwaitCommunicationAttempt(void)
{
m_iStatusPending = STATUS_CONNECTION_PENDING;
m_bInterrupted = FALSE;
OVERLAPPED ol;
// Block until a client connects.
DWORD dwInstances,dwStateNew;
if (!GetNamedPipeHandleState((HANDLE)m_hFile,&m_dwState,&dwInstances,NULL,NULL,NULL,0))
{
m_iErrorCode = GetLastError();
return FALSE;
};
dwStateNew = (m_dwState & !PIPE_WAIT) | PIPE_NOWAIT;
if (!SetNamedPipeHandleState((HANDLE)m_hFile,&dwStateNew,NULL,NULL))
{
m_iErrorCode = GetLastError();
return FALSE;
}; // I hope we'll never get here as that would be pretty serious re cleanup...
ol.hEvent = m_hEvent;
while (!m_bInterrupted)
{
ConnectNamedPipe((HANDLE)m_hFile,&ol);
if (GetLastError()==ERROR_PIPE_CONNECTED) break;
};
if (!SetNamedPipeHandleState((HANDLE)m_hFile,&m_dwState,NULL,NULL))
{
m_iErrorCode = GetLastError();
return FALSE;
}; // I hope we'll never get here as that would be pretty serious re cleanup...
if (m_bInterrupted)
{
m_iErrorCode = ERROR_OPERATION_ABORTED;
m_iStatusPending = STATUS_NOT_CONNECTED;
m_bInterrupted = FALSE;
return FALSE;
};
m_iStatusPending = STATUS_CONNECTED;
return TRUE;
};
BOOL CServerNamedPipe::CancelCommunicationAttempt()
{
if (!(m_iStatusPending&STATUS_CONNECTION_PENDING))
return FALSE;
m_bInterrupted = TRUE;
if (!SetEvent((HANDLE)m_hEvent))
{
m_iErrorCode = GetLastError();
return FALSE;
};
m_iStatusPending = STATUS_NOT_CONNECTED;
return TRUE;
};
void CServerNamedPipe::CloseInstance()
{
FlushFileBuffers((HANDLE)m_hFile);
DisconnectNamedPipe((HANDLE)m_hFile);
m_iStatusPending = STATUS_NOT_CONNECTED;
};
CServerCommunication *CServerNamedPipe::Duplicate()
{ HANDLE hNewHandle;
CServerNamedPipe *cnpReturn = new(CServerNamedPipe);
if (DuplicateHandle(GetCurrentProcess(),(HANDLE)m_hFile,
GetCurrentProcess(),&hNewHandle,NULL,FALSE,DUPLICATE_SAME_ACCESS))
{
cnpReturn->m_hFile = (UINT) hNewHandle;
cnpReturn->m_bWeAreServer = m_bWeAreServer;
cnpReturn->cOtherMachineName = cOtherMachineName;
cnpReturn->m_iMode = m_iMode;
cnpReturn->m_iStatusPending = m_iStatusPending;
return cnpReturn;
};
return (CServerCommunication *)NULL;
}
#ifdef SECURITY
BOOL CSecuredNamedPipe::SetTheDescriptor()
{
if (m_iStatusPending == STATUS_CONNECTION_PENDING)
{
m_iErrorCode = ERROR_PIPE_BUSY;
return FALSE; // we can't set the security while a connection is pending...
};
return (SetObjectSecurity((HANDLE)m_hFile));
};
BOOL CSecuredNamedPipe::GetTheDescriptor()
{
if (m_iStatusPending == STATUS_CONNECTION_PENDING)
{
m_iErrorCode = ERROR_PIPE_BUSY;
return FALSE; // we can't set the security while a connection is pending...
};
return (GetObjectSecurity((HANDLE)m_hFile));
};
BOOL CSecuredNamedPipe::ImpersonateClient(BOOL bParam)
{
if (bParam)
return ImpersonateNamedPipeClient((HANDLE)m_hFile);
else return RevertToSelf();
};
BOOL CSecuredNamedPipe::Open(const char* pszFileName, UINT nOpenFlags,CFileException* pError)
{
BOOL bReturn = FALSE;
SetPrivilegeInAccessToken(TRUE);
bReturn = CServerNamedPipe::Open(pszFileName,nOpenFlags,pError); // must resolve ambiguity here
if (!bReturn) goto ErrorExit;
bReturn = SetTheDescriptor();
ErrorExit:
SetPrivilegeInAccessToken(FALSE);
return bReturn;
}
#endif SECURITY
Sorry [username entfernt], diesen Codeschnipsel willst du mir jetzt nicht als Wndows Quellcode verkaufen, Komisch das scheinbar auch ausser dir keiner diesen Quellcode hat ...
Das ist der Quellcode vom Linuxkernel.
Kompiler C/C++ Libs alles ist Quelloffen. Ich weis gar nicht wie verblendet man sein muss um diesen Sicherheitsvorteil nicht zu sehen. Hab auch keine Lust das mit Dir zu Diskutieren. Es gibt genung Literatur und Papiere dazu.
Willze mehr? Ich hab da:
45.272 Dateien, 3.848 Ordner
3,55 GB (3.813.644.629 Bytes)
auf Datenträger: 4,65 GB (5.002.264.576 Bytes)
Zur Dateianzahl kommen noch diejenigen hinzu, die aus 688 cab-Dateien zu extrahieren sind.
Ca. 80% aller Files enthalten Win/MFC-Source relevanten Code, - wie im geposteten Beispiel,
90% sind Win/MFC-Source relevante Doku (z. B. dokumentarische Prototypien).
Der Rest von 10 % oder so sind die Binaries der VS-IDE-Tools, einschl. Hilfsprogramme usw., sowie Binaries, die für die Laufzeit der MSDN-DB OFFLINE, und den BETRIEB vereinzelter Beispiele/Projekte a priori, auch ohne Make/Build-Lauf, erforderlich sind.
Hardware-Treiber/WDF sind gar nicht, vxd-Treiberei unzureichend enthalten.
Kleinste u. wohl noch mal abgespeckte VS-Enterprise-Version, irgendwann zw. 1998 u. 2006 aus nem torrent besorgt.
Läuft am besten unter NT, sehr gut auch unter XP/SP2; mit Einschräkungen und Nachhilfen unter Win7 HoPre/64.
Die Enterprise-Version, die ich bei Fujitsu-Siemens als Unamite(accenture)-Mitarbeiter 2001 hatte, bestand etwa aus dem 10-fachen Umfang.
Daß es sich bei dem geposteten Code um einen Ausschnitt aus einem offenbar größeren Zusammenhang handelt (statisch eingebundener kernel-Teil?), lässt sich an dieser Stelle erkennen:
#ifdef SECURITY
#include "sec.h"
#endif
Sinnlos an dieser Stelle ohne über- bzw. vorgeordneten Quellcode-Kontext.
Weiter unten wird die Secure-Variante der ServerPipe implementiert, -
und unter der Voraussetzung, daß das Compiler-Symbol SECURITY definiert ist, - analog der Prototypie in NPIPE.H -, auch compiliert und ins Binary eingebunden. SONST NICHT, - aber hier in der Quelle wird NIRGENDS das SECURITY-Symbol definiert.
Dann könnte es nur noch in den include-chaines stehen, die aus den in der NPIPE.CPP angegebenen includes (die .h hat keine inc's) folgen.
Das würde man als Ersteller eines singulären NPIPE-Moduls, z. B. als DLL, SICHER NICHT überprüfen wollen, sondern die Entscheidung, ob die Binaries auch die secure-Variante der ServerPipe enthalten sollen, durch entspr. Symbolbehandlung, def oder undef, hier treffen.
Darauf, daß es sich um Kernel-Code handelt, verweist auch die Ableitung von CKernelSecObject in der NPIPE.h., dessen Prototyp in sec.h definiert und dessen Klasse in sec.cpp implementiert ist.
Wenn ich nicht wünsche, daß sich eine sichere Windows-Pipe in meiner Applikation auf die laufende Binary von Windows bezieht, weil die z. B. kompromittiert sein könnte (MS-Auslieferung, Infektion), binde ich die ganze Quell-Chain für Named-PIPE statisch mit ein. Sicher beruhen diese Quellen irgendwann unter anderem auch auf nicht quelloffenen Elementaren, - daß Windows quelloffen sei, habe ich nicht behauptet, sondern daß es weit weniger "geschlossen" ist als manche so insinuieren.
Mithilfe der windows.h-Prototypie einschließlich deren includes-chaines in Verbindung mit dem Gebrauch des VS-Runtime-Debuggers, der eben auch klaglos nicht quelloffene Bereiche des kernels präsentiert (Assembler), kann man auch diese Bereiche sicherheitstechnisch überprüfen und auch strukturell aufklären, wenn man das will (TÜV-Aufgabe). Zu 100% hilfreich war dafür natürlich die versehentlich mit DEBUG-Symbolen behaftete Binary von Windows, auf der die NSAKEY-Entdeckung beruhte.
Wir dürfen aber sicher sein, daß China, Russland u. a. derlei Pannen NICHT bedürfen, um auch letzte Reste geheimgehaltener Win-Quellen aufzuklären (Disassembler -> abstrakte Symbole <-> bekannte Prototypie NICHT mehr quelloffener Teile.)
Ach Gottchen, daß der break-through zur offenen Software-Welt unmittelbar bevorsteht, höre ich, seit es OpenSource gibt.
Neben der erleichterten Fälschung von, bzw. Injektion in bestehende, Binaries, die aus völlig quelloffenem SW Code erzeugt sein sollten, sind da noch das Netz selbst und eine irre Vielfalt von Anwendungen & OS-AddOns darin, die selbst BDs enthalten oder on the download-fly damit versorgt werden können, sowie die Hardware selbst und auch deren Treiber-Software (Netzwerkkartentreiber ff.), die die Quelloffenheit von OSs als relevanten Sicherheitsvorteil in der Entscheidungsmatrix doch deutlich marginalisieren.
Das ist, in den einschlägigen, oft "CIO", Chief Information Officer u. ä. anführenden Medien, herrschendes Blendergerede. Wer darauf reinfällt, ist vermutlich eine/r der ersten von denen, die's erwischen wird:
Nach drei höchst allgemeinen Absätzen über angeblich valide Untersuchungen von aktuellen "Gemütszuständen" von IT-Entscheidern und ausdrücklich als "vage" klassifizierten Ausagen zum Kern,
werden drei Spiegel-Punkte als Kriterien aufgezählt, die aus NSA-Sicht eine BD erfüllen sollte, um dann daraufhin zu behaupten, die seien unter OpenSource schwerer zu erfüllen, - darunter die Zahl der BD-Mitwisser gering zu halten usw., was sämtlichst für auch Geheimprojekte im proprietären Umfeld gilt. Sicher, man könnte glauben, " Die Wahrscheinlichkeit, dass die Hintertür jemand entdeckt, ist deutlich größer, weil sich einfach viel mehr Menschen mit den Systemen beschäftigen."
Aber man muß sich klarmachen, daß in die Binaries quelloffenen Ursprungs eben sehr viel leichter auch eine Backdoor ZUR LAUFZEIT eingehängt werden kann. Das macht man über tolle Tools und weniger tolle, aber populäre Gimmicks. Da alles quelloffen, kann man auch die Sicherheits-Signets der Binaries nach den von dort bekannten Verfahren anpassen (on-the-download-fly) usw., notfalls reicht eine einzige asm-Zeile (und hinreichende Privilegierung des Ausführungstatus -> guxu Quellcode) zur rechten Zeit, um eine eigene Funktion, z. B. in einer geladenen dll, anstelle einer zur Ausführung anstehenden OS-Funktion auszuführen.
Der Fehler ist, daß sich "viele" mit quelloffenem Code statt mit proprietärem befassen. In der Tat, da findet der Blender/Blinde ein Korn, indem oben von einer "reaktionären Reaktion" gesprochen wird:
Fortschrittllich wäre es, sich OFFENSIV technisch, rechtlich u. vor allem POLITISCH mit dem Proprietären im Feld zu befassen, statt defensiven Pseudo-Schutz durch "viele, die sich damit beschäftigen" in offenen Quellcodes von OSs zu suchen, die nur 10 bis 60 % des ausgeführten Codes einer leidlich benutzten Maschine ausmachen.
Daraufhin wird kräftig eine (Don?) "Alfreco"-Gruppe beworben, die natürlich als Unternehmen prima OpenSource-CMS anbietet.
Lächerlich:
"Wer mit seinen Programmen Geld verdienen will und muss, hat natürlich wenig Interesse an Scherereien mit Behörden, wird also in aller Regel auf die "Wünsche" der NSA eingehen. Und dass es offenbar so ist, hat die Praxis ja bereits bewiesen."
Als ob Ehrenamtliche weniger "Scherereien mit Behörden" wünschen müssten als Bezahlte.
Da ist reine reaktionäre Ideologie am Werk, und die zunächst richtig in den Eingangsabschnitten erwähnte Möglichkeit von Korruption u./o. Erpressung (u. sonstigen Einflussnahmen bis zu "Unfällen" betreffender Leute), wird ohne jede Plausibilität allein der kommerziellen Sphäre zugeschrieben.
Welch' reaktionären Geist man bei Alfreco pflegt, sieht man im Folgenden:
Bei Don Alfreco weiss nämlich jemand "dass es absolute Sicherheit nicht gibt. Darauf komme es auch gar nicht an. "Wer vor einem Löwen wegläuft, muss nicht auf Dauer schneller sein als der Löwe, sondern lediglich schneller als Andere, die auch vor ihm auf der Flucht sind.""
Das ist eine völlig desolidarisierte Auffassung von der Bedeutung der IT, - und die Quelloffenheit als Hauptpfad zum "schneller sein als andere" auch eine irreführende Sackgasse, wie technisch dargelegt.
In dem falschen Bewußtsein, in CIO-originären/spezifischen Kontexten zu arbeiten, bucht sich der Alfreco-Sprecher ("Regional" = deutschsprachig) des Artikels erstmal ein großes Zynismus-Ticket.
Das ist sicher notwendig für diese Sphäre, aber noch lange kein Eintrittsbillet dahin, von Gasteinladungen abgesehen.
Der Rest des Artikels ist wieder Allgemein-Quirk und Uralt-Folklore ("besser Links verschieben", "viel zu lange zur Ader gelassen"), dessen Kommentierung nicht mehr erforderlich scheint, weil jeder Bezug zur Quelloffenheit<->Sicherheits-Diskussion fehlt.
Nee [username entfernt], da gab's schon deutlich BESSERE "Papiere". Wie geduldig auch die waren, zeigt der Schiffbruch der darin oft völlig überzogenen Erwartungen an die Quelloffenheit von OS als wesentlichem Sicherheitsmerkmal.