Qualitätssicherung – Martins Blog

SHA1 und SHA256 Codesigning mit SIGNTOOL und einem Timestamp

Ihr seid vielleicht auch betroffen und nutzt bisher Code Signing für Eure Software oder MSI Pakete.
Ich zumindest habe von Symantec (ehemals Verisign) für unsere Zertifikate zum Jahresende eine Email bekommen, die mir empfiehlt zukünftig sowohl SHA1 als auch SHA256 zu nutzen. Entsprechende Links wurden mitgeliefert. (1) (2)(3)(4)

Ich habe also erstmal das bisherige Codesigning SHA1 Zertifikat als SHA256 Zertifikat neu ausgeben lassen. Das ganze war kostenlos über die Symantec Seite möglich und dauerte letzten Endes höchstens 30 Minuten.

Dann habe ich das neue Zertifikat im Produktionsserver installiert.
In unserem Produktionsprozess ist das Codesigning integriert. Die entsprechenden Dateien liegen in einem Quellordner und werden von unserem Produktionserver verwendet um daraus unsere Installationspakete oder Hotfixes zu generieren. Dabei werden alle Dateien entsprechend automatisch signiert.

Die entsprechende Code Passage in unserem Batch sah bisher so aus:

>signtool sign -sha1 FingerPint-SHA1-Zertifikat -fd sha1 -t http://timestamp.verisign.com/scripts/timstamp.dll myexe.exe

Da dachte ich: OK Ganz einfach, also nur eine zweite Zeile mit dem Parameter -as hinzufügen und das neue Zertifikat angeben.
Aber Pustekuchen:

>signtool sign -as -sha1 FingerPint-SHA256-Zertifikat -fd 256 -t http://timestamp.verisign.com/scripts/timstamp.dll myexe.exe
Done Adding Additional Store
SignTool Error: SignedCode::Sign returned error: 0x80070057
        Falscher Parameter.
SignTool Error: An error occurred while attempting to sign: AGVIP.exe

🙁 Nach einigem hin und her probieren und Lesen einiger Artikel, musste ich feststellen, dass die Ursache einzig und alleine in dem angegebenen Timestamp Server liegt. Der Verisign Timestamp Server mag einfach keine SHA256 Zertifikate für das Gegenzeichnen.

Die Lösung war also einfach. Ich habe einen anderen Timestamp Server benutzt und nun sehen die Befehlszeilen einfach so aus.

>signtool sign     -sha1 FingerPint-SHA1-Zertifikat   -fd sha1   -tr http://timestamp.geotrust.com -td sha1   myexe.exe
>signtool sign -as -sha1 FingerPint-SHA256-Zertifikat -fd sha256 -tr http://timestamp.geotrust.com -td sha256 myexe.exe

Und siehe da 🙂 alles funktioniert bestens und meine Programme haben nun 2 Zertifikate.

Wenn man nicht genau aufpasst mit Overlapped I/O und CancelIo vergisst

Overlapped I/O ist eine Standardtechnik, die ja jeder kennt, der mit Datenquellen arbeitet, die „irgendwann“ mal Informationen liefert, man aber in der Zeit evtl. noch anderes zu tun hat 😉

In meinem Fall, den ich hier schildere, benutzte unser Programm einen Service, mit dem es über Named Pipes kommuniziert. Das entsprechende Modul, ist schon ziemlich alt und hat seit ca. 3 Jahren keine Änderung erfahren. Aber jetzt auf einmal häuften sich Meldungen, dass unser Programm beim Beenden einen UAE auslöst.

Entsprechende Minidumps wurden angefordert und deren Analyse zeigte eigentlich nicht viel wirklich erhellendes. Es sah alles danach aus, als ob ein Speicherblock freigegeben wird, der bereits freigegeben wurde.
Leider konnte das Szenario in unserem Testfeld nicht einfach nachgestellt werden. Und auch mehrfache Analyse des Sourcecodes brachte erst einmal nichts. Man ist manchmal einfach betriebsblind 🙁

