8000 [SECURITY] CVE-2019-9740 urllib / urllib2: CRLF injection is possible if the attacker controls a url parameter · Issue #98 · jython/jython · GitHub
[go: up one dir, main page]
Skip to content

[SECURITY] CVE-2019-9740 urllib / urllib2: CRLF injection is possible if the attacker controls a url parameter #98

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.

Sign up f 8000 or GitHub

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

Jump to bottom
Closed
petehalbeisen opened this issue May 19, 2021 · 3 comments
Closed

[SECURITY] CVE-2019-9740 urllib / urllib2: CRLF injection is possible if the attacker controls a url parameter #98

petehalbeisen opened this issue May 19, 2021 · 3 comments

Comments

@petehalbeisen
Copy link

Hi, We use this library in our product's scripting engine and it's failing our security scans.

https://nvd.nist.gov/vuln/detail/CVE-2019-9740

Severity: Medium
Status New
Classification Definitive
Fix Group ID: a597f702-ac86-eb11-85aa-2818780a4fcb
Location <our_lib>/jython.jar
Source File <our_lib>/jython.jar
Date Created Tuesday, March 16, 2021
Last Updated Tuesday, March 16, 2021
CVE https://vuln.whitesourcesoftware.com/vulnerability/CVE-2019-9740
CWE:
829
File:
<our_lib>/jython.jar
Name: CVE-2019-9740
Description: An issue was discovered in urllib2 in Python 2.x through 2.7.16 and urllib in Python 3.x through 3.7.3. CRLF injection is possible if the attacker controls a url parameter, as demonstrated by the first argument to urllib.request.urlopen with \r\n (specifically in the query string after a ? character) followed by an HTTP header or a Redis command. This is fixed in: v2.7.17, v2.7.17rc1, v2.7.18, v2.7.18rc1; v3.5.10, v3.5.10rc1, v3.5.8, v3.5.8rc1, v3.5.8rc2, v3.5.9; v3.6.10, v3.6.10rc1, v3.6.11, v3.6.11rc1, v3.6.12, v3.6.9, v3.6.9rc1; v3.7.4, v3.7.4rc1, v3.7.4rc2, v3.7.5, v3.7.5rc1, v3.7.6, v3.7.6rc1, v3.7.7, v3.7.7rc1, v3.7.8, v3.7.8rc1, v3.7.9.
Resolution: Upgrade to version v2.7.17,v3.5.8,v3.6.9,3.7.4,3.7.5
URL:
https://vuln.whitesourcesoftware.com/vulnerability/CVE-2019-9740
@jeff5
Copy link
Member
jeff5 commented Mar 10, 2022

This change set should be a good guide to what changes directly address the issue: python/cpython@bb8071a

As the baseline on which it builds is not the current state, we should update the affected modules to 2.7.18, although I'm wary of simply updating the adopted stdlib wholesale. I expect it to raise too many other issues we don't have the capacity to iron out.

@Stewori
Copy link
Contributor
Stewori commented Mar 11, 2022

Indeed, updating the whole std lib is a nightmare. I once tried and it caused plenty of failures. I regard that an impossible task given the existing resources.

@jeff5 jeff5 closed this as completed in abad0ff Mar 13, 2022
@jeff5
Copy link
Member
jeff5 commented Mar 13, 2022

@Stewori I agree. Even with a few modules a head-on approach broke incomprehensibly. It was a weekend's work to sort out what needed to change and in what order to preserve passing tests. However, in the affected corner of the stdlib, we are now essentially at 2.7.18.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@Stewori @jeff5 @petehalbeisen
0