Android OS Forum banner

Major security hole in AOSP Web browser!

25K views 26 replies 16 participants last post by  blunden 
#1 · (Edited by Moderator)
The default web browser from AOSP exposes your password in plain text!

The package com.android.browser uses the default webview which is fine until you click remember after entering your password. The browser caches the password for you so you don't have to enter the same password every time you visit the same page. Sounds good right? Well it usually is good... except the password is then stored in plain text in an SQL database at '/data/data/com.android.browser/databases/webview.db' in a table with the brilliant table name 'password'.

This is crazy and puts all android enthusiasts with rooted devices at risk. I beg of Google to fix it!

Its noteworthy that in Chrome this issue DOES NOT exist. This default behavior is however in lots of other applications that use the default webview to prompt for passwords. One such example was Trello. Once this oversight was pointed out they fixed and pushed an update within 7 hours, bravo! If an app asks you to login through a webview you should check that the app is not storing your password in plain text, use the directions below and sub out the package/app names.

Interested to see what is stored about you? (using the default browser enter your password in any website; click 'Remember'; done your password is now in plain text in a table called password... Epic fail!)
  • You can pull the database using adb (adb pull /data/data/com.android.browser/databases/webview.db .) then explore like you would any sql database.
  • or if you would like to view from your phone use SQLite Editor; in the apps tab click 'Browser' then 'webview.db' and check out the table named 'password'
All accounts are saved in this manor... including your gmail password
Font Screenshot Technology Software Multimedia

A screen shot of the plain text passwords :-/
Rectangle Font Screenshot Multimedia Number


**PS** AOKP is already hard at work implementing a fix for our fork of the AOSP Browser package!

**Update**
Reported as Android Issue 52895
Hacker News thread
 

Attachments

See less See more
2
#2 ·
rooted devices at risk
Precisely why I wouldn't expect Google to fix this anytime soon.

In short, because you (the end-user) have futzed with your phone, and broken the security restraints placed on the Android filesystem, you have opened yourself up to vulnerabilities. It's your responsibility to manage what you do, and don't, grant root access, and if you pick poorly, you reap the benefits, much like installing some "Super Happy Funtime!" app from a Chinese warez site that has every permission possible. You can't be too surprised if next month you have a $10,000 bill due to the app calling and texting international premium numbers, and sending all of your personal information to every website the creator could think of.

So to summarize:
  • Not on a rooted device? Then Google probably won't care because the filesystem permissions will block any other app that doesn't have root access to your device from accessing that database file, and ADB isn't enabled by default.
  • On a rooted device? Then Google and your carrier/manufacturer won't care because you made that decision, and broke your warranty. You changed a critical function of how the system works.
 
#9 ·
This stuff here cracks me up. You have a device that is locked up for protection. You root said device. Then you are surprised by the fact that there is a security hole for a device that wouldn't have this unless you purposely removed security by rooting the device????? You should know what apps you are installing and what apps can access said personal information. Stop putting so much faith in a metal box that is nothing but small electric impulses.

Example: You buy a house with a lock on the door, you go ahead and remove said lock. You place an add on craigslist saying you may or may not have removed the locks. You come home and all your things are gone. Do you go after the company that sold you said house and ask for a refund?

Get you head out of your @$$ and be smart, "sometimes you need to be smarter than the device you are using".
 
#10 · (Edited by Moderator)
This stuff here cracks me up. You have a device that is locked up for protection. You root said device. Then you are surprised by the fact that there is a security hole for a device that wouldn't have this unless you purposely removed security by rooting the device????? You should know what apps you are installing and what apps can access said personal information. Stop putting so much faith in a metal box that is nothing but small electric impulses.
Specious reasoning. An exploit can access it with or without root. Hashing a password takes barely any time from my development experience and no excuse for not doing it. One also has root all the time on PC, so I suppose we should just chuck out security on PC, because one has root there.

I don't expect Google to patch it soon, but I look at this as more of a call for all of the major ROM developers to do so as it concerns them more.
 
#12 · (Edited by Moderator)
#18 ·
You can't one way hash passwords that must be retrieved.

You can do two way encryption but that is only wasting cpu cycles when it a malicious user has root. They will just extract the decryption key and decrypt. Archon (good/smart guy/, myself and even a google employee (Nick, again super smart, nice guy) replied with nearly identical responses on this. There is nothing to patch, this is standard behavior in this case.

To prove my point, I eagerly await the release of it with encryption, expect a decryption tool release from me shortly after (ETA depending on if it is released during my trip or not)
 
#19 · (Edited by Moderator)
So your argument is its better for passwords and usernames to be plaintext because encryption it won't stop experts in the field?

No passwords are 100% safe... So at what point do we stop caring?
 
#21 · (Edited by Moderator)
My argument is, it is better not to store passwords at all, but even more so when a device is compromised by default.

No expertise is needed to decrypt local, two way encryption. Hell, I am far far far from a crypto expert, but when the encryption routine is opensource (or easily reversed) anyone with basic java knowledge walk right through it.
 
#23 · (Edited by Moderator)
It would remove no risks, you are missing the concept here. Security by obscurity is NOT the solution, but it is what you are proposing. Even someone from Google's own security team spoke up on this.

You can not secure locally stored passwords with two way encryption if the key is stored locally, hell even if the user has to enter another password we just listen to keyboard input, hell we are root, so lets just MITM the connection and grab the passwords as they are sent, SSL? hell were root we can add our own cert too. That is just as weak as storing them in plaintext.

Why would the attacker have to take it to a remote server to "crack" it, we don't have to crack it, we can just decrypt it on the local device, the phone it self.

EDIT

I'm done ranting and won't comment on this (here, I will continue on the bug report if it isn't dead yet) again, by all means go ahead and do this, but do not fool your users nor yourself into thinking it is more secure, it is just an alternative storage system.
 
#24 ·
Ok we will encrypt our passwords and you are welcome to break them with malware.

I completely agree its not a fix but I fail to see why the passwords are better off in plain text
 
#26 · (Edited by Moderator)
Please see a well cited explanation here: https://code.google....ail?id=52895#c7

Ok I lied I am commenting here. Jbird no offense, but I can't help it when you cant understand basic security concepts. I hope the code reviewers understand the subject more than you do at this point, I have a strong feeling this won't be merged into AOKP or any mainline rom. If it is, great! More fodder for my talk on rom security this Aug. I keep seeing people speak out about how "vulnerable" this is, when people who are paid to know (lets not count me, even tho I am) are straight up pointing out why it is wrong, along with citation.

Also, please learn the definition of malware.



droided again, two different things, you can't do salted one way hashs in this instance, then the browser could not retrieve the password for reuse. Again, local two way encryption is the only option, and it is just as weak as plaintext in this particular case
 
This is an older thread, you may not receive a response, and could be reviving an old thread. Please consider creating a new thread.
Top