Shared libraries do not work for third-library apps. They are blocked. Also, there is no such thing as a ’suid share library’.

The rest of your reply is again based on false assumptions and speculation. If you think you have found a security issue then show some proof of concept code.

http://stefan.arentz.ca/2009/08/06/iphone-daemons

Perhaps an exploitable suid share library within the chrooted ~/Library would allow this sort of thing to happen. I don’t have the time or resources to sit and tinker with it, but given the legions of bugs exploited from an x86 system I’m sure there are thousands to be found in the ARM system to the point where you could do what you want with it upon finding one.

Just look at the recent SMS bug, for instance.

So its only a matter of time before either this or something along these lines becomes a reality, as it already has. I’m just trying to get creative in how it would be implemented, and just remember: these smartphones and embedded devices are the next security nightmare, probably just as bad as a Windows PC was a couple of years ago.

Popularity in a given product draws interest in
it and in the security of it as well. And like I said – there’s a will, so there is most certainly a way in there somewhere

I just had a theory that could still potentially work with the circumvention of NX’ing, chrooting, etc.

First of all, the iPhone has a non-executable heap and stack. So there is no way to load code into a buffer and then execute it. The system will simply not allow it.

Second, even if you download code to disk and then try to exec() it, the system will block it. The iPhone uses a very restricted environment and certain syscalls, like fork() and exec*(), are simply now allowed. This also means that system() will not work since it depends on those syscalls.

Third, even if you manage to get code running, your app is executed in a chrooted environment. This means that it can only see its own app directory and a minimal ~/Library directory to store app preferences and files.

Your claim that someone can use this method to for example access your iCal is therefore also false. There is no way to access the iCal database since it lives outside of the chrooted app executing environment.

If you somehow manage to execute malicious code then the most damage you can do is through the available APIs. This means networking, Address Book, maybe the iTunes library. Not super exciting.

Nice try, but no cigar.