I need help to test a CVE fix

[molcay]

Hi all,

Background

Currently, I am trying to apply this patch to have vuln-free dependency for a project. The project currently has a complex dependency tree and we cannot upgrade the werkzeug package due to the connexion package. So we are evaluating our options. One of the options is to apply these patches to the werkzeug v2.2.3. Before the next step; we need to test the changes and validate that the changes are working fine.

Goal

I am currently trying to create a patched version of the werkzeug v2.2.3.
I know the following CVEs found before;

• https://nvd.nist.gov/vuln/detail/cve-2023-46136
• https://nvd.nist.gov/vuln/detail/CVE-2024-49767

Here is the list of advisories for the CVEs:

• GHSA-hrfv-mqp8-q5rw
• GHSA-q34m-jh98-gwm2

I applied the changes that were implemented to fix these vulnerabilities. I wanted to test the vuln. fixed or not. To be able to test I try to read the advisories and come up with some test scenarios with synthetic environments.
However, I could not reproduce the issue while I was testing the werkzeug v2.2.3.

I wonder if someone will give me some ideas to reproduce this problem.

As far as I saw from the advisory page; @psrok1 has the credit for this advisory. I know, it is a bit old but do you remember, by any chance how you reproduced in the first place.

[potiuk]

Hello @davidism - short intro here, I am a maintainer (#1 committer) of Apache Airflow - and (as of recently - togetehr with @ashb we are also maintainers of palletseco's new addition - https://github.com/pallets-eco/croniter. And we have a kind request, in this small Werkzeug thing we would like to help with.

@molcay is working with us (and Google Security team) on applying security fixes he mentioned above to Werkzeug 2.2.3 and we hope you will be eventually open to releasing 2.2.4 version with those patches applied.

And we really hope you will be able to help with that (just a bit) together maybe wiht @psrok1 to explain reproducibility of the issue on 2.2.3 because @molcay has a bit of a problem with that repro.

Now... Why we would like to do it and why we have this really kind request to get 2.2.4 out with the fixes?

The main reason is because we have more and more questions from the users of Airflow 2 about those two vulnerabilitites, and due to a number of connected dependencies (Flask Application Builder, Connexion, Flask login etc.) that we use in Airflow 2 and cannot upgrade (it's too complex). Those dependencies of ours (particularly Connexion 2 [1]) have hard-coded Werkzeug < 2.3 dependency and that prevents us - and any other connexion 2 users to upgrade Werkzeug to 2.3.

We've been trying a LOT to migrate connexion to a new version - but those attempts were not successful - [2] - mostly due to Connexion 2 changing completely their architecture (moving from WSGI to ASGI).

In Airflow 3 we are moving to fast_api and dropping connexion altogether, but we would love it if we can help our users to get rid of the vulnerabilities reported in Werkzeug. We belive Airflow is not really affected, but do not currently have a good way of signalling it to our users (there is a lot of discussion about VEX in the security world - vulnerability exchange and we will likely be one of the first to use it, but it's still many months if not years ahead).

Together with Google Security team and molcay we analysed the options, and it seems that if we can get those patches by @molcay approved and merged and 2.3.4 Werkzeug released, that seems like the simplest way to handle the issue - and also it has this really nice property that many of your users might have similar issue. Werkzeug is very popular through a number of other dependencies - transitively, and I believe we are not the only ones with that issue.

Would it be possible to get a little of your help here @davidism and @psrok1 ? We can make our ecosystem a little bit safer together. Also you might be interested that this is part of a bigger initiative we have - called Airflow Beach Cleaning [3] where we work together with Alpha-Omega fund on eventually reviewing and helping our dependencies in making their security rock-solid. It would be great to get you on board of the "Beach Cleaning" excersise.

[1] https://pypi.org/project/connexion/2.14.2/#files : Requires-Dist: werkzeug (<2.3,>=1.0)
[2] apache/airflow#39055 -> attempt to migrate to Connexion 3
[3] https://www.youtube.com/watch?v=k11WRP0Yo8U -> My recent talk from the FOSS backstage about '"Airflow Beach Cleaning"

[potiuk]

Indeed it would be great to get some help here!

[molcay]

Hi,
While I was waiting for a response from the community, I created a testing environment to test the changes.

The PR is here: molcay#1
The testing environment is here: https://github.com/molcay/patched-werkzeug-test-env

The testing environment has gunicorn and a very basic Werkzeug server to render HTML and accept file upload via HTML.
I am running 4 different versions of Werkzeug to see the performance differences.

• Werkzeug v2.2.3
• Werkzeug v2.3.7
• Werkzeug v2.3.8
• Werkzeug-patched (v.2.2.5)

Werkzeug-patched v2.2.4 version was not working as expected

I executed the test manually and also the automated way (via simple Python script). Now, I have a working version (Werkzeug-patched (v.2.2.5)) on top of Werkzeug v2.2.3 and it includes the crucial changes for these CVE fixes.
My automated test results are here: Werkzeug Execution Time Comparison

@potiuk, I also tested the new version on Airflow 2 UI (in the add/edit connection page and also variables page: /variable/list/); and there was no problem.

Since I checked the changes on my end; now I just need an approval that my testing method is enough before creating a PR to this repository. If someone can have a look from the community side and guide us; it will be very much appreciated 🙏

[potiuk]

We would greatly apprectiate @davidism @psrok1 if we could get feedback on this one. This would be extremely helpful for the Airflow community to proceed with the proposal of @molcay here - if you could help with that?

Is there anything we can do to help with the release or support you with it? i understand we are all busy maintainers, and it drags you out from other things, but maybe there is a way we can lessen the burden for releasing the older Werkzeug version?

[davidism]

@potiuk reached out to me on Discord, so I'm going to post what I wrote there, with some edits:

I'm sorry, but 2.2 is too old to be backporting to. You can find our version support policy here: https://palletsprojects.com/versions

The latest feature version for each project will receive bug and security fixes. Older feature versions will not receive fixes. Depending on severity and level of effort, security fixes may be backported one version upon request.

It's not just the code work, it's also merging it forward to 2.3, and the the entire publishing workflow. Going back so many versions and years is not trivial. This policy is to set boundaries on my limited time and attention across so many projects. (I do appreciate that you put in the work of creating the patches though.)

Is there really no way to put this effort towards updating dependencies instead? It looks like both Flask-AppBuilder and Connexion 2 and 3 all support Werkzeug > 3.

---

We then both noticed that the support in Connexion 2 had just been merged and released 3 days ago. That's probably the way forward.