1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › Responsible Disclosure: "Wir sollten…

Widerspricht er sich da nicht selbst?

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Widerspricht er sich da nicht selbst?

    Autor: Avarion 07.06.17 - 12:29

    Erst wird gesagt das die Leute die Patches per Reverse-Engineering auseinandernehmen und Exploits daraus bauen und dann erzählt er das sie keine Details rausrücken wollen damit keine Exploits gebaut werden können.

  2. Re: Widerspricht er sich da nicht selbst?

    Autor: Anonymer Nutzer 07.06.17 - 12:37

    ganz genau

    Ich hab mir das bereits nach dem Lesen der Überschrift gedacht, dass das doch sowieso meist per reverse engineering geschieht und weitergehende infos überhaupt nicht nötig sind. Dann sagt er das sogar selbst.

    Schade dass es der Autor/Interviewer verfehlt hat darauf einzugehen.

  3. Re: Widerspricht er sich da nicht selbst?

    Autor: Kleba 07.06.17 - 12:39

    Ich denke es ist beides. Keine Details im CVE bis Zeitraum X nach Patchveröffentlichung (um genügend Zeit für eine Installation des Patchs zu haben). Das Reverse Engineering ist schließlich auch noch mal eine (je nachdem) kleine oder größere Hürde.
    Ein Reverse Engineering wird sich ja nicht verhindern lassen. Aber wenn die Ressourcenverfügbarkeit fürs RE geringer sind, als "einfach nur" die CVE Einträge nach Schwachstellen zu durchforsten, ist zumindest ein wenig gewonnen.
    Ich bin mir aber auch nicht sicher, ob das die optimale Vorgehensweise ist.

    Auch die letzten Veröffentlichungen von Googles Project Zero sind so ein zweischneidiges Schwert. Auf der einen Seite ist es natürlich sinnvoll die Informationen zu veröffentlichen. Auf der anderen Seite hatte MS bspw. einen Patch erstellt, bei dem in letztem Moment Probleme aufgefallen sind, welcher dann nicht ausgeliefert werden konnte. So war mutmaßlich klar, dass mit Hochdruck daran gearbeitet wird, aber es wurden trotz fehlenden Patchs die Details veröffentlicht. Das finde ich nicht so pralle. Wenn ein Hersteller nicht (oder viel zu langsam) reagiert, kann ich das ja verstehen. Aber wenn dann schon daran gearbeitet wird, es aber noch etwas länger dauert, dann sollten die beteiligten Parteien miteinander reden und ggf. einen Aufschub vereinbaren.

  4. Re: Widerspricht er sich da nicht selbst?

    Autor: bernd71 07.06.17 - 13:15

    Avarion schrieb:
    --------------------------------------------------------------------------------
    > Erst wird gesagt das die Leute die Patches per Reverse-Engineering
    > auseinandernehmen und Exploits daraus bauen und dann erzählt er das sie
    > keine Details rausrücken wollen damit keine Exploits gebaut werden können.

    Reverse Engineering ist schon mal einfacher wenn man weiß bei welcher Funktion man anfangen muss. Es ist ja ein Wettlauf mit der Zeit und es wird nie eine in allen Situationen perfekte Lösung für die Veröffentlichung geben. Man darf(sollte) aber immer das aktuelle Vorgehen hinterfragen.

  5. reverse engineering des patches...

    Autor: t_e_e_k 07.06.17 - 13:19

    Avarion schrieb:
    --------------------------------------------------------------------------------
    > Erst wird gesagt das die Leute die Patches per Reverse-Engineering
    > auseinandernehmen und Exploits daraus bauen und dann erzählt er das sie
    > keine Details rausrücken wollen damit keine Exploits gebaut werden können.

    wenn ich weiß ob ich einen zero day oder eine andere lücke suche, hilft das enorm bei der suche nach dem "fehler" im code, den ich gerade per RE auseinader nehme. Und wenn dann im patch auch noch "weiterentwicklungen" die nichts mit irgendwelchen bugs zu tun haben, vorhanden sind, wird das ganze schon deutlich komplexer, teurer und kostet mehr zeit. Zeit die Administratoren haben, um die Patches einzuspielen. Und wenn es nur 2 Tage sind.

  6. Re: Widerspricht er sich da nicht selbst?

    Autor: Cok3.Zer0 07.06.17 - 13:26

    Er arbeitet für die Israelis. Glaubt denn wirklich jemand, dass die die Exploits geheim halten und nicht an den Mossad weiterleiten?



    1 mal bearbeitet, zuletzt am 07.06.17 13:27 durch Cok3.Zer0.

  7. Re: Widerspricht er sich da nicht selbst?

    Autor: EQuatschBob 07.06.17 - 13:32

    Ja, er widerspricht sich total und geht in die völlig falsche Richtung.

    Er gibt ja selbst zu, daß die "black hats" z.T. über erhebliche Mittel (Geld, Personal) verfügen und somit auch mit weniger Informationen Exploits bauen können. Allenfalls wird es zu einer Verschiebung kommen: Kleine Hackerbanden kommen vielleicht nicht mehr hinterher, die großen machen dann mehr Reibach.

    Ich hoffe, daß es innerhalb der "security community" nicht zu einem Paradigmenwechsel kommt und auf Leute wie Vanunu auch weiterhin nicht gehört wird.

  8. Re: Widerspricht er sich da nicht selbst?

    Autor: RipClaw 07.06.17 - 14:03

    Avarion schrieb:
    --------------------------------------------------------------------------------
    > Erst wird gesagt das die Leute die Patches per Reverse-Engineering
    > auseinandernehmen und Exploits daraus bauen und dann erzählt er das sie
    > keine Details rausrücken wollen damit keine Exploits gebaut werden können.

    Es geht nicht darum komplett zu verhindern das Exploits gebaut werden sondern das man einfach nur etwas mehr Zeit gewinnt.

    So ein Reverse Engineering dauert seine Zeit und selbst wenn man den Patch auseinander genommen hat kann man noch nicht unbedingt einen Exploit bauen der auch zuverlässig funktioniert.

  9. Re: Widerspricht er sich da nicht selbst?

    Autor: Xiut 07.06.17 - 14:19

    Kleba schrieb:
    --------------------------------------------------------------------------------
    > [...]
    > Auch die letzten Veröffentlichungen von Googles Project Zero sind so ein
    > zweischneidiges Schwert. Auf der einen Seite ist es natürlich sinnvoll die
    > Informationen zu veröffentlichen. Auf der anderen Seite hatte MS bspw.
    > einen Patch erstellt, bei dem in letztem Moment Probleme aufgefallen sind,
    > welcher dann nicht ausgeliefert werden konnte. So war mutmaßlich klar, dass
    > mit Hochdruck daran gearbeitet wird, aber es wurden trotz fehlenden Patchs
    > die Details veröffentlicht. Das finde ich nicht so pralle. Wenn ein
    > Hersteller nicht (oder viel zu langsam) reagiert, kann ich das ja
    > verstehen. Aber wenn dann schon daran gearbeitet wird, es aber noch etwas
    > länger dauert, dann sollten die beteiligten Parteien miteinander reden und
    > ggf. einen Aufschub vereinbaren.

    Das Project Zero Team veröffentlicht die Informationen erst nach 90 (!) Tagen. Da scheint Microsoft dann einfach viel zu spät mit dem fixen der Probleme angefangen zu haben. 90 Tage sollten da selbst für Microsoft locker einhaltbar sein, WENN sie es wollen und die Prioritäten richtig setzen...

  10. Re: Widerspricht er sich da nicht selbst?

    Autor: AllDayPiano 07.06.17 - 14:24

    Naja ist doch eigentlich ganz logisch: Woher soll ein Mensch mit bösen Absichten wissen, dass eine an den Hersteller gemeldete Lücke gepatcht wird, oder ob das nicht einfach ein ganz regulärer Bugfix ist?

    In erster Linie weiß man dann nur: Ahh, hier wurde was verändert. Das lässt ja noch nichtmal auf den Grund schließen.

    Anders sieht es halt aus, wenn geschrieben wird: Fehler wurde in der Funktion XYZ behoben, der bei einem Überlauf Zugriff auf das System ermöglicht. Denn dann wird den Black Hats gesagt: In der Funktion XYZ musst du nur gucken, was vorher/nachher anders ist, und damit baust du den Exploit.

  11. Auf Linux Patch meist innerhalb von Stunden bereit....

    Autor: SJ 07.06.17 - 14:33

    Xiut schrieb:
    --------------------------------------------------------------------------------
    > Das Project Zero Team veröffentlicht die Informationen erst nach 90 (!)
    > Tagen. Da scheint Microsoft dann einfach viel zu spät mit dem fixen der
    > Probleme angefangen zu haben. 90 Tage sollten da selbst für Microsoft
    > locker einhaltbar sein, WENN sie es wollen und die Prioritäten richtig
    > setzen...


    Wenn ich so sehe, wie schnell Zeugs in Linux gepatcht wird.. meist innert wenigen Stunden bis einigen Tagen.... wieso können "nicht bezahlt Frickler" das in dieser Zeit hinkriegen, jedoch ein Multi-Milliarden Konzern mit "fast unbeschränkten Ressourcen" nicht innerhalb von 90 Tagen?

    Und zudem: Nur weil ein Sicherheitsloch noch nicht veröffentlicht worden ist bedeutet das ebe nicht, dass Hacker das nicht bereits ausnutzen. Wenn Google mit Project Zero Ausnahmen machen würde, dann sinds bald 100 Tage, danach 120 Tage, danach 150 Tage, danach 200 Tage, danach 1 Jahr....

    --
    Wer all meine Fehler findet und die richtig zusammensetzt, erhält die geheime Formel wie man Eisen in Gold umwandeln kann.

  12. Re: Widerspricht er sich da nicht selbst?

    Autor: Salzbretzel 07.06.17 - 14:36

    Nicht immer 90 Tage, wenn der Hersteller/Entwickler Kontakt aufnimmt ging es schon anders aus.
    Apple konnte sich 146 Tage Zeit nehmen. Aber MS hat auch das nicht getan.

    Und ohne Krawall gibt es ja schon seit (glaube) 2015 ein 14 Tage Aufschub bei Kontaktaufnahme.
    Der Punkt ist wie so oft im Leben die Kommunikation.

  13. Re: Widerspricht er sich da nicht selbst?

    Autor: DeathMD 07.06.17 - 14:54

    Das behauptest du so leicht... schon mal was mit Behörden zu tun gehabt? Die Mühlen mahlen dort sehr gemächlich vor sich hin und jetzt stell dir mal vor Microsoft bekommt so eine Lücke gemeldet und muss dann erst einmal bei allen Geheimdiensten einen Antrag stellen, ob diese überhaupt geschlossen werden darf.

    Nach 90 Tagen hast du mit viel Glück von einem eine Rückmeldung erhalten und in der steht dann: "Dies fällt leider nicht in unseren Zuständigkeitsbereich, bitte wenden Sie sich an das Bundesreferat für geheimdienstliche Sicherheitslücken, Abteilung 1ABuG."

    BRAWNDO: The Thirst Mutilator

    It's got Electrolytes



    1 mal bearbeitet, zuletzt am 07.06.17 15:02 durch DeathMD.

  14. Re: Auf Linux Patch meist innerhalb von Stunden bereit....

    Autor: Vielfalt 07.06.17 - 15:29

    SJ schrieb:
    --------------------------------------------------------------------------------
    > Xiut schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Das Project Zero Team veröffentlicht die Informationen erst nach 90 (!)
    > > Tagen. Da scheint Microsoft dann einfach viel zu spät mit dem fixen der
    > > Probleme angefangen zu haben. 90 Tage sollten da selbst für Microsoft
    > > locker einhaltbar sein, WENN sie es wollen und die Prioritäten richtig
    > > setzen...
    >
    > Wenn ich so sehe, wie schnell Zeugs in Linux gepatcht wird.. meist innert
    > wenigen Stunden bis einigen Tagen.... wieso können "nicht bezahlt Frickler"
    > das in dieser Zeit hinkriegen, jedoch ein Multi-Milliarden Konzern mit
    > "fast unbeschränkten Ressourcen" nicht innerhalb von 90 Tagen?
    >
    > Und zudem: Nur weil ein Sicherheitsloch noch nicht veröffentlicht worden
    > ist bedeutet das ebe nicht, dass Hacker das nicht bereits ausnutzen. Wenn
    > Google mit Project Zero Ausnahmen machen würde, dann sinds bald 100 Tage,
    > danach 120 Tage, danach 150 Tage, danach 200 Tage, danach 1 Jahr....

    So ein Unsinn.

  15. Re: Auf Linux Patch meist innerhalb von Stunden bereit....

    Autor: SJ 07.06.17 - 15:37

    Vielfalt schrieb:
    --------------------------------------------------------------------------------
    > So ein Unsinn.

    Aha

    --
    Wer all meine Fehler findet und die richtig zusammensetzt, erhält die geheime Formel wie man Eisen in Gold umwandeln kann.

  16. Re: Widerspricht er sich da nicht selbst?

    Autor: m00hk00h 07.06.17 - 16:19

    Wenn ein Patch auseinander gebastelt wird, heißt das in aller erster Linie: Es gibt zu diesem Zeitpunkt schon einen Patch!

    Die Situation ist eine völlig andere, wenn in einem beliebigen öffentlichen Bugtracker, Jira, github oder sonstwas ein Bug dokumentiert wird, oft schon inklusive Code, mit dem man ihn provozieren kann. Dann ist im schlimmsten Fall am selben Tag ein Exploit da, der Patch lässt aber noch Monate auf sich warten.

    Betrifft natürlich nicht die "großen 5", aber passiert wohl oft genug.

  17. Re: Widerspricht er sich da nicht selbst?

    Autor: Voutare 07.06.17 - 16:29

    Xiut schrieb:
    --------------------------------------------------------------------------------
    > Das Project Zero Team veröffentlicht die Informationen erst nach 90 (!)
    > Tagen. Da scheint Microsoft dann einfach viel zu spät mit dem fixen der
    > Probleme angefangen zu haben. 90 Tage sollten da selbst für Microsoft
    > locker einhaltbar sein, WENN sie es wollen und die Prioritäten richtig
    > setzen...

    So weit ich der Artikel verstanden habe, geht es nur um der zeit spanne zwischen ausliefern Patch und einspielen der Patch.

    Dass (nur) wenn Microsoft innerhalb der gegebene 90 Tage eine Patch bereitgestellt hat, für X Tagen mehr der Bug-Info nur begrenzt offen gelegt wird. (wo X als faire Zeit steht wo Firmen diese Patch testen/einspielen können)

    Diese 90 Tage aufweichen wurde eine schlechte Sache sein, da bin ich einverstanden.

  18. Re: Auf Linux Patch meist innerhalb von Stunden bereit....

    Autor: ldlx 07.06.17 - 17:50

    SJ schrieb:
    --------------------------------------------------------------------------------
    > Wenn ich so sehe, wie schnell Zeugs in Linux gepatcht wird.. meist innert
    > wenigen Stunden bis einigen Tagen.... wieso können "nicht bezahlt Frickler"
    > das in dieser Zeit hinkriegen, jedoch ein Multi-Milliarden Konzern mit
    > "fast unbeschränkten Ressourcen" nicht innerhalb von 90 Tagen?

    Weil es da sehr viele Abhängigkeiten gibt und da nicht versehentlich Müll reinprogrammiert (und veröffentlicht!) werden darf, der Betriebssysteme (letztens der Bug im Security-Only-Update, der die DCs lahmlegte) oder Anwendungssoftware von allen möglichen Drittanbietern (wie etwa Datev, SAP, Security-Lösungen oder jede andere Software, deren Ausfall im Sekundentakt Millionenschäden oder gar Personenschäden verursacht) oder gar eigene Produkte (wie etwa Office) lahmlegt. Und das über aktuell 5 supportete Betriebssysteme zzgl. Server-Ableger und unzähligen SKUs hinweg. Dass die Drittanbieter und auch die Endkunden meist eigene Prüfverfahren vor Freigabe einzelner Patches haben, macht das nicht einfacher - Windows XP wird ja allerorten nicht zum Spaß weit über die Supportgrenzen hinaus betrieben.

    Letztens stand mal in einem Artikel, dass das Windows-Repo alleine irgendwas um die 300 GB groß ist, wenn ich mich richtig erinnere.

  19. Re: Auf Linux Patch meist innerhalb von Stunden bereit....

    Autor: Dadie 07.06.17 - 18:21

    ldlx schrieb:
    --------------------------------------------------------------------------------
    > [..]
    > Weil es da sehr viele Abhängigkeiten gibt und da nicht versehentlich Müll
    > reinprogrammiert (und veröffentlicht!) werden darf, der Betriebssysteme
    > (letztens der Bug im Security-Only-Update, der die DCs lahmlegte) oder
    > Anwendungssoftware von allen möglichen Drittanbietern (wie etwa Datev, SAP,
    > Security-Lösungen oder jede andere Software, deren Ausfall im Sekundentakt
    > Millionenschäden oder gar Personenschäden verursacht) oder gar eigene
    > Produkte (wie etwa Office) lahmlegt. [..]

    Nur gibt es genau für diese Szenario schon seit Jahrzehnten eine Lösung, nennt sich "Hotfix". Ein "Hotfix" behebt einen Fehler, stellt aber keine Kompatibilität sicher. Erst der spätere Patch ist eine dauerhafte und geprüfte Fehlerkorrektur.

    Die Unterscheidung ergibt insbesondere bei Betriebssystemen Sinn. Im Zweifel ist es besser, dass eine Software kurzzeitig nicht mehr läuft, dafür aber dein System sicher ist, als dass deine Software zwar läuft, aber eben auch Schadsoftware die via Exploit auf dein System gekommen ist.

  20. Re: Auf Linux Patch meist innerhalb von Stunden bereit....

    Autor: ldlx 07.06.17 - 18:33

    Dann hätte ich gern mehr Hotfixes, bei denen ich anhand der vorliegenden Informationen und der selbst durchgeführten Funktionstests entscheiden kann, ob ich das in der Zwischenzeit ausrollen will.

    Aber auch das ist nicht so eindeutig gut, wenn es nicht gezielt angewendet wird.

    KB2775511 ist so ein "Hotfix" - der gefühlt Jahre zu spät erschien und neben MEINEM Problem viel zu viele andere Probleme behob - und bis heute ist mir kein entsprechendes "Update" zumindest für mein Problem bekannt - wurde auch nicht über Windows Update ausgerollt, soweit ich weiß (manueller Import in WSUS für Verteilung). Für micht entscheidend war der Rollout, weil es unter Windows 7 Probleme gab, das bei der Verwendung von MS Office in Kombination mit Ordnerumleitung/Offline-Sync haufenweise temporäre-Dateien zurückblieben und vor allem die eigentlichen Dokumente nicht in konsistentem Zustand über die Geräte hinweg vorlagen. Nebenbei wurden noch sehr viele andere Probleme im Bereich Drucker/Dateifreigabe gefixt, die mich nicht betrafen (aber mir auch nicht schadeten, das hätte aber auch gut Kollateralschäden auslösen können)

    Edit: warte kurz, wenn ich so zurückdenke... einzelne Updates für spezifische Probleme hat Microsoft Juli 2016 abgeschafft und eine monatliche "Blackbox" eingeführt - und bislang mehrere Bugs eingefügt, um die du nicht rundrum kommst.



    1 mal bearbeitet, zuletzt am 07.06.17 18:41 durch ldlx.

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. V-LINE EUROPE GmbH, Sehnde
  2. Kreisausschuss des Hochtaunuskreises, Bad Homburg
  3. OEDIV KG, Bielefeld
  4. dSPACE GmbH, Paderborn

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. Verkaufsstart RTX 3060 Ti um 15 Uhr
  2. Verkaufsstart RTX 3060 Ti um 15 Uhr
  3. Verkaufsstart RTX 3060 Ti um 15 Uhr
  4. Verkaufsstart RTX 3060 Ti um 15 Uhr


