Hash Generated Using Broken Cryptography API (SHA1)

[JayP2405]

Hash Generated Using Broken Cryptography API (SHA1)

Severity: Medium
Exploitability: Difficult
CVSS: 4.0

The following code locations within the App use 'CC_SHA1' or 'CryptoKit.Insecure.SHA1' functions to generate a message digest:
-[RNFSManager hash:algorithm:resolver:rejecter:] calls _CC_SHA1()

The vulnerable code locations use the 'CC_SHA1' or 'CryptoKit.Insecure.SHA1' hashing functions, which leverage hashing algorithms that are proven to be vulnerable to collision attacks, and are unsuitable for modern use.

Apple officially considers this algorithm insecure. They state in iOS 13 CryptoKit documentation:

This hash algorithm isn't considered cryptographically secure, but is provided for backward compatibility with older services that require it. For new services, prefer one of the secure hashes, like SHA512.

Recommendation:
Switch each usage of these outdated hashing functions to use a stronger algorithm with better collision resistance properties, such as SHA-256 or SHA-512.

Stack Trace:
The following related source code symbols were identified:

- [RNFSManager read:length:position:resolver:rejecter:]
- [RNFSManager __rct_export__3009]
- [RNFSManager readFile:resolver:rejecter:]
@"EISDIR: illegal operation on a directory, read"
@"ENOENT: no such file or directory, open '%@'"
@"Invalid hash algorithm '%@'"

Analysis:
On tracking, found the vulnerable codes inside RNFSManager.m file.

[JayP2405]

Can someone please help on this.!!?
@itinance @birdofpreyru

[birdofpreyru]

@JayP2405 well, my up-to-date fork of the library has its own repo — https://github.com/birdofpreyru/react-native-fs

I am also not sure if this is really an issue. I know, SHA1 is not crypto-secure; but as far as a file-system library is concerned — if for whatever reason the library consumer needs to calculate a SHA1 hash of a file, the library provides him a function to get it. I believe, it does not use it for anything else.

[JayP2405]

@birdofpreyru I checked the up-to-date fork of the library & it also contains the same piece of code.
I understood the proposed usecase of this code. Thanks for explaining that :)

But can there be a way to just remove these vulnerable hashing algorithms.??

I am new to understand these concepts, but my project security team is asking to remove these codes, as it can be a store release blocker anytime soon.

[birdofpreyru]

I don't know — I last released an update of my iOS app, relying on this lib, yesterday... and had no problems with it passing Apple review process. I doubt Apple will ban MD5 / SHA1 hash functions, as they routinely used as checksums, that do not have to be crypto-secure. Your project's security team just does not understand security and blindly follows whatever a security scanner tells them — exactly the sort of people who create bizarre security holes :D

In the end of day, you may use patch-package to patch the library in-place, removing code pieces that trigger security scanner; as I said, I don't see a reason to remove them from the library for everybody.