News SolarWinds-Attacke: Angreifer hatten Zugang zu Microsofts Quellcode

@KitKat::new()

Nein, ist es nicht. Bei einem richtigen Audit wird das Produkt auch gebaut (compiled) und es wird verglichen ob es die gleiche Signatur hat.
 
@Cool Master Ich glaube nicht, dass man Audits, bei welchen das Produkt nicht gebaut wird oder kein Signaturvergleich vorgenommen, nicht-richtige Audits nennen kann.
Darüber hinaus würde mich der Sinn eines Signaturvergleichs interessieren. Vermutlich willst du damit verifizieren, dass das Kompilat wirklich von dem Source Code kommt, von welchem er kommen sollte.
Aber ich denke, dass Microsoft durchaus in der Lage ist das auch ohne Signaturvergleich nachzuvollziehen.
Ein Signaturvergleich wäre darüberhinaus ziemlich sinnlos, falls die zu untersuchende Sache nicht entsprechend für einen solchen optimiert ist.

Davon abgesehen, hat Microsoft selbstverständlich die Möglichkeit ausgewählten Dienstleistern oder internen Auditteams die notwendigen Infos&Tools zum Bauen zu geben.
 
KitKat::new() schrieb:
Ich glaube nicht, dass man Audits, bei welchen das Produkt nicht gebaut wird oder kein Signaturvergleich vorgenommen, nicht-richtige Audits nennen kann.

Wie gesagt dann ist es meiner Meinung nach kein richtiges Audit. Es gibt in dem Fall keine Garantie, dass das Endprodukt dann den Code Stand entspricht welches untersucht wurde.

Genau das ist halt das Problem an Closed Source - man muss dem Hersteller vertrauen.

KitKat::new() schrieb:
Darüber hinaus würde mich der Sinn eines Signaturvergleichs interessieren. Vermutlich willst du damit verifizieren, dass das Kompilat wirklich von dem Source Code kommt, von welchem er kommen sollte.

Korrekt, damit kann man schnell feststellen ob aus dem Quellcode jeder die gleiche Binär Datei bekommt oder ob es ggf. beim kompilieren zu Codeänderungen (gewollt oder ungewollt) kommt.

KitKat::new() schrieb:
Ein Signaturvergleich wäre darüberhinaus ziemlich sinnlos, falls die zu untersuchende Sache nicht entsprechend für einen solchen optimiert ist.

Da muss nichts optimiert sein. Wenn ich ein Quellcode habe und nichts daran verändere wird stets die gleiche Signatur raus kommen zumindest sollte das passieren.
 
Cool Master schrieb:
Es gibt in dem Fall keine Garantie, dass das Endprodukt dann den Code Stand entspricht welches untersucht wurde.
1. Die gibt es auch mit Signaturvergleich nicht, da Hashcollisions
2. Doch: Falls Microsoft bezweifeln sollte, dass ihre Build-Pipeline wirklich von dem Source code stammt, kann Microsoft ja ebenfalls einen Audit jener verlangen
Cool Master schrieb:
Genau das ist halt das Problem an Closed Source - man muss dem Hersteller vertrauen.
Es sei denn Microsoft erlaubt der Organisation, welche den Audit durchführt, den Audit öffentlich zu machen oder sich in anderer Weise darüber zu äußern.

Cool Master schrieb:
Korrekt, damit kann man schnell feststellen ob aus dem Quellcode jeder die gleiche Binär Datei bekommt oder ob es ggf. beim kompilieren zu Codeänderungen (gewollt oder ungewollt) kommt.
Nein, man kann nur festestellen ob die gleiche Binärdatei rauskommt.
Ob Codeänderungen passieren, kann man nicht feststellen, da eine Signaturänderung viele verschiedene Ursachen haben kann.

Cool Master schrieb:
Da muss nichts optimiert sein. Wenn ich ein Quellcode habe und nichts daran verändere wird stets die gleiche Signatur raus kommen zumindest sollte das passieren.
Weit gefehlt. Es gibt sogar einen Fachbegriff für derartig optimierte Setups: Reproducible Builds
 
Zuletzt bearbeitet:
KitKat::new() schrieb:
Weit gefehlt. Es gibt sogar einen Fachbegriff für derartig optimierte Setups: Reproducible Builds

Gut ich kenne es nur für MacOS da passiert das wohl automatisch. Habs eben noch mal getestet und bekomme für eine meiner App jeweils die gleiche:
  • CandidateCDHash
  • CandidateCDHashFull
  • CDHash
Werte.

Zwei mal kompiliert mit einem Unterschied von ~5 Min.
 
Zurück
Oben