Haben wir etwas übersehen?

E-Mail an news@golem.de


Gemanagte Netzwerke: Was eine Quasi-Virtualisierung von WANs und LANs bringt
Gemanagte Netzwerke
Was eine Quasi-Virtualisierung von WANs und LANs bringt

Cloud Managed LAN, Managed WAN Optimization, SD-WAN oder SD-LAN versprechen mehr Durchsatz, mehr Ausfallsicherheit oder weniger Datenstau.
Von Boris Mayer


    iPhone 12 Mini im Test: Leistungsstark, hochwertig, winzig
    iPhone 12 Mini im Test
    Leistungsstark, hochwertig, winzig

    Mit dem iPhone 12 Mini komplettiert Apple seine Auswahl an aktuellen iPhones für alle Geschmäcker: Auf 5,4 Zoll sind hochwertige technischen Finessen vereint, ein besseres kleines Smartphone gibt es nicht.
    Ein Test von Tobias Költzsch

    1. Apple Bauteile des iPhone 12 kosten 313 Euro
    2. Touchscreen und Hörgeräte iOS 14.2.1 beseitigt iPhone-12-Fehler
    3. iPhone Magsafe ist nicht gleich Magsafe

    Macbook Air mit Apple Silicon im Test: Das beste Macbook braucht kein Intel
    Macbook Air mit Apple Silicon im Test
    Das beste Macbook braucht kein Intel

    Was passiert, wenn Apple ein altbewährtes Chassis mit einem extrem potenten ARM-Chip verbindet? Es entsteht eines der besten Notebooks.
    Ein Test von Oliver Nickel

    1. Apple Macbook Air (2020) im Test Weg mit der defekten Tastatur!
    2. Retina-Display Fleckige Bildschirme auch bei einigen Macbook Air
    3. iFixit Teardown Neue Tastatur macht das Macbook Air dicker

    1. Monitron und Panorama: Amazon will mit KI in die Fabriken
      Monitron und Panorama
      Amazon will mit KI in die Fabriken

      Dank KI in Sensoren oder Kameras will AWS auch in der Industrie Fuß fassen. Mit KI will Amazon aber auch seine Cloud-Dienste smarter machen.

    2. Banking: N26 führt Tagesgeldkonto ein
      Banking
      N26 führt Tagesgeldkonto ein

      Mit Easyflex Savings können N26-Kunden Geld beiseitelegen, das mit 0,17 Prozent pro Jahr verzinst wird.

    3. TheC64 Maxi im Test: Moderner Retro-Computer für C64-Nostalgiker
      TheC64 Maxi im Test
      Moderner Retro-Computer für C64-Nostalgiker

      Der TheC64 Maxi ist die moderne Version des C64. Der Nostalgiefaktor ist riesig, auch wenn er nicht alle Features des guten alten "Brotkastens" hat.


    1. 12:24

    2. 12:06

    3. 12:05

    4. 11:47

    5. 11:19

    6. 10:36

    7. 10:20

    8. 10:05