[Metalab] Frage an Coding-Freaks bzgl. Lambda Expressions in C++

[Michael Kafka]

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-writes-the-vuln


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-2017

-----------------------------------------------------------


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