Results from the bug bounty programme, update 31 December 2022
For its e-voting solution, SwissPost is running a public bug bounty program. On 28 September 2022 we made the last update.
Since then, the hunters submitted 7 reports:
- 2 reports concern cryptography-related issues in the cryptographic protocol and its specification.
- 5 reports concern source-code issues. They highlighted meaningful improvements in the source code.
SwissPost and YwH did not accept 3 reports since they could not be reproduced or did not identify a vulnerability and 3 reports are still under review. Triaging reports is a standard process in bug bounty programs and we took decisions together with our partner YesWeHack.
In total, SwissPost paid out since the last update €6’400 EUR.- rewards to the hunters who submitted the reports.
Cryptography-related issues
YWH-ID | Title | Description | Status | CVSS-severity |
---|---|---|---|---|
#YWH-PGM2323-105 | Feedback to Computational Proofs | Florian Moser suggested improvements to the presentation of the computational proof, highlighted issues with the definitions and the security analysis in the proof, and elaborated on ideas for future protocol versions. _Identified thanks to Florian Moser (famoser) _ |
We appreciate the constructive feedback on the computational proof as it improves the clarity and robustness of our security analysis. While it does not reveal a specific attack, the suggestions are still valuable and incorporating them in the computational proofs increases the confidence and validity of the analysis. The propositions are documented in this Gitlab issue. Many suggestions were implemented in version 1.1.0 of the computational proof while some changes will be addressed in a future redesign of the protocol. |
Medium |
#YWH-PGM2323-104 | Improve inconsistent naming of Return Choice Codes & Vote Cast Return Code | The naming conventions for the Choice Return Codes and Vote Cast Return Code variables are somewhat inconsistent, making it difficult to understand the protocol. Identified thanks to Florian Moser (famoser)
|
We accept this report and will consider the suggestions for improving variable naming in future versions of the protocol. The propositions are documented in this Gitlab issue. Many suggestions were implemented in version 1.1.0 of the computational proof while some changes will be addressed in a future redesign of the protocol. |
Low |
Source-code-related issues
YWH-ID | Title | Description | Status | CVSS-severity |
---|---|---|---|---|
#YWH-PGM2323-102 | Verifier - Consistency check for Number of Voters is prone to an integer overflow | According to the Verifier Specification, one of the consistency checks during the Setup phase is the following: _Verification Card IDs, in particular, that all verification card sets contain the expected number of voters._ As Java's 'sum()' does not provide any protection against Integer Overflows, it is possible to build a 'electionEventContextPayload.json' containing a specially crafted list of 'numberOfVotingCards' that wraps around. This integer overflow scenario may result in successfully passing the consistency check although independently, the Voting Card Set's 'numberOfVotingCards' is not consistent. Obviously, an attack where such a large number of voting cards are generated is not practical. However, it would be preferable to prevent such an integer overflow from occurring. Identified thanks to Ruben Santamarta (reversemode)
|
We addressed the report and replaced .sum() by .reduce(0, Math::addExact) on streams. This issue has been corrected in release evoting 1.2 & verifier 1.3. Here is the direct link to the commit evoting. Here is the direct link to the commit verifier. |
Low |
#YWH-PGM2323-98 | Create useless object | The class VoteResource creates an object named 'gson'. However, this object is never utilized in any subsequent operations resulting in an unnecessary allocation of memory resources. It is suggested that the object gson be removed or refactored for proper use to avoid wasting memory resources. | The unused object does not have a security impact. Nevertheless, we are going to remove the unused object in the next version. |
Medium |
#YWH-PGM2323-97 | SchemaFactory allows external DTDs | When the class XmlSigner parses xml, it doesn't have a safeguard to prevent external DTD. This can create a security vulnerability known as XXE. While there is no concrete attack scenario, these types of attacks are prevented as a best practice. This can be remedied by adding an extra step to disable external DTD when parsing xml. |
We deactivated external schemas in release evoting 1.2 and will add additional defenses against XXE attacks in release 1.3. Here is a direct link to the commit. |
Medium |
#YWH-PGM2323-96 | Incomplete consistency check when persisting votes in the control components. | Before calculating return codes, the control components do not check that the different identifiers are consistent (for instance that a verification card ID belongs to the expected verification card set ID). While this does not lead to an exploitable attack since other immutability checks on the database level are in place, it would still be a good practice to check the consistency of the identifiers before processing the vote. Identified thanks to Ruben Santamarta (reversemode)
|
We will improve the input validation as described in this report, we currently do not see any concrete attack from the observations described in this report. This issue has been corrected in release evoting 1.2 Here is the direct link to the commit. |
Low |
#YWH-PGM2323-95 | Object Model Violation: Just One of Equals and Hashcode Defined | Class DerivedKeyCache has a method that compares two objects to check if they are the same. This method compares the objects using the equals() method. The java.lang.Object class requires that any two objects that compare equal using the equals() method must produce the same number when the hashCode() method is used on them. However the default hashCode() method returns a different value for each object, even though the objects are logically equivalent thus leading to unexpected results. | We agree with the analysis described in this report. However, it is not recommended to only override equals and not the hashCode. In this case we have decided to remove the override of the equals method entirely, as it is not necessary with a record. This issue has been corrected in release evoting 1.2 Here is the direct link to the commit. |
Low |
Edited by Swisspost