Secunia CSI7
Advisories
Research
Forums
Create Profile
Our Commitment
PSI
PSI API
CSI
OSI
xSI
Vulnerabilities
Programs
Open Discussions
My Threads
Create Thread
Statistics
About

Forum Thread: QuickTime Player Streaming Debug Error Logging Buffer Overflow

You are currently viewing a forum thread in the Secunia Community Forum. Please note that opinions expressed here are not of Secunia but solely reflect those of the user who wrote it.

This thread was submitted in the following forum:
Vulnerabilities

See the original Secunia advisory:
QuickTime Player Streaming Debug Error Logging Buffer Overflow

Secunia QuickTime Player Streaming Debug Error Logging Buffer Overflow
Secunia Official 8th Aug, 2010 06:32
Ranking: 0
Posts: 0
User Since: -
System Score: -
Location: Copenhagen, DK
Krystian Kloskowski has discovered a vulnerability in QuickTime Player, which can be exploited by malicious people to compromise a user's system.

The vulnerability is caused due to a boundary error in QuickTimeStreaming.qtx when constructing a string to write to a debug log file. This can be exploited to cause a stack-based buffer overflow by e.g. tricking a user into viewing a specially crafted web page that references a SMIL file containing an overly long URL.

Successful exploitation allows execution of arbitrary code.

The vulnerability is confirmed in version 7.6.6 (1671) for Windows. Other versions may also be affected.

palisade RE: QuickTime Player Streaming Debug Error Logging Buffer Overflow
Member 8th Aug, 2010 06:32
Score: 37
Posts: 16
User Since: 26th Feb 2010
System Score: N/A
Location: US
Last edited on 8th Aug, 2010 06:34
Some questions I have:

Why isn't there available example code or string for this vulnerability so we can independently verify when it has been successfully cleared by Apple. Even if Apple someday releases a fix, no one will know if they have actually solved the problem.

There must be a way to disable the QuickTimeStreaming.qtx logging temporarily to resolve this issue until Apple has a fix. For example, if we knew where the extension stores the log file, perhaps we could set it to Read-Only so it cannot write to the log file.

Another question that I had that I ended up answering to myself; Is it possible to disable the extension. I looked in the menus and could not find a solution, and of course why would anyone want to disable so useful a feature. I then attempted to rename QuickTimeStreaming.qtx located in C:\Program Files (x86)\QuickTime\QTSystem to zQuickTimeStreaming.qtx and when I ran QuickTime Player again somehow restored the file.

Some details that were not in the Secunia report:

"SMIL is an XML-based markup language used to define various aspects of multimedia presentations, such as layout, timeline or elements.

A Polish security researcher named Krystian Kloskowski is credited with the bug's discovery. Back in May, he disclosed a similar remote code execution vulnerability affecting the latest version of Safari for Windows at the time. "

References:

Softpedia
http://news.softpedia.com/news/Highly-Critical-Vul...

Krystian Kloskowski's homepage:
http://h07.w.interia.pl/

---

After a bit of investigating using ProcessExplorer part of Microsoft's SysInternals tools I discovered where they keep the QT Streaming debug log file:

%LOCALAPPDATA%\Temp\QTStreaming Debug Log.txt

In mere seconds this file had grown to 9 MiB in size. I deleted the contents in notepad, and proceeded to flag the file as Read-Only, and I then re-ran QuickTime and attempted to stream a web URL again.

QuickTime did not realize this file was unwritable and did not complain, even after I started a stream it seemed to handle this gracefully. Instead of creating 2nd log file or setting the file to writable again, it appears it just decided to give up on trying to write to the log file. However, streaming still worked correctly, and I was able to watch a trailer for Nanny McPhee Returns the movie off of Apple's QuickTime Trailers website as a test case.

I'm not certain this temporarily resolves the problem or not, but it should be verified by other researches / Secunia, it may be a possible relief for those who do not wish to uninstall QuickTime to bypass the security vulnerability while they wait for Apple to release a patch.

Hope this helps someone out there.

References:

ProcessExplorer
http://technet.microsoft.com/en-us/sysinternals/bb...

Nanny McPhee Returns trailer
http://trailers.apple.com/movies/universal/nannymc...
Was this reply relevant?
+7
-7

miceyi

RE: QuickTime Player Streaming Debug Error Logging Buffer Overflow
[+]
This reply has been minimised due to a negative Relevancy Score.
dballew RE: QuickTime Player Streaming Debug Error Logging Buffer Overflow
Member 12th Aug, 2010 06:08
Score: 1
Posts: 1
User Since: 25th Jul 2010
System Score: N/A
Location: US
Last edited on 12th Aug, 2010 06:08
@palisade, if the vulnerability is in the code that constructs the string to write to the log file, it's quite likely that you're not shielded by attempting to make the actual write fail, as it's the constructor of the debug message that's triggering the exploit, which means by definition an exploit will stop there and jump to its arbitrary code, never actually going to the next instruction (presumably writing).

