back to article Android upgraded to be more resistant to hack attacks

The newest version of Google's Android mobile operating system has been upgraded to make it harder for hackers to hijack handsets by exploiting code errors in the underlying code. Android 4.0, aka Ice Cream Sandwich, has added a mitigation known as ASLR, or address space layout randomization. It works by routinely changing the …

COMMENTS

This topic is closed for new posts.
  1. Anonymous Coward
    Anonymous Coward

    Pity

    That none of the handset manufacturers will be releasing a version except for new shiny handsets, and that google is keeping ICS source to itself.

    1. Anonymous Coward
      Anonymous Coward

      FUD-off, Mr chickenshit-AC

      That is all.

      1. Peter Storm
        Trollface

        Ah, the razor sharp wit of the archetypal fandroid.

        1. Anonymous Coward
          Anonymous Coward

          'Wit' - I've heard of it...

          ... and I don't need to waste mine to bitch slap some fucking anonymous iTwunt.

      2. Tom 38
        Thumb Down

        How is that FUD? If it isn't FUD, when/where can I get the ICS update for the ZTE Blade/Orange San Francisco?

        Oh wait, no source, no new firmwares except for new phones. Colour me shocked.

        1. Anonymous Coward
          Anonymous Coward

          @ Tom 38

          "...when/where can I get the ICS update for the ZTE Blade/Orange San Francisco?"

          Well, if ZTE or Orange don't provide an ICS update the chances are that someone else in the Android community will once Google open-source the code.

          Anyway, why should it concern you? You are an iPhone owner.

        2. Craigness
          FAIL

          @Tom38

          Tom, 2 claims were made and both are false. How is that not FUD? You made a further claim, which is also false. Let me do the same and see how it looks from another angle:

          Apple is open sourcing their OS and you can't upgrade an iphone4 to iOS5.

    2. Craigness
      FAIL

      They will and it's not

      HTC, already announced.

      http://www.techradar.com/news/phone-and-communications/mobile-phones/ice-cream-sandwich-coming-to-as-many-htc-devices-as-possible-1036042

      Sony Ericsson, already announced.

      http://www.fonehome.co.uk/2011/10/20/sony-ericsson-xperia-arc-xperia-play-xperia-neo-xperia-ray-to-get-android-ice-cream-sandwich/

      Google, already announced.

      http://www.anandtech.com/show/4999/google-to-release-ice-cream-sandwich-source-code-soon

      You earned a fail.

      1. Tom 38

        Oooh, its coming "soon" is it? Can't wait for "soon" to get here. Do you think it will be the same "soon" that the Gingerbread source will be available "soon"? (then "maybe", then "never")

        Did you even read the links you posted? Rather than prove your point, they backup mine:

        "Beyond Gingerbread 2.3.4, we plan to upgrade our 2011 Xperia smartphone portfolio to the next Android platform made available to us"

        2011 phones are new phones. 2010 phones are not new phones. Not new phones are not getting upgrades from SE. Has this made it any clearer to you?

        Contrast with iOS, the latest version of which could be installed on the 2009 version of the phone (3GS), from the moment it was released.

        1. Anonymous Coward
          Anonymous Coward

          Er, don't you mean "Honeycomb"? Gingerbread HAS been released, that's why we have Cyanogen Mod doing their thing.

          1. Tom 38
            Thumb Up

            Yep, I meant Honeycomb. Act in haste, repent at leisure.

            1. Craigness

              Honeycomb wasn't open source.

              Why complain about a non-open-source product being closed source? Honeycomb was created for tablets because OEMs were putting Gingerbread (or earlier) onto tablets even though it wasn't specifically designed for that, which devalues the brand. Honeycomb wasn't designed to work with phones but it did a good job of bringing a tablet-specific Android to tablets. Even though they'd obviously put a lot of thought and design into making another great Android OS, it wasn't on the path they wanted to be on, so it was kept closed. They wanted something which could work on tablets and phones, and they wanted it open source. Now they've got it.

        2. Anonymous Coward
          Facepalm

          @ Tom 38

          What are you on about? The Gingerbread source was released in December last year:

          http://www.engadget.com/2010/12/17/android-2-3-gingerbreads-source-code-now-available/

          The number '38' in your username - that's your IQ, isn't it?

          1. Tom 38

            Bra size.

        3. Craigness

          Tom38

          You're in a hole and digging.

          You said: Oh wait, no source

          Fact is: source

          You said: no new firmwares except for new phones

          Fact is: new firmwares on existing phones

          (Facts are really useful when your're trying to make a point.)

          Why compare it the iphone? You've been proven wrong without a need to reference that. There was a legitimate complaint to be made about Android upgrades for previous generations of hardware, but the complaint has essentially been addressed. Unfortunately you chose to spread FUD and be completely wrong instead of being legitimate yet slightly out of date.

          If you want the gingerbread source, here's a link:

          http://source.android.com/source/downloading.html

          1. Tom 38
            Thumb Down

            Fact: No SE 2010 phone is scheduled to get ICS.

            1. This post has been deleted by its author

        4. Eddy Ito
          Meh

          @Tom 38

          "Contrast with iOS, the latest version of which could be installed on the 2009 version of the phone (3GS), from the moment it was released."

          So it only works on the three models they currently sell. Of course that assumes one counts the black 4 and the white 4 as the same model but a second coming.

  2. DrXym

    I'd like more fine grained security.

    When you install an app, Android says what permissions an app needs. Problem is the app doesn't tell you what it needs the permission for and there is no way to interactively veto / divert requests which are made once you install the app.

    This causes a problem because an app might legitimately need access to phone calls (e.g. because it's a contact manager) but a user has no way of vetoing requests in case it turns out to be malicious and is surreptitiously ringing premium numbers in the middle of the night.

    Even aside from malicious apps, some apps have annoying behaviour that a user should be able to curb. e.g. The facebook app tracks my location, even firing up GPS to ask for it. I find this incredibly annoying even if the rest of the app is okay. I'd like to be able to tell the OS, that when the Facebook app asks for location to give it either a fake location or one which has been made more vague through some distortion. Basically dummy the behaviour and feed it a duff value. Perhaps when Facebook are fed crap data they might provide a setting not to bother asking for it.

    Basically Android needs a better trust model, something that lets me set a trust level for apps (implicit, interactive, or custom) where I intercept & veto certain actions or farm them off to dummy behaviours. A combination of UAC and a traditional Unix jail.

    1. Paul 135

      agreed

      Well said. This is the #1 thing that pisses me off about Android. I would have thought that the open sourse philosophy would have given me MORE control, not less!

      In addition to what you have said I would especially like control over applications that decide to automatically start themselves in the background without having to root. Far far too many background processes are running on my Gingerbread phone, I have no idea what they are doing and can do sweet FA about them. Try to kill them and they just restart themselves!

      1. Paul 135

        Damn - meant to say "open sourCe philosophy". The new spellchecker coming in ICS is the top new feature for me!

    2. Roadkill

      CyanogenMod 7.1

      ...offers app permission control. This gives the user "line item veto" control over app permission entries. Of course, this yanks the rug out from the app; how the app responds depends on how gracefully the developer coded for the permission failure.

      For example, I installed Shazam but found it undesirable to allow the app to retain the "Read Phone State and Identity" permission. I disabled that one and allowed the rest; however, upon launch, Shazam reported a connection error despite the phone having full internet connectivity at the time.

      Other apps seem to take being neutered in stride, so YMMV.

    3. Swedish Chef
      Pint

      App permissions management

      If your phone happens to be rooted, try LBE Privacy Guard. It runs in the background and lets you set permissions to grant/deny/prompt on a per-app basis. It also notifies you every time an untrusted app wants to use a permission you've blocked. I've been using it for 4 months and am very happy with it - no app crashes due to withdrawn permissions so far, and it allows me to install some useful apps that request a rather questionable set of permissions.

      Paris, just because.

    4. Craigness

      There's an app for that

      But you need to root your phone. CyanogenMod has it too, but you need to root to get that.

      Try the mobile web for Facebook. Or just don't install the apps.

      1. DrXym

        At least someone has thought of it

        I think I'll eventually install Cyanogenmod on my HTC Desire at some point but it's a shame this stuff is not there in Android from the beginning. I think the upfront permissions model isn't sufficient and if other parties can augment security I wonder why Google can't.

  3. Silverburn
    Coat

    Cue another fanboi/droidboi slagging match

    It won't be long now until both OS's have pretty much identical features that operate nearly identically. But the respective fanbois will still be arguing the virtues of their respective platforms.

    Is anyone else reminded of the futurama episode, with Jack Johnson and John Jackson (identical clones) vying for the presidency, using identical but differently worded policies?

    Just me? Oh. I should get out more.

  4. Thomas 18
    Meh

    Battery

    Doesn't it waste battery power constantly copying stuff around in memory.

    1. Trevor 3

      I might be wrong

      But as far as I'm aware it doesn't keep shifting the memory around, it just creates another set of pointers in front of the actual memory address space.

      The app wants to write to 0x12345678 android actually writes to 0x87654321 and remembers the change

      when the app tries to read 0x12345678 android steps in and retrieves the data from 0x87654321 and hands it over.

      The app is oblivious to it.

      I think that's how it works anyway. I may be wrong.

      1. Anonymous Coward
        Anonymous Coward

        http://en.wikipedia.org/wiki/Address_space_layout_randomization

        ASLR basically moves the "starting point" for various segments around. Things within each segment are in the same place relative to one another. Addressing memory is a relative thing under Linux (like most modern timesharing OSes), so you do not incur a performance penalty by enabling ASLR. It's a pretty useful technology, since you don't pay much overhead and at least make the bad guys fish around in memory a little before they can hijack execution.

        Unfortunately, due to how Android half-starts the Dalvik VM that runs virtually everything (look up Zygote), ASLR is still not fully deployed. Every Dalvik VM will have the same randomized base addresses. At least this is a step in the right direction.

      2. Gerhard Mack

        it doesn't copy

        @trevor 3 you are close but Android doesn't do it the CPU does. On any modern CPU architecture the CPU can map memory however you want so a given resource can be relocated anywhere regardless of it's physical location in RAM. This is the same virtual memory function that gives us Swapping but someone has discovered a way to re-purpose it as a security tool.

        1. Trevor 3
          Pint

          AC, Gerhard - thanks!

  5. Pat 11

    misses the main problem

    I want device level encryption. No reason not to do it (see Whispercore). I'm more worried about physical access to the device (I might lose it) than bad software (I won't instal it)

    1. Anonymous Coward
      Anonymous Coward

      Ice Cream Sandwich...

      ICS offers full device encryption. Not personally seen any details, but it was part of the recent announcements.

      1. Random Handle

        This is already option in Honeycomb see Settings | Location & Security | Encrypt Tablet....

    2. Craigness

      Main problem covered

      Full device encryption is in ICS.

      http://www.eweekeurope.co.uk/news/google-adds-security-features-to-ice-cream-sandwich-43523

      1. Pat 11

        Oh, that sounds good.

        That's mega if true (but I'll only be happy if it's minimum /data partition and preferably all partitions with some kind of second channel lockdown if authentication is failed multiple times, no bypass, no automatic adb server. Basically the device should be entirely inaccessible without the lock code).

  6. Anonymous Coward
    Anonymous Coward

    Errr

    "Microsoft Windows, Mac OS X and Apple's iOS rely on ASLR to minimize the risk of someone successfully attacking a system when targeting flaws that are inevitable in every complex piece of code."

    So why is Winblows more prone to viruses, malware etc than Apple (and everyone else)?

    1. DrXym

      Because

      "Winblows" has far more users and those users are far more likely to run some arbitrary attachment. So it has a larger attack surface and a larger install base to do damage with.

      There are exploits for other platforms. Indeed anyone who jail breaks iOS is relying on them and the Mac is usually the first to go in Pwn2Own competitions.

      1. Andrew Jones 2
        FAIL

        Because Windows was never built for security in mind.

        Take this example -

        on any Windows XP machine pre SP3 -

        If you were to schedule a windows scheduled task to run explorer.exe and then kill explorer.exe before the task runs - when windows runs the task it runs it as "SYSTEM" - that's an account that has more privileges than the Administrator account. Once windows has run explorer.exe you are now a SYSTEM user and can change anyone's password, uninstall any protected software and even delete c:\windows if you really want to. This was due to the fact that for some reason the designers programmed windows scheduled task to execute all it's tasks with superuser permissions :/

        Note that in order to pull this off - you have to schedule the task using the command line.

    2. Graham 32

      because it's the world's most popular OS so virus writers, quite sensibly, write most of their viruses for it. And ASLR is not the be all and end all of combating viruses.

    3. cloudgazer

      Because ASLR only protects against certain classes of error, and Windows has a bunch of other structural faults that invite attack in other ways.

      Ultimately because windows started as an intrinsically insecure single user OS, whereas OS-X, linux et al started out as intrinsically secure multi-user OSes. Windows has had problems patched over the years, but there are still too many services running as admin that can be exploited, user permissions are still too great, graphics drivers run in kernel etc. etc.

  7. Anonymous Coward
    Anonymous Coward

    32-bit ASLR

    ASLR on 32-bit code is vulnerable to brute force attacks on the entire memory address space with today's hardware. Won't stop a real cracker.

    http://www.stanford.edu/~blp/papers/asrandom.pdf

  8. Joe Montana
    WTF?

    ASLR

    I thought the Linux kernel already had an implementation of ASLR, and has done for quite some time... Did previous Android versions ship with this turned off?

    Or have they done something extra, like merge the grsec/pax patches in?

    1. fishman

      ALSR in Linux 2.6.12

      Linux has had ALSR since June of 2005.

  9. Michael H
    Facepalm

    ASLR might stop people exploiting buffer overflows...

    ...but it still isn't going to stop J. Random Luser (the sort who uninstalls their AV protection because "the update balloons were annoying") from installing an app off the market that runs up a £4000 bill in premium rate dialing scams. This is where the real security issues in Android lay. (Of course, enabling ASLR is still an improvement, I'm not deriding that)

    I'm firmly of the belief that background services in Android should be restricted from texting and calling, and bring up a confirmation when done by third party apps in the foreground, without explicitly setting it otherwise in the preferences. Not nanny state, just opt-out protection for those who don't know what they're doing.

  10. Dropper

    Apps?

    This is not a dig at Android, I have one and have no desire to change to something inferior like the Apple Chocolate-Clone, but I'm not sure why anyone would choose to install more than a handful of apps that aren't Netflix and a task killer. 99% of apps for ALL phones are just throwbacks to 1980s 4-bit software.

  11. regorama
    FAIL

    "have long relied on ASLR" - FAIL!

    > Mac OS X and Apple's iOS have long relied on ASLR...

    Do your research! Mac OS X only got proper ASLR with Lion. It only arrived in iOS with 4.3.

This topic is closed for new posts.

Other stories you might like