DirectX - DirectPlay vulnerability

The issue(s) involves quartz.dll [again] and Apple's QuickTime or
other applications or helpers which use DirectPlay/DirectShow for
presentation, such as games.
DirectX versions affected are 7.0 through 9.0 [a,b,c,]. Microsoft has
advised of work-arounds and provides fixes for supported operating
systems [9X is not supported though at least one of the work-arounds
suggested below may work in that environment].

Microsoft Security Advisory (971778)
Vulnerability in Microsoft DirectShow Could Allow Remote Code Execution
Published: May 28, 2009
http://www.microsoft.com/technet/security/advisory/971778.mspx
"What is DirectShow?
DirectX consists of a set of low-level Application Programming
Interfaces (APIs) used by Windows programs for multimedia support.
Within DirectX, the DirectShow technology performs client-side audio and
video sourcing, manipulation and rendering.

Microsoft DirectShow is used for streaming media on Microsoft Windows
operating systems. DirectShow is used for high-quality capture and
playback of multimedia streams. It automatically detects and uses video
and audio acceleration hardware when available, but also supports
systems without acceleration hardware. DirectShow is also integrated
with other DirectX technologies. Some examples of applications that you
can create using DirectShow include DVD players, video editing
applications, AVI to ASF converters, MP3 players, and digital video
capture applications."

http://blogs.zdnet.com/security/?p=3465

--
~
--
MEB
http://peoplescounsel.org/ref/windows-main.htm
Windows Diagnostics, Security, Networking
http://peoplescounsel.org
The *REAL WORLD* of Law, Justice, and Government
_______

 

Re: DirectX - DirectPlay vulnerability (win-9x/me probably notvulnerable)

MEB wrote:

> The issue(s) involves quartz.dll [again] and Apple's QuickTime or
> other applications or helpers which use DirectPlay/DirectShow for
> presentation, such as games.

DirectShow in Microsoft DirectX 8.1 and 9.0 allows remote attackers to
execute arbitrary code via an MJPEG file or video stream with a
malformed Huffman table, which triggers an exception that frees heap
memory that is later accessed, aka "MJPEG Decompression Vulnerability."

> DirectX versions affected are 7.0 through 9.0 [a,b,c,].

I am only seeing DirectX 8.1 through 9.x being listed. And only when
used in conjunction with certain NT-based OS's - no mention of 9x/me.

> [9X is not supported though at least one of the work-arounds
> suggested below may work in that environment].

Delete this registry key:

HKEY_CLASSES_ROOT\CLSID\{D51BD5A0-7548-11CF-A520-0080C77EF58A}

That will disable QuickTime content playback.

Or, delete or unregister quartz.dll. Windows Media Player will not be
able to play .AVI or .WAV files after that.

Regsvr32.exe –u %WINDIR%\system32\quartz.dll

Most likely, this exploit either does not function on Windows 9x/Me, or
it would require special crafting by coders in order to function as
intended to take control of the exposed win-9x/me PC.

If Milw0rm posts POC code for this, I'll try it on win-98.

The patched version of quartz.dll that will be released (eventually) for
Win-2K for this exploit will most probably run just fine on win-9x/me.

 

Re: DirectX - DirectPlay vulnerability (win-9x/me probably notvulnerable)

98 Guy wrote:
> MEB wrote:
>
>> The issue(s) involves quartz.dll [again] and Apple's QuickTime or
>> other applications or helpers which use DirectPlay/DirectShow for
>> presentation, such as games.
>
> DirectShow in Microsoft DirectX 8.1 and 9.0 allows remote attackers to
> execute arbitrary code via an MJPEG file or video stream with a
> malformed Huffman table, which triggers an exception that frees heap
> memory that is later accessed, aka "MJPEG Decompression Vulnerability."
>
>> DirectX versions affected are 7.0 through 9.0 [a,b,c,].
>
> I am only seeing DirectX 8.1 through 9.x being listed. And only when
> used in conjunction with certain NT-based OS's - no mention of 9x/me.

Look again... might even look AT DirectX 7.0 or do something I know
you won't do, and review the historical inclusions in the DirectX versions.