Auffällig war aber, dass diese Meldungen erst vereinzelt auftraten nachdem unsere Software auf VS-2013 Update 3 umgestellt war und diese an Kunden ausgerollt wurde. Und weiterhin konnten wir feststellen, dass alle diejenigen, die diesen Fehler gemeldet haben, relativ leistungsfähige Rechner hatten.

Schließlich gelang es mir, das Szenario auf einem meiner Entwicklungsrechner nachzustellen.

Das passierte:

Das Programm erhielt den Befehl zum Beenden.
Irgendwann wurde auch dem Thread, der mit dem Service interagiert gesagt, dass er sich beim Dienst ausloggen soll.
Der Dienst gibt auch brav den Befehl „Logoff“ an den Service.
Der Thread der in einer Schleife immer auf einen Response des Dienstes wartet beendet sofort.
Und nun erfolgte der Crash.

Die Ursache war ein fehlender CancelIo. Damit das Beenden möglichst schnell vonstatten geht, wurde darauf verzichtet, auf eine Antwort des Services zu warten, ob der Logoff Befehl verstanden wurde, denn kurz danach wird sowieso die Pipe geschlossen. Keine gute Idee in diesem Fall! Das hatte auch den Grund darin, dass

Was ist also passiert ❓

Die OVERLAPPED Struktur für den Lesevorgang lag auf dem Stack innerhalb einer while Schleife, die auf verschiedene Events wartet.
Die Funktion in der diese Struktur deklariert war wurde aber bereits verlassen.
Wenn dann sehr schnell die Antwort des Dienstes kam, wurde in die alte Adresse der OVERLAPPED Struktur ein Wert verändert.
… und damit wurde der Stack an dieser Stelle zerstört.

Es waren in meinem Fall nur 4 Bytes und in manchen Fällen würde eine Rücksprungadresse verändert und es kam zum Crash. In anderen Fällen wurde Speicher verändert, der nicht mehr benutzt wurde. Das ganze passierte eben auch nur auf den Systemen, die sehr schnell auf die Antwort des Dienstes reagierten. Kam die Antwort spät genug, war die Änderung des Speichers nicht mehr gefährlich.

Der Fehler blieb jahrelang unentdeckt, weil scheinbar das Stacklayout, das durch den VS-2010 Compiler erzeugt wurde, gegen diesen Fehler unempfindlich war, weil nur Speicher verändert wurde, der nicht zu einem Fehler führte.

Was lerne ich daraus:
Wenn ich einen ReadFile mit OVERLAPPED verwende, sollte ich immer darauf achten, dass im Bedarfsfall auch dieser Vorgang abgebrochen wird durch ein CancelIo ❗ Ein CancelIo mehr kann nicht schaden, wenn man den Block verlässt, in der eine OVERLAPPED Struktur definiert war.

Das Problem, wenn man Fehler richtig erkennt, richtig dokumentiert aber dann den gleichen Blödsinn wieder macht

… oder auch: Es gibt Tage, da könnte man sich in der Tischplatte verbeißen…

Wir haben vor ein paar Wochen einen sehr mystischen Fehler in unserer Software gefunden.
Das Problem war eine Funktion, die einen (const) Zeiger auf einen Datenblock bekam.
Die Funktion hat aber unter Umständen eine UI-Interaktion (Dialog) ausgelöst und die entsprechende offene Nachrichtenschleife hat es wiederum einen Hintergrundthread erlaubt (unter bestimmten Umständen) Nachrichten an den Mainthread zu senden, der wiederum die Anzeige aktualisierte und auch den Datenblock, der eben noch als Zeiger übergeben wurde, ungültig machte.

Die Funktion sah in etwa so aus:

