New weaknesses regarding 3rd party libs #11
Conversation
|
As discussed: it relates in a way but the New weaknesses could be something like "Dependencies Known to be Malicious". It could leverage the SBOM (from the dev side or from binary analysis) and consult a malware DB. |
Updated title and description for clarity and specificity regarding malicious libraries leaking sensitive data. Adjusted profiles and added mention of SBOM checks.
|
@cpholguera and @sushi2k I rewrote these WE placeholders. I rewrote WE-xxxB to given feedback. Let me know if should consolidate WE-xxxA with some other WE, so far I didn't something relevant, therefore I suggest we add it. Check updated description above |
| masvs-v2: [MASVS-PLATFORM-3, MASVS-STORAGE-2] | ||
| cwe: [200, 359] | ||
| draft: | ||
| description: Embedded third-party libraries known to be malicious can leak sensitive data to external services. These libraries have access to e.g. ApplicationContext on Android or the full app memory on iOS. This gives them access to read data stored on the disk or in memory and thus could act as an insider threat within the app's process and boundaries. Apply supply chain security best practices to ensure the integrity of embedded libraries such as SBOM checks. |
There was a problem hiding this comment.
The fact that the library/SDK is malicious should be irrelevant as weaknesses are generic. The focus here should be put on the fact that the app includes libraries/SDKs already known to be malicious. Regardless of what exactly they do. Those "bad" things they do should be all covered by other weaknesses.
There was a problem hiding this comment.
Fair. I rewrote the the placeholder with that in mind. I also found existing
https://mas.owasp.org/MASWE/MASVS-CODE/MASWE-0076/ which targets Vulnerabilities in libraries. Therefore we could add this new WE or consider expanding existing WE-0076 as impact and mitigations (in a brief look) are close if not similar
There was a problem hiding this comment.
This reads more like an attack pattern than a weakness e.g: "CAPEC-533: Malicious Manual Software Update". What is the weakness that causes someone to use dependencies known to be malicious? I think the weakness we are looking for is something along the lines of "CWE-494: Download of Code Without Integrity Check", or "CWE-1395: Dependency on Vulnerable Third-Party Component", but rewritten in a mobile context. These should, however, already be covered by MASWE-0076.
There was a problem hiding this comment.
Should this instead be something like:
Embedded Malicious Code? https://cwe.mitre.org/data/definitions/506.html
The malicious code doesn't necessarily need to be part of dependencies. It could, as you say, be an insider.
| platform: [android, ios] | ||
| profiles: [L1,L2] | ||
| mappings: | ||
| masvs-v2: [MASVS-PLATFORM-3, MASVS-STORAGE-2] |
There was a problem hiding this comment.
updated to CODE-3, which was the closest to this group. Also updated the CWE.
let me know if we should keep this L1, L2 or R should also be considered
Co-authored-by: Carlos Holguera <perezholguera@gmail.com>
3 participants
Description
Adds 2 new WE placeholders regarding 3rd party libraries. I could not find any similar WE.
Explanation: this weakness uses the same logic there is in WE-53, WE-54, WE-55. See https://mas.owasp.org/MASWE/#q:sensitive%20data%20leaked
This currently focuses on P but can be rescoped.