>
>> [9X is not supported though at least one of the work-arounds
>> suggested below may work in that environment].
>
> Delete this registry key:
>
> HKEY_CLASSES_ROOT\CLSID\{D51BD5A0-7548-11CF-A520-0080C77EF58A}
>
> That will disable QuickTime content playback.
>
> Or, delete or unregister quartz.dll. Windows Media Player will not be
> able to play .AVI or .WAV files after that.
>
> Regsvr32.exe �u %WINDIR%\system32\quartz.dll
>
> Most likely, this exploit either does not function on Windows 9x/Me, or
> it would require special crafting by coders in order to function as
> intended to take control of the exposed win-9x/me PC.

Most likely the issues DO affect the DirectX spectrum mentioned,
ass-ume otherwise makes something out of those doing the ass-uming.
9X needs no elevated privileges or conversion to such for hacks to
work in that environment.

>
> If Milw0rm posts POC code for this, I'll try it on win-98.
>
> The patched version of quartz.dll that will be released (eventually) for
> Win-2K for this exploit will most probably run just fine on win-9x/me.

Milworm will likely not receive nor address any issues in 9X, that
would require someone competent to actually create and test within that
environment. Is it that YOU intend to create the test code?
Moreover, why would anyone trust your testing?

You see no mention of 9X because 9X is unsupported since 2006.
Microsoft could give a rat-butt whether 9X is affected, the OS is ignored.

The quartz.dll replacement MIGHT be viable, HOWEVER, that also
requires *competent* parties FULLY test the replacement.


--
~
--
MEB
http://peoplescounsel.org/ref/windows-main.htm
Windows Diagnostics, Security, Networking
http://peoplescounsel.org
The *REAL WORLD* of Law, Justice, and Government
_______

 

Re: DirectX - DirectPlay vulnerability (win-9x/me probably notvulnerable)

MEB wrote:

> > Most likely, this exploit either does not function on
> > Windows 9x/Me, or it would require special crafting by
> > coders in order to function as intended to take control
> > of the exposed win-9x/me PC.
>
> Most likely the issues DO affect the DirectX spectrum mentioned,
> ass-ume otherwise makes something out of those doing the ass-uming.

I never said that this is NOT a DIRECTX issue.

I said that this vulnerability probably does not exist within the
win-9x/me operating environment, or if it does it requires code
specially crafted for that environment to operate as intended.

> 9X needs no elevated privileges or conversion to such for hacks to
> work in that environment.

So any exploit code that attempts a privilege escalation on a win-98
platform would presumably crash itself in the process.

> > If Milw0rm posts POC code for this, I'll try it on win-98.
>
> Milworm will likely not receive nor address any issues in 9X, that
> would require someone competent to actually create and test within
> that environment. Is it that YOU intend to create the test code?

You are admitting in the above statement that the same exploit code that
works on an NT-based platform would likely not run on a win-98 platform
and would likely require special alteration in order to function as
intended on a win-9x platform.

The consequence being that the OS of the target system must be know
prior to the exploit code being presented to the target system.

Exploit code is usually presented to target systems by web servers that
have been hacked to serve iframe attachments along with their otherwise
legit web content. Even though the servers probably are aware (or can
be aware) of the OS of the target system, it's not clear to me that the
awareness can be transfered to the mechanism by which the exploit is
delivered via iframe injection so that the appropriate exploit
(9x/me-specific or NT-specific) is selected and presented to the target
system.

And in cases where the exploit arrives via e-mail attachment, such
attachment must be either 9x/me-specific or NT-specific because it can't
dynamically "morph" from one form into another at the instant it has the
opportunity to exploit the target system. Since the number of win-98
PC's with internet connectivity is now vanishingly small, it does not
make sense for bot-owners to have their spam zombies send spam with
exploit attachments that are 9x/me specific.

> Moreover, why would anyone trust your testing?

If I say that the POC does (or does not) run on a 98 system, others need
not trust that statement. They can try it for themselves and post their
experience.

