“By creating a crafted iPhoto photocast XML feed, a malicious user could abuse a format string vulnerability in the handling of the “title” element, potentially leading to a remote arbitrary code execution condition,” LMH reports – without first informing Apple of the issue, thereby irresponsibly jeopardizing users – via his “Month of Apple Bugs” blog.
LMH reports, “This issue has been verified in iPhoto 6.0.5 (316). Previous versions supporting the photocast features might be affected as well.”
Full article here.
Landon Fuller’s “MoAB Fixes” Google Group (more info, discussions, and fix files) can be found here.
[Thanks to MacDailyNews Reader “Masa” for the heads up.]
Related articles:
Apple Mac OS X guru combats ‘Month of Apple Bugs’ – January 03, 2007
MoAB #3: Apple Quicktime HREFTrack Cross-Zone Scripting vulnerability – January 04, 2007
MoAB #2: VLC Media Player udp:// Format String Vulnerability – January 03, 2007
MoAB #1: Apple Quicktime RTSP URL Handling Buffer Overflow Vulnerability – January 02, 2007
That’s it. Time to put a Trojan on my router…
“potentialy” causing code execution ?
i really would like to know if these bugs are CERTAIN to cause code execution, or if they simple cause crashes (address errors, bus errors)
to cause code execution the bug has to corrupt the stack, that rarely happens, in 20 years of development, 99% of my bugs resulted in harmless crashes caused by invalid pointers.
the difference is huge, and even causing code execution does not mean u can actually make it execute the code u want, that would be close to a miracle !
That reminds me, back when I was “married” to a PC sh!t, I caught something from my Wi Fi….
someone should find a vulnerability in his skull and expoit it.
when u look at his debugging log, u clearly see that the crash is NOT an arbitrary code execution, but a EXC_BAD_ACCESS error in vprintf.
that is a completely different type of problem, and one does not transform into the other.
the result is : iPhoto crashes, no viruses installed, nothing !
i’m going to check each of his bug reports from now on.
Mac os, and all applications that run on it, (and windows + it’s apps) contain THOUSANDS of similar bugs.
what a waste of time.
(and this is not a kernel panic, it’s not an Mac OS bug, nothing is lost, and the user is not in danger)
Why would someone ever subscribe to a malicious (unknown) XML feed (as opposed to an XML feed created by family & friends)?
I’ll worry above this if even the proof of concept can be shown that this can be used to execute a rmdir or kill shell command, download and install a trojan, or something that is more malicious than a crash. Hell, I can design a web page that will crash, or even kernel panic, any Mac (hopefully my customers don’t see it first
” width=”19″ height=”19″ alt=”wink” style=”border:0;” /> ). That’s not a particularly notable bug and just tells me that Mr. MoAB is going to really be stretching by January 31.
to Martin –
Huh?
LOL – Glad somebody smarter than me can decipher this!
mmmh, actually there is some code being executed that should not be.
actually im really glad this guy is doing these exploits! im a long time mac user, and these “bugs” are pretty minor. there is also a developer who is doing the month of apple bug fixes! as for windows, there is not enough time in a month to exploit all of its bugs. also, i suppose someone at apple is looking at these bugs, and there will be a security update soon! which is GREAT!
well it’s OK that he is doing this, BUT he is doing it for the wrong reasons, why not just send a bug report ?
just a detail: yes some code is executed that should not be, but it’s not some random code, u can’t make it execute the code u want, so, like i said, iPhoto crashes, that’s it.
(rediscovering the fun of low level debugging)
+ learning x86 assembler 🙁
thekilldare, you like this?
I think I’ll start a “month of ways to get into thekilldare’s house and bank accounts” website.
Be sure to check it out regularly (sorry no RSS), before anyone tries out my hints. You should have secured all those entries way before this. And while you’re on this exploit site, be sure to click on the ads, I need the income.
If we take what Martin says as truth, and it sounds good to me, that really would indicate that all of this stuff from LMH et. al. is simply a radicle attempt at negative PR aimed straight at Apple.
and positive PR for himself.
it’s a bit arbitrary, you could do what he is doing to almost any application, on any operating system.
i’m still waiting for him to show how he could actually do any harm. (not that he ever said he was going to do that)
ok, i finaly reproduced the bug myself, instead of looking at his log,
well i can now say with 100% certainty that there is no code executed AT ALL, it’s a simple crash because of invalid data here:
0x9000c0bb <__vfprintf+4970>: mov -1756(ëp),ìx
” width=”19″ height=”19″ alt=”grin” style=”border:0;” />
0x9000c0c1 <__vfprintf+4976>: mov ìx,(êx) <- here to be precise
0x9000c0c3 <__vfprintf+4978>: jmp 0x9000af15 <__vfprintf+452>
this is valid code, not data
so he is lying, and he knows it.
Martin:
I have had an idea.
Martin. you seem to know what you are doing.
Why don’t you put up a blog telling people how these bugs are not the type that allow arbitrary code execution..
Then post links on sites that LMH’s blog is publicised on.
Hopefully after say a week this twat will give up and stop lying about harmless bugs being OS X security vulnerabilities.
Can’t wait for the decade of Windows bugs on the net.
DoWB
actually im really glad this guy is doing these exploits! im a long time mac user, and these “bugs” are pretty minor.
I agree. You have to do something uncommon, if not unusual, to be subject to these bugs in the first place, and then most don’t even have any actual dangerous effect.
This is raising my smugness to unheard of levels.
” width=”19″ height=”19″ alt=”LOL” style=”border:0;” />
Is this guy’s 15 minutes up yet???
I mean really, I bet that LMH has a corner office right next to Ballme(r) at MS.
Any time you can get a program to crash, the opportunity is there for a malicious payload. What they have released doesn’t actually DO anything, but someone with enough time and effort (and a severe lack of life) could POSSIBLY craft something that could at least be annoying and at most cause some data loss.
I don’t THINK anything has been demonstrated that would result in a self-propagation though.
that’s simply incorrect.
there are only a few ways a program can crash, the most common are:
1 accessing an invalid address in memory
this can happen because of a null pointer (out of memory), a corrupted pointer, or just an invalid one (as is the case here)
2 executing invalid code,
this can happen because a pointer used to jump into code is incorrect, when the code is corrupted, or (most frequently) when the return address on the stack is changed before the function returns.
3 math errors (divide by zero)
—
in this case (MOAB 4), a function (vsprintf) is called with invalid parameters, making this function use a pointer that is invalid, to access data, not to execute code, it crashes with a memory access error.
i don’t see how this particular bug can cause the execution of arbitrary code, it’s not what happens with his example, and even if he changes the parameters, it’s NOT going to happen, ever !
some bugs can cause either invalid access to memory, or execution of arbitrary code, but certainly not this one.
in fact, if a bug cause one of the other it is a bug of type 2, that sometimes causes problem 1
but a problem of type 1 will never cause problem 2
vprintf is just accessing data, it’s not using any pointers to execute code, and this bug is NOT changing the return address, and never will.
u can’t generalize, and simply state that any crash can lead to the execution of code, are u a programmer ?, did u read this somewhere ?
Thank you Martin. I think you have done more to debunk this publicity stunt than anyone else. MDN should front page your posts as an exclusive article somehow. Contact John Gruber at DaringFireball and see if he’ll work with you on some kind of article… I think it’s important this information gets out.
I did not write “any crash can lead to the execution of code”
I wrote “Any time you can get a program to crash, the opportunity is there for a malicious payload.” After determination, you may discover that this either is or is not possible with a given crash event. You agree with me when you say “SOME bugs can cause … execution of arbitrary code”
Don’t listen to Martin.
Programs can crash for lots of other reasons. You can also have raise uncaught exceptions, call unimplemented traps (e.g. on 68K), attempt to access system resources without the right permissions, tweak hardware registers to put the machine in a bad state (by tweaking the clock speed or changing a serial port state, for example), attempt to access hardware features that your process doesn’t have permissions to, pass invalid arguments to system calls, turn off the fans to cause overheating, send some signals (like SIGABRT or SIGKILL), and on and on.
In computer science, even an infinite loop, deadlock, or other freeze is considered a crash.
Anyway, the point (besides taking some of the wind out of Martin’s sails) is, string formatting errors are a well known exploitable security flaw. Apple takes them very seriously. That’s why length-unprotected functions like strcmp() are deprecated in OS X, in favor of length protected functions like strncmp(). The idea is that a black hat can use a string (in this case in the title element in an XML file) that’s longer than the buffer that accepts it, and your string overwrites the memory past the end of the buffer. If the nature of the coding error is that the buffer lies in the heap just before some code, you can exploit that by putting opcode bytes in your overlong XML string so that it overwrites that function, and when the function is called your evil code gets executed. It has to be pretty short, but once you get to that point, you can put more code somewhere else, like in a JPEG file, and have your code load and execute that.
Bottom line. Trust me. It’s dangerous.
my comments apply to this particular bug, not any of the others, he might find a bug that is a real security risk.
Sum, i did not talk about uncaught exceptions, access priv errors etc, because those cannot cause the execution of code.
the unimplemented trap exception is usually the result of executing arbitrary code (that starts with an 0xA), and is covered by case number 2
passing invalid arguments to system calls will not crash the computer in itself, it has to cause an addressing error, arbitrary code execution, math error etc..
infinite loops or deadlocks will NEVER cause arbitrary code execution, they are not crashes, they are bugs.
all i’m saying is that the statement “potentially leading to a remote arbitrary code execution condition” is absolutely false !
i agree with your last statement (that u could potentially destroy something in the heap by overloading the stack, but, isn’t memory protection supposed to take care of that ?
+ this is not the case here, the crash is caused by the “%x”, making sprintf believe there is a pointer on the stack.
it’s a simple memory access error (caused by invalid parameters passed to sprintf).
explain, please, how that could lead to code execution, instead of coming with some generalizations.
Martin 3 – Sum Jung Gai /Wrong Again 0