... all the apps on the Android Market get access permissions from
Android's built-in security, which is so flawed it can't stop applications
from improperly accessing data even when they don't intend to. So, if
Google gets rid of all the apps Android would allow to access data
improperly, it will be getting rid of all the apps.

"We need a more fine grained permission system on android,"
http://lwn.net/Articles/409230/

"Dr. Android and Mr. Hide: Fine-grained security policies on unmodified
Android," http://www.cs.umd.edu/~jfoster/papers/acplib.pdf

"The Effectiveness of Application Permissions,"
http://www.cs.berkeley.edu/~afelt/felt-permissions-webapps11.pdf

And last but not least (its alarming how permissions map to actions in
practice):

"Android Permissions Demystified,"
http://www.cs.berkeley.edu/~afelt/android_permissions.pdf

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

Search Discussions

  • Jeffrey Walton at Mar 8, 2012 at 11:57 pm

    On Sat, Mar 3, 2012 at 9:47 PM, Jeffrey Walton wrote:
    From http://www.itworld.com/security/255210/google-response-flaw-lets-apps-steal-photos-ditch-insecure-apps-thats-all-them:

    ... all the apps on the Android Market get access permissions from
    Android's built-in security, which is so flawed it can't stop applications
    from improperly accessing data even when they don't intend to. So, if
    Google gets rid of all the apps Android would allow to access data
    improperly, it will be getting rid of all the apps.

    "We need a more fine grained permission system on android,"
    http://lwn.net/Articles/409230/

    "Dr. Android and Mr. Hide: Fine-grained security policies on unmodified
    Android," http://www.cs.umd.edu/~jfoster/papers/acplib.pdf

    "The Effectiveness of Application Permissions,"
    http://www.cs.berkeley.edu/~afelt/felt-permissions-webapps11.pdf

    And last but not least (its alarming how permissions map to actions in
    practice):

    "Android Permissions Demystified,"
    http://www.cs.berkeley.edu/~afelt/android_permissions.pdf
    And this one is from Barbara Dizon, a social media manager (not an
    engineer!). "Company at centre of Android apps scare responds,"
    http://www.cbronline.com/blogs/cbr-rolling-blog/company-at-centre-of-android-apps-scare-responds-080312:

    "[Dizon] also suggested that the issue with capturing data is more to
    do with the way Android app permissions work, not with any
    functionality MobClix or Velti has added to apps. Android permissions
    often grant access to chunks of information rather than a single piece
    of data. Therefore, in some cases, apps that would like permission to
    access a single piece of data technically have access to other stuff
    because of Android's permission system," she wrote. "There is nothing
    we can do about that."

    --
    You received this message because you are subscribed to the Google Groups "Android Security Discussions" group.
    To post to this group, send email to android-security-discuss@googlegroups.com.
    To unsubscribe from this group, send email to android-security-discuss+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/android-security-discuss?hl=en.
  • Jeffrey Walton at Apr 12, 2012 at 9:25 pm

    On Sat, Mar 3, 2012 at 9:47 PM, Jeffrey Walton wrote:
    From http://www.itworld.com/security/255210/google-response-flaw-lets-apps-steal-photos-ditch-insecure-apps-thats-all-them:

    ... all the apps on the Android Market get access permissions from
    Android's built-in security, which is so flawed it can't stop applications
    from improperly accessing data even when they don't intend to. So, if
    Google gets rid of all the apps Android would allow to access data
    improperly, it will be getting rid of all the apps.

    "We need a more fine grained permission system on android,"
    http://lwn.net/Articles/409230/

    "Dr. Android and Mr. Hide: Fine-grained security policies on unmodified
    Android," http://www.cs.umd.edu/~jfoster/papers/acplib.pdf

    "The Effectiveness of Application Permissions,"
    http://www.cs.berkeley.edu/~afelt/felt-permissions-webapps11.pdf

    And last but not least (its alarming how permissions map to actions in
    practice):

    "Android Permissions Demystified,"
    http://www.cs.berkeley.edu/~afelt/android_permissions.pdf
    A new twist just arrived (or it looks new to me). An app with no
    permissions gets pseudo-READ_PHONE_STATE for free.

    ""No permissions" Android app allows secret data harvesting,"
    http://www.zdnet.com/blog/hardware/no-permissions-android-app-allows-secret-data-harvesting/19709

    Paul Brodeur, security researcher with Leviathan Security Group, has
    created a proof-of-concept app that shows how an Android application
    which doesn’t ask for any security permissions is still able to get
    access to data stored on SD cards, data stored on the handset by other
    apps, and information about the handset and handset’s Android ID.
    ...

    --
    You received this message because you are subscribed to the Google Groups "Android Security Discussions" group.
    To post to this group, send email to android-security-discuss@googlegroups.com.
    To unsubscribe from this group, send email to android-security-discuss+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/android-security-discuss?hl=en.
  • Tim at Apr 12, 2012 at 9:33 pm
    New twist to an old concept. It was actually already done about 2 years ago
    now;
    https://www.defcon.org/images/defcon-18/dc-18-presentations/Lineberry/DEFCON-18-Lineberry-Not-The-Permissions-You-Are-Looking-For.pdf

    And then again a few months back;
    https://viaforensics.com/security/nopermission-android-app-remote-shell.html

    It's interesting that people are making a fuss over the Android_ID though:
    << The Android ID could be used as a way to identify a specific handset. >>
    Especially since it is _meant_ to be used to identify a specific handset
    and not require extra permissions (like the IMEI/IMSI). This value is also
    changed on each factory reset of a device.

    -Tim Strazzere

    On Thu, Apr 12, 2012 at 2:25 PM, Jeffrey Walton wrote:
    On Sat, Mar 3, 2012 at 9:47 PM, Jeffrey Walton wrote:
    From
    http://www.itworld.com/security/255210/google-response-flaw-lets-apps-steal-photos-ditch-insecure-apps-thats-all-them
    :
    ... all the apps on the Android Market get access permissions from
    Android's built-in security, which is so flawed it can't stop
    applications
    from improperly accessing data even when they don't intend to. So, if
    Google gets rid of all the apps Android would allow to access data
    improperly, it will be getting rid of all the apps.

    "We need a more fine grained permission system on android,"
    http://lwn.net/Articles/409230/

    "Dr. Android and Mr. Hide: Fine-grained security policies on unmodified
    Android," http://www.cs.umd.edu/~jfoster/papers/acplib.pdf

    "The Effectiveness of Application Permissions,"
    http://www.cs.berkeley.edu/~afelt/felt-permissions-webapps11.pdf

    And last but not least (its alarming how permissions map to actions in
    practice):

    "Android Permissions Demystified,"
    http://www.cs.berkeley.edu/~afelt/android_permissions.pdf
    A new twist just arrived (or it looks new to me). An app with no
    permissions gets pseudo-READ_PHONE_STATE for free.

    ""No permissions" Android app allows secret data harvesting,"

    http://www.zdnet.com/blog/hardware/no-permissions-android-app-allows-secret-data-harvesting/19709

    Paul Brodeur, security researcher with Leviathan Security Group, has
    created a proof-of-concept app that shows how an Android application
    which doesn’t ask for any security permissions is still able to get
    access to data stored on SD cards, data stored on the handset by other
    apps, and information about the handset and handset’s Android ID.
    ...

    --
    You received this message because you are subscribed to the Google Groups
    "Android Security Discussions" group.
    To post to this group, send email to
    android-security-discuss@googlegroups.com.
    To unsubscribe from this group, send email to
    android-security-discuss+unsubscribe@googlegroups.com.
    For more options, visit this group at
    http://groups.google.com/group/android-security-discuss?hl=en.
    --
    You received this message because you are subscribed to the Google Groups "Android Security Discussions" group.
    To post to this group, send email to android-security-discuss@googlegroups.com.
    To unsubscribe from this group, send email to android-security-discuss+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/android-security-discuss?hl=en.
  • William Enck at Apr 13, 2012 at 2:45 pm
    Jeffrey,

    Please correct me if I'm wrong, but this article is a bunch of FUD.

    The article includes a link to the source code: http://leviathansecurity.com/blog/uploads/NoPermissions.zip

    The readIdentifiers() method in NoPermissionsActivity.java is calling:

    - TelephonyManager.getNetworkOperator(): "Returns the numeric name (MCC+MNC) of current registered operator." This is the Mobile Country Code (MCC) and Mobile Network Code (MNC), which is only going to say what country and cellular provider you are on (e.g., AT&T, T-Mobile). It's not very specific to a handset, and therefore a very low privacy risk.

    - TelephonyManager.getSimOperator(): "Returns the MCC+MNC (mobile country code + mobile network code) of the provider of the SIM."

    - Settings.Secure.ANDROID_ID: As Tim Strazzere indicated in his reply, this is readable without a permission *by design*. Note that the ANDROID_ID is different than IMEI/IMSI, because you can change it without purchasing a new handset.

    The readVersion() method is getting the value of /proc/version, which is the kernel version (not sensitive).

    The stealAppData() method gets the list of installed packages from /data/system/packages.list (also available from PackageManager.getInstalledPackages() without a permission). It then looks for app home directories that are readable (i.e., on the SDCard). The SDCard is well known to be insecure for storing information, and apps have to specify if they can be loaded to the SDCard, *and* the user has to move them there. As for access to the SDCard without a permission, see the next point.

    The stealSD() method goes through all the files in /sdcard and just sends a list of files. Android has no limitations on applications reading the contents of the SDCard. While this is a well known fact, there was another story recently about the concern over apps stealing photos that caused a lot of hype, and IIRC, Google responded that they are working on it. This fix is going to take some time due to legacy compatibility, but hopefully now that Android 3.0 and later connect to PCs using MTP and not a USB mass storage device, there's an opportunity to use file permissions on the SDCard. So yes, this is something that really needs to be fixed, but it's not a new finding (it's been the elephant in the room since day one of Android).

    The sendGzByBrowser() and sendByBrowser() just take the acquired information and include it in a URL passed to the Web Browser. This method of exfiltrating data is well known (Tim includes a link on implementing a root shell using this method).

    Thanks,
    -Will
    On Apr 12, 2012, at 5:25 PM, Jeffrey Walton wrote:
    A new twist just arrived (or it looks new to me). An app with no
    permissions gets pseudo-READ_PHONE_STATE for free.

    ""No permissions" Android app allows secret data harvesting,"
    http://www.zdnet.com/blog/hardware/no-permissions-android-app-allows-secret-data-harvesting/19709

    Paul Brodeur, security researcher with Leviathan Security Group, has
    created a proof-of-concept app that shows how an Android application
    which doesn’t ask for any security permissions is still able to get
    access to data stored on SD cards, data stored on the handset by other
    apps, and information about the handset and handset’s Android ID.
    ...


    --
    William Enck
    Assistant Professor
    Department of Computer Science
    North Carolina State University
    Email: enck@cs.ncsu.edu
    Web: http://www.enck.org

    --
    You received this message because you are subscribed to the Google Groups "Android Security Discussions" group.
    To post to this group, send email to android-security-discuss@googlegroups.com.
    To unsubscribe from this group, send email to android-security-discuss+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/android-security-discuss?hl=en.
  • William Enck at Apr 13, 2012 at 3:12 pm

    On Apr 13, 2012, at 10:45 AM, William Enck wrote:

    The sendGzByBrowser() and sendByBrowser() just take the acquired information and include it in a URL passed to the Web Browser. This method of exfiltrating data is well known (Tim includes a link on implementing a root shell using this method).

    Sorry, I meant a "remote" shell (https://viaforensics.com/security/nopermission-android-app-remote-shell.html).

    -Will

    --
    William Enck
    Assistant Professor
    Department of Computer Science
    North Carolina State University
    Email: enck@cs.ncsu.edu
    Web: http://www.enck.org

    --
    You received this message because you are subscribed to the Google Groups "Android Security Discussions" group.
    To post to this group, send email to android-security-discuss@googlegroups.com.
    To unsubscribe from this group, send email to android-security-discuss+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/android-security-discuss?hl=en.
  • Paul Brodeur at Apr 13, 2012 at 10:25 pm
    I think you're incorrect, the article isn't written as FUD. Some media
    outlets don't understand, and so they throw around titles like "Major
    Android Vulnerability" and similar garbage. The purpose and tone of the
    article is to document and inform. Yes, I agree, none of this is news to
    someone with intimate knowledge of the Android API, like the folks on this
    list.

    The fact that 2-way communication with the Internet is possible without
    INTERNET permission, and that it's been publicly discussed for 2 years, is
    exactly the type of thing that should have attention brought to it. Maybe
    the android.intent.category.BROWSABLE Intent should be restricted? Or maybe
    there should be a OPEN_BROWSER permission? However it's done in the future,
    I think the current situation is rather serious.

    Those who've read the Android documentation know that SD/External storage
    shouldn't be used for anything sensitive and that any app can read it.
    Great. But what about the millions of non-developer Android users? Do they
    know that a random app can access their backups, upload their pictures
    somewhere, etc.?

    FYI, stealAppData() actually looks in /data/data/<packagename> for readable
    data. The purpose of this was to find apps that use world-readable
    permission on their files, such as the Skype vulnerability linked in the
    article or the Lookout vulnerability from last year:
    http://blog.mylookout.com/look-11-001/ -- these are not Android OS
    vulnerabilities, they are vulnerabilities in apps that specifically go
    against the suggestions in the documentation. I don't think it's stated any
    differently in the article.


    Paul Brodeur

    On Friday, April 13, 2012 8:45:02 AM UTC-6, Will Enck wrote:

    Jeffrey,

    Please correct me if I'm wrong, but this article is a bunch of FUD.

    The article includes a link to the source code:
    http://leviathansecurity.com/blog/uploads/NoPermissions.zip

    The readIdentifiers() method in NoPermissionsActivity.java is calling:

    - TelephonyManager.getNetworkOperator(): "Returns the numeric name
    (MCC+MNC) of current registered operator." This is the Mobile Country Code
    (MCC) and Mobile Network Code (MNC), which is only going to say what
    country and cellular provider you are on (e.g., AT&T, T-Mobile). It's not
    very specific to a handset, and therefore a very low privacy risk.

    - TelephonyManager.getSimOperator(): "Returns the MCC+MNC (mobile country
    code + mobile network code) of the provider of the SIM."

    - Settings.Secure.ANDROID_ID: As Tim Strazzere indicated in his reply,
    this is readable without a permission *by design*. Note that the ANDROID_ID
    is different than IMEI/IMSI, because you can change it without purchasing a
    new handset.

    The readVersion() method is getting the value of /proc/version, which is
    the kernel version (not sensitive).

    The stealAppData() method gets the list of installed packages from
    /data/system/packages.list (also available from
    PackageManager.getInstalledPackages() without a permission). It then looks
    for app home directories that are readable (i.e., on the SDCard). The
    SDCard is well known to be insecure for storing information, and apps have
    to specify if they can be loaded to the SDCard, *and* the user has to move
    them there. As for access to the SDCard without a permission, see the next
    point.

    The stealSD() method goes through all the files in /sdcard and just sends
    a list of files. Android has no limitations on applications reading the
    contents of the SDCard. While this is a well known fact, there was another
    story recently about the concern over apps stealing photos that caused a
    lot of hype, and IIRC, Google responded that they are working on it. This
    fix is going to take some time due to legacy compatibility, but hopefully
    now that Android 3.0 and later connect to PCs using MTP and not a USB mass
    storage device, there's an opportunity to use file permissions on the
    SDCard. So yes, this is something that really needs to be fixed, but it's
    not a new finding (it's been the elephant in the room since day one of
    Android).

    The sendGzByBrowser() and sendByBrowser() just take the acquired
    information and include it in a URL passed to the Web Browser. This method
    of exfiltrating data is well known (Tim includes a link on implementing a
    root shell using this method).

    Thanks,
    -Will
    On Apr 12, 2012, at 5:25 PM, Jeffrey Walton wrote:
    A new twist just arrived (or it looks new to me). An app with no
    permissions gets pseudo-READ_PHONE_STATE for free.

    ""No permissions" Android app allows secret data harvesting,"
    http://www.zdnet.com/blog/hardware/no-permissions-android-app-allows-secret-data-harvesting/19709
    Paul Brodeur, security researcher with Leviathan Security Group, has
    created a proof-of-concept app that shows how an Android application
    which doesn’t ask for any security permissions is still able to get
    access to data stored on SD cards, data stored on the handset by other
    apps, and information about the handset and handset’s Android ID.
    ...
    --
    William Enck
    Assistant Professor
    Department of Computer Science
    North Carolina State University
    Email: enck@cs.ncsu.edu
    Web: http://www.enck.org


    On Friday, April 13, 2012 8:45:02 AM UTC-6, Will Enck wrote:

    Jeffrey,

    Please correct me if I'm wrong, but this article is a bunch of FUD.

    The article includes a link to the source code:
    http://leviathansecurity.com/blog/uploads/NoPermissions.zip

    The readIdentifiers() method in NoPermissionsActivity.java is calling:

    - TelephonyManager.getNetworkOperator(): "Returns the numeric name
    (MCC+MNC) of current registered operator." This is the Mobile Country Code
    (MCC) and Mobile Network Code (MNC), which is only going to say what
    country and cellular provider you are on (e.g., AT&T, T-Mobile). It's not
    very specific to a handset, and therefore a very low privacy risk.

    - TelephonyManager.getSimOperator(): "Returns the MCC+MNC (mobile country
    code + mobile network code) of the provider of the SIM."

    - Settings.Secure.ANDROID_ID: As Tim Strazzere indicated in his reply,
    this is readable without a permission *by design*. Note that the ANDROID_ID
    is different than IMEI/IMSI, because you can change it without purchasing a
    new handset.

    The readVersion() method is getting the value of /proc/version, which is
    the kernel version (not sensitive).

    The stealAppData() method gets the list of installed packages from
    /data/system/packages.list (also available from
    PackageManager.getInstalledPackages() without a permission). It then looks
    for app home directories that are readable (i.e., on the SDCard). The
    SDCard is well known to be insecure for storing information, and apps have
    to specify if they can be loaded to the SDCard, *and* the user has to move
    them there. As for access to the SDCard without a permission, see the next
    point.

    The stealSD() method goes through all the files in /sdcard and just sends
    a list of files. Android has no limitations on applications reading the
    contents of the SDCard. While this is a well known fact, there was another
    story recently about the concern over apps stealing photos that caused a
    lot of hype, and IIRC, Google responded that they are working on it. This
    fix is going to take some time due to legacy compatibility, but hopefully
    now that Android 3.0 and later connect to PCs using MTP and not a USB mass
    storage device, there's an opportunity to use file permissions on the
    SDCard. So yes, this is something that really needs to be fixed, but it's
    not a new finding (it's been the elephant in the room since day one of
    Android).

    The sendGzByBrowser() and sendByBrowser() just take the acquired
    information and include it in a URL passed to the Web Browser. This method
    of exfiltrating data is well known (Tim includes a link on implementing a
    root shell using this method).

    Thanks,
    -Will
    On Apr 12, 2012, at 5:25 PM, Jeffrey Walton wrote:
    A new twist just arrived (or it looks new to me). An app with no
    permissions gets pseudo-READ_PHONE_STATE for free.

    ""No permissions" Android app allows secret data harvesting,"
    http://www.zdnet.com/blog/hardware/no-permissions-android-app-allows-secret-data-harvesting/19709
    Paul Brodeur, security researcher with Leviathan Security Group, has
    created a proof-of-concept app that shows how an Android application
    which doesn’t ask for any security permissions is still able to get
    access to data stored on SD cards, data stored on the handset by other
    apps, and information about the handset and handset’s Android ID.
    ...
    --
    William Enck
    Assistant Professor
    Department of Computer Science
    North Carolina State University
    Email: enck@cs.ncsu.edu
    Web: http://www.enck.org
    --
    You received this message because you are subscribed to the Google Groups "Android Security Discussions" group.
    To view this discussion on the web visit https://groups.google.com/d/msg/android-security-discuss/-/TEjG-vIH_KcJ.
    To post to this group, send email to android-security-discuss@googlegroups.com.
    To unsubscribe from this group, send email to android-security-discuss+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/android-security-discuss?hl=en.
  • Kevin Chadwick at Apr 14, 2012 at 2:06 pm

    On Fri, 13 Apr 2012 15:05:21 -0700 (PDT) Paul Brodeur wrote:

    The purpose of this was to find apps that use world-readable
    permission on their files, such as the Skype vulnerability linked in the
    article or the Lookout vulnerability from last year:
    http://blog.mylookout.com/look-11-001/ -- these are not Android OS
    vulnerabilities, they are vulnerabilities in apps that specifically go
    against the suggestions in the documentation. I don't think it's stated any
    differently in the article.
    Does that include all apps that allow moving to the msdos filesystem
    sdcard? Maybe android should use some sort of RBAC as mandating a non
    dos filesystem like nexus uses looks troublesome to me for those who
    want to use the card directly.

    --
    You received this message because you are subscribed to the Google Groups "Android Security Discussions" group.
    To post to this group, send email to android-security-discuss@googlegroups.com.
    To unsubscribe from this group, send email to android-security-discuss+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/android-security-discuss?hl=en.
  • Paul Brodeur at May 11, 2012 at 7:54 pm
    I've posted a follow-up on my Zero-Permission Android findings.
    http://www.leviathansecurity.com/blog/archives/18-Zero-Permission-Android-Applications-part-2.html

    In that posting, I discuss a vulnerability in the ping binary as it exists
    in the 2.3 branch. The vulnerability is that ping can be executed without
    being in the "inet" or similar group. As such, an app with no permissions
    is able to have limited network access, capable of performing DNS lookups
    and sending ICMP Echo packets. As I mention in the blog post, this was
    patched in the 4.0 branch.

    My question to the folks on this list is whether this vulnerability was
    ever discussed, or if it was just silently patched.

    Further, am I correct in assuming that security vulnerabilities like this
    don't get backported? Considering that more than 90% of devices are running
    2.3.x or below (as of May 1, according to android.com), this seems like a
    terrible patch policy.

    --
    You received this message because you are subscribed to the Google Groups "Android Security Discussions" group.
    To view this discussion on the web visit https://groups.google.com/d/msg/android-security-discuss/-/xRcfTpG0MfAJ.
    To post to this group, send email to android-security-discuss@googlegroups.com.
    To unsubscribe from this group, send email to android-security-discuss+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/android-security-discuss?hl=en.
  • Kevin Chadwick at May 11, 2012 at 8:08 pm

    On Fri, 11 May 2012 12:54:01 -0700 (PDT) Paul Brodeur wrote:

    Further, am I correct in assuming that security vulnerabilities like this
    don't get backported? Considering that more than 90% of devices are running
    2.3.x or below (as of May 1, according to android.com), this seems like a
    terrible patch policy.
    Yeah Sony promised me fast updates when I bought. They changed that to
    Neo V and Neo by the end of April. Still not to be seen. I wonder if
    the 'tested' version will be unpatched.

    Makes me consider though not for long right now spending time I
    don't have rooting and modding!! I'd get a firewall atleast and maybe
    decent anti-theft as my Sister recently had happen. Might of caught the
    Bæstard.

    --
    You received this message because you are subscribed to the Google Groups "Android Security Discussions" group.
    To post to this group, send email to android-security-discuss@googlegroups.com.
    To unsubscribe from this group, send email to android-security-discuss+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/android-security-discuss?hl=en.
  • Jeffrey Walton at Apr 21, 2012 at 11:49 pm

    On Sat, Mar 3, 2012 at 9:47 PM, Jeffrey Walton wrote:
    From http://www.itworld.com/security/255210/google-response-flaw-lets-apps-steal-photos-ditch-insecure-apps-thats-all-them:

    ... all the apps on the Android Market get access permissions from
    Android's built-in security, which is so flawed it can't stop applications
    from improperly accessing data even when they don't intend to. So, if
    Google gets rid of all the apps Android would allow to access data
    improperly, it will be getting rid of all the apps.

    "We need a more fine grained permission system on android,"
    http://lwn.net/Articles/409230/

    "Dr. Android and Mr. Hide: Fine-grained security policies on unmodified
    Android," http://www.cs.umd.edu/~jfoster/papers/acplib.pdf

    "The Effectiveness of Application Permissions,"
    http://www.cs.berkeley.edu/~afelt/felt-permissions-webapps11.pdf

    And last but not least (its alarming how permissions map to actions in
    practice):

    "Android Permissions Demystified,"
    http://www.cs.berkeley.edu/~afelt/android_permissions.pdf
    Sometimes, we just need some permissions: "Proof-of-concept Android
    Trojan App Analyzes Motion Sensor Data to Determine Tapped Keys,"
    http://www.pcworld.com/businesscenter/article/254170/proofofconcept_android_trojan_app_analyzes_motion_sensor_data_to_determine_tapped_keys.html/

    "Accelerometer and orientation sensor data are not protected under
    Android's security model, and this means that they are exposed to any
    application, regardless of its permissions on the system, the research
    team said in a paper that was presented during the ACM Conference on
    Security and Privacy in Wireless and Mobile Networks on Tuesday."

    --
    You received this message because you are subscribed to the Google Groups "Android Security Discussions" group.
    To post to this group, send email to android-security-discuss@googlegroups.com.
    To unsubscribe from this group, send email to android-security-discuss+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/android-security-discuss?hl=en.
  • Jeffrey Walton at May 7, 2012 at 7:59 pm

    On Sat, Mar 3, 2012 at 9:47 PM, Jeffrey Walton wrote:
    From http://www.itworld.com/security/255210/google-response-flaw-lets-apps-steal-photos-ditch-insecure-apps-thats-all-them:

    ... all the apps on the Android Market get access permissions from
    Android's built-in security, which is so flawed it can't stop applications
    from improperly accessing data even when they don't intend to. So, if
    Google gets rid of all the apps Android would allow to access data
    improperly, it will be getting rid of all the apps.

    "We need a more fine grained permission system on android,"
    http://lwn.net/Articles/409230/

    "Dr. Android and Mr. Hide: Fine-grained security policies on unmodified
    Android," http://www.cs.umd.edu/~jfoster/papers/acplib.pdf

    "The Effectiveness of Application Permissions,"
    http://www.cs.berkeley.edu/~afelt/felt-permissions-webapps11.pdf

    And last but not least (its alarming how permissions map to actions in
    practice):

    "Android Permissions Demystified,"
    http://www.cs.berkeley.edu/~afelt/android_permissions.pdf
    http://techie-buzz.com/online-security/addressing-android-security.html

    Some people want to cut Google some slack, since the Android platform
    is relatively new. The security issues can be worked on and rectified.
    However, Android isn’t just failing at keeping developers from
    creating harmful apps, it’s also failing at controlling what
    permissions normal apps are acquiring. “No permission” apps have the
    ability to get access to things that have nothing to do with them. For
    example, the Facebook app has access to your text messages, even
    though it has nothing to do with them. An app may ask for ‘obvious’
    permission which it requires to work, but can secretly gain access to,
    something as off limits as your SD card. A user’s sensitive data can
    very easily make its way into someone else’s hands....

    --
    You received this message because you are subscribed to the Google Groups "Android Security Discussions" group.
    To post to this group, send email to android-security-discuss@googlegroups.com.
    To unsubscribe from this group, send email to android-security-discuss+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/android-security-discuss?hl=en.
  • Nikolay Elenkov at May 8, 2012 at 2:44 am
    Re-posting to group.


    ---------- Forwarded message ----------
    From: Nikolay Elenkov <nikolay.elenkov@gmail.com>
    Date: Tue, May 8, 2012 at 10:55 AM
    Subject: Re: [android-security-discuss] Re: Call for Action: Android Permissions
    To: noloader@gmail.com

    On Tue, May 8, 2012 at 4:58 AM, Jeffrey Walton wrote:


    http://techie-buzz.com/online-security/addressing-android-security.html
    No offence, but this article is complete BS. The author is not only clueless,
    but his 'writing' is severely lacking: how does listing a bunch of completely
    unrelated 'things' under nonsensical headings make an article?

    Facebook a 'no-permission' app? 'The system files of an Android'? Really?

    If you want to spread FUD, at least make sure it half-coherent before
    posting.

    --
    You received this message because you are subscribed to the Google Groups "Android Security Discussions" group.
    To post to this group, send email to android-security-discuss@googlegroups.com.
    To unsubscribe from this group, send email to android-security-discuss+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/android-security-discuss?hl=en.
  • Jeffrey Walton at May 8, 2012 at 4:10 am

    On Mon, May 7, 2012 at 9:56 PM, Nikolay Elenkov wrote:
    Re-posting to group.


    ---------- Forwarded message ----------
    From: Nikolay Elenkov <nikolay.elenkov@gmail.com>
    Date: Tue, May 8, 2012 at 10:55 AM
    Subject: Re: [android-security-discuss] Re: Call for Action: Android Permissions
    To: noloader@gmail.com

    On Tue, May 8, 2012 at 4:58 AM, Jeffrey Walton wrote:


    http://techie-buzz.com/online-security/addressing-android-security.html
    No offence, but this article is complete BS. The author is not only clueless,
    but his 'writing' is severely lacking: how does listing a bunch of completely
    unrelated 'things' under nonsensical headings make an article?

    Facebook a 'no-permission' app? 'The system files of an Android'? Really?

    If you want to spread FUD, at least make sure it half-coherent before
    posting.
    Android has a serious problem with their capabilities permissions (or
    lack thereof), not the UriPermissions. The problem is clearly chronic
    for consumers since Google is not evolving the platform for the
    security needs of the users. Perhaps Google's strategy is apply the
    Ostrich Algorithm - in which case Its not going to get better on its
    own.

    That the "author is clueless [sic]" speaks volumes to the breadth of
    the problem. Its sad when media managers and clueless tech reporters
    even realize there are issues, yet the security and architecture folks
    who are responsible for platform security allow the problem to fester.

    Its very unfortunate current users are asked to live with a
    model/granularity that is years old just so Google can provide
    backwards compatibility for dated APIs and applications. I personally
    don't like being sacrificed and store no personal information on the
    device. Business material is clearly out of the question.

    Its is also causing problems for many folks in the Enterprise,
    including the folks who have to try to secure the devices (speaking
    from experience). In fairness to Google, the company may want to be a
    "consumer electronics company" so that the Enterprise does not matter.
    This position is not new and has been used successfully by another
    popular player. Google's lack of an Enterprise management tool for
    centralized administration seems to point in this direction.

    Google's Market is quickly becoming like a Linux repository -
    hundreds/thousands of useless, broken, or insecure applications. And
    many of the apps are not to blame since Google controls the platform.

    Jeff

    --
    You received this message because you are subscribed to the Google Groups "Android Security Discussions" group.
    To post to this group, send email to android-security-discuss@googlegroups.com.
    To unsubscribe from this group, send email to android-security-discuss+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/android-security-discuss?hl=en.
  • Jeffrey Walton at May 27, 2012 at 7:20 pm

    On Sat, Mar 3, 2012 at 9:47 PM, Jeffrey Walton wrote:
    From http://www.itworld.com/security/255210/google-response-flaw-lets-apps-steal-photos-ditch-insecure-apps-thats-all-them:

    ... all the apps on the Android Market get access permissions from
    Android's built-in security, which is so flawed it can't stop applications
    from improperly accessing data even when they don't intend to. So, if
    Google gets rid of all the apps Android would allow to access data
    improperly, it will be getting rid of all the apps.

    "We need a more fine grained permission system on android,"
    http://lwn.net/Articles/409230/

    "Dr. Android and Mr. Hide: Fine-grained security policies on unmodified
    Android," http://www.cs.umd.edu/~jfoster/papers/acplib.pdf

    "The Effectiveness of Application Permissions,"
    http://www.cs.berkeley.edu/~afelt/felt-permissions-webapps11.pdf

    And last but not least (its alarming how permissions map to actions in
    practice):

    "Android Permissions Demystified,"
    http://www.cs.berkeley.edu/~afelt/android_permissions.pdf
    From "About the Android Security Key app and permissions,"
    http://www.swtor.com/community/showthread.php?t=466008. The OP does
    not realize this is a platform problem that Google refuses to fix.

    I'm not quite sure this is the place to post this,
    but I'm proper curious:

    I looked into installing the security key app last
    night as I'd like the extra layer of security. So I
    went to the Android store and looked it up.
    Pressed download. Being the paranoid person I
    am I looked over the permissions before installing.
    I'm glad I did.

    Why on Earth does the app need to read my phone
    state? That seems really, really invasive to be frank.
    I'd love to install it, but no way am I giving anyone
    access to my phone calls or the numbers in my phone
    book.

    Any chance of updating the permissions so it's not a
    Stasi app anymore?

    --
    You received this message because you are subscribed to the Google Groups "Android Security Discussions" group.
    To post to this group, send email to android-security-discuss@googlegroups.com.
    To unsubscribe from this group, send email to android-security-discuss+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/android-security-discuss?hl=en.
  • Jeffrey Walton at May 28, 2012 at 5:42 pm

    On Sat, Mar 3, 2012 at 9:47 PM, Jeffrey Walton wrote:
    From http://www.itworld.com/security/255210/google-response-flaw-lets-apps-steal-photos-ditch-insecure-apps-thats-all-them:

    ... all the apps on the Android Market get access permissions from
    Android's built-in security, which is so flawed it can't stop applications
    from improperly accessing data even when they don't intend to. So, if
    Google gets rid of all the apps Android would allow to access data
    improperly, it will be getting rid of all the apps.

    "We need a more fine grained permission system on android,"
    http://lwn.net/Articles/409230/

    "Dr. Android and Mr. Hide: Fine-grained security policies on unmodified
    Android," http://www.cs.umd.edu/~jfoster/papers/acplib.pdf

    "The Effectiveness of Application Permissions,"
    http://www.cs.berkeley.edu/~afelt/felt-permissions-webapps11.pdf

    And last but not least (its alarming how permissions map to actions in
    practice):

    "Android Permissions Demystified,"
    http://www.cs.berkeley.edu/~afelt/android_permissions.pdf
    "Angry Birds Malware Sparks $78,000 Fine,"
    http://www.informationweek.com/news/security/mobile/240000966

    ...
    According to Lookout, the RuFraud application scam targeted
    people in 18 countries, including not just Britain, but also France,
    Germany, Israel, Latvia, Poland, and Russia, although not the
    United States. But it's unclear how many people in the other 17
    targeted countries may have been affected by the malware.

    "It was very clever, it picked up on the correct country code based
    on which type of SIM card was in the phone," said the PhonepayPlus
    spokesman. He said his agency had informed other countries about
    the results of its investigation.

    I believe the fraudulant software implicates READ_PHONE_STATE

    --
    You received this message because you are subscribed to the Google Groups "Android Security Discussions" group.
    To post to this group, send email to android-security-discuss@googlegroups.com.
    To unsubscribe from this group, send email to android-security-discuss+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/android-security-discuss?hl=en.
  • Jeffrey Walton at Jun 29, 2012 at 11:21 pm

    On Sat, Mar 3, 2012 at 9:47 PM, Jeffrey Walton wrote:
    From http://www.itworld.com/security/255210/google-response-flaw-lets-apps-steal-photos-ditch-insecure-apps-thats-all-them:

    ... all the apps on the Android Market get access permissions from
    Android's built-in security, which is so flawed it can't stop applications
    from improperly accessing data even when they don't intend to. So, if
    Google gets rid of all the apps Android would allow to access data
    improperly, it will be getting rid of all the apps.

    "We need a more fine grained permission system on android,"
    http://lwn.net/Articles/409230/

    "Dr. Android and Mr. Hide: Fine-grained security policies on unmodified
    Android," http://www.cs.umd.edu/~jfoster/papers/acplib.pdf

    "The Effectiveness of Application Permissions,"
    http://www.cs.berkeley.edu/~afelt/felt-permissions-webapps11.pdf

    And last but not least (its alarming how permissions map to actions in
    practice):

    "Android Permissions Demystified,"
    http://www.cs.berkeley.edu/~afelt/android_permissions.pdf
    "Fake Android Anti-Virus Records Calls, Steals Info,"
    http://www.securitynewsdaily.com/1987-fake-android-anti-virus.html.

    Looking at Symantec's analysis
    (http://www.symantec.com/security_response/writeup.jsp?docid=2012-060514-1301-99&tabid=2),
    it looks like READ_PHONE_STATE is complicit again.

    To be fair, this app asked for the world and some users agreed. Taking
    READ_PHONE_STATE away (or decomposing its permissions) would have only
    lessened the impact.

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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupandroid-security-discuss @
categoriesandroid
postedMar 4, '12 at 2:47a
activeJun 29, '12 at 11:21p
posts17
users6
websiteandroid.com

People

Translate

site design / logo © 2019 Grokbase