Major security flaw lets anyone bypass Samsung Galaxy S II security

[roadbloc]

The post above your post links to source about major security issues affecting all Android devices.

http://blog.duosecurity.com/2011/09/android-vulnerabilities-and-source-barcelona/

My mistake then.

 

[Rodimus Prime]

The post above your post links to source about major security issues affecting all Android devices.

http://blog.duosecurity.com/2011/09/android-vulnerabilities-and-source-barcelona/

I have learned to take a lot of those things with a Massive and I mean a massive dose of salt. Most of it is complete FUD. Yes some is relevant but it mostly FUD.

Common sense solves 99% of the problems no matter the OS.

 

[munkery]

I have learned to take a lot of those things with a Massive and I mean a massive dose of salt. Most of it is complete FUD. Yes some is relevant but it mostly FUD.

Common sense solves 99% of the problems no matter the OS.

This isn't the case with this vulnerability.

It is a local privilege escalation with easy vectors to exploit remotely.

So the first bug is a permission escalation vulnerability that affects all Android handsets in the world. This permission escalation allows an attacker to install additional arbitrary applications with arbitrary permissions without prompting the user to approve those permissions. [...] An attacker can exploit this vulnerability to gain additional privileges after gaining code execution on the device. It’s important to note that this attack can also be performed by compromising an existing application.

 

[Rodimus Prime]

This isn't the case with this vulnerability.

It is a local privilege escalation with easy vectors to exploit remotely.

Read it again. It requires an someone installing malware of some type to pull that off. It still requires going threw the biggest security hole (the user). Only difference is that it is a little easier to hide it and not make it as blaring to do it.


So again goes right back to the point I was originally making.

 

[munkery]

Read it again. It requires an someone installing malware of some type to pull that off. It still requires going threw the biggest security hole (the user). Only difference is that it is a little easier to hide it and not make it as blaring to do it.

No it doesn't.

Gaining code execution on the device can include remote arbitrary code execution in a existing application on the device.

So the first bug is a permission escalation vulnerability that affects all Android handsets in the world. This permission escalation allows an attacker to install additional arbitrary applications with arbitrary permissions without prompting the user to approve those permissions. [...] An attacker can exploit this vulnerability to gain additional privileges after gaining code execution on the device. It’s important to note that this attack can also be performed by compromising an existing application.

http://blog.duosecurity.com/2011/09/android-vulnerabilities-and-source-barcelona/

 

[Rodimus Prime]

No it doesn't.

Gaining code execution on the device can include remote arbitrary code execution in a existing application on the device.



http://blog.duosecurity.com/2011/09/android-vulnerabilities-and-source-barcelona/

yeah I watch it. It still requires an something being installed by the user. It can not be done with out the user installing it. It is an exploit that way.
Really watch the video and listen to it. It is done by requiring it to be installed on the phone. It still has to have physical access to the device (user installed). Now they can make it easier to get in there but still is Trojan so standard practices will avoid it.

 

[munkery]

It can not be done with out the user installing it.

You're incorrect.

The quote I provided is from the transcript of the video provided in the following link.

http://blog.duosecurity.com/2011/09/android-vulnerabilities-and-source-barcelona/

An attacker can exploit this vulnerability to gain additional privileges after gaining code execution on the device. It’s important to note that this attack can also be performed by compromising an existing application.

Using remote arbitrary code execution would allow the attacker to leverage the exploit without the user installing anything.

 

[Rodimus Prime]

You're incorrect.

The quote I provided is from the transcript of the video provided in the following link.

http://blog.duosecurity.com/2011/09/android-vulnerabilities-and-source-barcelona/



Using remote arbitrary code execution would allow the attacker to leverage the exploit without the user installing anything.

which again requires running the code. That is the key part. How are you going to run that code remotely? You need to get the code on said device which is going to require the user running it. It does not need to be an APK. It requires running it in with some file. It still would be a Trojan.
How do I see this one being used? well I see it getting deeper in the phone on one malware app then hiding by going threw things like facebook making it harder to find and remove.

 

[munkery]

which again requires running the code. That is the key part. How are you going to run that code remotely? You need to get the code on said device which is going to require the user running it.

You run the code remotely by exploiting a client-side application on the device.

That is explicitly what is stated in the quote.

 

[munkery]

Unlike many desktop Linux distros, Android doesn't have DEP (non-executable stack/heap) or full ASLR.

http://jon.oberheide.org/files/summercon10-androidhax-jonoberheide.pdf -> same author as the exploits.

Both of these runtime security mitigations are better implemented in iOS.

Android mostly relies on privileges to prevent malware install.

The aforementioned exploit allows Android's implementation of privileges to be bypassed.

 

[r.j.s]

There is a temporary fix:

Samsung and AT&T are investigating a permanent solution. In the meantime, owners of the Galaxy S II can remedy the situation by re-setting their time-out screen to the "immediately" setting. This is done by going to the Settings->Location and Security->Screen unlock settings->Timeout->Immediately.

A more permanent fix is coming.

 

[ChazUK]

Wirelessly posted (Mozilla/5.0 (Linux; U; Android 2.3.4; en-gb; GT-I9100 Build/GINGERBREAD) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1)

It seems it's not only Samsung that can have issues with lock screen security.

http://mashable.com/2011/10/19/siri-lets-you-make-calls-on-passcode-locked-iphone-4s/

Security firm Sophos  discovered and Mashablehas confirmed that you can make calls (and more) with the voice activation service Siri, even when the Apple iPhone 4S  is locked.

It could be an obvious security misstep for the Cupertino tech giant, or it’s in fact an intended feature. In any case, this news will likely do little to slow the momentum of the iPhone 4S, which sold 4 million units in its first weekend  available.

If you have an iPhone 4S, testing the security glitch is easy. Set up a passcode, which you’ll find under Settings/General/Passcode Lock. Enter your new passcode (twice) and then lock your iPhone 4S by pressing the power button once. Normally, to access your phone you would hit the home or power button, swipe the unlock arrow and then enter your four-digit passcode. In this case, tap the home button once, then hold it down to activate Siri. Alternately, you can simply hold down the home button and Siri will come to life asking “What can I help you with?” Simply say “Call “. Siri will immediately access the phone’s contact database and present you with dialing options. We dialed a number and completed a call with no issue.
Now, it’s important to note you can receive calls on both the iPhone 4 or iPhone 4S without unlocking the phone, so at least half this functionality is intended. On the other hand, this means anyone who finds your phone can access your contacts and perhaps look up phone numbers of your friends, family and business associates. Siri will perform a variety of functions without unlocking the phone, including searching for local businesses, and searching for and playing music on your phone. She won’t, however, search the web. When we tried to perform a web search, Siri told us, “I can’t search the web while your phone is locked. You’ll need to unlock it first.”

 

[roadbloc]

Maybe it is intentional that you can get Siri to make a call without unlocking your phone. Bit of a stupid intention if you ask me, but you'd have thought Apple would have spotted a security flaw as simple as this well before iOS 5was released to the general public.

 

[munkery]

Can Siri call any number or only numbers in your contact list and local businesses?

Is this functionality of Siri disabled via locking the device using Find My iPhone?

 

[ChazUK]

It seems it was intentional judging by what others are saying as apple does offer the option to disable voice control when locked in settings but by default it is on. I don't know if you can get Siri to call any number or only those on your contacts but I have no doubt that most of the management where I work have our Managing directors number saved under his name.

Siri, send message to [MD's name], this job is crap and you have no idea what you are doing. I quit.

Apple could make make this more secure by offering a passphrase or word when the phone is locked with a pin whenever Siri is invoked.

Siri: Pleased say passphrase
User: Apples
Siri: What would you like to do.

Due to the fact that it could be easily overheard or that people you work in close proximity with would easily pick it up, Apple could add the option to set a reminder to change the password after a user defined set of days.

I can understand why you have this level of access to a locked iPhone via voice control but but when you set up a pin, you should be warned that Siri still lets people access many features, bypassing some security.

 

[munkery]

It seems it was intentional judging by what others are saying as apple does offer the option to disable voice control when locked in settings but by default it is on...

I can understand why you have this level of access to a locked iPhone via voice control but but when you set up a pin, you should be warned that Siri still lets people access many features, bypassing some security.

I agree a prompt should appear to tell users the implications of having voice control/Siri enabled when a passcode is set.

Most of the implications of this issue, such as workplace sabotage, could occur completely independent of an individual's phone if the malicious individual is highly motivated.

But, proper disclosure via a prompt would help users to decide if they want to eliminate this vector for that type of malicious behaviour.

 

[KnightWRX]

Android has a much bigger security issue than the one presented by the OP.

This flaw affects all Android devices.

And iOS has had its share of PDF exploits that permitted jailbreaking (and could have been used for much worse) straight from Safari by visiting a website.

So what ? Why does this conversation need to be tainted with slurs and attacks and airs of superiority ?

 

[miles01110]

So what ? Why does this conversation need to be tainted with slurs and attacks and airs of superiority ?

Because the trolls want this thread about "something not Apple" to resemble all the other threads about "things that are not Apple."

 

[munkery]

And iOS has had its share of PDF exploits that permitted jailbreaking (and could have been used for much worse) straight from Safari by visiting a website.

So what ? Why does this conversation need to be tainted with slurs and attacks and airs of superiority ?

Read the original post in this thread:

It looks like Samsung copied nearly everything from Apple's iPhone... except the ability to secure your phone!

http://www.bgr.com/2011/09/30/major-security-flaw-lets-anyone-bypass-att-samsung-galaxy-s-ii-security-video/

The focus of this thread is Android vulnerabilities so I posted about Android vulnerabilities.

 

[KnightWRX]

Read the original post in this thread:

The original post was tainted with the same. iOS is no better than Android in this regard, no matter how much the OP wants it to be.

 

[roadbloc]

The focus of this thread is Android vulnerabilities so I posted about Android vulnerabilities.

A thread's focus or topic has to change (within reason) for it to evolve and live on and for it to become and interesting discussion. I dunno about you, but I think this focus change is just within reason.

However, if your concern persists I suggest you contact a forum moderator or report everyone's posts.

 

[munkery]

The original post was tainted with the same. iOS is no better than Android in this regard, no matter how much the OP wants it to be.

See post below for corrections.

 

[KnightWRX]

I don't believe this is true for several reasons:

1) The Linux kernel is known to contain more privilege escalation vulnerabilities than the kernel used in iOS.

