Visual Basic feiert 25. und Microsoft hält Code unter Verschluss

Microsofts Programmiersprache Visual Basic (VB) gehörte lange zu den wichtigsten Fertigkeiten, die ein Entwickler beherrschen musste, wenn er für die Redmonder Windows-Plattform programmieren wollte. Inzwischen gibt es sie 25 Jahre - und in ihrem ... mehr... Windows 3.1, Windows 3.11, Windows 3.11 for Workgroups Bildquelle: Wikipedia Windows 3.1, Windows 3.11, Windows 3.11 for Workgroups Windows 3.1, Windows 3.11, Windows 3.11 for Workgroups Wikipedia

Diese Nachricht vollständig anzeigen.

Jetzt einen Kommentar schreiben
 
Ich denke mal, so einfach wird man das nicht OpenSource machen können, da sicher noch viele Firmenanwendungen im Backend auf VB6 laufen könnten. Bzw generell viele spezialisierte Anwendungen. Eine Offenlegung des Quellcodes würde dann viele neue Angriffsvektoren öffnen. Ebenso kann ich mir gut vorstellen, dass, selbst wenn VB.net eine Neuentwicklung ist, es auch hier potentielle neue Angriffsvektoren durch eine Offenlegung von VB6 geben kann.
 
@LoD14: Was bitte meinst du mit "im Backend auf VB6 laufen". Das ist eine Sprache, die kompiliert wird und dann eine fertige EXE liefert. Dass die alle dann die selbe Lücke enthalten kann ich mir nicht vorstellen. Was sollte das sein? Auch gibt es etliche andere Compiler, die weit verbreitet sind, und open source. Sollten sich da dann auch Angriffsvektoren ergeben, nur weil das alles mit einem bestimmten Compiler übersetzt wird?
 
@FensterPinguin: Die Runtime gehört auch dazu. Schwachstellen die dort neu gefunden werden betreffen jedes einzelne VB6 Programm bzw. jedes System auf dem die Runtime installiert ist, selbst wenn kein VB6-Programm genutzt wird.
 
@FensterPinguin: Du weisst aber schon, dass VB nun mal nicht direkt auf Windows läuft, sondern nur mit der VB-Laufzeit?
 
@Kirill: ...welche seit Jahren Teil von Windows ist und auch über die Windows Updates gepatcht wird.
 
@TiKu: Du meinst wohl welche seit 2004 (SP6) kein einziges Update mehr bekommen hat.
 
@James8349: Das letzte Update gab es in Form eines Sicherheitsupdates für Windows 7 im Januar dieses Jahres.
 
@TiKu: Das war für die VB6 IDE, nicht für die Runtime. Sieht man auch am Eintrag in der KB: "To apply this security update, you must have the release version of Visual Basic 6.0 IDE installed on the computer."

Willst das als reiner Nutzer der Runtime haben, musst dir das Update selbst runterladen, entpacken und die mscomctl.ocx eigenhändig ersetzen. Ich bezweifle das ein normaler Nutzer das jemals macht.
 
@James8349: Okay, dass das nicht auch auf Endanwender-PCs landet, war mir nicht mehr bewusst.
Nichtsdestotrotz wird bspw. die MSVBVM60.dll als Systemkomponente behandelt und trägt bspw. unter Windows 10 eine höhere Versionsnummer als unter Windows XP mit allen Updates.
 
@TiKu: Das stimmt, sie ist der im SP6 der VB6 Runtime um 33 Builds voraus. Allerdings ist sie nicht einen einzigen Byte größer oder kleiner. Ich hab jetzt aber nicht eingehend verglichen, daher muss das nichts heißen...

Ich glaub aber nicht das sich da groß was geändert hat, abgesehen vom neu kompilieren zu kompatibilitätszwecken.
 
@TiKu: Tut nichts zur Sache. Die Runtime ist immer noch da und eine Lücke in der Runtime betrifft immer noch alle VB-Programme.
 
@FensterPinguin: Könnte nicht sogar der Fehler so tief drin sein das er in der Grundstruktur sitzt also ein Day One Fehler der nicht zu Fixen geht ohne weiteres und dadurch eine nennen wir sie mal Super Gau Sicherheitslücke rauskommt.
Das wäre ein Gau denn will doch niemand und wenn Microsoft denn Fehler kennt wäre das mehr wie Fatal .
So ein Fehler würde dann natürlich egal mit welchem Compiler immer wieder mit eingebaut und befände sich in jeder einzelnen Anwendung die auf VB6 basiert.
 