bool CSomeClass::SomeAction(const S_FOO *pData)
{
...

pData war nun ungültig und wurde verändert, war aber immer noch gültiger Speicher in dem ein paar Ids aus einer Datenbank standen. Das Programm stürzte nicht ab. Tat aber aufgrund der falschen Ids auch nicht das, was es eigentlich sollte.

Der Code wurde dann wie folgt geändert und ein entsprechender Kommentar geschrieben:

bool CSomeClass::SomeAction(const S_FOO &data)
{
// We use a copy of the result object. There is a chance that the
// global result gets replaced while we are inside this routine and 
// the storage where our pointer points gets deleted and replaced 
// by a new result object.
...

Oha. Aber was passierte hier. Anstatt wirklich eine Kopie zu verwenden, wurde wieder nur ein Zeiger verwendet. Nur diesmal in Form einer Referenz.

Es wird nun niemanden wundern., dass mir die selbe Fehlebeschreibung wieder auf den Tisch flatterte. Im Debugger wurden die selben Probleme festgestellt und ich musste dreimal auf die Code-Zeile schauen und den Kommentar dreimal lesen, bevor ich verstand was hier geändert wurde.

Fehler erkannt.
Fehler dokumentiert.
Fehler aber nicht gefixed.

So hätte es aussehen müssen:

bool CSomeClass::SomeAction(const S_FOO data)
{
...

PS: Ich oute mich mal. Der Trottel war ich…

Windows 7, PlaySound und die vermisste Prüfung auf Speicherlecks

Bei der Entwicklung von neuen Funktionen in einem Modul bekam ich irgendwann einen ASSERT. Diesen ASSERT hatte ich in einem Cache eingebaut. Der ASSERT sprang an, wenn bei Programmende der Cache nicht sauber aufgeräumt wurde. Also eigentlich in der Entwicklungsphase nichts ungewöhnliches. Irgendwo wurde also eine Funktion zum Aufräumen nicht aufgerufen.

Aber was mich in diesem Moment extrem stutzig machte, war, dass in der Debugausgabe meines VisualStudios keine Memory Leaks angezeigt wurden ❗ Das machte irritierte mich nun schon sehr. Erster Verdacht. Evtl. hat ja jemand die Leakprüfung für den Cache ausgeschaltet (siehe AfxEnableMemoryTracking). Aber eine kurze Prüfung ergab, dass dem nicht so ist.

Also den Test noch mal ausgeführt. Diesmal wieder der ASSERT und zusätzlich der Dump. „Oha“ dachte ich „Hier ist aber was richtig faul!“

Nachdem ich immer wieder andere Testszenarien verwendet habe, erschienen mal die Leaks und mal erschienen sie nicht. Und nach einiger Zeit kaum ich dahinter, dass immer wenn PlaySound in meiner Debug Version der Anwendung verwendet wurde, kein Leak-Check erfolgte. Wurde PlaySound nicht verwendet war alles gut und die Leaks wurden ausgegeben.

Jetzt ging es ans eingemachte. Schnell isolierte ich folgende DLLs die zusätzlich beim ersten PlaySound geladen wurden.

'xyz.exe': Loaded 'C:\Windows\SysWOW64\MMDevAPI.dll', Symbols loaded (source information stripped).
'xyz.exe': Loaded 'C:\Windows\SysWOW64\propsys.dll', Symbols loaded (source information stripped).
'xyz.exe': Loaded 'C:\Windows\SysWOW64\wdmaud.drv', Symbols loaded (source information stripped).
'xyz.exe': Loaded 'C:\Windows\SysWOW64\ksuser.dll', Symbols loaded (source information stripped).
'xyz.exe': Loaded 'C:\Windows\SysWOW64\avrt.dll', Symbols loaded (source information stripped).
'xyz.exe': Loaded 'C:\Windows\SysWOW64\setupapi.dll', Symbols loaded (source information stripped).
'xyz.exe': Loaded 'C:\Windows\SysWOW64\cfgmgr32.dll', Symbols loaded (source information stripped).
'xyz.exe': Loaded 'C:\Windows\SysWOW64\devobj.dll', Symbols loaded (source information stripped).
'xyz.exe': Loaded 'C:\Windows\SysWOW64\AudioSes.dll', Symbols loaded (source information stripped).
'xyz.exe': Loaded 'C:\Windows\SysWOW64\msacm32.drv', Symbols loaded (source information stripped).
'xyz.exe': Loaded 'C:\Windows\SysWOW64\msacm32.dll', Symbols loaded (source information stripped).
'xyz.exe': Loaded 'C:\Windows\SysWOW64\midimap.dll', Symbols loaded (source information stripped).

Und nach etwas weiter debuggen kam ich dahinter, dass der DllMain Code von setupapi.dll beim DETACH_PROCESS den Prozess sofort terminiert und nicht alle DLLs einen DETACH_PROCESS Aufruf erhalten. Aber der Code für die Leak-Detection der MFC liegt in der MFCx.DLL und wird durch eine statische Variable ausgelöst, die beim Entladen der MFCx.DLL dann zur Ausgabe der Speicherlecks führt. (Siehe PROCESS_LOCAL(_AFX_DEBUG_STATE, afxDebugState) und AfxDiagnosticInit).

Eine genauere Analyse des Stacktraces ergab folgendes Bild:

ntdll.dll!_ZwTerminateProcess@8()  + 0x5 bytes	
ntdll.dll!_RtlpWaitOnCriticalSection@8()  + 0x1d38f bytes	
ntdll.dll!_RtlEnterCriticalSection@4()  + 0x16a38 bytes	
setupapi.dll!_pSetupInitGlobalFlags@4()  + 0x1fc bytes	
setupapi.dll!_pSetupGetGlobalFlags@0()  + 0xe2 bytes	
setupapi.dll!_FlushWVTCache@0()  + 0x2f bytes	
setupapi.dll!_DestroyDeviceInfoSet@8()  + 0x3f bytes	
setupapi.dll!_SetupDiDestroyDeviceInfoList@4()  + 0x44 bytes	
MMDevAPI.dll!CDeviceEnumerator::FinalRelease()  + 0x78 bytes	
MMDevAPI.dll!ATL::CComObjectCached::~CComObjectCached()  + 0x3c bytes	
MMDevAPI.dll!ATL::CComObjectCached::`scalar deleting destructor'()  + 0xd bytes	
MMDevAPI.dll!ATL::CComObjectCached::Release()  + 0xf0c6 bytes	
MMDevAPI.dll!ATL::CComClassFactorySingleton::~CComClassFactorySingleton()  + 0x18 bytes	
MMDevAPI.dll!ATL::CComObjectNoLock<ATL::CComClassFactorySingleton >::`scalar deleting destructor'()  + 0x1a bytes	
MMDevAPI.dll!ATL::CComObjectNoLock<ATL::CComClassFactorySingleton >::Release()  + 0xe0e3 bytes	
MMDevAPI.dll!ATL::CAtlComModule::Term()  + 0x27 bytes	
MMDevAPI.dll!__CRT_INIT@12()  + 0x26e6 bytes	
MMDevAPI.dll!__CRT_INIT@12()  + 0x2588 bytes	
ntdll.dll!_LdrpCallInitRoutine@16()  + 0x14 bytes	
ntdll.dll!_LdrShutdownProcess@0()  + 0x141 bytes	
ntdll.dll!_RtlExitUserProcess@4()  + 0x74 bytes	
kernel32.dll!75eb7a0d() 	
msvcr100d.dll!__crtExitProcess(int status=0)  Line 709	C
msvcr100d.dll!doexit(int code=0, int quick=0, int retcaller=0)  Line 621 + 0x9 bytes	C
msvcr100d.dll!exit(int code=0)  Line 393 + 0xd bytes	C
xyz.exe!__tmainCRTStartup()  Line 568	C

Ursache war, dass MMDevAPI.DLL in seinem DllMain Code ausführt in der setupapi.dll, die aber bereits den DETACH_PROCESS abgearbeitet hat. Das grundsätzliche Problem wird hier in diesem Blog Artikel geschildert: http://blogs.msdn.com/b/oldnewthing/archive/2005/05/23/421024.aspx
Mit eigenen Worten: Die MMDevAPI.dll ruft Funktionen in einer DLL auf, die bereits alle Ihren Speicher und Ressourcen freigegeben hat. Und wie es hier im Code so aussieht, versucht die SetupAPI.DLL wieder Ressourcen zu akquirieren, die eben bereits schon freigegeben wurden, weil eine DLL sie erneut benutzt.

Die Folge ein „Crash“ in DllMain, die der Windows-Lader aber abfängt und sofort mit einer Terminierung des Prozesses ahndet. D.h. nun aber, dass nicht alle DLLs, die noch einen DllMain Aufruf mit DETACH_PROCESS erhalten müssten, auch an die Reihe kommen.

Etwas weitere Recherche ergab, dass dieses Problem auch in den MSDN Foren bereits diskutiert wurde inkl. einer möglichen Lösung.
http://social.msdn.microsoft.com/Forums/vstudio/en-US/8cb1847d-3218-4610-9cb8-6905bd255ff5/no-dllprocessdetach-after-calling-playsound-on-windows-7-64bit

Die Lösung ist erstaunlich einfach: Wenn vor der Benutzung von PlaySound explizit die SetupAPI.DLL geladen wird, dann verläuft der Rest der Deinitialisierung vollkommen normal. SetupAPI.DLL wird nicht entladen, weil die DLL durch den LoadLibrary Aufruf die DLL im Speicher sperrt. MMDevAPI.DLL kann erfolgreich selbst aufräumen und der Code läuft nicht mehr ins Nirvana.

Hier handelt sich offensichtlich um einen Bug in Windows 7 (Windows 8 konnte ich dies bzgl. nicht testen).
Dieser Bug kann natürlich auch empfindlichere Probleme mit sich bringen, wenn Ressourcen betroffen sind, die nicht automatisch mit Prozessende freigegeben werden und wenn diese Ressourcen ausschließlich in der DllMain bei einem DETACH_PROCESS behandelt werden.

Strg+V und Umschalt+Einfg macht doch eigentlich das selbe… oder etwa nicht?

Ja! Das könnte man denken. Strg+V sowie Umschalt+Einfg sind Shortcuts um etwas aus der Zwischenablage einzufügen.
Man könnte weiterhin davon ausgehen, dass Windows in einem Edit-Control beide gleich behandelt. D.h. benutzt der Anwender Strg+V oder Umschalt+Einfg oder das im Edit-Control, dann wird immer der selbe Vorgang ausgelöst.

Schön wäre es ja 🙁 …

Sowohl bei Strg+V, wie auch bei Umschalt+Einfg und über das Kontextmenü wird WM_PASTE an das Edit-Control gesendet. Schön!

Aber hat das Edit-Control den Stil ES_READONLY – ist also als nur lesend definiert -, dann wird bei Eingabe von Strg+V die Nachricht WM_PASTE nicht gesendet. Auch das Kontextmenü blendet den Menüpunkt Einfügen brav aus. Auch das ist gut so und wie erwartet.

Aber was passiert bei Umschalt+Einfg?
Ja. Das unerwartete passiert und in diesem Fall wird doch WM_PASTE gesendet…

Herausgekommen ist das als Bug in unserer Software bei einer speziellen Edit-Control Klasse, die auch bestimmte andere Datenformate aus der Zwischenablage verstehen soll. Ein Kunde stellte letzten Endes fest, dass er über Umschalt+Einfg weiterhin auch in ein Readonly-Control Daten einfügen kann.

Ich war ziemlich überrascht als ich dieses „unlogische“ Verhalten im Testfeld nachvollziehen konnte.
Wer hätte es gedacht? Ich nicht…

Die Tücke mit temporären Objekten und Konvertierungs-Operatoren

Wieder mal ein Beispiel für einen versteckten Bug.
Nachfolgender Code sieht ganz unscheinbar aus, aber er birgt eine Falle mit sich, die in der Implementierung der Klasse verborgen ist:

void CImageButton::OnSysColorChange()
{
   // Farbe hat geändert
   CButton::OnSysColorChange();
   // Bitmap neu laden
   LoadBitmap(m_strResource.IsEmpty() ? m_lpszResource : m_strResource);
}

LoadBitmap ist eine Funktion, die die Bitmap neu lädt und entsprechend der eingestellten Systemfarben einige Farben aktualisiet. Also das bekannte Verhalten von Toolbars. LoadBitmap nimmt einen LPCTSTR und damit kann die CImageButton Klasse entweder mit einem Ressource String arbeiten (der evtl. mit MAKEINTRESOURCE eine ID ist und kein echter Zeiger), oder eben einem Namen zu einer Bitmap Ressource.

Damit bei einem Wechsel der Systemfarben, die Bitmap neu laden werden kann, merkt es sich die Resource. In der Funktion findet hier eine Konvertierung des alten CString Wertes in einen LPCTSTR statt, mit dem eingebauten Konvertierungs-Operator.

Das Problem in der Implentierung dieser Klasse war aber, dass LoadBitmap sich den neuen Ressourcennamen merken soll aber zuvor eine interne Clear Funktion aufruft, die die bestehende Bitmap und andere Klassendaten freigibt, bevor m_strResource oder m_lpszResource, neu gesetzt werden:

void CImageButton::Clear()
{
  ...
  // Clear old infos
  m_lpszResource = NULL;
  m_strResource.Empty();
  ...
}

bool CImageButton::LoadBitmap(LPCTSTR pszResource)
{
   Clear();
...
   if (ISINTRESOURCE(pszResource))
...
   else
   {
       m_strResource = pszResource;
...
   }
...
}

Das führt aber nun zu folgendem Problem: Clear löscht m_strResource und damit wird der übergebene Zeiger an LoadBitmap ungültig, mit der Folge, dass die ürsprüngliche Bitmap nicht mehr gefunden wird, wenn in der Zwischenzeit der Heap auf dem dieser String lag neu verwendet wurde. In der Release Version trat dieser Fehler selten auf. In der Debug Version war der Fehler sofort nachvollziehbar, denn hier wird der Heap bei der Freigabe auf einen einhaltlichen Wert zurückgesetzt.

Die Lösung ist einfach: Es ist nötig den alten Inhalt zu kopieren um einen gültigen Zeiger zu behalten.

void CImageButton::OnSysColorChange()
{
  // System colors changed
  CButton::OnSysColorChange();
  // We need to protect the resource name, because LoadItem calls
  // Clear and this might empty m_sResource. And this causes
  // the string object on the stack to get deleted and the pointer
  // points into nowhere land. So we use a copy of the string here.
  CString strRessource(m_strResource);
  LoadBitmap(strRessource.IsEmpty() ? m_lpszResource : strRessource);
}

Auflösung des GetBuffer und GetAllocLength Rästels

Dann will ich mal das Problem lüften, dass sich mit diesem Code ergibt, dein ich meinem letzten Artikel vorgestellt habe:

template <class T>
void SecureClearString(T &strText)
{
  ::SecureZeroMemory(strText.GetBuffer(0),strText.GetAllocLength());
  strText.Empty();
}

Zuerst einmal liegt es nicht daran, dass es hier Template verwendet wurde.
Ein Template wurde verwendet, weil in dem Code nicht nur CString, sondern implizit CStringA und CStringW verwendet wurde. Der Code sollte also mit beiden Typen funktionieren.

Und damit sind wir bei Problem 1, das auch gelöst wurde:
Wenn ein CStringW verwendet wird, dann wird nur die Hälfte des Strings gelöscht, und nicht alles.

Das Szenario, dass zu einem miesen Crash führen kann, will ich nun in den einzelnen Schritten schildern (es wurde ja vermutet, dass es mit GetBuffer zusammenhängt und die Vermutung ist richtig):

Der CString der mit diesem template behandelt wurde enthielt einen größeren CString und anschließend wurde ein kürzerer CString zugewiesen. Damit ist GetAllocLength>GetLength.
Dieser CString wird nun an eine weitere Variable zugewiesen. Durch die Referenzzählung wird keine volle Kopie erzeugt.
Nun kommt unsere schöne Funktion ins Spiel und einer der beiden Strings wird mit dieser Template Funktion behandelt.
Die Funktion hat zwei Argumente, die von rechts nach links berechnet und auf den Stack geschoben werden.
D.h. Zuerst wird GetAllocLength ausgeführt. Und dies ergibt einen Wert für die Länge, der ursprünglich einmal in diese Variable passte.
Als zweites erfolgt nun der Aufruf von GetBuffer. Da wir aber einen CString haben, der mehrfach benutzt wird, muss nun ein Copy on Write erfolgen. D..h. der String wird kopiert und mit der jetzt benötigten Länge neu alloziert und der Zeiger auf diesen Speicher wird zurückgegeben, dieser ist aber eben kürzer als der ursprüngliche Puffer.
Und nun erfolgt der memset, auf einen Speicher der nur noch so groß ist wie der kurze String. Folgerichtig wird der Heap zerstört, weil der Speicher hinter dem String überschrieben wird.
Peng ❗ Wir haben hier einen ganz miesen Seiteneffekt.

Hier der Code, mit dem man den Crash gezielt nachbauen kann:

void Crash()
{
  CString str1 = _T("12345678901234567890");
  str1 = _T("123");
  CString str2 = str1;
  SecureClearString(str1); // Crash
  SecureClearString(str2);
}

Der Vollständigkeit halber will ich aber auch noch ein Stück Code zegen, der es richtig macht:

template <class T>
void SecureClearString(T &strText)
{
  // We need this only if there is a private buffer
  if (strText.GetAllocLength()!=0)
  {
    // Execute GetBuffer first. This might cause a fork and may change
    // GetAllocLength.
    T::XCHAR *pBuffer = strText.GetBuffer(0);
    size_t iLen =strText.GetAllocLength();
    ::SecureZeroMemory(pBuffer,iLen*sizeof(T::XCHAR));
  }
  strText.Empty();
}

PS: Der Leser kann sich denken, dass mich dieser Bug und die entsprechende Reproduktion einige Nerven gekostet haben. Denn es war nicht einfach die Vorbedingung (erst langer String, dann kurzer String, dann Zuweisung) zu ermitteln. Und wie es oft so ist führen Heap-Fehler erst sehr verzögert zu einem Problem.
Wen es genau interessiert: Ich habe ca 7 Stunden an dem Fall geknobelt und hatte 3 verschiedene Crashdumps zur Verfügung. Selbst konnte ich diesen Fehler in unserem Testfeld zuvor nicht erzeugen, weil eben nie alle Bedingungen erfüllt waren. Erst als mir klar war wo das Problem lag, gelang es mir natürlich auch sofort Eingaben zu erzeugen, die den Crash reproduzierten.

Zur Abwechslung mal ein kleines Quiz: Was ist das Problem mit diesem Template?

Folgender Code wurde in einem Programmteil von uns eingebaut:

template <class T>
void SecureClearString(T &strText)
{
  ::SecureZeroMemory(strText.GetBuffer(0),strText.GetAllocLength());
  strText.Empty();
}

Der Sinn und Zweck sollte sein, dass der Inhalt einer CString Variable durch diesen Code überschrieben und anschließend freigegeben wird, damit zum Beispiel ein Kennwort oder ein Benutzername nicht mehr im Speicher lesbar bleibt.
Die Anwendung sieht in etwa so aus (war allerdings noch in einer Klasse gekapselt):

CString strPassword;
...
// Fill password and use it
...
SecureClearString(strPassword);

Doch leider ist was faul mit dem Code… zwei Probleme gibt es mit diesem Stück Code.
Meine Frage an meine Leser lautet nun was ❓

GetModuleFileName liefert nicht exakt den Namen der EXE/DLL Datei wie er auf der Platte steht

Wir haben ein Stück Code, dass verhindern soll, dass ein Programm zweimal gestartet werden kann.
Dieser basiert auf einem Mutex und einer Memory Mapped File, mit der man sich auch das Fenster-Handle einer bereits gestarteten Instanz besorgen kann.

Nun gelang es einem unserer Händler aber dennoch dieses Programm zweimal in einer Session zu starten und zwar auf folgendem Weg:

Er startet die Software mit dem normalen Link auf dem Desktop, der durch das Installationsprogramm angelegt wurde.
Er öffnen eine Console mit CMD.EXE und wechselt in das Verzeichnis, gibt den Programmnamen ein und das Programm startet erneut. 😮

Die Ursache ist war wie folgt:

Der Mutex den wir intern verwendet haben nutzte den Dateinamen der EXE. Der Name des Mutex wird unter Anderem auch durch GetModuleFileName ermittelt.
Der Dateiname der EXE, wenn sie als Verknüpfung gestartet wird ist „XYZ.exe“ (so wie die Datei auch auf der Festplatte heißt) und das liefert auch GetModuleFileName als Ergebnis.
Der Dateiname, den GetModuleFileName liefert, wenn man das Programm aus CMD.EXE startest ist exakt so wie man es eintippt, also z.B. „xyz.exe“. Erstaunlich.
Da der Mutex einen Namen case sensitiv behandelt (was ich nicht vermutet hätte und erst mit staunenden Augen nachgelesen habe), wurde das bereits gestartete Programm nicht erkannt und eine zweite Instanz gestartet.

Was schreiben wir uns also hinter die Löffel für die Zukunft:
a) GetModuleFileName liefert nicht den „exakten“ Dateinamen (obwohl ich es anders erwartet hätte)!
b) Mutexe sind case sensitiv wie auch Events (obwohl ich hier eine Behandlung wie bei einem Dateinamen erwartet habe)!
c) Manche Erwartungen trügen… 😉

