Stories
Slash Boxes
Comments

SoylentNews is people

posted by Fnord666 on Tuesday September 12 2017, @03:44PM   Printer-friendly
from the you-wash-my-back... dept.

Submitted via IRC for SoyCow1937

A team of Oxford and Cambridge researchers is the latest to join a chorus of voices sounding the alarm on a new attack vector named Intra-Library Collusion (ILC) that could make identifying Android malware much harder in the upcoming future.

The research team has described the ILC attack vector in a research paper released last month and named "Intra-Library Collusion: A Potential Privacy Nightmare on Smartphones."

An ILC attack relies on threat actors using libraries to deliver malicious code, instead of standalone Android apps packed with all the malicious commands.

Apps usually require permissions for all the operations they need to perform. An ILC attack relies on spreading the malicious actions across several apps that use the same library(ies).

Each app gets different permissions, and malicious code packed in one app could use shared code from other apps — with higher privileges — to carry out malicious operations.

The advantage — for malware authors — is that investigators analyzing a compromised devices would see the breadth of malicious activities, but would exclude certain apps as the infection's source because they do not possess all the permissions needed to execute the attack.

Source: https://www.bleepingcomputer.com/news/security/intra-library-collusion-attacks-open-the-door-for-a-whole-new-kind-of-android-malware/


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 1, Informative) by Anonymous Coward on Tuesday September 12 2017, @04:17PM (13 children)

    by Anonymous Coward on Tuesday September 12 2017, @04:17PM (#566804)

    It doesn't sound like a problem related to dynamic linking.

    The issue seems to be that some forms of library calls on android can cross privilege boundaries, allowing an app with less privileges to call functions in a library with more privileges, and the library operations work with elevated privileges. This seems like a broken by design security model.

    Libraries (dynamic or otherwise) on normal operating systems don't work this way.

    Starting Score:    0  points
    Moderation   +1  
       Informative=1, Total=1
    Extra 'Informative' Modifier   0  

    Total Score:   1  
  • (Score: 1, Interesting) by Anonymous Coward on Tuesday September 12 2017, @04:32PM

    by Anonymous Coward on Tuesday September 12 2017, @04:32PM (#566815)

    How can it be that a multi-billion-dollar organization that employs for Big Bucks almost exclusively the creme-de-la-creme of the intelligentsia can produce such obvious flaws? HOW?!

    I've spent much time around those "smart" people; they're not that smart—or, perhaps more accurately: They don't give a fuck; it doesn't tickle them to make something well, but rather it tickles them to make other people feel that they've made something well, especially for money. It's all junk.

  • (Score: 2, Interesting) by Anonymous Coward on Tuesday September 12 2017, @04:33PM (10 children)

    by Anonymous Coward on Tuesday September 12 2017, @04:33PM (#566819)

    It doesn't sound like a problem related to dynamic linking.

    But it *is* related to dynamic linking. It's because the library is used by app A which has permission set P1 as well as app B which has permission set P2, thus giving the library L the permission set (P1 + P2). *that* is exactly the problem.

    Libraries (dynamic or otherwise) on normal operating systems don't work this way.

    You're right on spot there... "on NORMAL operating systems"...

    • (Score: 2) by Runaway1956 on Tuesday September 12 2017, @05:01PM (8 children)

      by Runaway1956 (2926) Subscriber Badge on Tuesday September 12 2017, @05:01PM (#566843) Journal

      So - I'm thinking - on a multiuser system, it's the user, not the app, that is assigned permissions. Super User and/or Root have all these magical permissions, while, I, a mere user, am restricted in many ways. SU uses some of the same libraries that I use, sometimes, even at the same time. But the system doesn't get confused, and grant me SU powers because we are using the same libraries.

      Trying to assign permissions to libraries seems a damned half assed way to address security issues. Did they just take all of Microsoft's worst ideas, and try to make them even worse?

      How about we all just decide NOT to install random apps, published by unknown, faceless people, about whom we know NOTHING.

      Oh hell, that's just to simple a solution. Everyone needs bling on their little electronic screen.

      • (Score: 2, Funny) by fustakrakich on Tuesday September 12 2017, @05:12PM

        by fustakrakich (6150) on Tuesday September 12 2017, @05:12PM (#566852) Journal

        Everyone needs bling on their little electronic screen.

        Well, the weather apps are nice, if they could predict the weather...

        And the need for Solitaire? I would hope that goes without mentioning...

        --
        La politica e i criminali sono la stessa cosa..
      • (Score: 1, Touché) by Anonymous Coward on Tuesday September 12 2017, @05:15PM

        by Anonymous Coward on Tuesday September 12 2017, @05:15PM (#566855)

        >So - I'm thinking - on a multiuser system, it's the user, not the app, that is assigned permissions.

        But on mobile, user is the product, while app distributors are customers. A different ownership model.

      • (Score: 5, Funny) by DannyB on Tuesday September 12 2017, @05:45PM

        by DannyB (5839) Subscriber Badge on Tuesday September 12 2017, @05:45PM (#566872) Journal

        Did they just take all of Microsoft's worst ideas, and try to make them even worse?

        That would be unwise indeed. Microsoft patented all of its worst ideas. Taking them, let alone modifying them, would surely invite a patent infringement lawsuit.

        --
        People today are educated enough to repeat what they are taught but not to question what they are taught.
      • (Score: 0) by Anonymous Coward on Tuesday September 12 2017, @05:54PM (3 children)

        by Anonymous Coward on Tuesday September 12 2017, @05:54PM (#566875)

        Trying to assign permissions to libraries seems a damned half assed way to address security issues.

        Take a look at the sudo binary. It's got the setuid flag set and is owned by root. This is why, when you sudo something, whatever you run, runs as root. Sudo just validates a password and if successful, runs the binary you tell it to run in its own context (i.e. as user 0 - root)

        • (Score: 0) by Anonymous Coward on Tuesday September 12 2017, @07:40PM

          by Anonymous Coward on Tuesday September 12 2017, @07:40PM (#566934)

          And them what?

        • (Score: 2) by maxwell demon on Tuesday September 12 2017, @08:00PM (1 child)

          by maxwell demon (1608) on Tuesday September 12 2017, @08:00PM (#566941) Journal

          That's not a library.

          --
          The Tao of math: The numbers you can count are not the real numbers.
          • (Score: 0) by Anonymous Coward on Wednesday September 13 2017, @01:53AM

            by Anonymous Coward on Wednesday September 13 2017, @01:53AM (#567045)

            Indeed, but it is permissions assigned to code, as opposed to the thing that invokes the code.

      • (Score: 2) by Nerdfest on Tuesday September 12 2017, @05:54PM

        by Nerdfest (80) on Tuesday September 12 2017, @05:54PM (#566876)

        They do assign permissions based on user, but every app has a different userid. Not sure how this works, or whether it's just a bug or a serious architectural failing.

    • (Score: 0) by Anonymous Coward on Tuesday September 12 2017, @05:57PM

      by Anonymous Coward on Tuesday September 12 2017, @05:57PM (#566879)

      The terminology seems to be messing up our understanding. Since libraries work one way on normal operating systems, and another way on Android.

      On a *normal* os, dynamic linking loads library code into the process's memory space and runs with its privileges. Or, it stays within privilege boundaries.

      On "android", dynamic linking is another form of IPC sending unregulated data to some "library"? It crosses privilege boundaries?

      Using "dynamic linking" or just a "library" on andoid seems like a different thing. It should probably have its own terminology since those words don't seem to mean what we think they do. (in the context of Android.)

  • (Score: 1, Interesting) by Anonymous Coward on Tuesday September 12 2017, @04:43PM

    by Anonymous Coward on Tuesday September 12 2017, @04:43PM (#566829)

    This.

    It's not the linking that's the problem, its the uncontrolled communication channel between the app with privileges to read the private data and the app with privileges to expatriate it. This hack goes through an extra library, but it could go through any superstitiously shared memory area - photo metadata or anything else that sounds innocent enough.