• Introducing XDA Computing: Discussion zones for Hardware, Software, and more!    Check it out!

Potential Security Issue with S-Memo and JB

Search This thread

graffixnyc

Retired Forum Mod / Inactive Recognized Developer
Jan 21, 2011
6,628
6,475
New York City
www.graffixnyc.com
I was poking around my GS3 today (ATT version but running the Sprint Official JB release LJ7) and I found something pretty shocking. I was poking around the S-memo databases when I opened a table using SQLIte editior. When I opened the table I was shocked to see my Google account username and password in clear plain text. Now, I did have the option to sync to Google drive and the app did prompt for my google username and password so obviously it stores it somewhere. I was just shocked to see it stored in plain text and not encrypted.

I know someone who checked his ATT GS3 running ICS and he did not have these entries in his DB which makes me think it's a JB thing.

To check you need to be rooted and have SQLite editor installed.

Steps to check
1. Set up S-Memo to sync with your Google account
2. Use SQLite editor and navigate to /data/data/com.sec.android.provider.smemo/databases
3. Open the Pen_memo.db file and select the CommonSettings table. Look to see if your Google account info is stored in plain text.

This could potentially be a serious issue. If people running JB on their GS3 can check this that would be awesome. Someone already checked the latest ICS build for the ATT variant but if others on ICS or with a different variant can check that would be great. I will get to check my GF's I-9300 running JB tomorrow when I see her.

Also I'm not sure how app permissions work on android, meaning if one app could access the data/database of another app(without root, because obviously with root another app can, in this case SQLite opened the file). Since the DB is in the /data partition and the permissions are r/w by default I'm thinking it wouldn't be difficult for a malicious non root app to access this database and query it for the information unless there is something built into android that wont allow that.

I have attached a SS of what my table looked like. Obviously I blacked out my PW and also the Google auth ID

Screenshot_2012-11-09-19-50-34.png
 

ViViDboarder

Inactive Recognized Developer
Mar 25, 2010
1,584
630
San Francisco, CA
Actually, while /data is available for you to browse, that is because you have root. It's RW but only within the packages that each app is sandboxed. If you disable root you will not be able to view that database.

It is possible for the same developer to access the /data files of another one of their apps if they use the same namespace.

So, while this is indeed a risk, it would not be trivial for another app to gain access without asking for root or cracking root itself.
 

graffixnyc

Retired Forum Mod / Inactive Recognized Developer
Jan 21, 2011
6,628
6,475
New York City
www.graffixnyc.com
Actually, while /data is available for you to browse, that is because you have root. It's RW but only within the packages that each app is sandboxed. If you disable root you will not be able to view that database.

It is possible for the same developer to access the /data files of another one of their apps if they use the same namespace.

So, while this is indeed a risk, it would not be trivial for another app to gain access without asking for root or cracking root itself.

Ahh OK. Yeah I wasn't sure if another app would be able or not. Ive never not been rooted so I wasnt 100% sure about that. So I guess this issue would just concern root users. I still think though the data should have been encrypted before the record was inserted. It did kinda freak me out to open that table and see my google password staring at me.
 

csmasn

Senior Member
Sep 17, 2011
850
280
Actually, while /data is available for you to browse, that is because you have root. It's RW but only within the packages that each app is sandboxed. If you disable root you will not be able to view that database.

It is possible for the same developer to access the /data files of another one of their apps if they use the same namespace.

So, while this is indeed a risk, it would not be trivial for another app to gain access without asking for root or cracking root itself.

There are on Play and on the net "free apps" which needs root access to work. Once you grant access to any of them those can get your info and sent it to anyplace.

Sent from my O=O
 

Jarmezrocks

Senior Member
Mar 25, 2011
959
493
Gold Coast
tinyurl.com
There are on Play and on the net "free apps" which needs root access to work. Once you grant access to any of them those can get your info and sent it to anyplace.

Sent from my O=O

Agreed but that is why you should be checking carefully what root apps are doing. Also not just willy-nilly granting Superuser permissions. Half of XDA would be at risk cause they see the SuperUser popup and most of the time just press grant not ever thinking 'What does that mean?' yes they want to test an app, but FFS check what it wants to do. That is the screen that pops up (another one people ignore - yes I am guilty of it my self sometimes thinking nothing has changed between one version to the next) just as you are installing the app. If it is wanting to do things in areas you don't want it to be then don't install it and confront the developer about it.

In this case you can't really confront Samsung devs about this, but the thing is we know what it is for, and secondly your not installing it comes pre-installed. But you get my point. I doubt that the Samsung devs have malicious intensions, where as other developers that your are granting SuperUser permissions to...who knows?
 

jcase

Retired Forum Mod / Senior Recognized Developer
Feb 20, 2010
6,331
15,773
Sequim WA
Yikes! Good news, this is not as bad as it seems. The data is not accessible without root.

Once an app has root, it is all over. You have to trust the app to use it wisely (trust me a lot of root apps are unsafe). With this kind of issue, it is probably safer to notify the OEM before publishing, allowing them time to fix it. This is exactly why I am not one to run root apps without a review of them myself.

I took the liberty to forward this on to those that can get it fixed. Nice find.
 

pulser_g2

Admin Emeritus / Senior Recognized Developer
Nov 27, 2009
19,537
11,595
This should probably use a token-based authentication system, rather than the ACTUAL google account username and password...

Still not brilliant for security, but at least it's not your ACTUAL password in plaintext...
 

csmasn