If milw0rm produces a POC for this exploit, and if that POC does not
operate as intended on a 9x/me platform (but it does operate on, say,
2K/XP), then one can conclude that either 9x/me is not vulnerable to
this exploit, or special (different) code needs to be written for
execution on 9x/me platforms.

Now we can speculate that there exists a way to engineer the code such
that it can effect the desired result regardless of the OS, and that
some hacker somewhere will have sufficient desire and motivation to
perform the work necessary to discover and impliment that code, but I
would put the odds of that happening at small to none.

> You see no mention of 9X because 9X is unsupported since 2006.

Stating that 9x is (or is not) vulnerable to this or that does not
constitute "support" in the traditional sense.

Providing an actual patch would be considered support.

The fact that MacroShaft hasn't provided any updates or patches for 9x
has got nothing to do with anyone else's ability to state whether or not
9x is vulnerable to any given exploit (new or old).

> Microsoft could give a rat-butt whether 9X is affected, the
> OS is ignored.

Not all discoveries or announcements of new vulnerabilities or detailed
analysis of exploit code comes from MicroStalk. MilkroSoft has been
guilty of obfuscation during (at least) 2006 and 2007 for how it
mentions 9x in it's security advisories, with the intent being to give
the impression that a given advisory (erroneously) implicates 9x
vulnerability.

> The quartz.dll replacement MIGHT be viable, HOWEVER, that also
> requires *competent* parties FULLY test the replacement.

Maybe it does in your deluded world.

But in the practical, real world, the substitution of the replacement
file combined with the continuation of correct system functionality
would satisfy most people that the exploit window no longer exists on
that system.

 

Re: DirectX - DirectPlay vulnerability (win-9x/me probably notvulnerable)

98 Guy wrote:
> MEB wrote:
>
>>> Most likely, this exploit either does not function on
>>> Windows 9x/Me, or it would require special crafting by
>>> coders in order to function as intended to take control
>>> of the exposed win-9x/me PC.
>> Most likely the issues DO affect the DirectX spectrum mentioned,
>> ass-ume otherwise makes something out of those doing the ass-uming.
>
> I never said that this is NOT a DIRECTX issue.
>
> I said that this vulnerability probably does not exist within the
> win-9x/me operating environment, or if it does it requires code
> specially crafted for that environment to operate as intended.
>
>> 9X needs no elevated privileges or conversion to such for hacks to
>> work in that environment.
>
> So any exploit code that attempts a privilege escalation on a win-98
> platform would presumably crash itself in the process.
>
>>> If Milw0rm posts POC code for this, I'll try it on win-98.
>> Milworm will likely not receive nor address any issues in 9X, that
>> would require someone competent to actually create and test within
>> that environment. Is it that YOU intend to create the test code?
>
> You are admitting in the above statement that the same exploit code that
> works on an NT-based platform would likely not run on a win-98 platform
> and would likely require special alteration in order to function as
> intended on a win-9x platform.
>
> The consequence being that the OS of the target system must be know
> prior to the exploit code being presented to the target system.
>
> Exploit code is usually presented to target systems by web servers that
> have been hacked to serve iframe attachments along with their otherwise
> legit web content. Even though the servers probably are aware (or can
> be aware) of the OS of the target system, it's not clear to me that the
> awareness can be transfered to the mechanism by which the exploit is
> delivered via iframe injection so that the appropriate exploit
> (9x/me-specific or NT-specific) is selected and presented to the target
> system.
>
> And in cases where the exploit arrives via e-mail attachment, such
> attachment must be either 9x/me-specific or NT-specific because it can't
> dynamically "morph" from one form into another at the instant it has the
> opportunity to exploit the target system. Since the number of win-98
> PC's with internet connectivity is now vanishingly small, it does not
> make sense for bot-owners to have their spam zombies send spam with
> exploit attachments that are 9x/me specific.
>
>> Moreover, why would anyone trust your testing?
>
> If I say that the POC does (or does not) run on a 98 system, others need
> not trust that statement. They can try it for themselves and post their
> experience.
>
> If milw0rm produces a POC for this exploit, and if that POC does not
> operate as intended on a 9x/me platform (but it does operate on, say,
> 2K/XP), then one can conclude that either 9x/me is not vulnerable to
> this exploit, or special (different) code needs to be written for
> execution on 9x/me platforms.
>
> Now we can speculate that there exists a way to engineer the code such
> that it can effect the desired result regardless of the OS, and that
> some hacker somewhere will have sufficient desire and motivation to
> perform the work necessary to discover and impliment that code, but I
> would put the odds of that happening at small to none.
>
>> You see no mention of 9X because 9X is unsupported since 2006.
>
> Stating that 9x is (or is not) vulnerable to this or that does not
> constitute "support" in the traditional sense.
>
> Providing an actual patch would be considered support.
>
> The fact that MacroShaft hasn't provided any updates or patches for 9x
> has got nothing to do with anyone else's ability to state whether or not
> 9x is vulnerable to any given exploit (new or old).
>
>> Microsoft could give a rat-butt whether 9X is affected, the
>> OS is ignored.
>
> Not all discoveries or announcements of new vulnerabilities or detailed
> analysis of exploit code comes from MicroStalk. MilkroSoft has been
> guilty of obfuscation during (at least) 2006 and 2007 for how it
> mentions 9x in it's security advisories, with the intent being to give
> the impression that a given advisory (erroneously) implicates 9x
> vulnerability.
>
>> The quartz.dll replacement MIGHT be viable, HOWEVER, that also
>> requires *competent* parties FULLY test the replacement.
>
> Maybe it does in your deluded world.
>
> But in the practical, real world, the substitution of the replacement
> file combined with the continuation of correct system functionality
> would satisfy most people that the exploit window no longer exists on
> that system.