@LoD14: wenn die Lücken drin sind, dann sollte man lieber der Community die Möglichkeit geben sie zu fixen, als dass man hofft dass sie niemals entdeckt werden. Gerade Microsoft sollte das besser wissen, als andere, wenn ich mal auf die CVE Listen von Windows im Vergleich zu freien OS gucke.
 
@dpazra: Eher ist es so, dass MS will, dass VB6 ausstirbt und Entwickler nur noch VB.net nutzen. VB6 OpenSource zu machen würde einer Wiederbelebung gleich kommen, die MS aber auf keinen Fall will.
 
@Scaver: Da gehe ich sofort mit. Ich begründe, dass Sicherheit kein Argument ist. Ich glaube nicht, das MS zu blöd ist das einzusehen. MS ist primär seinen Aktionären verpflichtet, insofern gehe ich bei jeder Entscheidung von einem wirtschaftlichen Hintergrund aus.
 
@Scaver: Und genau das ist auch richtig so. VB6 ist ein Krampf und eine Altlast die man nicht ewig mit schleifen sollte.
 
VB oder Delphi

Die meisten datenbankgestützten Firmenanwendungen (Warenwirtschaft, Controlling, Buchhaltung, CRM, etc. pp.) sind entweder in Delphi oder aber in VB programmiert worden. Erst ab 2005 wurde dann vermehrt zu C# oder VB .NET gegriffen. Und es sind genau die Anwendungen, welche keine Firma ohne wirklich große Not auswechseln möchte, daher haben sie die längste Verweildauer auf Firmenrechnern.

Da stecken wahrscheinlich überall Sicherheitslücken ohne Ende drin, und wenn dann noch die Programmiersprache selbst und damit auch der Compiler offen gelegt wird, dann hätten gerade viele Mittelständler ein ernsthaftes Problem.

G.-J.
 
@Gajus-Julius: Kann der Argumentation nicht ganz folgen. Die alte Software wird also mittelfristig nicht ausgetauscht und ist vermutlich über die Sicherheitslücken einer Laufzeitumgebung angreifbar, die nicht mehr weiterentwickelt wird. Dann haben wir den Salat doch schon, denn wenn VB6 noch Sicherheitslücken hat, dann werden sie auch von Angreifern entdeckt werden.
Diesem Problem könnte man ja begegnen, wenn VB6 noch von der Community weiterentwickelt werden könnte.
Nach dieser Logik würde man erwarten, dass Windows XP sicherer ist, als eine aktuelle GNU/Linux Distribution.
 
@dpazra: Nö, denn ein Update würde bei den Unternehmen nicht erfolgen. Software ist wie sie ist in Unternehmen. Die Chance das Sicherheitslücken nicht erkannt werden, oder nur wenige davon Wissen, ist ohne OpenSource wesentlich größer.

VB6 hat Sicherheitslücken die auch bekannt sind, aber es könnte auch sein, dass es noch mehr gibt.
Ein Weiterentwicklung der VB6 hätte aber wie gesagt Null Auswirkung auf diese Unternehmen. Diese Patchen in über 90% der Fälle nur, wenn etwas nicht funktioniert oder wenn eine neue Funktion dazu kommen bzw. geändert werden soll.
Updates nur wegen Sicherheitslücken werden im Unternehmensbereich nicht mal von 10% vorgenommen.
 
@Scaver: Das ist imho eine sehr sonderbare Argumentation, ganz abgesehen davon, dass ich bisher nur in/für Organisationen gearbeitet habe, denen Sicherheit nicht egal war und die folglich auch Updates gemacht haben, wenn sie eben anstanden.

VB6 hat also laut dir bekannte Sicherheitslücken (glaube ich dir gerne, habe ich aber nicht nachgeprüft, ich nutze kein VB), für die in mind. 90% der Unternehmen, die es benutzen (nach deinen Zahlen, unter der Annahme, dass die Nutzung von VB6 mit der Updatewilligkeit un- oder negativ korrelliert ist), keine Patches eingespielt werden. Dann haben diese 90% der VB6-Nutzer sicherheitstechnisch die höchste Alarmstufe erreicht.

Ob meine Mitarbeiter auf eine Datei klicken, die 4 oder 40 Exploits ausnutzt, ist jetzt kein qualitativer Unterschied. Das sieht man auch daran, wie ein Zero-Day gehandhabt wird. Der erscheint direkt auf den Sicherheitstickern und die Empfehlung ist selbstverständlich, die betroffene Funktion nicht zu nutzen, bis der Patch da ist (das geht üblicherweise auch recht schnell).

