Des détours ou des techniques similaires peuvent entraîner des comportements inattendus avec SQL Server

Cet article décrit la stratégie de support Microsoft lorsque vous utilisez des détours tiers avec des SQL Server et des problèmes qui peuvent se produire lorsque vous les utilisez.

Version du produit d’origine : SQL Server
Numéro de la base de connaissances d’origine : 920925

Résumé

Le support Microsoft a rencontré de nombreux produits tiers qui utilisent des détours pour fournir des fonctionnalités supplémentaires à SQL Server. Il s’agit généralement de fonctionnalités d’audit. Il n’existe aucun processus de certification pour les détours tiers pour les applications Microsoft. Par conséquent, en règle générale, Microsoft déconseille fortement l’utilisation de détours.

Les fonctionnalités qui utilisent des détours ou des techniques similaires pour modifier le comportement de SQL Server peuvent entraîner les problèmes suivants :

• Problèmes de performances.
• Résultats incorrects.
• Altération du disque et de la mémoire.
• Perte de réponse SQL Server.
• Arrêt inattendu du processus.
• Impossibilité d’utiliser des diagnostics standard, telles que la fonction fn_get_sql et la DBCC INPUTBUFFER commande .
• Utilisation de 100 % du processeur et temps de récupération de base de données longs lorsque vous utilisez des tables OLTP en mémoire dans SQL Server.

Vous pouvez rencontrer ces mêmes problèmes lorsque vous utilisez des logiciels non-Microsoft tels que des serveurs liés, des procédures étendues ou des objets COM dans le processus de SQL Server. Les détours sont masqués de la vue DBA. Pour découvrir un détour, vous devez utiliser les techniques décrites dans la section Plus d’informations qui suit. Les serveurs liés, les objets COM et les procédures étendues ont une inscription explicite et des interfaces définies.

Il est courant, dans le cadre de la résolution des problèmes, que les services de support Microsoft vous demandent de désactiver les travaux non essentiels et de désactiver ou de supprimer des composants tiers et d’autres techniques similaires. Microsoft tente toujours de réduire l’empreinte du problème lors de l’identification du problème. Une fois que le problème est identifié comme non lié aux travaux ou aux produits tiers, ces travaux ou produits tiers peuvent être remis en production.

Nous n’avons pas l’intention de découvrir un détour et de considérer que la instance de SQL Server n’est pas prise en charge. Microsoft reconnaît que certaines implémentations sont nécessaires. Toutefois, Microsoft vous oblige à valider la prise en charge des détours. Un détour par une entreprise digne de confiance est certainement différent d’un détour inattendu qui est utilisé par un virus. Microsoft ne garantit ni ne certifie ces produits tiers, ni la façon dont les produits tiers interagissent avec les produits et services Microsoft. Au lieu de cela, les fournisseurs tiers sont responsables de l’identification et de la fiabilité de leurs produits et services. Si vous avez des questions sur les produits et services tiers, veuillez contacter le tiers applicable. Microsoft n’est pas responsable des problèmes causés par votre utilisation de produits ou services tiers dans le cadre de SQL Server.

Plus d’informations

Les détours offrent des capacités améliorées et un compromis risque/récompense. En règle générale, lorsqu’un détour est implémenté dans SQL Server, du code tiers est injecté dans l’espace de processus. Cette activité peut modifier le comportement de SQL Server.

Voici quelques exemples de situations et d’effets secondaires possibles :

• Les paquets TDS (Trafic réseau entrant) sont analysés et modifiés. Le détour est ajouté à un emplacement critique au niveau du thread de processus réseau net_readdata. Même 100 cycles de processeur à cet emplacement peuvent réduire considérablement le débit de traitement par lots.

  Une modification des données TDS réelles peut entraîner des griffons de mémoire. Ce problème a déclenché divers problèmes de stabilité SQL Server et d’altération des données. Les problèmes peuvent entraîner la modification partielle d’un paquet TDS et la relecture de la mémoire à SQL Server. Les fonctionnalités de journalisation à ce niveau peuvent exposer des mots de passe et d’autres données sensibles que SQL Server suivi est conçu pour supprimer et sécuriser.

• SQL Server routines d’analyse sont détournées pour changer de comportement. Les effets secondaires possibles sont les suivants :

  • Les plans d’exécution ne correspondent pas au texte de requête réel.
  • Une commande n’est envoyée qu’une seule fois par le client. Toutefois, la commande est exécutée plusieurs fois.
  • La sortie de trace affiche la commande d’origine au lieu de la requête modifiée.
  • La DBCC INPUTBUFFER commande affiche la commande d’origine au lieu de la requête modifiée.
  • La fn_get_sql fonction affiche des données incorrectes. En outre, la fn_get_sql fonction est susceptible d’être exposée à des exceptions et à des résultats incorrects. La fn_get_sql fonction est utilisée par de nombreuses solutions de supervision et peut entraîner des problèmes sur les solutions de surveillance.
  • La planification globale du mode utilisateur (UMS) et la planification du système d’exploitation SQL Server (SQLOS) peuvent être interrompues. Cela entraîne une perte de SQL Server réponse, des changements de performances et des pannes.

