Peut-on convaincre un utilisateur distant de « taper une ligne de commande à l'insu de son plein gré » ? Car, explique Bernard Ourghanlian, l'homme sécurité de Microsoft France, c'est là plus ou moins ce qu'implique l'exploitation du « défaut » dénoncé par Heise et rapporté dans les colonnes de CSO Online. Propos on ne peut plus justes, mais qui, à notre humble avis, ne constituent pas un « facteur amoindrissant » quant aux résultats de l'exploitation de ladite caractéristique. Le social engineering est hélas une arme peut-être inélégante et fruste, mais redoutablement efficace lorsque maniée par des « artistes ».
Ce détail mis à part, « l'exploit Heise », comme beaucoup d'autres preuves de faisabilité, n'est pas aisément utilisable et ne doit effectivement pas être pris pour « virus comptant ».
Ce qui suit est la transcription intégrale du texte de Monsieur Bernard Oughanlian



A propos de votre article sur « XP-SP2, déjà les premiers véritables bugs », je voudrais apporter les éléments d'appréciation suivants :
L'article publié par Jürgen Schmidt de Heise Security ne fait, à mon sens, qu'illustrer, non pas un bogue, mais une limitation de Windows XP SP2. En effet, ce dont se réclame cet article est le fait que la nouvelle fonctionnalité de sécurité qui permet de contrôler l'exécution d'attachement en provenance des sources indignes de confiance ne fonctionnerait pas.
Or, si l'on regarde d'un peu plus près la description de cette fonctionnalité ( AES - Attachment Execution Service), « Application developers will be able to call the new Attachment Execution Service (AES) dialog box from their Windows applications by using the API that is described in AES API Integration ». Ce qu'indique l'article de Heise Security est la simple conséquence que, contrairement à Outlook, Outlook Express ou Windows Messager, CMD.EXE n'utilise pas cette API et qu'il est donc possible de contourner l'utilisation d'AES (comme d'ailleurs dans la plupart des autres clients de messagerie actuellement sur le marché et certainement bien d'autres applications).
Si l'on regarde la documentation, on se rend compte que, pour bénéficier d'AES, il faut appeler l'interface COM IAttachmentExecute (cf. exemple) :

// CClientAttachmentInfo, defined by the client, implements all the
// necessary client functionality concerning attachments.
Class CclientAttachmentInfo;
// Creates an instance of IattachmentExecute
HRESULT CreateAttachmentServices(IattachmentExecute **ppae)
{
// Assume that CoInitialize has already been called for this thread.
HRESULT hr = CoCreateInstance(CLSID_AttachmentServices,
NULL,
CLSCTX_INPROC_SERVER,
IID_IattachmentExecute,
(void**)&pAttachExec);
if (SUCCEEDED(hr))
{
// Set the client's GUID.
// UUID_ClientID should be created using uuidgen.exe and
// defined internally.
(*ppae)->SetClientGuid(UUID_ClientID);

// You also could call SetClientTitle at this point, but it is
// not required.
}
return hr;
}
BOOL IsAttachmentBlocked(CclientAttachmentInfo *pinfo)
{
// Assume that a client function has copied the file from the mail store
// into a temporary file.
PWSTR pszFileName;
// GetFileName is a method in this class for which we do not provide
// an implementation here.
HRESULT hr = pinfo->GetFileName(&pszFileName);
if (SUCCEEDED(hr))
{
IattachmentExecute *pExecute;
hr = CreateAttachmentServices(&pExecute);
if (SUCCEEDED(hr))
{
hr = pExecute->SetFileName(pszFileName);
// Do not call SetLocalPath since we do not have the local path yet.
// Do not call SetSource since e-mail sources are not verifiable.
// Do not call SetReferrer since we do not have a better zone
// than the default (Restricted sites).
// Check for a policy regarding the file.
If (SUCCEEDED(hr))
{
hr = pExecute->CheckPolicy();
}
pExecute->Release();
}
LocalFree(pszFileName);
}
return FAILED(hr);
}

HRESULT OnDoubleClickAttachment(HWND hwnd, CclientAttachmentInfo *pinfo)
{
// Assume that a client function has copied the file from the mail store
// into a temporary file.
PWSTR pszTempFile;
// CopyToTempFile is a method in this class for which we do not provide
// an implementation here.
HRESULT hr = pinfo->CopyToTempFile(&pszTempFile);
if (SUCCEEDED(hr))
{
IattachmentExecute *pExecute;
hr = CreateAttachmentServices(&pExecute);
if (SUCCEEDED(hr))
{
hr = pExecute->SetLocalPath(pszTempFile);
// Do not call SetFileName since we already have the local path.
// Do not call SetSource since e-mail sources are not verifiable.
// Do not call SetReferrer since we do not have a better zone
// than the default (Restricted sites).
If (SUCCEEDED(hr))
{
hr = pExecute->Execute(hwnd, NULL, NULL);
}
pExecute->Release();
}
LocalFree(pszTempFile);
}
return hr;
}
HRESULT OnSaveAttachment(HWND hwnd, CclientAttachmentInfo *pinfo)
{
// Assume that a client function has copied the file from the mail store
// into a location selected by the user.
PWSTR pszUserFile;
// CopyToUserFile is a method in this class for which we do not provide
// an implementation here.
HRESULT hr = pinfo->CopyToUserFile(hwnd, &pszUserFile);
if (SUCCEEDED(hr))
{
IattachmentExecute *pExecute;
hr = CreateAttachmentServices(&pExecute);
if (SUCCEEDED(hr))
{
hr = pExecute->SetLocalPath(pszTempFile);
// Do not call SetFileName since we have the local path.
// Do not call SetSource since e-mail sources are not verifiable.
// Do not call SetReferrer since we do not have a better zone
// than the default (Restricted sites).
If (SUCCEEDED(hr))
{
hr = pExecute->Save();
}
pExecute->Release();
}
LocalFree(pszUserFile);
}
return hr;
}

Il est donc clair que si l'on n'appelle pas cette méthode, on ne bénéficiera pas de ses apports
Par ailleurs, la méthode évoquée par Jürgen Schmidt de Heise Security repose sur une attaque de type « ingénierie sociale » qui consisterait à demander, en fait, à l'utilisateur de sauvegarder le fichier et à l'exécuter depuis le prompt de commande. Je sais bien que la crédulité humaine n'a pas de limite, mais je pense que la probabilité de réussir à demander à l'utilisateur de créer une fenêtre de commande et à y faire glisser le fichier attaché pour l'y exécuter est quand même un scénario un peu scabreux...
- A mon sens donc,
- on peut parler de limitation mais pas de bogue,
- la probabilité d'exploitation de cette limitation est extrêmement faible.

. Ontrack : Programme Privilège
Le programme client Privilèges permet à toute entreprise de retrouver rapidement l'accès à ses données perdues suite à une panne ou un sinistre.
Chez Ontrack, nos 20 ans d'expérience nous ont prouvé qu'aucun système informatique n'est à l'abri, quelles que soient les précautions prises.
La seule vraie protection : s'enregistrer au programme Privilège, juste au cas où...

. Web-profils.com, la place de marché du conseil et de l'ingénierie