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 …
"...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.
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.
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.
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.
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
This post has been deleted by its author
"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.
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.
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!
...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.
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.
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.
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.
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.
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.
@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.
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).
"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.
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.
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.
...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.
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.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
