Hallo Liebe Listen, (verzeiht das Cross-Posting) (Ist etwas länger, bitte ignorieren, wenn's den Aufwand nicht wert ist. Bitte, bitte kein MS-Bashing draus machen, nur weil Microsoft bei irgendjemand irgendwas triggert) Das betrifft Inline Assembler in Lambda Expressions als Parameter für Function Calls. Klingt sehr esoterisch, ist sicher nicht daily business und nur für sehr spezifische Szenarien relevant. Hoffentlich erwecke ich das akademische bzw. philosophische Interesse von euch. Mich interessiert die Meinung von "Code-Freaks" ob das im typischen Coding-Alltag eine Rolle spielt oder es ein üblicher Ansatz für sauberen und stabilen Code ist. Ich würde mich über Antworten freuen, bin aber weder enttäuscht noch beleidigt, wenn das bei euch kein Interesse findet oder der Aufwand, das durchzulesen und eine objektive, fundierte Antwort zu schreiben zu hoch ist. Ich bin durch eine Meldung auf CERT.at-Discussion aufmerksam geworden auf: CVE-2019-0546, "Visual Studio Remote Code Execution Vulnerability." bzw. ZDI-19-448, Zero Day Initiative von Trend Micro. Es geht um C++ Lambda Expressions die im speziellen Fall als Parameter für einen Function-Call C++ Code übergeben und der übergebene Code __asm enthält. Meine Betrachtungen auf der CERT.at-Discussion Liste: (Ich begrüsse auch hier objektive, fundierte Kritik) ----------------------------------------------------------- (Übersicht als Timeline) Oktober 2018 ist Simon Zuckerbraun (aka @HexKitchen) von Zero Day Initiative auf einen Compiler-Fehler in MS-VS gestossen Jannuar 2019 wurde CVE-2019-0546 publiziert: "... Victim must voluntarily interact with attack mechanism" https://nvd.nist.gov/vuln/detail/CVE-2019-0546 Und Microsoft hat am selben Tag publiziert: "Exploitation of the vulnerability requires that a user open a specially crafted file which was compiled with an affected version of Visual Studio. In an email attack scenario, an attacker could exploit the vulnerability by sending a specially crafted project, or resource file, to the user and convince the user to open the file." Jan 2019 gibt es einen Patch für VS2017, __asm in Lambdas verboten: Visual Studio 2017 version 15.9.5 Service Release -- released on January 08, 2018 https://docs.microsoft.com/en-us/visualstudio/releasenotes/vs2017-relnotes “This specific report, CVE-2019-0546, is about disallowing inline assembly inside C++ lambda bodies. The said vulnerability is about downloading and running untrusted code, which has always existed in all releases prior VS2017 Update 9 that supported lambdas. The scenario is not common coding practice and considering we've always had this in all our prior releases and have not seen any evidences of exploit it would not make sense to port the change as hotfix from 15.9 to prior VS releases.” (scheint eine direkte Nachricht an ZDI zu sein, kann keine Ressource im Internet finden. Das Zitat ist dem untenstehen Blog entnommen) Februar 2019 publiziert Simon Zuckerbraun einen Blog dazu: "The bug is triggered by a lambda expression meeting these two conditions: 1) The lambda has an implicit capture, either by reference or by copy. 2) The lambda contains an __asm block." Er äussert sich auch enttäuscht darüber, das MS einfach __asm in Lambdas nicht mehr unterstützt (siehe oben) und führt weiter aus: "I find it a bit amusing that Microsoft’s fix for Visual Studio 2017 was to remove support for __asm blocks within lambdas. Und weiter unten: "we still believe it worth patching and hope Microsoft reconsiders in the future." https://www.thezdi.com/blog/2019/2/28/finding-unicorns-when-the-c-compiler-w... April 2019 publiziert ZDI einen "Zero-Day" dessen Beschreibung auf CVE-2019-0546 passt mit Credit HexKitchen (Simon Zuckerbraun): https://www.zerodayinitiative.com/advisories/ZDI-19-448/ Das Datum des "initial report to vendor" ist identisch mit dem Patch für Visual Studio. (Meine Meinung: Möglicher Hintergrund ist, das Trend Micro mit der Lösung von Microsoft unzufrieden ist oder dass Trend Micro die Gelegenheit sieht Publicity zu bekommen. Es ist keine dazu passende CVE zu finden, das scheint ein ZDI Alleingang zu sein.) Hintergrund Lambda Expressions: Lambda Expression in C++ (Visual Studio): " ...is a convenient way of defining an anonymous function object (a closure) right at the location where it is invoked or passed as an argument to a function." Dabei wird ein Code-Block als Parameter für einen Funktionsaufruf übergeben. Etwa so: function(a, b, [] (x, y) {c-code}) \________ _______/ V "Lambda Expression" Wenn die Lambda Expression __asm enthält dann crasht das bei Visual Studio, deshalb disallowed im Patch. https://docs.microsoft.com/en-us/cpp/cpp/lambda-expressions-in-cpp?view=vs-2... ----------------------------------------------------------- Meine Vermutungen, Fragen, Bitten: Vermutung: Eine Lambda Expression als Parameter mit Inline Assembler bietet kein klar definiertes Environment für Assembler Code im Gegensatz zu Inline Assembler innerhalb einer normalen Function Declaration. Frage: Wie verhalten sich andere C++ Compliler in der selben Situation? llvm, gcc, g++ etc? Bitte: Wäre es unverschämt zu fragen, ob eine Hackerin oder ein Hacker ein kleines C++ PoC zu schreiben? Mein Coding ist zu eingerostet und ich hab keine Erfahrung mit Inline Assembler. Liebe Grüsse und danke im Voraus, MiKa