Senior Member
Sep 17, 2011
850
280
Agreed but that is why you should be checking carefully what root apps are doing. Also not just willy-nilly granting Superuser permissions. Half of XDA would be at risk cause they see the SuperUser popup and most of the time just press grant not ever thinking 'What does that mean?' yes they want to test an app, but FFS check what it wants to do. That is the screen that pops up (another one people ignore - yes I am guilty of it my self sometimes thinking nothing has changed between one version to the next) just as you are installing the app. If it is wanting to do things in areas you don't want it to be then don't install it and confront the developer about it.

In this case you can't really confront Samsung devs about this, but the thing is we know what it is for, and secondly your not installing it comes pre-installed. But you get my point. I doubt that the Samsung devs have malicious intensions, where as other developers that your are granting SuperUser permissions to...who knows?

Agreed with you.

But about Google's Devs, because it's a Google's flaw. Encryption is old enough, so they can implement it.

Sent from my O=O
 

Turbotab

Senior Member
May 2, 2011
902
819
If somebody knowledgeable stole your GS3, and mounted it in Linux using adbfs, would make a bad situation worse, if they got your Google account login. Passwords in plaintext are bad in any case, I still don't trust either Android or iOS for really sensitive apps like banking.
 

fomofo

Senior Member
Oct 19, 2010
55
5
Adelaide
Checked mine (4.1.1 International version though), and these are the entries in my CommonSettings table...

IS_BOOT_COMPLETED
IS_MEDIA_MOUNTED
SAVED_PAPER
tutorial_view_state
_pref_list_type_before_tag
serialization_hashcode
serialization_canvas_mode
serialization_tag_mode

...nothing about my Google ID.
 
Last edited:

da-pharoah

Senior Member
Mar 24, 2009
2,779
1,593
Seacoast near Joppa
So I'm on cm10 tmous and don't use smemo... but I can confirm this issue is the same for com.android.email in databases in the email provider.db is a HostAuth.. and when I open that up sure as sh!t there is ALL my email accounts and listed PW in plain text... not secured... really jacked up its not just an s-memo issue..
 

jamcar

Senior Member
Aug 11, 2010
1,215
400
Orlando
So I'm on cm10 tmous and don't use smemo... but I can confirm this issue is the same for com.android.email in databases in the email provider.db is a HostAuth.. and when I open that up sure as sh!t there is ALL my email accounts and listed PW in plain text... not secured... really jacked up its not just an s-memo issue..

I just pulled that up on mine too! Wtf!

Generating random authentication keys
 

cybergaf

Member
May 20, 2005
8
0
Has anything been done about this or basically can anyone with any clue about phones easily get your goggle password if they nick your phone?
 

da-pharoah

Senior Member
Mar 24, 2009
2,779
1,593
Seacoast near Joppa
Has anything been done about this or basically can anyone with any clue about phones easily get your goggle password if they nick your phone?

Yea just uninstall s-memo. You really don't need it that bad. And if so use other notepad apps that have voice to text capability or use the aosp keyboard. Anything but s-memo

.:Sent from the Hellfire Galaxy of S & 3:.
 

cybergaf

Member
May 20, 2005
8
0
Yea just uninstall s-memo. You really don't need it that bad. And if so use other notepad apps that have voice to text capability or use the aosp keyboard. Anything but s-memo

.:Sent from the Hellfire Galaxy of S & 3:.

Ummm thought you said above you didn't use s-memo so it's not just an s-memo problem or am I reading it incorrectly?

I've also just checked s-memo and can only see an option for syncing to Samsung account not Google?
 
Last edited:

Top Liked Posts

  • There are no posts matching your filters.
  • 5
    I was poking around my GS3 today (ATT version but running the Sprint Official JB release LJ7) and I found something pretty shocking. I was poking around the S-memo databases when I opened a table using SQLIte editior. When I opened the table I was shocked to see my Google account username and password in clear plain text. Now, I did have the option to sync to Google drive and the app did prompt for my google username and password so obviously it stores it somewhere. I was just shocked to see it stored in plain text and not encrypted.

    I know someone who checked his ATT GS3 running ICS and he did not have these entries in his DB which makes me think it's a JB thing.

    To check you need to be rooted and have SQLite editor installed.

    Steps to check
    1. Set up S-Memo to sync with your Google account
    2. Use SQLite editor and navigate to /data/data/com.sec.android.provider.smemo/databases
    3. Open the Pen_memo.db file and select the CommonSettings table. Look to see if your Google account info is stored in plain text.

    This could potentially be a serious issue. If people running JB on their GS3 can check this that would be awesome. Someone already checked the latest ICS build for the ATT variant but if others on ICS or with a different variant can check that would be great. I will get to check my GF's I-9300 running JB tomorrow when I see her.

    Also I'm not sure how app permissions work on android, meaning if one app could access the data/database of another app(without root, because obviously with root another app can, in this case SQLite opened the file). Since the DB is in the /data partition and the permissions are r/w by default I'm thinking it wouldn't be difficult for a malicious non root app to access this database and query it for the information unless there is something built into android that wont allow that.

    I have attached a SS of what my table looked like. Obviously I blacked out my PW and also the Google auth ID

    Screenshot_2012-11-09-19-50-34.png
    4
    Actually, while /data is available for you to browse, that is because you have root. It's RW but only within the packages that each app is sandboxed. If you disable root you will not be able to view that database.

    It is possible for the same developer to access the /data files of another one of their apps if they use the same namespace.

    So, while this is indeed a risk, it would not be trivial for another app to gain access without asking for root or cracking root itself.
    2
    This should probably use a token-based authentication system, rather than the ACTUAL google account username and password...

    Still not brilliant for security, but at least it's not your ACTUAL password in plaintext...