Programming Books

Main Menu

  • Home
  • Phyton programming
  • Java programming
  • Php programming
  • C++ programming
  • Additional Topics
    • Programming industry
    • Privacy Policy
    • Terms and Conditions

Programming Books

Header Banner

Programming Books

  • Home
  • Phyton programming
  • Java programming
  • Php programming
  • C++ programming
  • Additional Topics
    • Programming industry
    • Privacy Policy
    • Terms and Conditions
Java programming
Home›Java programming›Oracle Java wins ‘cryptographic bug of the year’ for workaround • The Register

Oracle Java wins ‘cryptographic bug of the year’ for workaround • The Register

By Brandy J. Richardson
April 20, 2022
0
0

Java versions 15 through 18 contain a flaw in its ECDSA signature validation that makes it trivial for criminals to digitally sign files and other data as if they were legitimate organizations.

Cybercriminals could therefore pass off cryptographically signed malicious downloads and false information as if it were real, and the affected Java applications and services will not know the difference.

The scope of damage that could be done is vast: encrypted communications, authentication tokens, code updates, etc., built on faulty Oracle code could be reversed, and as far as Vulnerable programs written in Java, data appear legitimate and reliable.

The gaffe was patched this month by Oracle – among more than 500 vulnerabilities patched by the database giant this quarter – so, as always, update early and update often.

ECDSA stands for Elliptic Curve Digital Signature Algorithm. It uses elliptic curve cryptography, implementations of which have encountered various problems over the years.

Although Oracle only gave this latest security flaw (CVE-2022-21449) a severity rating of 7.5 out of 10, security consultancy ForgeRock – which said it had seen it and disclosed it privately in November – rates the vulnerability out of ten.

Infosec expert Thomas Ptacek once described it as “the crypto bug of the year”, which we’re inclined to agree with.

Good. This is the crypto bug of the year. Write it down for April. Java 15-18 ECDSA does not check that the random x coordinate and signature proof are not null; a signature (0,0) validates any message. Case JWT, SAML, etc. https://t.co/t2WgnS0g3A

—Thomas H. Ptacek (@tqbf) April 20, 2022

What’s particularly interesting about this problem is that it’s incredibly easy to exploit, and it’s an obvious programming error. The bug was introduced when some of Java 15’s signature verification code was rewritten from its native C++ to Java itself – including the ECDSA verification code.

To simplify what happened, an ECDSA signature consists of a pair of numbers, called (r, s). To verify a signature, the code performs calculations involving a hash (a fingerprint, if you will) of the data, the public key of the organization or person who digitally signed the data, rand s; one side of the equation uses rThe other r and s.

Both sides of this calculation must be equal for signature verification to pass. This would mean that the data has been digitally signed by the signer’s private key, indicating that the data comes from or is trusted by the signer. If the signature verification fails, it probably means that the person who signed the data is not who they claim to be (because they don’t have access to the secret private key that matches the given public key) and that the data should not be trusted.

In theory, for a signature to be valid, (r, s) it’s not possible (0, 0) because some calculations involve multiplying these numbers by other values. The bug arose because the original C++ code checked that both r and s are nonzero and would not accept the signature if they were. The new Java code didn’t check, it just went forward and calculated with the values.

You don’t need to know a lot of math to know that anything multiplied by zero equals zero. Part of the calculation is to divide by s – but, unfortunately, in a way that doesn’t generate an error if you divide by zero.

The result is that in the affected versions of the code, anyone with a blank signature will be accepted. The normal audit trail still works fine, which is why it wasn’t noticed two years ago. He just accepts now (0,0)and validate it successfully.

And that’s on top of gazillon’s remote code execution flaws, with no authentication needed to exploit, in Oracle’s other products. ®

Boot Note

This defect was describe by Neil Madden of ForgeRock as psychic paper vulnerability, after a plot device from a 2007 Doctor Who episode. Your humble book vulture thinks this sounds more like the imp card from AA Attanasio’s 1987 novel In Other Worlds:

You will receive a third and final artifact, a magnetic interface plate – an imp. It looks like a cash card, except it’s pure white. Insert it into any banking computer system and you will be credited with large sums of real capital.

Related posts:

  1. Goa, 13-year-old boy, manages millions of dollars in cryptocurrency | Goa News
  2. 4 “exotic” programming languages ​​popular with malware developers
  3. Intimidated by Kafka? Discover the new Confluent developer site
  4. 5 Best Java Development Companies in Vietnam

Archives

  • May 2022
  • April 2022
  • March 2022
  • February 2022
  • January 2022
  • December 2021
  • November 2021
  • October 2021
  • September 2021
  • August 2021
  • July 2021
  • June 2021
  • January 2021
  • December 2019
  • November 2019
  • October 2019
  • April 2019
  • March 2019
  • February 2019
  • January 2019
  • December 2017

Categories

  • C++ programming
  • Java programming
  • Php programming
  • Phyton programming
  • Programming industry

Recent Posts

  • 12-bit dual-channel PCIe card samples at 2x 3.2 Gsample/s
  • Woster: Need work for those stifled by student loans – Mitchell Republic
  • How to Become a Cloud Engineer
  • [Unveil]Emerging indie band SURL wants to bring rock back to the masses
  • Ansible vs. Puppet | Compare DevOps tools
  • Privacy Policy
  • Terms and Conditions