Apple patches QuickTime flaw
Posted by configure on 01 May 2004 - 15:23 · 12 comments & 1831 views
About the Author
Full name: Unknown
Forum name:
configure
Contact: via forum PM
Submissions: Normal · Headline
Full name: Unknown
Forum name:
configureContact: via forum PM
Submissions: Normal · Headline
Slashdot It!
Submit to reddit
Submit to blinklist
Bookmark on del.icio.us
Add to furl
Share on Facebook
Add to Windows Live
Add to Google- Advertisement
-
-
(5 replies)
#1 Posted by ThunderRiver on 01 May 2004 - 15:25
- haha talk about slacking off .. Microsoft is not the only one.
Nonetheless, due to the seriousness of its nature, I guess Apple doesn't have to address it right away, considering it only crashes QuickTime, not the whole system. -
#1.1 Posted by the evn show on 01 May 2004 - 17:02
- EDIT: I was wrong.
Last edited by 13631 on 01 May 2004 - 19:10 -
#1.2 Posted by idbuythatforadollar on 01 May 2004 - 17:19
QUOTE (#1.0) , I guess Apple doesn't have to address it right away, considering it only crashes QuickTime, not the whole system.
No, did you not read it?
'cause malicious code to execute when the user opened the file.'
This means code can be injected into the system and do pretty much anything you want, exactly why eEye Digital Security were claiming apple is playing it down.-
#1.5 Posted by roadwarrior on 02 May 2004 - 01:31
QUOTE (#1.2) This means code can be injected into the system and do pretty much anything you want
Not really, since it could not affect system files or files belonging to other users. The worst it could do would be deleting files in the current user's home directory.
-
(3 replies)
#2 Posted by Avi on 01 May 2004 - 18:12
- Call me lazy for not reading this article... one question: did QuickTime 6.5.1 already fixed this flaw?
-
#2.1 Posted by DELTA75329 on 01 May 2004 - 19:00
- Don't be lazy. Especially with security. Read the article and find out.
-
#2.2 Posted by x2cube on 01 May 2004 - 21:00
QUOTE (#2.1) Don't be lazy. Especially with security. Read the article and find out.
I don't feel like reading it either, can you jus tell me?-
#2.3 Posted by Mav Phoenix on 01 May 2004 - 21:09
- Lazy Mac users.
-
(1 reply)
#3 Posted by aristotle-dude on 01 May 2004 - 19:13
- Wow, but the time I read this article, i had already downloaded the patch a couple days ago.
One more thing... this bug cannot be used as an exploit on the Mac running on a PPC due to differences in processor design whereas X86 processors are vulnerable to buffer overflow exploits.
It has to do with PPC processors having mostly general purpose registers whereas X86 processors have many more special purpose registers which control the sequence of code execution. The registers can be stuffed by a buffer overflow to point to a different memory address containing malicious code.
I am not aware of any buffer overflow exploit on any PPC system to date.
Last edited by 18285 on 01 May 2004 - 20:09 -
#3.1 Posted by the evn show on 01 May 2004 - 21:52
- PPC is just as vulnerable as x86. If you'll forgive the artificial construct here's an example.
<br /> #include <iostream><br /> int main(const int argc, const char **argv) {<br /> // assume there is a bunch of code and functions already defined<br /> <br /> int* anarray;<br /> int arraysize;<br /> std::cout << "how big is the array? ";<br /> std::cint >> arraysize;<br /> anarray = new int[arraysize];<br /> std::cout << "last number is: ";<br /> std::cin >> anarray[arraysize];<br /> <br /> return 0;<br /> }<br />
arrays are defined somearray[x] where x is the number of elements the array holds; if x is 5, then the array will hold 5 items. Arrays are indexed from 0 so the 'slots' in the array are 0,1,2,3,4 - note the last item is x -1.
in the above code we declare an array of size 'arraysize', the last element should be at arraysize - 1, but we store the "last value" in arrasize which is one location past the end of the array.
That location could be the start of where a function is held, it could be a variable that controls how a function is run, or it could be random, never-used, memory space. Either way, when you dump data past the end of an array you've got yourself a buffer overflow. PowerPC offers no protection against this, I'm not aware of any ARCHITECTURE that does.
AMD-64 has W^X protection - which means you can mark areas of memory as executable or not. if a page is marked as not executable, which will protect you from executing code in the event of a buffer overflow. This is not standard issue on any of the PPC line to the best of my knowledge (definitely not on the g3/g4/g5 models in powermacs anyway).
Apple said the flaw in the QuickTime movie player for Mac OS X could cause the player to crash. "Playing a malformed .mov (movie) file could cause QuickTime to terminate," Apple said in an advisory published on late Friday afternoon.
The company that found and reported the flaw to Apple in February, eEye Digital Security, claimed Apple is downplaying the seriousness of the flaw in its advisory. A movie file could be created, the firm maintained, that would cause malicious code to execute when the user opened the file.
"We told them that if you are not able to execute code then talk to us, so we can show you the issues," said Marc Maiffret, chief hacking officer for eEye Digital Security.
An Apple representative could not be reached for comment.
What's New: