News Project Zero: Bug in Windows-10-Versionen hebelt UMCI aus

mischaef

Kassettenkind
Teammitglied
Dabei seit
Aug. 2012
Beiträge
1.626
#1
Das Security-Team von Google hat erneut eine Sicherheitslücke in einem Betriebssystem von Microsoft bekanntgemacht, bevor der Software-Riese diese beheben konnte. Eine Gefahr besteht jedoch nur unter bestimmten Umständen, dann kann aber auf Systemen mit Windows 10 S und Enterprise-Versionen Schadcode dauerhaft ausgeführt werden.

Zur News: Project Zero: Bug in Windows-10-Versionen hebelt UMCI aus
 
Dabei seit
Juni 2005
Beiträge
2.933
#2
90 Tage finde ich fair. Wenn jemand es in diesem Zeitraum nicht schafft seinen Code abzudichten sollte den Code so weit in den Griff kriegen, dass er es schafft.

Die eigentliche Arbeit, das finden des Bugs hat ja Google dankenswerterweise kostenlos erledigt.
 

Palmdale

Lt. Commander
Dabei seit
Apr. 2009
Beiträge
1.535
#3
Hm, man kann irgendwie beide Seiten verstehen. Einerseits die von Google, dass so schnell wie möglich die Lücken behoben werden. Andererseits aber auch die von Microsoft, dass Windows eben nicht so leicht zu patchen ist; nicht weil sie nicht wollen (wurde ja bestätigt), sondern weil bei Fehlern im Patch mit ggf neuen Lücken das Geschrei groß ist mit dem Vorwurf, man testet nicht ausreichend genug.

Keine Ahnung, ob hier 90 Tage ein gut bemessener Zeitraum ist :/
 
Dabei seit
Nov. 2009
Beiträge
2.516
#4
Finde es selbst auch schwierig zu sagen ob 90 Tage ausreichend sind.

Klar, man hätte es gerne schnell gepatcht aber was wenn durch den Patch noch größere Lücken entstehen.
Für einen schnellen Patch ist es sicherlich viel zu komplex. Ist letzten Endes ein Betriebssystem und keine einzelne App.
 

nickless_86

Lt. Commander
Dabei seit
Juli 2009
Beiträge
2.030
#5
Naja bei einem Unternehmen wie MS sollten doch genügend Ressourcen da sein um es in 90Tagen zu realisieren. ist ja keine 5 Mann Abteilung
 
Dabei seit
Apr. 2017
Beiträge
724
#6
In dem Zeitrahmen schaffen es Großkonzerne nicht mal bestimmte Dinge in ihren internen Reports ändern zu lassen. Wenn ich jetzt vom Controlling ausgehe und unser internes Konzencontrolling anschaue - wenn wir hier am Kern unseres Produkts Änderungen machen müssten, würde das eher 1/2 Jahr benötigen ;)

Keiner von uns, der nicht mal an einem großen OS mit programmiert hat - kann sagen, wie lange das dauern würde. Schon gar nicht, wenn da Ahängigkeiten zu anderen Softwareteilen vorhanden sind. Ich war mal der letzte in der Reihe der "UATs" (user accecptance test) und habe ein Projekt, welches kurz vor dem Abschluss stand, berechtigt scheitern lassen (weil es ein "gröberes" Durcheinander verursacht hätte ^^). Dieses Projekt ging ziemlich genau ein Jahr später "live", nach gründlicher Überarbeitung.
 

Hauro

Commodore
Dabei seit
Apr. 2010
Beiträge
4.978
#7
Viele hier haben dieselbe Durchdringung wie Stakeholder. Falls es eine zentrale Komponente betrifft, die Auswirkung auf eine andere Komponente hat, muss/müssen auch diese angepasst werden. Dann kommt der ganze Spaß mit der Rollout Planung, wie QS und der Sicherheitsabnahme bei einem Betriebssystem hinzu. Bei uns müssen meistens Penetrationstests eingeplant und durchgeführt werden.

Das Chinesen-Prinzip funktioniert oft nicht. Die Annahme, dass sich das Projektergebnis linear zu den eingesetzten Mitarbeitern entwickelt (Chinesen-Prinzip) ist widerlegt.

