You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have our IBM Traditional WebSphere Application Server using jython. I would like to know regarding the vulnerability exposure of jython towards CVE-2024-3220.
I found a Python CVE to assess to determine if the Jython we use in tWAS 855 and 9.0 is vulnerable or not. The description of the CVE is as follows:
A flaw was found in the mimetypes standard library module for Python. On Windows systems, the default list of known file locations is writable, meaning other users can create invalid files to cause MemoryError to be raised on Python runtime startup or have file extensions be interpreted as the incorrect file type. This defect is caused by the default locations of Linux and macOS platforms (such as /etc/mime.types) also being used on Windows, where they are user-writable locations (C:\etc\mime.types).
I could see a work around addressing this in NVD link. To work-around this issue a user can call mimetypes.init() with an empty list (“[]”) on Windows platforms to avoid using the default list of known file locations.
I suspect jython is vulnerable since we use python.Do anyone have assessed this vulnerability and the level of its exposure ? And are we planning for a fix for this?
Seems to be an issue. (You can guess what I did.) It is not for us, I think, to assess impact.
Our mimetypes is just copied from CPython 2.7 (at some vintage), which of course is not maintained. If there's an easy fix in a later CPython stdlib, it might be possible port the idea. Copying a Python 3 module into Jython is generally a bad idea because of the cumulative change.
@jeff5 what you implied by "I can't even find an issue for it" - is this not a vulnerability ? I think the issue is not reported because still they are in analysis phase. We can see awaiting for analysis state at https://nvd.nist.gov/vuln/detail/CVE-2024-3220. Anayway, the code is vulnerable right ?
I mean I looked in CPython GitHub and not only was there not a change set referring to the CVE, there wasn't an issue either (until you opened one). It is worth reflecting that work on security patches is sometimes hidden, although there does not seem much point once the vulnerability is public.
Activity
jeff5 commentedon Feb 22, 2025
Seems to be an issue. (You can guess what I did.) It is not for us, I think, to assess impact.
Our
mimetypesis just copied from CPython 2.7 (at some vintage), which of course is not maintained. If there's an easy fix in a later CPython stdlib, it might be possible port the idea. Copying a Python 3 module into Jython is generally a bad idea because of the cumulative change.jeff5 commentedon Feb 23, 2025
It's not fixed in CPython yet, and I can't even find an issue for it.
i004ncc commentedon Feb 23, 2025
@jeff5 what you implied by "I can't even find an issue for it" - is this not a vulnerability ? I think the issue is not reported because still they are in analysis phase. We can see awaiting for analysis state at https://nvd.nist.gov/vuln/detail/CVE-2024-3220. Anayway, the code is vulnerable right ?
jeff5 commentedon Feb 24, 2025
I mean I looked in CPython GitHub and not only was there not a change set referring to the CVE, there wasn't an issue either (until you opened one). It is worth reflecting that work on security patches is sometimes hidden, although there does not seem much point once the vulnerability is public.
Yes, it works as demonstrated.