7 ms·

The Apple walled garden is way more dangerous, because it's almost as easy to slip malware into your code (remember, Apple doesn't do full source code audits),

• nhangen 16y ago
  I would like to see you qualify that comment with fact. Apple does not examine full source code, but they do watch network traffic and examine API calls. At least they do something.
  • sid0 16y ago
    You can slip the malware in as a timebomb. It's not exactly as easy as it is with Android or an open platform, but it is almost as easy.
    • ceejayoz 16y ago
      Why aren't we seeing it happen, then?
      • joebananas 16y ago
        It's much easier to spread FUD on the internet than to actually do it.
      • moe 16y ago
        How do you know it isn't already happening? Do you monitor the outgoing traffic from your cellphone?
        • ceejayoz 16y ago
          > How do you know it isn't already happening? There is no evidence that it is happening, with plenty of security researchers and interested amateurs keeping their eyes open for it. There's nothing special about iOS that prevents you from discovering this sort of app behaviour that isn't present on Android.
          • moe 16y ago
            There is no evidence that it is happening You mean other than seeing it happen in the biggest similar ecosystem? There's nothing special about iOS [...] that isn't present on Android Exactly. So why should iOS be different with regard to malware then?
            • ceejayoz 16y ago
              > You mean other than seeing it happen in the biggest similar ecosystem? It's being noticed in the biggest similar ecosystem, too, so by that logic it should be noticed in both if it is present in both. > Exactly. So why should iOS be different with regard to malware then? The Apple review process is present in iOS. The process to market is markedly different.
              • moe 16y ago
                It's being noticed in the biggest similar ecosystem, too, so by that logic it should be noticed in both if it is present in both Sorry, but how does discovering one instance of malware in the android market imply that any instance in the iOS Store will be discovered at the same time? Is there some sort of quantum-link that I'm missing? The Apple review process is present in iOS. I was told the Apple review process does not involve a full code analysis. And even if it did, malware authors are known to be quite creative in hiding their payloads. Apps you have installed might or might not already contain shell-code embedded into seemingly innocent images or assets, with very little chance of detection. I'm not a security researcher or blackhat. But under the premise that you can (afaik) not root a phone without the user noticing, my strategy for pulling off an attack would be a sleeper-strategy. I'd first seed my payload silently, and then pull the trigger all at once, at some point in the future. Moreover, considering there has been a one-click safari jailbreak[1], you may not even need to embed actual malware in an app. It may be enough to be able to remotely instruct the app to load a specific URL at your command - now how's that for an attack vector. So, technically there is no difference between doing either on android or doing it on iOS. If you still want to claim otherwise then you should come up with a better argument than "but apple has a review process!". [1] http://lifehacker.com/#!316287/jailbreak-your-iphone-or-ipod-touch-with-one-click http://lifehacker.com/#!316287/jailbreak-your-iphone-or-ipod...
    • mrcharles 16y ago
      This is one thing I've been wondering about, how is it that they don't know every single API call the executable is linked to? I know that Objective C and messaging is different from function linking in some fashion, but certainly there must be a way of determining if disallowed APIs are ever called, at all, without just using the app and hoping you trap them. I think at the very least they should be able to examine the executable for object types used, and function signatures used, as well as determining what signatures are passed to which objects.
      • jedsmith 16y ago
        > This is one thing I've been wondering about, how is it that they don't know every single API call the executable is linked to? They do. I used an old example from the Internet, and that API was now private; Apple rejected the app and included the name of the API that I wasn't supposed to use.
        • sid0 16y ago
          But you were being honest in your use of the API.
    • jedsmith 16y ago
      Are you speaking from experience?
      • sid0 16y ago
        No, from logic. I don't have a Mac to develop on, sorry.
        • mkramlich 16y ago
          I think you're both right in different ways. The positions "if it can happen it has or will" versus "yes but there is no evidence so it probably hasn't or won't" both have merit and are not explicitly in conflict. But I'm reminded of that quote: "In theory there is no difference between theory and practice. In practice there almost always is!"
    • nhangen 16y ago
      So how is that more dangerous?
      • sid0 16y ago
        It gives users a false sense of security. The average user is far more willing to trust an arbitrary iPhone application than an arbitrary Windows application, do you not agree?
        • nhangen 16y ago
          No, I don't really. I don't think those with a high level of technical intelligence will be affected by wall or wall-less, while those with less than moderate TI probably don't even realize that one marketplace has or doesn't have an approval process. So it's equally dangerous, but I don't think moreso.
          • sid0 16y ago
            You have people talking in this very thread about a walled garden being better: http://news.ycombinator.com/item?id=2279823 http://news.ycombinator.com/item?id=2279823
            • danssig 16y ago
              A walled garden is unquestionably better. It isn't fool proof but it's the same situation as security: you can't make your system completely secure but you can make it more secure than the next guy. The Android store is the next guy.
