Sie sind hier:
Wissen
Telefon (Mo-Fr 9 bis 16 Uhr):
0201/649590-0
|
Kontaktformular
MENU
Medien
Übersicht
Lexikon/Glossar
Spickzettel
Weblog
Konferenzvorträge
Fachbücher
Fachartikel
Leserportal
Autoren gesucht!
Literaturtipps
Praxisnahe Fallbeispiele
Downloads
Newsletter
.NET
Startseite
.NET 8.0
.NET 7.0
.NET 6.0
.NET 5.0
.NET Core
.NET 4.0/4.5.x/4.6.x
.NET 3.0/3.5
.NET 2.0
.NET-Lexikon
Programmiersprachen
Entwicklerwerkzeuge
Klassenreferenz
Softwarekomponenten
Windows Runtime
World Wide Wings-Demo
Versionsgeschichte
Codebeispiele
ASP.NET
Artikel
Bücher
Schulung & Beratung
Konferenzen/Events
ASP.NET
Startseite
Lexikon
Sicherheit
Konfiguration
Global.asax
Tracing
Technische Beiträge
Klassenreferenz
Programmiersprachen
Entwicklerwerkzeuge
Softwarekomponenten
Forum
Schulung & Beratung
PowerShell
Startseite
Commandlet-Referenz
Codebeispiele
Commandlet Extensions
Versionsgeschichte
Schulungen+Beratung
Windows
Startseite
Windows Runtime (WinRT)
Windows PowerShell
Windows Scripting
Windows-Schulungen
Windows-Lexikon
Windows-Forum
Scripting
Startseite
Lexikon
FAQ
Bücher
Architektur
Skriptsprachen
Scripting-Hosts
Scripting-Komponenten
COM/DCOM/COM+
ADSI
WMI
WMI-Klassenreferenz
Scripting-Tools
WSH-Editoren
Codebeispiele
.NET-Scripting
Forum
Schulung & Beratung
Nutzer
Anmeldung/Login
Buchleser-Registrierung
Gast-Registrierung
Hilfe
Website-FAQ
Technischer Support
Site Map
Tag Cloud
Suche
Kontakt
Erklärung des Begriffs: Execution Protection (NX)
Begriff
Execution Protection
Abkürzung
NX
Eintrag zuletzt aktualisiert am
07.03.2004
Zur Stichwortliste unseres Lexikons
Was ist
Execution Protection
?
Microsoft führt mit XP SP2 die sogenannte Execution Protection (NX) ein, die verhindert, dass Daten als Code ausgeführt werden (was üblicherweise bei Buffer-Overflow-Attacken ausgenutzt wird).
Auf 64-Bit-Prozessoren wird das hardwareseitig (NX-Flag), auf 32-Bit-Prozessoren nur softwareseitig unterstützt.
Probleme kriegen alle Anwendungen, die bewußt oder unbewußt (!) Speicher als Datenbereich allokieren und darin Code ausführen. Betroffen sein könnten Treiber sowie alle Anwendungen, die mit Laufzeitcodegenerierung arbeiten.
.NET
-Anwendungen (
Managed Code
) sind *nicht* betroffen, auch wenn Sie mit Laufzeitcodegenerierung arbeiten.
Betroffen sind auch alle Anwendungen, die nicht sauber programmiert sind und die einen Buffer-Overflow produzieren und nur durch glückliche Umstände in der Regel dabei nicht abstürzen, weil zufällig was sinnvolles im Datenbereich steht. Diese Anwendungen werden nun immer mit einer ACCESS_VIOLATION beendet werden.
Wenn Entwickler mit Laufzeitcodegenerierung arbeiten, muss der Entwickler sicherstellen, dass Sie Speicher mit einem PAGE_
EXE
CUTE-Flag anfordern. Solche Anwendungen sollten unbedingt intensiv getestet werden unter SP2. Auch alle Treiberhersteller sollten unbedingt testen.
Wie gross der Aufwand im einzelnen Fall ist, hängt natürlich vom Umfang der Anwendung, der Qualität der Programmierung und der vorhandenen Quelleocodedokumentation ab. Im Allgemeinen halte ich den Aufwand aber bei gut entwickelter Software für sehr überschaubar.
Querverweise zu anderen Begriffen im Lexikon
Managed Code
.NET (DOTNET)
Executable (EXE)
Beratung & Support
Anfrage für Beratung/Consulting zu Execution Protection NX
Gesamter Beratungsthemenkatalog
Technischer Support zum Execution Protection NX
Schulungen zu diesem Thema
ASP.NET Core WebAPI 8.0/9.0: REST Services/HTTP Services/Microservices
Dokumentengenerierung mit dem Microsoft Office Open XML SDK
Angular - Aufbauwissen (Angular Advanced)
Umstieg von .NET-Desktop-Entwicklung (WPF/Windows Forms) auf Webentwicklung (ASP.NET/ASP.NET Core + JavaScript/TypeScript mit Webframeworks wie Angular, Vue.js oder React)
Docker-Basiswissen
Machine Learning (ML) / Künstliche Intelligenz (KI) / Artificial Intelligence (AI) mit ML.NET
Anfrage für eine individuelle Schulung zum Thema Execution Protection NX
Gesamter Schulungsthemenkatalog
Bücher zu diesem Thema
Alle unsere aktuellen Fachbücher
E-Book-Abo für ab 99 Euro im Jahr