Results from the bug bounty programme, update 22 September 2023

For its e-voting solution, SwissPost is running a public bug bounty program. On the 30 June 2023 we made the last update. Since then, the hunters submitted 19 reports:

• 4 reports concern cryptography-related issues in the cryptographic protocol and its specification.
• 4 reports concern source-code issues. They highlighted meaningful improvements in the source code.

SwissPost and YwH did not accept 4 reports since they could not be reproduced or did not identify a vulnerability and 7 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 €18’500 EUR.- rewards to the hunters who submitted the reports.

Cryptography-related issues

YWH-ID	Title	Description	Status	CVSS-severity
#YWH-PGM2323-127	Suggestion for a stricter ballot privacy definition.	One could come up with a stricter ballot privacy definition where the following two scenarios must be indistinguishable: The Swiss Post Voting System encodes the selected voting options for Q1 and Q2 into the same plaintext before encryption. Hence after decryption, an adversary could distinguish the above cases. The privacy offered by the Swiss Post Voting System aligns with that of traditional paper ballots, where voters respond to multiple questions on a single ballot paper. Nevertheless, we believe that the Swiss Post Voting System has the potential to enhance upon the traditional paper ballot approach by considering the use of separate ciphertexts for individual questions. Practically, there will be some constraints on this approach because questions might be interdependent (variant ballots). Identified thanks to Ben Smyth.	Will be improved in a future version.	Low
#YWH-PGM2323-132	Improving the universal verifiability definition	Swiss Post provides a computational proof of universal verifiability. In cryptography, a computational proof establishes the security of a cryptographic scheme by demonstrating that any adversary with bounded computational resources cannot break the system within a reasonable time frame. These proofs often rely on mathematical assumptions, such as the difficulty of factoring large composite numbers, and employ formal models to argue that an algorithm meets a specific security criterion. While the reporter could not detect any attacks against universal verifiability, the formal definition reveals several limitations: • Rather than explicitly deriving the public parameters, the definition merely presupposes their existence. Incorporating the derivation process within the definition would not only enhance its elegance but also bolster its persuasiveness, especially from an adversarial standpoint. • The definition's validity hinges on the specific functionalities of the VerifyTally and GetMixnetInitialCiphertexts algorithms. Should these algorithms undergo modification, the property of universal verifiability would be compromised. An algorithm-agnostic approach to defining universal verifiability would offer greater robustness. We agree that the definition could be improved in future versions of the computational proof. Identified thanks to Ben Smyth	Will be improved in a future version.	Low
#YWH-PGM2323-142	Strengthen ZKP against malleability attacks	The encrypted vote contains a multi-recipient ciphertext E2. The individual elements of E2 are not included in the zero-knowledge proof’s hash. Thereby, an attacker can modify the individual elements of E2 in a certain way while keeping the zero-knowledge proofs valid (malleability). Exploiting the malleability of E2 does not result in a demonstrable attack, since there would be no corresponding entries in the pCC allow list during the execution of the CreateLCCShare algorithm. Nevertheless, we agree that it would be a sensible improvement to add the elements of E2 to the voting client's zero-knowledge proofs to detect these type of attacks even earlier in the voting phase's execution. Identified thanks to Ben Smyth	Resolved with Release 1.4.	Low

Source-code-related issues

YWH-ID	Title	Description	Status	CVSS-severity
#YWH-PGM2323-140	Improve checks on published hash values	The security advice provided by the Swiss Post Voting System includes instructions for voters to verify the correctness of JavaScript files by referring to the provided link. To enhance clarity and reinforce security measures, it is recommended to explicitly state in the instructions that no JavaScript files other than those specified in the protocol should be loaded. This addition helps to emphasize the importance of adhering strictly to the designated JavaScript files and mitigates potential risks associated with unauthorized or unverified scripts. Identified thanks to Ben Smyth	Resolved with e-voting version 1.3.1.	Low
#YWH-PGM2323-175	The exception for retrying on OrientDB database update failure is not complete.	In the current code, if an OrientDB database update fails, only the ONeedRetryException exception is caught and retried. However, according to the official documentation of OrientDB, exceptions like OConcurrentModificationException and OTransactionException may also occur due to concurrency issues. Therefore, these two exceptions should also be caught and retried.	Resolved with E-voting Release 1.5.0.	Low
#YWH-PGM2323-182	Path Traversal in the SDM	This report identifies a potential Path Traversal due to a lack of sanitisation and verification of the electionEventId in the WhiteList.java of the Secure Data Manager. At present, these deficiencies in input validations do not appear to pose a security risk to the E-Voting system. Nonetheless, for best-practice, we should add input validation in the method WhiteList::getExportList and adopt a more rigorous input validation in the method ImportExportFileSystemService::exportFileSystem. This precaution will help prevent issues that may arise from future code changes. Identified thanks to Mr_Professor.	This has been fixed in Release 1.4.	Low
#YWH-PGM2323-189	Path Traversal in evoting-domain	The hunter has reported a potential Path Traversal vulnerability due to the lack of path sanitization in the XmlSigner during the verification process of digital signatures for XML files used by the xml-signature tool. As outlined in the E-Voting Architecture Document, Section 3.2 Technical Context, the xml-signature is considered as an auxiliary tool. Nevertheless, we will consider the remediation proposal and add input validation in the XmlSigner class to follow best practices. Identified thanks to Mr_Professor.	This has been fixed in Release 1.4.	Low
#YWH-PGM2323-190	Concurrent command execution isolation broken	The issue has initially been reported on GitLab Identified thanks to Florian Moser	Resolved in E-Voting Release 1.3.2.1, see commit.	High