That is called a trojan. And lack of upstream verification does not mean lack of verification. You cannot upgrade an existing application with a new key.
On Mon, May 4, 2009 at 9:46 AM, guillaume leterrier (Teleca Germany) < [email protected]> wrote: > > > Well, I m simply relying on user application download to spread a > sleeping virus ! > > Imagine, a small application that is so nice and useful that many > users install it. > > This nice application may perform (permission granted by the user) > useful functions and perform them in a proper way during a long time. > > Unfortunately, this application could contain a sleeping virus. Yes, > this application could have been designed or modified by a malicious > developer. The modified version could also be available on the web and > downloaded by end-user. End-user have no way to distinguish between an > original signed application and a malicious one. > We assume there is no Certificate authority that track applications , > the signature keys and developer ID. > > After couple of months, the virus may become active and take advantage > of the user granted permissions to perform money costly operations or > simply drain the battery. > For example, low standby-time of the mobile may trigger many complain > calls to after-services and generate unexpected cost for the mobile > manufacturers and the operators. > > > > Disconnect wrote: > > A virus, by definition, spreads. How do you expect an android virus to > > spread? > > > > Also, what can it damage? (Leaving aside gaping holes like 'su' in > 1.0/1.1 > > dev phones and full access to sd card data) "Oh no, the virus hidden in > > TwitterFooler deleted all the data from .. um.. twitterfooler. Ha, take > > that.. me..." > > > > On Mon, May 4, 2009 at 8:54 AM, guillaume leterrier (Teleca Germany) < > > [email protected]> wrote: > > > > > > > > > > > Unfortunatly, that is also my understanding of the current Android > > > security model. > > > > > > There is no certificate authority scheme that check application > > > content and ID/rights of the developer. > > > > > > All developers and all applications are treated as equal by the > > > android security model. > > > > > > The end-user is mainly in charge of assessing the trustworthiness of > > > an application and its installation consequences, based on its > > > requested permission. ( an exception to be noticed is the shared ID. > > > see related discussion thread....) > > > > > > It is also assumed that the end-user is responsible enough to get > > > application from a known market place and not from any unknown web- > > > site source. > > > > > > The end-user could still un-install the application if not satisfied, > > > it could also rate the application on the market place. Ok, this is a > > > reactive approach, after damages could be done. > > > > > > Next end-users could use the application rating to assess the quality > > > of the application provided by previous user, before taking any > > > installation decision. > > > > > > However, the malicious developer could still regenerate the same > > > malware with a different key, and potentially continue the damages > > > under an other identity. > > > > > > The market place could implement an automatic scheme that scan > > > applications to limit such cloning behavior by comparing binary signed > > > with different keys and reject black listed malware application. > > > > > > Moreover, if there is a virus embedded in the application source code, > > > and such virus could still become active after a sleeping period. An > > > anti-virus could also scan ( at installation time ) the application > > > binary and compare it against an updated list of unknown malware. The > > > anti-virus check could also be performed by the market place itself. > > > > > > > > > > > > Android wrote: > > > > The silence in the thread scares me. Does anyone knowledgeable have > an > > > > answer to Tote's question? > > > > > > > > Is the totality of Android API protection based solely on the idea > that > > > > self-signing out of self-generated certificates is trustworthy? No > chain > > > of > > > > trust? No identity escrow? No skin in the game of any sort whatsoever > to > > > be > > > > able to track down the originator of a rogue app? No validation that > > > someone > > > > with bad intentions isn't self-signing an innocuous-looking > application > > > that > > > > gets on marketplace but that triggers bad behavior after it's been > widely > > > > installed? > > > > > > > > Please tell me that the effectiveness of Android's API security model > > > isn't > > > > purely based on crowdsourcing and user-generated feedback... > > > > > > > > -jfr > > > > > > > > > > > > Dave, > > > > Thanks for the exhaustive answer and I naturally appreciate Google's > > > > decision on working out this security model. Nevertheless, you seemed > > > > not to answer one of the important questions I also asked: > > > > > > > > "Another question is that if any developers can sign their apps > > > > freely > > > > without any consequences (I mean there's no accountability on self- > > > > signed certificates) what will really prevent malware from spreading? > > > > " > > > > > > > > That is, if I were a malware author it wouldn't give me too much > head- > > > > ache to change my self-signed certificates frequently - and I don't > > > > want to update my previous app, either. What is Google's approach to > > > > this problem? > > > > > > > > Thanks, > > > > > > > > Tote > > > > > > > > On Feb 5, 3:02 am, Dave Bort <[email protected]> wrote: > > > > > > > > ________________________________________________ > > > > Message sent using UebiMiau 2.7.10 > > > >
