XP-SP2, déjà les premiers véritables bugs

[Yota Moteuchi]

Article tiré de Réseaux & Télécoms

XP-SP2, déjà les premiers véritables bugs

Marc OLANIE 18/08/2004

L’on mentionne souvent les incompatibilités des rustines avec certaines applications, mais ce qui est le plus à craindre, lors de l’arrivée d’un correctif, ce sont les « bugs induits », les inconsistances apportées –parfois provoquées par- la modification elle-même du code. Nos confrères allemands de Heise viennent de découvrir deux belles failles. L’une, notamment, permet l'exécution d'un programme sur la seule "certification" de son identifiant de zone, lequel peut être « patché » avec un outil fort heureusement quasi introuvable et relativement complexe à utiliser : Notepad. Ce n’est pas la première fois que les ADS (additional data stream… pas les actives directories) d’un fichier sont utilisés dans le cadre d’une injection « cachée » d’informations ou de code.

Un autre problème moins important, et corrigé depuis par Microsoft, porte sur les machines utilisant une adresse de bouclage autre que 127.0.0.1*. De prime abord, tout cela relève de l’opération abracadabrante… mais à bien y réfléchir, l’on se rend compte que beaucoup d’adresses de bouclage autres que la fameuse « 127 » ont été « bidouillées » par des administrateurs prudents. Notamment celles qui semblent émises par NT lui-même au moment du démarrage du système ou lors de l’ouverture d’une session. Précisons que le correctif fourni par l’éditeur n’a pas subit de tests de non régression intensifs, le fait est consigné sur le bulletin d’alerte. A déployer avec prudence si cela est nécessaire.

* http://support.microsoft.com/default.aspx?scid=kb;[LN];884020 <------- copier-coller cette adresse entièrement dans votre navigateur si vous voulez y accéder.

[asmodeus]

quelle bande de boulaÿ chez crosoft ^^

[Yota Moteuchi]

Article tiré de Branchez-vous.com !

SP2 : des vulnérabilités à l'horizon

Alors que la distribution automatique du SP2 anglais pour les consommateurs vient à peine de commencer, des experts en sécurité informatique estiment que la mise à jour majeure de Windows XP n'est pas sans problème.

La semaine dernière, Jürgen Schmidt, un expert allemand de Heise Security, a identifié des faiblesses dans le nouveau système qui prévient l'exécution de fichiers appartenant à des zones non sécurisées. Dans son avertissement, il indique que deux vulnérabilités pourraient éventuellement être exploitées par des créateurs de virus pour contourner les nouvelles mesures de sécurité introduites par le SP2.

Mais ce n'est pas tout; dans un article publié sur News.com, on peut lire qu'un spécialiste en sécurité informatique, Thor Larholm, aurait lui aussi décelé des problèmes dans le SP2 bien qu'il refuse pour l'instant d'en dire davantage. Il aurait transmis les informations à Microsoft, qui dit enquêter sur la question.

Cela dit, les experts en sécurité informatique s'accordent tous sur le fait que les utilisateurs de Windows XP devraient installer le «service pack» 2 dès que possible. Il n'est peut-être pas parfait mais il représente une véritable progression dans l'instauration d'un système qui protège les internautes contre les menaces d'Internet.

Texte rédigé par : Jean-Charles Condo

Publié dans BRANCHEZ-VOUS! le 19 août 2004

[MadMarc]

d'asmodeus :

encore quelques efforts et il s'autoformatera le windows...

j'aime bien, et je le cite, car il a bien raison...

[Yota Moteuchi]

Article tiré de Réseaux & Télécoms

Bugs XP-SP2, précisions de Microsoft France

Marc OLANIE       20/08/2004

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.

* cf 1er article ci-dessus : "XP-SP2, déjà les premiers véritables bugs"

[Moustache]

Un peu maso... je me suis lancé... SP2 installé... un peu longuet l'installation, à priori tout fonctionne correctement... prudent quand même j'ai mis la dernière version de Nero (6120) à jour, au cas où...

Photoshop element 2 qui devrait faire partie des logiciels à problème semble être OK... à voir à l'usage...

250 Mo ici http://www.microsoft.com/downloads/details...45-9e368d3cdb5a

mais inutile de se précipiter... une version plus légère devrait voir le jour bientôt...

A voir ... je vous tiens au courant.

PS : Yota, pourquoi ne pas se contenter du lien d'un article plutôt que de le recopier ? Nous ne sommes pas à un clic de souris près d'autant que tu cites tes sources... Autre détail, certaines pages sont copyrightées donc en principe, il n'est pas possible de les recopier ailleurs, mais bon, ce que j'en dis...

[asmodeus]

Ils me font marrer ceux qui ont écrit cet article : l'ingénierie sociale est tellement plus simple que le "hack" pur et dur que cette faille risque fort d'avoir du succès :o

[matali]

Une question : il sert à quoi le SP2 ? Il est vraiment important ?

(Moi je crois que je vais attendre de voir les avis des utilisateurs avant de me lancer là-dedans :P)

[poitou]

Service Pack 2 installé, aucun bug jusqu'à présent. Les services que j'avais désactivés ne sont pas réactivés, il m'a même demandé.

En plus, je récupère la possiblité de lire des cd, que je venais de perdre avec un bug de dll.

[ferrari]

j'ai mis le sp2 des sa sortie et franchement je n'ai aucun probleme avec

seul nero etait pas compatible mais en passant a la sous version 20 ca a marche nickel

d'une maniere generale sur la liste interminable de microsoft concernant les applis non supporte par XP SP2 il suffit en general d'ouvrir des ports sur le firewall de xp pour rendre l'appli operationnel.

donc ce n'est pas un pbl d'incompatibilite mais de securite lol