Look, I appreciate the intent and desire to make 9X seem less
susceptible to attack, but as usual you miss and deliberately ignore
what occurs during these types of activities.
The NT, Linux, OSX, and other like OSs require the party attempting
the hack, first deal with the permission levels and other security
measures within the OS. *9X has no such discriminatory levels* with
which one must deal, even WITH the full blown installation of policies
and other security measures.
What part of this don't you understand?
The code needed for 9X is FAR simpler to create than for OSs which
provide in-built protection schemes.

I realize, as does anyone left on this world with even half a brain,
that just because something fits into an OS does NOT mean it has
corrected any vulnerabilities MERELY because it causes no errors. Buy
into that one and you immediately set yourself up for the "this upgrade
fixes all your issues" with the disclaimer of no fitness or liability is
to be presumed or construed [and the inevitable need to provide
additional updates to correct the errors THAT fix instilled]. You also
set yourself up as one of the more ignorant parties, such as those who
fail or failed to realize and understand the issues CAUSED by the
installation of I.E.6 into 9X.

What gives the FALSE impression that 9X users need not fear new attacks?
Parties such as yourself, ignorant,, no let's be truthful here,,
stupid people such as yourself who will deliberately spout falsehoods,
unverified results, and claims based upon your own blind ignorance.
THESE are the types now found prowling around purported security
forums; helping hackers debug their code, posting hack code for others
to use, and other moronic attitudes which cause ALL the rest of us so
much trouble. Yes, you are a bright bunch...

Are there NT specific code which ONLY affects NT based systems, of
course, same holds true for OSX or Linux. DirectX, however, WAS a *cross
platform* {Microsoft OSs} addition. Instead of acting like a moron,
monitor and profile [use Dependency Walker if that's all you have]
DirectPlay/DirectShow within 9X and one of the NTs. SHOW how they are
fundamentally different by POSTING your results.


*You posted* Microsoft erroneously stated 9X was susceptible to some
vulnerabilities, post a complete list -here in this forum- *with
evidence to support those claims for each particular event*.

Finish that list and post EACH AND EVERY Microsoft supplied security
bulletin and/or other authorities, which specifically addresses 9X
*AFTER* end of support by Microsoft.

--
~
--
MEB
http://peoplescounsel.org/ref/windows-main.htm
Windows Diagnostics, Security, Networking
http://peoplescounsel.org
The *REAL WORLD* of Law, Justice, and Government
_______