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: 2) by maxwell demon on Tuesday September 12 2017, @08:07PM (1 child)

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

    Code sharing doesn't lead to privilege escalation. On a normal Linux system, the user binaries share the complete C library (and quite a few others) with services running as root, without allowing me to gain root privileges that way.

    But if the library's only purpose (or one of its undocumented purposes) is to cache data accessed by your address book app (for speed - say), and surreptitiously pass that data to some other app the next time that app makes an innocuous library call, it gets fairly difficult to detect this.

    But that is completely unrelated to dynamic linking. Passing data that way requires data memory sharing, not code memory sharing.

    --
    The Tao of math: The numbers you can count are not the real numbers.
    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 2) by frojack on Tuesday September 12 2017, @10:55PM

    by frojack (1554) on Tuesday September 12 2017, @10:55PM (#566996) Journal

    Passing data that way requires data memory sharing, not code memory sharing.

    Which suggests the hand wringing worry about detecting this new attack vector may be overwrought, and this is not an un solvable problem. You would have to look for data writes to on-device locations that might be accessible to multiple libraries.

    There can be several mechanism whereby something is written by one library in a place the other library knows how to get at it. That place could be somewhere in memory on the device, or somewhere on the internet. TFA suggests multiple separate apps each having one or more privileges that can be combined to steal information. But these actions don't have to happen all at the same time, nor have data stored all on the same device, or even on the same remote mother-ship spy site. You could use meaningless file names, hidden files, or simply open unix sockets (or internet sockets) and pass data that way.

    Then you sit back and wait for joe user to install the second, or third, app, until you have assembled your entire attack vector out of pieces and parts.

    --
    No, you are mistaken. I've always had this sig.