Security
Headlines
HeadlinesLatestCVEs

Headline

CVE-2023-26053: Merge pull request #23946 Trusted GPG-key should only accept 160-bit … · gradle/gradle@bf3cc0f

Gradle is a build tool with a focus on build automation and support for multi-language development. This is a collision attack on long IDs (64bits) for PGP keys. Users of dependency verification in Gradle are vulnerable if they use long IDs for PGP keys in a trusted-key or pgp element in their dependency verification metadata file. The fix is to fail dependency verification if anything but a fingerprint is used in a trust element in dependency verification metadata. The problem is fixed in Gradle 8.0 and above. The problem is also patched in Gradle 6.9.4 and 7.6.1. As a workaround, use only full fingerprint IDs for trusted-key or pgp element in the metadata is a protection against this issue.

CVE
#java#gradle

@@ -27,7 +27,7 @@ import spock.lang.Unroll import static org.gradle.security.fixtures.SigningFixtures.getValidPublicKeyLongIdHexString import static org.gradle.security.fixtures.SigningFixtures.signAsciiArmored import static org.gradle.security.fixtures.SigningFixtures.validPublicKeyHexString import static org.gradle.security.internal.SecuritySupport.toLongIdHexString import static org.gradle.security.internal.SecuritySupport.toHexString
class DependencyVerificationSignatureCheckIntegTest extends AbstractSignatureVerificationIntegrationTest {
@@ -60,36 +60,6 @@ class DependencyVerificationSignatureCheckIntegTest extends AbstractSignatureVer outputContains(“Dependency verification is an incubating feature.”) }
def “doesn’t need checksums if signature is verified and trust using long id”() { createMetadataFile { keyServer(keyServerFixture.uri) verifySignatures() addTrustedKey("org:foo:1.0", validPublicKeyLongIdHexString) addTrustedKey("org:foo:1.0", validPublicKeyLongIdHexString, "pom", “pom”) }
given: javaLibrary() uncheckedModule("org", "foo", “1.0”) { withSignature { signAsciiArmored(it) } } buildFile << “"” dependencies { implementation “org:foo:1.0” } “"”
when: serveValidKey() succeeds “:compileJava”
then: outputContains(“Dependency verification is an incubating feature.”) }
@Unroll def "if signature is verified and checksum is declared in configuration, verify checksum (terse output=#terse)"() { createMetadataFile { keyServer(keyServerFixture.uri) @@ -490,8 +460,8 @@ If the artifacts are trustworthy, you will need to update the gradle/verificatio createMetadataFile { keyServer(keyServerFixture.uri) verifySignatures() addTrustedKeyByFileName("org:foo:1.0", "foo-1.0-classy.jar", trustedKey) addTrustedKey("org:foo:1.0", trustedKey, "pom", “pom”) addTrustedKeyByFileName("org:foo:1.0", "foo-1.0-classy.jar", validPublicKeyHexString) addTrustedKey("org:foo:1.0", validPublicKeyHexString, “pom", “pom”) } given: @@ -519,11 +489,6 @@ If the artifacts are trustworthy, you will need to update the gradle/verificatio If the artifacts are trustworthy, you will need to update the gradle/verification-metadata.xml file by following the instructions at ${docsUrl}""” where: trustedKey << [ validPublicKeyHexString, validPublicKeyLongIdHexString ] } @Unroll @@ -575,7 +540,7 @@ This can indicate that a dependency has been compromised. Please carefully verif def keyring = newKeyRing() def secondServer = new KeyServer(temporaryFolder.createDir(“keyserver-${UUID.randomUUID()}”)) secondServer.registerPublicKey(keyring.publicKey) def pkId = toLongIdHexString(keyring.publicKey.keyID) def pkId = toHexString(keyring.publicKey.fingerprint) secondServer.start() createMetadataFile { keyServer(keyServerFixture.uri) @@ -1145,7 +1110,7 @@ This can indicate that a dependency has been compromised. Please carefully verif def “passes verification if an artifact is signed with multiple keys and one of them is ignored”() { def keyring = newKeyRing() keyServerFixture.registerPublicKey(keyring.publicKey) def pkId = toLongIdHexString(keyring.publicKey.keyID) def pkId = toHexString(keyring.publicKey.fingerprint) createMetadataFile { keyServer(keyServerFixture.uri) verifySignatures() @@ -1311,7 +1276,7 @@ If the artifacts are trustworthy, you will need to update the gradle/verificatio def “can read public keys from keyring”() { // key will not be published on the server fixture but available locally def keyring = newKeyRing() def pkId = toLongIdHexString(keyring.publicKey.keyID) def pkId = toHexString(keyring.publicKey.fingerprint)
createMetadataFile { keyServer(keyServerFixture.uri)

Related news

CVE-2023-2974

A vulnerability was found in quarkus-core. This vulnerability occurs because the TLS protocol configured with quarkus.http.ssl.protocols is not enforced, and the client can force the selection of the weaker supported TLS protocol.

RHSA-2023:3809: Red Hat Security Advisory: Red Hat build of Quarkus 2.13.8 release and security update

An update is now available for Red Hat build of Quarkus. Red Hat Product Security has rated this update as having a security impact of Moderate. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability. For more information, see the CVE links in the References section.This content is licensed under the Creative Commons Attribution 4.0 International License (https://creativecommons.org/licenses/by/4.0/). If you distribute this content, or a modified version of it, you must provide attribution to Red Hat Inc. and provide a link to the original. Related CVEs: * CVE-2022-45787: A flaw was found in Apache James's Mime4j TempFileStorageProvider class, where it may set improper permissions when utilizing temporary files. This flaw allows a locally authorized attacker to access information outside their intended permissions. * CVE-2023-0481: In RestEasy Reactive implementation of Quarkus the insecure File.createTempFi...

CVE: Latest News

CVE-2023-50976: Transactions API Authorization by oleiman · Pull Request #14969 · redpanda-data/redpanda
CVE-2023-6905
CVE-2023-6903
CVE-2023-6904
CVE-2023-3907