• Les API Win32 qui fournissent des fonctionnalités de sécurité renforcée sont détournées. En fonction de l’implémentation, les fonctionnalités de journalisation à ce niveau peuvent exposer des mots de passe et d’autres données sensibles. La planification globale UMS et SQLOS est interrompue. Cela entraîne une perte de SQL Server réponse et des pannes.

• La modification des tables de fonctions et la redirection des fonctions SQL Server principales ou des API Windows ne sont pas prises en charge dans le processus de SQL Server. Cela peut entraîner une instabilité et un comportement inattendu dans la fonctionnalité SQL Server.

L’exemple suivant montre que la kernel32!GetQueuedCompletionStatus fonction a été détournée.

MyDLL!MyGetQueuedCompletionStatus
ssnetlib!ConnectionReadAsyncWait

Dans l’assembly de la GetQueuedCompletionStatus fonction, la première instruction a été remplacée par une instruction de saut.

0:038> u kernel32!GetQueuedCompletionStatus
kernel32!GetQueuedCompletionStatus
77e660f1 e90a9f00aa jmp 21e70000 ß This points to an address that does not appear in the loaded module list (lm). It is injected code.
77e660f6 83ec10 sub esp,10h

L’assembly du code injecté affiche l’activité détournée et un appel au fichier MyDLL .

0:038> u 21e70000
21e70000 55 push ebp
21e70001 8bec mov ebp,esp
21e70003 51 push ecx
21e70004 8b4518 mov eax,dword ptr [ebp+18h]
21e70007 50 push eax
21e70008 8b4d14 mov ecx,dword ptr [ebp+14h]
21e7000b 51 push ecx
21e7000c 8b5510 mov edx,dword ptr [ebp+10h]
21e7000f 52 push edx
21e70010 8b450c mov eax,dword ptr [ebp+0Ch]
21e70013 50 push eax
21e70014 8b4d08 mov ecx,dword ptr [ebp+8]
21e70017 51 push ecx
21e70018 e8234d19ee call MyDLL+0x4d40 (10004d40) <- Call to the MyDLL file.
21e7001d 8945fc mov dword ptr [ebp-4],eax
21e70020 8b55fc mov edx,dword ptr [ebp-4]

Vous pouvez utiliser les outils de débogage pour Windows pour déterminer si des détours sont utilisés. Pour cela, procédez comme suit.

1. Joignez les outils de débogage pour Windows pour SQL Server ou chargez un fichier de vidage utilisateur complet.

2. Exécutez la commande de débogueur suivante. Cette commande inspecte chaque image par rapport à l’image sur disque pour déterminer si des détours ont été injectés.

   !for_each_module "!chkimg -v @#Base -d"
   

3. Détachez le débogueur.

Si l’image en mémoire a été modifiée, la sortie peut ressembler à ce qui suit :

Comparison image path: c:\program files\microsoft sql server\mssql\binn\ssnetlib.dll\ssnetlib.dll
Scanning section: .text
Size: 56488  
Range to scan: 0c261000-0c26eca8  
0c263710-0c26371a 11 bytes - ssnetlib!ConnectionClose  
[ 8b ff 55 8b ec 83 ec 10:68 00 00 00 00 e9 27 8a ]  
0c2641e0-0c2641ea 11 bytes - ssnetlib!ConnectionReadAsync (+0xad0)  
[ 8b ff 55 8b ec 83 ec 38:68 00 00 00 00 e9 00 7e ]  
0c265160-0c26516a 11 bytes - ssnetlib!ConnectionWriteAsync (+0xf80)  
[ 8b ff 55 8b ec 83 ec 28:68 00 00 00 00 e9 ba 70 ]  
Total bytes compared: 56488(100%)  
Number of errors: 33  
33 errors : 0c260000 (0c263710-0c26516a)

Vous pouvez examiner l’assembly pour examiner plus en détail le problème comme suit :

0:038> u ssnetlib!ConnectionClose
ssnetlib!ConnectionClose]:
0c263710 6800000000 push 0
0c263715 e9278ada03 jmp MyDLL!MyGetQueuedCompletionStatus <- A detour has been installed.

Les programmes antivirus qui effectuent le suivi des attaques par injection de code SQL peuvent détourner SQL Server code. Dans ce scénario, la sortie de l’extension !for_each_module "!chkimg -v @#Base -d" peut indiquer que les SQL Server et yyparseex_raise2 sont modifiés :

Comparison image path: <symbol file path>\sqlservr.exeRange to scan: c81000-3de7d48 ed71a8-ed71ad 6 bytes - sqlservr!yyparse [ ff f5 41 54 41 55:e9 c7 95 5c 76 90 ]1202820-1202824 5 bytes - sqlservr!ex_raise2 (+0x32b678) [ ff f3 57 41 54:e9 20 e0 29 76 ] Total bytes compared: 51801416(17%)Number of errors: 11

Nous vous recommandons de contacter le fournisseur des détours ou des techniques similaires pour obtenir des informations détaillées sur l’utilisation des détours dans SQL Server. Pour plus d’informations sur les détours et les techniques similaires, consultez Détours.