It's possible that if the open of the log file was before the construction of the string you'd have had a way to test (but you'd need "safe" exploit code to attempt the test), the mere fact that it opened a second debug log means that your test would've failed.

I think you're thought that your steps might help you is incorrect, I'd caution you against assuming you're protected.

Sorry to be the bearer of bad news.
Was this reply relevant?
+1
-0
palisade RE: QuickTime Player Streaming Debug Error Logging Buffer Overflow
Member 14th Aug, 2010 19:23
Score: 37
Posts: 16
User Since: 26th Feb 2010
System Score: N/A
Location: US
on 12th Aug, 2010 06:08, dballew wrote:
@palisade, if the vulnerability is in the code that constructs the string to write to the log file, it's quite likely that you're not shielded by attempting to make the actual write fail, as it's the constructor of the debug message that's triggering the exploit, which means by definition an exploit will stop there and jump to its arbitrary code, never actually going to the next instruction (presumably writing).


Yes, but, you're assuming they attempt to perform a write to the log even though the file fails to open. Programmers don't do that, what they do instead is attempt to open the file, and then before they perform writes or reads from that file they check to see if it is open. If it is not open, they do not perform the write or the read. Otherwise, their program would crash attempting to access a resource that did not exist. Since Quicktime did not crash, they are actually checking if the file is open beforehand.

Potential example (with overrun attack purposely allowed as an example):

[code]
BOOL QuickTimeStreamer::writeLog(FILE *fp, char *lpError, int nErrorCode) {
if (NULL != fp && NULL != lpError) {
const size_t uiBufferSize = 256; // this size will cause overrun, should be 255
char szMessage[255] = {0}; // not large enough, will cause overrun

// sprintf_s was used so the programmer feels he's safe
// but he's offered the wrong buffer size
sprintf_s(szMessage, uiBufferSize, "Error %d: %s", nErrorCode, lpError);
fprintf(fp, "%s: %s\n", __FUNCTION__, szMessage);

return TRUE;
}

return FALSE;
}
[/code]

You are right, though, that they might be constructing the debug message long before the write occurs, and then the exploit could still occur. It depends on when that message is created, which is why I asked that security researchers verify if my fix has resolved the problem.

Potential example of a read-only log file not protecting against this problem (includes the overrun example):

[code]
BOOL QuickTimeStreamer::writeLog(FILE *fp, char *lpError, int nErrorCode) {
if (NULL == lpError) return FALSE;

const size_t uiBufferSize = 256; // this size will cause overrun, should be 255
char szMessage[255] = {0}; // not large enough, will cause overrun

// sprintf_s was used so the programmer feels he's safe
// but he's offered the wrong buffer size
sprintf_s(szMessage, uiBufferSize, "Error %d: %s", nErrorCode, lpError);

// he checked for file not open too late
if (NULL != fp) {
fprintf(fp, "%s: %s\n", __FUNCTION__, szMessage);

return TRUE;
}

return FALSE;
}
[/code]

However, I don't know anyone who codes like that.

It is also worth noting that it a pretty easy thing for Apple to fix, now that they know where in the code that the problem is. I'm actually sort of surprised this hasn't been addressed yet actually. Time will tell.
Was this reply relevant?
+1
-0
ddmarshall RE: QuickTime Player Streaming Debug Error Logging Buffer Overflow
Dedicated Contributor 14th Aug, 2010 22:35
Score: 1210
Posts: 961
User Since: 8th Nov 2008
System Score: 98%
Location: UK
They have done what you suggest by disabling logging in 7.6.7.

http://support.apple.com/kb/HT4290

A full fix which retains the logging function seems to require more time.

--
This answer is provided “as-is.” You bear the risk of using it.
Was this reply relevant?
+1
-0

palisade

RE: QuickTime Player Streaming Debug Error Logging Buffer Overflow
[+]
This reply has been minimised due to a negative Relevancy Score.

miceyi

RE: QuickTime Player Streaming Debug Error Logging Buffer Overflow
[+]
This reply has been minimised due to a negative Relevancy Score.

carlalva01

RE: QuickTime Player Streaming Debug Error Logging Buffer Overflow
[+]
This reply has been deleted

division

RE: QuickTime Player Streaming Debug Error Logging Buffer Overflow
[+]
This reply has been deleted

jannypan

RE: QuickTime Player Streaming Debug Error Logging Buffer Overflow
[+]
This reply has been deleted


 Products Solutions Customers Partner Resources Company
 
 Corporate
Vulnerability Intelligence Manager (VIM)
Corporate Software Inspector (CSI)
Consumer
Personal Software Inspector (PSI)
Online Software Inspector (OSI)
 Industry
Compliance
Technology
Integration
 Customers
Testimonials
 VARS
MSSP
Technology Partners
References
 Reports
Webinars
Events
 About us
Careers
Memberships
Newsroom


 
© 2002-2014 Secunia ApS - Rued Langgaards Vej 8, 4th floor, DK-2300 Copenhagen, Denmark - +45 7020 5144
Terms & Conditions and Copyright - Privacy - Report Vulnerability - Disclaimer