Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Denial of Service in latest version [1.2.3] #52

Closed
findneo opened this issue Jan 19, 2020 · 7 comments · Fixed by #53
Closed

Denial of Service in latest version [1.2.3] #52

findneo opened this issue Jan 19, 2020 · 7 comments · Fixed by #53
Assignees

Comments

@findneo
Copy link

@findneo findneo commented Jan 19, 2020

Please confirm if it is vulnerable.
Mitre id: CVE-2020-7226
Reporter: findneo

[Suggested description]
CiphertextHeader.java in
Cryptacular 1.2.3, as used in Apereo CAS and other products, allows
attackers to trigger excessive memory allocation during a decode
operation, because the nonce array length associated with "new byte" may
depend on untrusted input within the header of encoded data.


[Additional Information]
any encoded network communication based on
org.cryptacular.CiphertextHeader#decode(byte[]) is affected. xxx of
new byte[xxx] can be controlled by client and can be up to 0x7ffffffd
,which caused 2G of memory consuming without demanding for any
privilege.

one of the products using this vuln code is cas4.2.0.
login flow of cas4.2.0 based on
org.cryptacular.CiphertextHeader#decode(byte[]) ,Concretely
speaking,the affected code is
org.jasig.spring.webflow.plugin.EncryptedTranscoder#decode

besides,codebase for cas4.2.0 is apereo/cas-overlay-template@7eaf9d7


[VulnerabilityType Other]
Denial of Service


[Vendor of Product]
http://www.cryptacular.org/


[Affected Product Code Base]
cryptacular - 1.2.3


[Affected Component]
org.cryptacular.CiphertextHeader#decode(byte[]) ,
https://github.com/vt-middleware/cryptacular/blob/master/src/main/java/org/cryptacular/CiphertextHeader.java#L153


[Attack Type]
Remote


[Impact Denial of Service]
true


[Attack Vectors]
a crafted header of encoded data.
e.g '\x00\x00\x00\x34\x7f\xff\xff\xfd'

@serac
Copy link
Member

@serac serac commented Jan 21, 2020

Confirmed. We're analyzing feasibility of a backward-compatible patch and will follow up with release schedule shortly.

serac added a commit to serac/cryptacular that referenced this issue Jan 23, 2020
serac added a commit to serac/cryptacular that referenced this issue Jan 23, 2020
New format does not allocate any memory until HMAC check passes, which
guards against untrusted input. All encryption components have been
updated to use the new header, while preserving backward compatibility
to decrypt messages encrypted with the old format. The decoding process
for the old header has been hardened to impose reasonable limits on header
fields: nonce sizes up to 255 bytes, key names up to 500 bytes.

Fixes vt-middleware#52.
@serac
Copy link
Member

@serac serac commented Jan 30, 2020

Resolved by #53.

@ManjunathMS35
Copy link

@ManjunathMS35 ManjunathMS35 commented Feb 4, 2020

Hi,

When is the fixed version planned to be released? and is there a plan to backport this patch to 1.1.x version?

Thanks,
Manjunath

@dfish3r
Copy link
Member

@dfish3r dfish3r commented Feb 5, 2020

I'm hoping for a release in the next week. Have you done any testing with the latest snapshot?

@dfish3r
Copy link
Member

@dfish3r dfish3r commented Feb 7, 2020

1.2.4 has been released.

ManjunathMS35 added a commit to ManjunathMS35/java-opensaml that referenced this issue Feb 19, 2020
Hi,

Thanks for this open-source project.

The project Cryptacular is vulnerable to CVE-2020-7226, for details see [1]

This is mitigated in Cryptacular version 1.2.4 [2]

Regards,
Manjunath

1. https://nvd.nist.gov/vuln/detail/CVE-2020-7226
2. vt-middleware/cryptacular#52
dfish3r added a commit that referenced this issue Feb 24, 2020
@daniel-beck
Copy link

@daniel-beck daniel-beck commented Feb 26, 2020

Actual source code reference seems to be

@findneo
Copy link
Author

@findneo findneo commented Feb 27, 2020

Actual source code reference seems to be

right . and here

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants