On 30/08/2011 00:28, Chris Stratton wrote :
> On Saturday, August 27, 2011 1:53:12 PM UTC-4, KK wrote:
> 
>       I have an android EditText which holds a password. I have to
>     retrieve this in one of my modules and pass it to another. I am
>     calling EditText.getEditableText and encrypting its content. But I
>     want to know if android creates any immutable objects internally for
>     the EdiText Content(like String), in which case there might still be a
>     way for a hacker to get the password out?
> 
> 
> At first glance this seems like an interesting question - the whole idea
> of abstraction is that you aren't supposed to care about implementation
> details, but here you do have appear to have a good reason for caring.
> 
> However, if you take a step back, it would seem that someone in a
> position to exploit a detail like this is someone who has breached the
> primary android security mechanism - the separation of distinct
> applications into distinct unprivileged users, tricked your program into
> running pieces of their code, or else has tricked someone into
> installing a modified version of your program.  If either of those
> situations has occurred, there are so many means of obtaining
> confidential data that it may not be worth worrying about them individually.
> 
> So for the question to be useful, I think you would either need to
> postulate a situation where the answer matters on a device where the
> security model is intact, or suggest a reason why attacking the internal
> implementation of EditText on a compromised system would be easier than
> attacking the interface between your code and EditText, or between
> EditText and the rest of the android system.

Hi,

Indeed, this is a very interesting question and Chris' answer definitely
makes sense. But what about the garbage collector ?

Let's assume that an application
 + uses an EditText to get a password from the user,
 + this password is stored internally in a String object,
 + the application is willing to wipe the memory location containing
   the password,
 + the user interface remains open for a long time...

1) Can the garbage collector move the password, or any memory pages from
one location to another ?

2) Is there any way for the application to lock a memory page, so that
it can be neither accessed by another app nor moved by the garbage
collector ?

3) When another application allocates memory, could it be possible that
this memory contains sensitive data written by another app ? Is the
memory automatically zeroed when allocated ?

4) At the end, is there any way for an application to be sure that any
of its data in memory is wiped (including String or any immutable objects) ?

Thanks in advance,
Quentin

-- 
You received this message because you are subscribed to the Google Groups 
"Android Security Discussions" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/android-security-discuss?hl=en.

Reply via email to