@Google
Vielleicht mal bei Android vormachen und die Lücken in 90 Tagen schließen und an alle verteilen.
 

Zero_Point

Cadet 4th Year
Dabei seit
Feb. 2017
Beiträge
100
#8
Hm, man kann irgendwie beide Seiten verstehen. Einerseits die von Google, dass so schnell wie möglich die Lücken behoben werden. Andererseits aber auch die von Microsoft, dass Windows eben nicht so leicht zu patchen ist; nicht weil sie nicht wollen (wurde ja bestätigt), sondern weil bei Fehlern im Patch mit ggf neuen Lücken das Geschrei groß ist mit dem Vorwurf, man testet nicht ausreichend genug.

Keine Ahnung, ob hier 90 Tage ein gut bemessener Zeitraum ist :/
Wenn sich Microsoft auf die wichtigen Dinge beschränken würde anstatt immer nur neue fehleranfällige Features einzubauen, dann hätten sie vielleicht nicht diese Problematik. Vor allem könnten sie dann auch ausreichend testen.

90 Tage sind ok, sind immerhin 3 Monate. In der Zeit ändert Microsoft sonst auch eine Menge.
 
Dabei seit
Jan. 2008
Beiträge
2.783
#9
In dem Zeitrahmen schaffen es Großkonzerne nicht mal bestimmte Dinge in ihren internen Reports ändern zu lassen. Wenn ich jetzt vom Controlling ausgehe und unser internes Konzencontrolling anschaue - wenn wir hier am Kern unseres Produkts Änderungen machen müssten, würde das eher 1/2 Jahr benötigen ;)
Ich denke genau darum geht es. Heutzutage dauert alles viel zu lange. Nicht nur in diesem Kontext hier. Tausende Leute wollen mitentscheiden, es muss durch zig Instanzen gehen und abgsegnet werden, wobei locker die Hälfte davon eigentlich gar nicht weiß worum es eigentlich geht. Große Konzerne sind in dieser Hinsicht meist eine Katastrophe. Extrem starr, unflexibel und verbohrt. Hauptsache alles läuft ausschließlich nach den von Erbsenzählern ausgearbeiteten Ablaufplänen. Und wehe einer weicht ab um ein Problem einfach mal schnell und effizient zu lösen. :rolleyes:
 
Dabei seit
Apr. 2007
Beiträge
3.251
#10
Wenn sich Microsoft auf die wichtigen Dinge beschränken würde anstatt immer nur neue fehleranfällige Features einzubauen, dann hätten sie vielleicht nicht diese Problematik. Vor allem könnten sie dann auch ausreichend testen.

90 Tage sind ok, sind immerhin 3 Monate. In der Zeit ändert Microsoft sonst auch eine Menge.
Bei Daimler läuft alle 96 Sekunden ein Sprinter vom Band, daher muss es doch auch in der Zeit möglich sein die Fahrzeug-Konstruktion zu ändern... oder auch nicht.
Die erscheinenden Änderungen belegen höchstens die kontinuierliche Arbeit an den Themen, nicht aber wie lange die Bearbeitung gedauert hat.

Abgesehen davon klingt die Aussage so, als würde es irgendwer besser machen und das ist nicht der Fall...
 
Dabei seit
Juni 2017
Beiträge
782
#11
@Google
Vielleicht mal bei Android vormachen und die Lücken in 90 Tagen schließen und an alle verteilen.
Google behebt gefundene Fehler immer möglichst schnell, und gibt die Änderungen an Ihre Partner und Kunden weiter. Das es dann ewig dauert bis die Partner diese Änderung patchen ist nicht die Schuld von Google. Kauf dir ein Pixel dann hast du immer möglichst schnell deine Updates.
 
Dabei seit
Jan. 2013
Beiträge
4.454
#12
Auch der Vorschlag seitens Microsoft, mit der Offenlegung der Lücke bis zur Veröffentlichung des Redstone-4-Updates für Windows 10 zu warten, wurde von Google mit der Begründung des fehlenden Termins ebenfalls abgelehnt.
Ganz blöd gelaufen. :evillol:

