EU should not require sharing unpatched vulnerabilities

Sun, 11 Jun 2023 00:00:00 +0000

We, the undersigned organisations, write to express our concern with vulnerability disclosure requirements under the proposed Cyber Resilience Act (CRA). The CRA’s objective to encourage software publishers to patch vulnerabilities and report cyber incidents is salutary. However, the CRA’s mandatory disclosure of unmitigated vulnerabilities will undermine the security of digital products and the individuals who use them.

The CRA would require organisations to disclose software vulnerabilities to government agencies within 24 hours of exploitation (Cyber Resilience Act, Articles 11.1, 13.6, 14.4). However, such recently exploited vulnerabilities are unlikely to be mitigated within such a short time, leading to real-time databases of software with unmitigated vulnerabilities in the possession of potentially dozens of government agencies. The more this kind of information is spread, the more likely it is to be misused for state intelligence or offensive purposes, or to be inadvertently exposed to adversaries before a mitigation is in place. In addition, laws that require disclosure of unmitigated vulnerabilities to government agencies create an international precedent that may be reflected by other countries.

We call on you to help improve the CRA by including safeguards that help prevent misuse of vulnerability information:

Limit details. The regulation should not require disclosure of technical details of unmitigated vulnerabilities to government bodies that would enable another party to reconstruct the vulnerability or develop code to exploit it.
Prohibit offensive uses. The regulation should include a clear restriction on the use of software vulnerabilities by public bodies, i.e. for intelligence, surveillance, or offensive purposes.
Provide time to mitigate. In the absence of user harm or a substantial incident, organisations should have a reasonable time to remediate or address the vulnerability before requiring disclosure of its details to governments. A typical standard period for the mitigation of known vulnerabilities is 90 days.
Secure vulnerability information. Agencies should be obligated to protect vulnerability information with robust security safeguards and shared only on a very strict need-to-know basis.
Protect good faith security researchers. The regulation should distinguish between vulnerabilities discovered in good faith for defensive purposes and those that are exploited by malicious actors. Good faith security researchers who follow coordinated vulnerability disclosure standards should be protected from retaliation.

We share the goal of strengthening the security of digital products and protecting individuals. The above safeguards will help the CRA achieve its goals of a more resilient and protective technology ecosystem. We appreciate your consideration of our recommendations.

original PDF with all signers

IOCipher is the antidote to “Man-in-the-Disk” attack

Fri, 17 Aug 2018 16:56:00 -0400

Recently, at DEFCON 2018, researchers at Check Point announced a new kind of attack made possible by the way many Android apps are implemented. In summary, developers use the shared external storage space in an unsafe manner, by not taking into consideration that other apps also have read and write access to the same space. A malicious app can modify data used by another app, as a vector for compromising that app, causing it to be compromised or crash.

While Google does provide guidelines on safe external storage use, most developers ignore them. Here is what they say:

“Perform input validation when handling data from external storage”
“Do not store executables or class files on External Storage”
“External Storage files should be signed and cryptographically verified prior to dynamic loading”

This is most likely due to lack of time or knowledge…. and, that is where our IOCipher encrypted virtual filesystem library for Android comes in!

IOCipher provides a virtual encrypted disk for Android apps without requiring the device to be rooted. It uses a clone of the standard java.io API for working with files, so developers already know how to use it. Only password handling, and opening the virtual disk are what stand between the developer and working encrypted file storage. It is based on and SQLCipher, and designed to work with CacheWord for handling the keys and passwords.

Regarding the three guidelines from Google, by storing downloaded data into an IOCipher virtual volume, you both benefit from the use of external storage, while ensuring, thanks to cryptography, that your data or executable code has not been read or modified by another application. If a malicious application tries to access or modify the encrypted volume, it will be detected and not able to load, without causing a crash in the application.

You can find IOCipher on Github today (and likely get it implemented in your app today, as well!)

https://github.com/guardianproject/IOCipher

Vulnerability on Guardian Project

EU should not require sharing unpatched vulnerabilities

IOCipher is the antidote to “Man-in-the-Disk” attack