• rmc 16y ago
  Not to mention that the Underhanded C Programming content is showing how you can have malicious code hidden in plain sight. Even doing a source code audit wouldn't be guaranteed to show exploits.
  • bad_user 16y ago
    It's not so hard to detect exploits - usually all you have to do is to detect system-calls - it's more efficient than looking at source-code. That said, I don't think Apple does any kind of audit that targets exploits and only relies on reviews.
    • ootachi 16y ago
      That's assuming the malicious syscalls actually fire while Apple is reviewing the app. An iOS malware author would likely do everything possible to prevent the payload going off during the review process; it might be as simple as checking the system time and only launching the obfuscated malicious code a month or two after submission. Disabling the payload under circumstances that put the perpetrator at risk of being discovered is a very common malware tactic (see Conficker disabling itself if it detects it's being run in the Ukraine, for example).
      • bad_user 16y ago
        That's assuming that Apple doesn't think about serving different GPS-coordinates, different IPs, different device IDs, different system time. And this could very well be completely automated - you just need someone to design a map of gestures / time intervals for simple workflows of the app, and then let the system run the app and interact with it for every possible configuration. Of course, the malware author could then try different tactics to detect if the app is running inside a virtual machine, and not on a real device. But that's as hard as detecting a well-behaved / modern root-kit, and that also implies certain sequences of system-calls that can be detected. Virtual machines do this all the time, i.e. detecting illegal operations. Not only that, but it doesn't have to be accurate - it just has to raise a red-flag in some intranet bug-tracker that these and these apps need closer inspection. It also makes it much harder for malware author, because instead of searching just for an iOS / Android exploit, now they also have to game this approval process.
• jedsmith 16y ago
  They do static analysis of your executable and check what you call, which is why they know if you're using a private API and reject you because of it. They've also caught bugs in my app and sent it back. I believe the advantage of Objective-C for them is that all messages pretty much go through one point in the runtime (as far as I know). That signature is probably very obvious, and they can probably do a lot of looking at your code with very little effort. If you have malware in your code, there's a pretty good chance they'll find it based on what it does. I imagine they can see a lot more about our apps than you'd think, since they probably run them in a debug build of iOS. I can think of literally dozens of things they can look at, and I don't even have access to their systems to know what data is available. They have hundreds of engineers who have probably figured all of that out, and automated it for the approvers, too. And how would we know? Is a malware author going to blog and say "I tried to slip malware into the App Store, and they denied it?" Since an attempt costs $99 (I can't imagine you'd keep your account after a failed attempt), that raises the bar to trying. I seriously doubt we're the first to think of exploiting iOS, and you haven't heard a word about it... I think security theater is a bit of a stretch, frankly.
  • sid0 16y ago
    They do static analysis of your executable and check what you call Doesn't Objective-C have dynamic binding? I'm sure you can determine what function to call at runtime, which means you can always get past a static analysis. I can think of literally dozens of things they can look at I can think of literally dozens of ways any analysis can be subverted. Even dynamic analysis wouldn't work in case the thing uses a timebomb or even something simple like downloading data from the internet (apps do that right), and sending in a special payload that instructs the application to do something evil once you reach, say, 1,000 users. Apple wouldn't test your application by installing it on a thousand phones, would it?
    • jedsmith 16y ago
      > Doesn't Objective-C have dynamic binding? I'm sure you can determine what function to call at runtime, You need a message name (@selector), and the names are strongly typed -- meaning, they're pretty obvious with reflection tools. If there's a way to send a dynamic message without putting a @selector in your code, I don't know it, and I'm willing to learn. When you start talking about the POSIX layer and stuff near the bottom (C), traditional wisdom applies there: what does your app link against? If you're linking against the dynamic libraries near the bottom of the stack and walking their contents (to avoid putting a string in your binary of what you're looking for, perhaps?), Apple's probably going to check that disassembly pretty heavily. > Even dynamic analysis wouldn't work in case the thing uses a timebomb You keep on writing time bomb as if it's some magical device that circumvents all security. A time bomb needs a callback in the binary, and Apple's going to wonder why your app registers a timer for a specific date. This is what you don't seem to get: Apple has a disassembly of your entire binary, and they can see when they run it that you register a callback for December 2012. Where does that callback go? Code in the binary. Same thing with your 1,000 phones case: clearly something needs to count, and the obvious candidate is a Web server of some kind, and then the app needs to actually do something if the response comes back as 1,000. Which means that code needs to be in the binary. Or you need to download code from the Web server to execute. Which is easily detectable by Apple, and you'd never get approved. > something simple like downloading data from the internet (apps do that right) You will be rejected if it's used as any part of execution, and they can (and do) check that. If you even touch APIs that try to sneak data into executable pages, I bet they'd terminate the app in record time. Trust me, they've thought this through. The reason that I asked if you're speaking from experience is because you're making a lot of FUD claims which are easily fixable. Seriously, buy a Mac and try doing something malware-like with the iOS API. Then try submitting it to Apple. Otherwise, you and I are both bags of hot air, theorizing about hypotheticals.
• danssig 16y ago
  Hyperbolic nonsense as explained here: http://news.ycombinator.com/item?id=2283338 http://news.ycombinator.com/item?id=2283338