Im Rahmen des Security Development Lifecycle (SDL) hat Microsoft bereits Kopierfunktionen wie strcpy(), strncat() und gets() geächtet, die die Größe der zu beschreibenden Speicherbereiche nicht überprüfen und somit in der Vergangenheit sehr häufig zu sicherheitskritischen Pufferüberläufen führten. Jetzt soll memcpy() das gleiche Schicksal ereilen.
Wie ihr Name nahelegt, dient die C-Funktion zum Kopieren von einem Speicherbereich in einen anderen. Microsoft rät aus Sicherheitsgründen bereits seit einiger Zeit von ihrem Einsatz ab. Jetzt heißt es jedoch, dass aus dieser Empfehlung noch in diesem Jahr ein hartes Verbot werden soll. Im selben Topf sollen dann auch CopyMemory() und RtlCopyMemory() landen.
Derartige Vorschriften werden in Redmond automatisiert überwacht. Das bedeutet konkret, dass Microsofts Entwickler keinen Code mehr ins Versionsverwaltungssystem einchecken können, der die inkriminierten Funktionen aufruft – auch wenn dies ausreichend abgesichert wurde. Als Ersatz schlägt Microsoft die Funktion memcpy_s() vor, die als zusätzlichen Parameter die Größe des Zielpuffers entgegennimmt und auch überprüft, ob die Zahl der zu schreibenden Bytes diese übersteigt.
Doch ganz so eindeutig, wie Microsoft es scheinen lassen will, liegt der Fall diesmal nicht. Anders als bereits geächtete Funktionen wie strcpy(), die keinerlei Längenparameter vorsehen, muss der Entwickler bei memcpy() bereits die Zahl der zu schreibenden Bytes angeben: memcpy(dst, src, len); Bei der Ersatzfunktion kommt die Größe des Zielbereichs hinzu, sodass ein Aufruf idealerweise so aussähe:
memcpy_s(dst, sizeof(dst), src, sizeof(src));Das könnte sich jedoch als Wunschdenken erweisen. Wahrscheinlicher sei es, dass Entwickler, die sich nicht um Sicherheit kümmern, die Sperre im Zweifelsfall umgehen, indem sie aus memcpy(a,b,c) einfach memcpy(a,c,b,c) machen, prophezeit der auf Code Reviews spezialisierte Sicherheitsexperte Felix von Leitner. Das brächte dann überhaupt nichts. Und für die Entwickler, die sich um die Sicherheit ihrer Programme ohnehin Gedanken machen, sei memcpy() bereits hinreichend sicher. "Man kriegt Bugs nicht weg, indem man gefährliche APIs verbietet", kritisiert von Leitner Microsofts Ansatz.
Ein weiteres Problem, das Microsoft aber wahrscheinlich wenig kümmert, ist die Tatsache, dass die Ersatzfunktion nicht standardisiert ist. So gibt es memcpy_s() beispielsweise in der unter anderem auf Linux-Systemen eingesetzten C-Bibliothek glibc nicht. Damit legt man Software-Entwicklern, die plattformunabhängig entwickeln oder Windows-Programme auf andere Plattformen portieren wollen, einen weiteren Stein in den Weg.
Quelle :
www.heise.de