Es wäre wirklich toll, wenn man sich bei MS endlich wieder weniger um X belanglose Features und mehr um ein stabiles und zuverlässiges System kümmern würde. Das läuft mit Win 10 und den gefühlt 100 unterschiedlichen Varianten und Versionen doch mächtig aus dem Ruder.
 

Hauro

Commodore
Dabei seit
Apr. 2010
Beiträge
4.978
#13
@TheTrapper
Dann liegt es am Betriebssystem, wenn es Google bei Android Updates nicht direkt verteilten kann - design failure. Den Kunden interessiert nur, ob sein Gerät sicher ist. Deshalb wird bei uns in der Firma auch iOS / Apple eingesetzt. Die Einschränkungen, die mich persönlich von Apple abhalten, sind hier eher ein Vorteil.
 
Zuletzt bearbeitet:
Dabei seit
Jan. 2013
Beiträge
4.454
#14
Wie man bei Android sehen kann, so interessiert es den Kunden eher nicht.
 
Dabei seit
Dez. 2013
Beiträge
4.168
#15
Das läuft mit Win 10 und den gefühlt 100 unterschiedlichen Varianten und Versionen doch mächtig aus dem Ruder.
Nein, Sicherheitslücken gab es in Betriebssystemen schon immer, nur hast du nie mitbekommen, wie lange die intern bekannt waren.

Ich sehe auch echt keinen Grund, warum Google die Lücken nach 90 Tagen veröffentlicht außer des Anprangerns der Konkurrenz. Natürlich baut man damit einen gewissen Druck / Handlungsbedarf auf, aber 90 Tage für nur wenig komplexen Programmen ist nun mal fairer, als 90 Tage für die Behebung eines Fehler in einem OS, wie z.B. Windows. Natürlich hat MS mehr Mitarbeiter, aber Mitarbeiter ist nicht 1:1 auf die Leistung zu übertragen.

Erst wird ein Team, das mit dem Modul, das die Sicherheitslücke beinhaltet, vertraut ist, damit beauftragt, diese zu schließen. Dadurch entstehen andere Probleme, die evtl. erst durch die QA/QS festgestellt werden, woraufhin anderes behoben werden muss, ... Das kann unter Umständen eine echt lange "Problemkette" in Gang setzen. Und nein, es gibt dabei nicht immer einen Weg, um das zu verhindern, vor allem, da Programme / Betriebssysteme mit der Zeit wachsen.
 
Dabei seit
Juni 2005
Beiträge
2.933
#16

Cool Master

Fleet Admiral
Dabei seit
Dez. 2005
Beiträge
23.317
#17
90 Tage sind vollkommen ok. Wenn man das binnen 90 Tage nicht packt muss man eben mehr Ressourcen an das Problem setzen aber das kostet halt mal Geld und das will sich MS wohl sparen...

 
Dabei seit
Mai 2015
Beiträge
221
#18
Witzig, die genannten Schwachstellen wurden nicht geheimgehalten sondern am 24. Januar bei der BlueHat in Tel Aviv demonstriert. Komischerweise gibt es ausgerechnet von James Forshaws Präsentation keine Aufnahme. Die Folien sind aber online!

Für Interessierte: http://www.bluehatil.com/files/New and Improved UMCI, Same Old Bugs.pdf

@Google
Vielleicht mal bei Android vormachen und die Lücken in 90 Tagen schließen und an alle verteilen.
Für jeden Menschen der an Android arbeitet gibt es bei Google 10 weitere, die andere Dinge tun.
James Forshaw gehört definitiv zu letzteren.
 
Dabei seit
Mai 2011
Beiträge
3.955
#19
Was viele hier übersehen: Niemand weiß, wie lange die Lücke schon von Kriminellen ausgenutzt wird. Deshalb MUSS sie schnell geschlossen werden.

Wenn Microsoft sich weniger weniger mit Nutzer-Gängelung und unnötigen Ballast-Features beschäftigen würde, könnten sie auch in 3 Monaten ihr Betriebssystem patchen.

Google macht bei sich selbst übrigens keine Ausnahme: Für Google-Produkte gilt die gleiche Frist, und auch da wird veröffentlicht, wenn immer noch nicht gefixt wurde. Deshalb ist der Druck ja auch hoch genug, den Fix rechtzeitig anzugehen.
 
Top