Towards new release 0.25.0 about opensc HOT 8 OPEN

Hi, @alt3r-3go , great to hear! We will update the table once we have created a release candidate. When that is done, you can extend the wiki (and the test result page) by making a pull request here https://github.com/OpenSC/Wiki

from opensc.

This one seems noteworthy for the upcoming release, because the 6d1fcd9 was part of 0.24.0. However, it can only be triggered by a malicious card and during modification of the card. If we want to allocate a CVE for this, we could use the description of CVE-2023-40661 as template.

Here is the draft of the CVE:

Memory use after free in AuthentIC driver when updating token info

The Use After Free vulnerability was identified within the AuthentIC driver in OpenSC packages, particularly in the card enrollment process using pkcs15-init when a user or administrator enrolls or modifies cards. An attacker must have physical access to the computer system to take advantage of this flaw. The attack requires a crafted USB device or smart card to present the system with specially crafted responses to the APDUs, which are considered high complexity and low severity. This manipulation can potentially allow for compromising card management operations during enrollment.

References

• https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=64898
  • fixed with 5835f0d

from opensc.

please also pick up the code signing of the Windows installer in the changelog (#2799)

from opensc.

The release candidate 1 is out now https://github.com/OpenSC/OpenSC/releases/tag/0.25.0-rc1.

We would appreciate further testing of rc1 (https://github.com/OpenSC/OpenSC/wiki/Smart-Card-Release-Testing); results can be added as PR to https://github.com/OpenSC/Wiki or shared as a comment on this issue.

from opensc.

Regarding the security relevant bugs reported by OSS-Fuzz, there are two issues

• https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=65684
  • fixed with c354501
• https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=64898
  • fixed with 5835f0d

but they are both fixing previously reported and fixed fuzzing issues .

From Coverity high impact issues, there are only problems connected to unit tests for PKCS#1 v1.5 depadding, fixed by #3016.

from opensc.

Thanks for the summary, looks good so far!

Regarding the security relevant bugs reported by OSS-Fuzz, there are two issues

* https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=65684
  
  * fixed with [c354501](https://github.com/OpenSC/OpenSC/commit/c3545018d059b4debde33b9f34de719dd41e5531)

If I understand correctly, then the original issue was a loss of memory. Since the use after free was not part of any release version, I'd rather fall back to the severity of the old issue (loss of memory, not security relevant)

* https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=64898
  
  * fixed with [5835f0d](https://github.com/OpenSC/OpenSC/commit/5835f0d4f6c033bd58806d33fa546908d39825c9)

This one seems noteworthy for the upcoming release, because the 6d1fcd9 was part of 0.24.0. However, it can only be triggered by a malicious card and during modification of the card. If we want to allocate a CVE for this, we could use the description of CVE-2023-40661 as template.

from opensc.

I'd like to contribute to this release (and hopefully future ones!) by testing it with my Nitrokey Start and Pro tokens and updating the Release Testing wiki page accordingly. Hopefully that's useful :)

I have a quick question though - I don't see any tags for 0.25 yet, should I wait for one, or just go ahead with a build off of master? Both tokens are OpenPGP, so based on the list above all the changes potentially touching that part are already in (as far as I understand, anyway - please let me know if I'm missing anything), but I wonder if I'd better wait for the "official" tag so that the test is more relevant.

from opensc.

• https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=64898

This one seems noteworthy for the upcoming release, because the 6d1fcd9 was part of 0.24.0.

The UAF could happen only, when the sc_get_challenge() would return value 0 / SC_SUCCESS, which would get through the condition if (!rv) {, but not through the condition if (_ret < 0) { to return.

So I agree that it would make sense to get the CVE for this (with low priority as it only affects the enrollment).

from opensc.