Review

Windows 95 Sicherheit: Die SMB1-Sandbox-Strategie

  • Updated December 15, 2025
  • Lila Castillo
  • 18 comments

Microsoft hätte die Sicherheit von Windows 95 erheblich verbessern können, indem es mehrere praktische, nutzerorientierte Funktionen implementiert hätte. Ein Ansatz wäre gewesen, DOS- und 16-Bit-Anwendungen in einem erweiterten Kompatibilitätssandbox auszuführen, die sie beim Start abfängt, um Windows-ebene Sicherheitsregeln anzuwenden. Dies hätte verhindert, dass solche Programme Systemschutzmechanismen umgehen, wodurch die meisten DOS-basierten Schadsoftware unwirksam werden würden. In der Nachhinein wäre diese opt-in-Lösung weniger störend gewesen als der Weg, den Microsoft später mit Windows Me ging, der das echte DOS-Modus und die Einschränkungen bei Dateiüberschreibungen vollständig entfernte.

Zusätzliche Schutzmaßnahmen hätten beispielsweise darin bestehen können, neu heruntergeladene oder kopierte Dateien standardmäßig als nicht ausführbar zu kennzeichnen und eine explizite Benutzerfreigabe zu verlangen, bevor sie ausgeführt werden konnten. Selbst genehmigte Dateien würden einen kurzen Ausführungsverzögerung erfahren, um die sofortige Aktivierung von Schadsoftware zu unterbinden. Die Netzwerksicherheit würde durch einen Remote Attack Nullification Mode gestärkt, der eingehende Verbindungen über Protokolle wie FTP, TELNET, SSH, SMB1, NetBIOS, IPX/SPX und NetBEUI blockiert, es sei denn, sie werden manuell deaktiviert. Benutzer könnten auch entscheiden, alle Browser-Downloads zu blockieren, während der Webzugriff erhalten bleibt, und ein prozessbezogenes Vertrauensystem würde verdächtigen Programmen das Zugreifen auf kritische Systembereiche oder das Ausführen risikoreicher Befehle verbieten. Ergänzend dazu würden eine Liste blockierter Programme und Kernel-Betriebswarnungen weitere Kontrolle und Transparenz bieten, um unabsichtliche Softwareausführung und Systemmanipulation zu verhindern.

Choose a language:

18 Comments

  1. Regarding your first point, one of Windows 95’s development goals was to improve compatibility with existing DOS applications over Windows 3.1, which made further restrictions impractical. The same applies to Windows 3.1 applications. If not necessary, you could have used Windows NT instead.

    1. Even though I would have preferred a better sandbox, I understand the priority of compatibility. Still, giving users the choice would have been a better approach.

      1. The stakes were different in 1995. Most users had never used a mouse or computer. Windows 95’s goal was to democratize computers in homes and offices, which required compatibility with as many legacy DOS and Windows 3.1 programs as possible. The restrictions involved in sandboxing would have prevented this from working effectively. For example, DMPI servers and games using VGA Mode-X likely wouldn’t have functioned under such limitations.

        1. By allowing users to toggle the feature on or off, we could address compatibility issues without introducing vulnerabilities.

          You’re overlooking a key point: when Microsoft introduced Win32 security features for 32-bit applications, they granted 16-bit applications full system privileges. This indicates that the developers were aware this would become a problem later.

          My approach resolves the vulnerability without requiring a major kernel rewrite.

          This fits the context because Microsoft later attempted to improve security in Windows 98 and Me, whereas in this scenario, security measures would have been implemented earlier and more effectively.

          I suspect Microsoft didn’t adopt this approach because they recognized the 9x kernel lacked proper memory and process isolation, prompting the shift to NT. In this alternate timeline, they would have enhanced security before transitioning to NT.

  2. This is hindsight that overlooks the practical constraints of the time. Many of these suggestions would have significantly impacted system performance. Windows 95 was typically installed on 486 machines with 4MB of RAM, paired with hard drives that were mostly 4500 RPM or the emerging 5400 RPM models. This combination would have resulted in a sluggish system.

    Additionally, many users avoided running antivirus software due to its performance impact.

    1. My per-process flags don’t degrade performance significantly, and it’s not an antivirus.

      The operating system executes commands, but they’re filtered by if-statements that check for keywords and variables. Commands only execute through else statements when no insecure keywords are found, such as those targeting C:\Windows.

      Microsoft even removed real-DOS mode in Windows Me in our timeline. I don’t think they would have had trouble implementing these ideas before committing to NT.

      1. They didn’t go that far; they mainly removed the VxD thunks.

        There’s minimal process isolation in Windows 9x, which makes any concept of security irrelevant. If security was a concern, NT was already available.

Antwort hinterlassen