Patchday vom 14.06.2011 behebt die Probleme der VisualStudio 2005/2008 Servicepacks vom 13.04.2011

Die nachfolgenden 4 Sicherheitsupdates wurden am 14.06.2011 von Microsoft herausgegeben:

Sicherheitsupdate für Microsoft Visual C++ 2005 Service Pack 1 Redistributable Package (KB2538242)
Sicherheitsupdate für Microsoft Visual Studio 2005 Service Pack 1 (KB2538218)
Sicherheitsupdate für Microsoft Visual C++ 2008 Service Pack 1 Redistributable Package (KB2538243)
Sicherheitsupdate für Microsoft Visual Studio 2008 Service Pack 1 (KB2538241)

Eigentlich beheben Sie nur das, was am Patchday vom 13.04.2011 hätte behoben werden sollen. Ich habe dazu ja mehrere Artikel geschrieben (1, 2, 3, 4, 5). Nach Vergleich der entsprechenden Sourcen machen Sie Änderungen jetzt das, was sie sollen.

Auch das Problem, dass mit dem letzten Sicherheitsupdate, die Größe der Executables immens angewachsen ist wurde behoben.
Schade, dass dieses Problem in VS-2010 weiter bestehen bleibt.
Insbesondere funktioniert diese neue Runtime für VS-2005 auch auf Windows 2000. Eines der Hauptprobleme vom Patchday im April.

Anzumerken wäre hier eigentlich nur noch die neuen Versionen der Runtime die mit diesem Sicherheitsupdate veröffentlicht werden, d.h. auch, dass man nun die neuen Runtimes auch in sein Setup einbauen sollte, bzw. dass man die neueste passende VCRedist_x86 nun auch mit ausliefern muss. D.h. auch, dass sich die entsprechenden Manifeste wieder ändern, sofern man diese manuell angepasst hat:

Die neuen Runtimedateien von VS-2005 haben die Versionsnummer 8.0.50727.6195
Die neue Runtime für VS-2005 gibt es hier zum Download.
Die neuen Runtimedateien von VS-2008 haben die Versionsnummer 9.0.30729.6161
Die neue Runtime für VS-2008 gibt es hier zum Download.

Weitere und vollständige Infos zu diesem Sicherheitsupdate finden sich im VC-Blog:
http://blogs.msdn.com/b/vcblog/archive/2011/06/17/10175518.aspx

Ich jetzt kann nur allen Entwicklern raten diese neuen Sicherheitsupdates auch zu installieren und zu nutzen!