Eine (sicherheitsrelevante) Software, die keine Updates bekommt, sollte überhaupt nicht mehr benutzt werden. Die Idee, dass es weniger schlimm wird, weil man ja evt. nicht so schnell weitere Lücken zu den vorhanden erkennt, erscheint mir völlig absurd. Nicht zuletzt ist ein Angreifer auch nicht auf den Source Code angewiesen um Lücken zu finden. Nicht zuletzt dank der Forschung aus dem Hause Google gibt es gute Werkzeuge um Hinweise auf Sicherheitslücken automatisch zu generieren.
 
Security by Obscurity? glaube nicht das MS dies mit der Geschlossenhaltung erreichen will. Hier wird eher die Angst nach einem Fork ersichtlich. Konkurenz zu VB .net will MS nicht.
 
@ThreeM: Richtig und was ist falsch da dran? Beides gehört MS und wenn sie wollten, könnten und dürften sie VB auf Windows unbrauchbar machen. Was irgendwann im Lebenszyklus von Windows 10 mit großer Sicherheit eh kommen wird.
Die Möglichkeit der Programmiersprachen wird MS hier noch drastisch einschränken und viele Funktionen nur über die eigenen Mittel verfügbar machen (siehe den Store).
 
@ThreeM: VB6 ist und wird nie eine Konkurenz zu VB .Net sein.
Da ist C# eine größere Konkurenz...
 
Wer das fordert, dem würde ich zwei Dinge sagen:
1. Dein Wunsch nach freier Software für die von dir präferierte Sprache ist sofort nachvollziehbar. Eine Freilegung würde, ohne den wahnwitzigen Aufwand des Reverse Engineerings, erlauben:
- die Sprache auf beliebige Plattformen zu bringen
- unabhängige Security Audits zu organisieren und Compiler und IDE von Sicherheitslücken zu befreien
- die Sprache weiterzuentwickeln.

2. Warum hast du nicht direkt auf eine freie Sprache gesetzt? Der Wunsch nach freier Software ist immer nachvollziehbar, warum fängst du dann überhaupt an diese Sprache zu nutzen, die dich in die Abhängigkeit von proprietärer Software bringt.

Ich selbst habe in Ermangelung besseren Wissens mit QBasic angefangen. Zum Glück kam ich rasch zu C++.
 
@dpazra: VB6 brauchst du nicht auf andere Plattformen bringen oder einem Audit unterziehen. Die Sprache ist alt und hat keine Existenzberechtigung mehr.
 
@Kubwa: das sind Dinge, die man tun sollte, wollte man sie weiterverwenden. Die Fans, die eine Freilegung fördern, wollen die Sprache offenbar weiterverwenden. Ich selbst habe kein Interesse an VB6, der Absatz ist aber allgemein auf Gründe bezogen, die es gibt um Sprachen offen zu legen, damit sie eine Zukunft haben.
 
Es könnte hier evtl. um Komponenten von Drittanbietern gehen die von Microsoft für VB lizensiert wurden und unter eigener Lizenz stehen.
 
Danke WinFuture für die geniale Präsentation von Bill Gates :D
 
Man nenne mir einen Grund wieso man heutzutage noch auf VB6 zurückgreifen sollte.

Ich kenne VB6 sowie VB .Net und arbeite (notgedrungen) noch mit VB6, aber eher VB .Net.... und VB6 ist nicht nur technisch eine Katastrophe, selbst simpelste Dinge wie TCP Sockets sind kaum richtig nutzbar. Ich fange jetzt lieber nicht mit Threading und Objektorientierung an....

Lasst VB6 in frieden sterben!
 
@Kubwa: Ich benutze VB6 noch in einer Virtuellen Maschine, für kleinere Tools. Manchmal ist dieses streng durchgezogene OOP einfach nur eine Last und überladen. Generell ist VB.Net nicht wirklich ein Visual Basic, es ist C# mit etwas anderer Syntax und dem Unterschied das VB.Net immer noch die Groß-/Kleinschreibung ignoriert.

Im Prinzip macht es keinen Sinn einen Unterschied zwischen VB.Net und C# zu machen. Und eben weil VB6 so anders war als .NET kann ich sogar verstehen wenn die Community es selbst weiterentwickeln und/oder patchen will.
Kommentar abgeben Netiquette beachten!

Video-Empfehlungen

WinFuture Mobil

WinFuture.mbo QR-Code Auch Unterwegs bestens informiert!
Nachrichten und Kommentare auf
dem Smartphone lesen.

Folgt uns auf Twitter

WinFuture bei Twitter

Interessante Artikel & Testberichte