iOS (2010-11) = 3 -> http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=apple+iOS+gain+privileges

Linux (2010-2011) = 26 -> http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=linux+kernel+gain+privileges

Seriously ? The first one for Linux :

The agp_generic_remove_memory function in drivers/char/agp/generic.c

What Android phone uses the AGP sub-system ?

You've just searched for all vulnerabilities in Linux, a very versatile and generic OS that supports so many hardware configurations dating back to pre-historic times in the computer industry that it can run on everything from TVs to micro-controllers to desktop computers to full NUMA enabled supercomputing nodes.

And then you compare that to iOS, a very small subset of a very niche OS kernel that runs on either PCs branded as Macs or portable devices.

And you deem that a fair comparison ? Of course the Linux kernel is going to have more vulnerabilities, it supports hundreds more sub-systems and drivers. There's just more code there. Now answer this :

How many of those Linux vulnerabilities can be used to exploit an Android based smartphone ? All 3 of those iOS vulnerabilities can be used.

And again : jailbreakme.com. It only takes 1 nasty vulnerability to do it. Numbers don't matter if that 1 you have is highly exploitable.

 

[munkery]

You've just searched for all vulnerabilities in Linux, a very versatile and generic OS that supports so many hardware configurations dating back to pre-historic times in the computer industry that it can run on everything from TVs to micro-controllers to desktop computers to full NUMA enabled supercomputing nodes.

And then you compare that to iOS, a very small subset of a very niche OS kernel that runs on either PCs branded as Macs or portable devices.

And you deem that a fair comparison? Of course the Linux kernel is going to have more vulnerabilities, it supports hundreds more sub-systems and drivers. There's just more code there. Now answer this :

How many of those Linux vulnerabilities can be used to exploit an Android based smartphone? All 3 of those iOS vulnerabilities can be used.

OK, I fixed it for you. I don't believe this is true for several reasons:

1) Below are the numbers for total amount of vulnerabilities in the OSs. This includes both local and remote vulnerabilities.

Android = 88 -> http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=android - the list shows 89 but 1 of the vulnerabilities is limited to HTC Android devices that use the Sense UI.

- 4 of the vulnerabilities are local privilege escalation vulnerabilities but the list doesn't include the 2 vulnerabilities found by Oberheide because these vulnerabilities haven't yet received a CVE.

- Information about these vulnerabilities can be found at http://www.securityfocus.com/bid/49709

- BTW, 1 of Oberheide's local privilege escalation exploits is not yet patched despite being disclosed on Sept. 20, 2011. So, this has remained unpatched for a month despite Google's OTA updates. This is the reason that these vulnerabilities are not yet disclosed in CVE. CVE doesn't disclose public and unpatched vulnerabilities.

iOS = 63 -> http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=apple+ios

- 3 of the vulnerabilities are local privilege escalation vulnerabilities. The two separate Jailbreakme local privilege escalation vulnerabilities are included in the list. The Jailbreakme vulnerabilities were patched in 13 days and 8days, respectively. This was prior to iOS 5 which introduced OTA updates for iOS.

FYI, malware install via exploitation requires a remote arbitrary code execution vulnerability to be linked with a local privilege escalation vulnerability into a single exploit.

2) EDIT: Android has supported NX (aka DEP) since 2.3. Android will support ASLR starting with 4.0. Both technologies are already supported in iOS.

3) The vetting process for app submission to the Android Market is much less strict than the equivalent for iOS.



http://jon.oberheide.org/files/summercon10-androidhax-jonoberheide.pdf

4) These factors contributed to the following comparison between Android and iOS.



http://www.symantec.com/content/en/us/about/media/pdfs/symc_mobile_device_security_june2011.pdf

And again : jailbreakme.com. It only takes 1 nasty vulnerability to do it. Numbers don't matter if that 1 you have is highly exploitable.

Actually, it requires a remote arbitrary code execution vulnerability to be linked together with a local privilege escalation vulnerability in a single exploit.

This is also required to install malware via exploitation. This is true for both iOS and Android.

Android also has a greater surface area of attack due to the inclusion of Flash. Combined with a greater number of local privilege escalation vulnerabilities, Android is less secure in this regard.

 

[neiltc13]

Looks like anyone with a smart cover or a couple of magnets can now also get access to a passcoded iPad 2!