ReDoS vulnerability in svnurl.py #287

SCH227 · 2022-09-22T01:01:09Z

Good night!

I found that this regex is vulnerable to Regular Expression Denial of Service.

PoC:

>>> from py._path.svnurl import InfoSvnCommand
>>> payl = "   2256      hpk        165 Nov 24 17:55 __init__.py" + " " * 5000
>>> InfoSvnCommand(payl)

Attack vector:

An user accessing a (possibly remote) subversion repository that provides malicious "info" data.
Or an attacker injecting 'svn ls http://...' output (less realistic).

Fix:

Use a pattern with non-overlapping groups. I can help in finding a better regex and testing if needed.

The text was updated successfully, but these errors were encountered:

The-Compiler · 2022-09-22T04:52:28Z

Related: #256

bluetech · 2022-10-16T10:44:48Z

I doubt there's anyone using this code, so I don't think it would warrant any sort of security notification that users should bother with, but if you prepare a PR for this I'll merge & release it.

skialpine · 2022-10-18T14:24:38Z

GHSA-w596-4wvx-j9j6
https://nvd.nist.gov/vuln/detail/CVE-2022-42969

jenstroeger · 2022-10-19T05:11:04Z

As @skialpine mentions, the advisory now triggers pip-audit and thus can fail CI runs (like this one).

Is there a fix on the horizon?

RonnyPfannschmidt · 2022-10-19T06:31:37Z

The issue is not considered critical, im not aware of anyone working towards a fix

The-Compiler · 2022-10-19T07:40:02Z

Well, congratulations to whoever it is that decided that the right path of action here is getting a CVE for...

Something that seems very questionable to be titled a "vulnerability" in the first place (if I can control an SVN repo/server, I might as well just Slowloris the initial info request, I suppose... though admittedly I didn't try that.)
For some ~18 year old code...
...which is only there for historical reasons and discouraged to use
...which, to the best of our knowledge, is not used anywhere in the wild outside of some old PyPy development scripts nobody probably uses anymore (and certainly not against random SVN servers). Note the search results seem to be copies of those PyPy scripts, as far as I can tell.
...which, given the above, nobody is terribly interested in maintaining
...yet you ended up generating nothing but noise for hundreds of thousands of pytest users, which for historical reasons depends on pylib (since it came from the PyPy project, like pylib does). Yes, not everyone of the ~~half~~ quarter a million projects there will monitor CVEs against dependencies, but at the same time, lots of people that do (in companies and such) are probably not in that list on GitHub.

Given that it will still take some time for pytest to get fully rid of it's py internals, and people seem to like getting CVEs for this project (which just happens to be very popular via pytest, but pretty much unused outside of pytest), but without really making an attempt to understanding the context... can we please consider:

Either vendoring the remaining code (py.path I assume) in pytest, and archiving pylib...
...or releasing a pylib 2.0.0 which simply drops all the code that isn't used in pytest?

Sorry if I sound frustrated. But requesting a CVE without understanding the context of the project/issue you're reporting, and then generating false reports for hundreds of thousands of pytest users is doing a major disservice to both pytest/pylib maintainers and all those users.

RonnyPfannschmidt · 2022-10-19T07:48:55Z

I'd go as far as to label this cve report a supply chain attack

Pytest should keep dropping pylib as it does

The cve should be added as common false positive

The-Compiler · 2022-10-19T07:51:44Z

I'd go as far as to label this cve report a supply chain attack

I would not, but I'd certainly add it to my "examples of behavior causing open source maintainer burnout" list, given that we're now getting the first pytest issue about this, and it almost certainly won't be the last one.

bluetech · 2022-10-19T09:11:42Z

I should have known better that this was going to happen when I replied as I did... If someone can get the notification retracted that'd be best. But I guess since they've already put out a security notification to the entire world and their grandmother through GitHub, the path of least resistence would be to issue a release to fix this "security issue". I'll try to do it today.

RonnyPfannschmidt · 2022-10-19T10:05:31Z

@bluetech @The-Compiler i woudnt mind to cut a release that drops the svn wc stuff alltogether

The-Compiler · 2022-10-19T10:28:02Z

@RonnyPfannschmidt agreed, and perhaps a bit more even - I opened #288 with some overview on that.

The-Compiler · 2022-10-19T10:30:55Z

FWIW, I've also proposed adding a note to the GitHub advisory (github/advisory-database#761) and tweeted a PSA.

The-Compiler · 2022-10-19T17:59:08Z

GitHub have now reacted and amended the advisory:

The particular codepath in question is the regular expression at py._path.svnurl.InfoSvnCommand.lspattern and is only relevant when dealing with subversion (svn) projects. Notablely the codepath is not used in the popular pytest project.

and apparently also added that information for Dependabot alerts:

I've also added the codepath to the advisory so that dependabot can more intelligently target alerts.

woodruffw · 2022-10-20T00:03:32Z

pip-audit maintainer here. I have no say in it, but it's a shame (in my personal opinion) that this kind of low-quality finding was assigned a CVE ID without any significant cross-checking.

I've filed a CVE rejection request with MITRE, since they're the CVE CNA in this case. If they successfully reject it, getting it removed from GHSA should also be easy.

woodruffw · 2022-10-20T00:06:14Z

Actually, looks like I'll be able to propose a GHSA withdrawal even if the CVE itself hasn't been retracted. I'll open a PR for that in a moment.

woodruffw · 2022-10-20T00:40:14Z

I've filed github/advisory-database#762 to mark the GHSA report as withdrawn.

jenstroeger · 2022-10-20T04:55:57Z

@The-Compiler agreeable and funny #287 (comment) 😁

@woodruffw thanks for following up on the advisory! That means that pip-audit won’t pick up that CVE any longer once pypa/pip-audit#385 has merged, correct?

woodruffw · 2022-10-20T07:52:40Z

@woodruffw thanks for following up on the advisory! That means that pip-audit won’t pick up that CVE any longer once pypa/pip-audit#385 has merged, correct?

Once that's merged and the OSV entry is marked as withdrawn, yeah.

Denelvo · 2022-10-21T10:33:10Z

@The-Compiler @bluetech @woodruffw & other maintainers: don't sweat it! Even though 18 years ago, someone wrote a regex, not thinking of 2022-levels of security paranoia, your efforts are still very much appreciated and your contributions are incredibly productive.

The CVE did trigger some alarms in builds of valuable systems used by financial institutions. But that's good. It doesn't necessarily mean that pytest is suddenly unusable. It just forces downstream developers in highly secured places to stop and think. Alerts can be ignored, assessed, categorized, accepted,...

Please look at CVEs as mostly just a catalyst. Having the CVE removed is a harsh reaction, but the right one if we're absolutely sure that that particular regex is not exploitable. But try to think of it from the point of view of a security officer, with full paranoia goggles on (and no intimate knowledge of the module). The regex is present in the code. It could be executed. A hacker could penetrate, set up a SVN repo, craft some commands, take advantage of other existing vulnerabilities on the system,... You have to think worst case and then some.

In the end, I think a correctly worded CVE with a low severity score which clearly includes all the IFs, would have been the best option here.

Thanks!

The-Compiler · 2022-10-21T10:42:09Z

Taking the freedom to quote what I wrote over at github/advisory-database#762 (comment):

but to my eye the advisory is in fact talking about a real redos vulnerability. I do understand the annoyance with what you call CVE spam, but if the advisory is valid then we want to include it in our data set.

In theory, when viewed in a vacuum: indeed.

However, even a very broad search on GitHub for the affected code yields 92 results. I've looked through them all, and from what I can tell, all the matches fall into one of those categories:

Copies of py using it (in svnurl(), which the search captures as well)

Copies of pypy (where the py library originates from historically), in it's development tools directory. However, PyPy has moved away from SVN in 2010, so they're probably just bitrotting. In any case, they use the repository the current file is in, or are hardcoded to run on a specific old PyPy team server (codespeak.net). If someone has control over that, they might as well just change those scripts. Even if there are certain scripts which actually run on arbitrary SVN servers, the context they are run in is unlikely to make a DoS a real problem. But given that they won't actually work anymore for their intended original purpose, the chance of anyone running them is pretty much zero.

On the other side of the coin, you have at least half a million projects depending on pylib via pytest, which got noise in their inbox.

I believe the main point of a CVE and security advisories is to make people aware of problems which have a real (even if small) chance of affecting them. An advisory which just adds noise to what I believe will be 100.0% of the receivers is just going to hurt the whole system and community.

In this particular case, and when viewed in context, the sheer amount of noise the advisory generates vs. its real usage is so high that the word "spam" is unfortunately very fitting. I can't help but think that "oh, I get a shiny CVE in a popular project" was the only motivation behind it.

woodruffw · 2022-10-21T19:23:45Z

Just to make sure there's no confusion: I'm not a maintainer of this project or of pytest, so my opinions are not those of the maintainers. I'm the maintainer of a separate dependency scanning project, so I have an interest in dependency feeds having a high signal-to-noise ratio. After this comment, I'll step out of this thread now (since I'm not a maintainer and I only stepped in to coordinate on the pip-audit side).

With that being said: I disagree that it's good that a CVE was filed for this behavior. The fact that one was filed and published seemingly without any review represents a series of communication and authority breakdowns; the fact that the project's own maintainers have done more investigation into exploitability potential than the original reporter seems to have is an indicator of this.

As for why that matters: not everybody is a bank, with roles dedicated to reviewing a constant deluge of security reports. In the context of more limited resources, managing security fatigue is far more important than reporting weakness classes like ReDoS, which don't manifest as exploitable vulnerabilities in the overwhelming majority of cases. When users get tired of useless reports, they disable their security tools entirely.

SCH227 · 2022-10-24T16:16:12Z

First of all, I did fill for a CVE, but I didn't publish it. Someone else did it. I find illogical it was you, but the GH advisory says "Credits - @The-Compiler".
The other thing I can think of, is that GH made it automatically because this is described in a public issue. But I find it strange, because I already reported other security issues to MITRE and they never got published before I informed they were made public

ret2libc · 2023-04-11T13:56:57Z

Is the POC in the description actually working for anyone?

>>> from py._path.svnurl import InfoSvnCommand
>>> payl = "   2256      hpk        165 Nov 24 17:55 __init__.py" + " " * 5000
>>> InfoSvnCommand(payl)

For me it executes everything in a fraction of a second.

RonnyPfannschmidt · 2023-04-11T14:16:12Z

It's thinkable that recent python versions have complexity enhancements

See pytest-dev/py#287 (comment) for more info.

Update Python Package Version - find issue: pytest-dev/py#287

Ignore Safety ID 51457 dues to a false-positive reported here: pytest-dev/py#287

Upgrade plugin dependencies to cover security risks Ignore Safety ID 51457 dues to a false-positive reported here: pytest-dev/py#287 Ignore bandit B113 request timeout issue

Resolves CVE: pytest-dev/py#287 (comment)

Dependabot flagged 'py' as being vulnerable to a DoS. It likely doesn't affect us, but the recommendation is that 'pytest' removed dependency on 'py' in 7.2.0 so let's do that. This is discussed in a thread found here: pytest-dev/py#287 (comment)

* Update pytest version to remove py dependency Dependabot flagged 'py' as being vulnerable to a DoS. It likely doesn't affect us, but the recommendation is that 'pytest' removed dependency on 'py' in 7.2.0 so let's do that. This is discussed in a thread found here: pytest-dev/py#287 (comment) * Remove 'py' py is a dependency of pytest so can be removed as of pytest version==7.2.0.

The py library through 1.11.0 for Python allows remote attackers to conduct a ReDoS (Regular expression Denial of Service) attack via a Subversion repository with crafted info data, because the InfoSvnCommand argument is mishandled. The particular codepath in question is the regular expression at py._path.svnurl.InfoSvnCommand.lspattern and is only relevant when dealing with subversion (svn) projects. Notably the codepath is not used in the popular pytest project. The developers of the pytest package have released version 7.2.0 which removes their dependency on py. Users of pytest seeing alerts relating to this advisory may update to version 7.2.0 of pytest to resolve this issue. See pytest-dev/py#287 (comment) for additional context.

…#4880) * Update pytest (which removes their dependency on py) The py library through 1.11.0 for Python allows remote attackers to conduct a ReDoS (Regular expression Denial of Service) attack via a Subversion repository with crafted info data, because the InfoSvnCommand argument is mishandled. The particular codepath in question is the regular expression at py._path.svnurl.InfoSvnCommand.lspattern and is only relevant when dealing with subversion (svn) projects. Notably the codepath is not used in the popular pytest project. The developers of the pytest package have released version 7.2.0 which removes their dependency on py. Users of pytest seeing alerts relating to this advisory may update to version 7.2.0 of pytest to resolve this issue. See pytest-dev/py#287 (comment) for additional context. * Added conditions so that we keep using 7.0.0 on python 3.6

fix security issues pytest upgrade to 7.2.0

@lhoestq

### Generic implementation of a processing graph Remove explicit mentions to /splits or /first-rows from code, and move them to the "processing graph": ```json { "/splits": {"input_type": "dataset", "required_by_dataset_viewer": true}, "/first-rows": {"input_type": "split", "requires": "/splits", "required_by_dataset_viewer": true}, } ``` This JSON (see libcommon.config) defines the *processing steps* (here /splits and /first-rows) and their dependency relationship (here /first-rows depends on /splits). It also defines if a processing step is required by the Hub dataset viewer (used to fill /valid and /is-valid). A processing step is defined by the endpoint (/splits, /first-rows), where the result of the processing step can be downloaded. The endpoint value is also used as the cache key and the job type. After this change, adding a new processing step should consist in: - creating a new worker in the `workers/` directory - update the processing graph - update the CI, tests, docs and deployment (docker-compose files, e2e tests, docs, openapi, helm chart) This also means that the services (API, admin) don't contain any code mentioning directly splits or first-rows. And the splits worker does not contain direct reference to first-rows. ### Other changes - code: the libcache and libqueue libraries have been merged into libcommon - the code to check if a dataset is supported (exists, is not private, access can be programmatically obtained if gated) has been factorized and is now used before every processing step and before even accepting to create a new job (through the webhook or through the /admin/force-refresh endpoint). - add a new endpoint: /admin/cancel-jobs, which replaces the last admin scripts. It's easier to send a POST request than to call a remote script. - simplify the code of the workers by factorizing some code into libcommon: - the code to test if a job should be skipped, based on the versions of the git repository and the worker - the logic to catch errors and to write to the cache This way, the code for every worker now only contains what is specific to that worker. ### Breaking changes - env vars `QUEUE_MAX_LOAD_PCT`, `QUEUE_MAX_MEMORY_PCT` and `QUEUE_SLEEP_SECONDS` are renamed as `WORKER_MAX_LOAD_PCT`, `WORKER_MAX_MEMORY_PCT` and `WORKER_SLEEP_SECONDS`. --- * feat: 🎸 add /cache-reports/parquet endpoint and parquet reports * feat: 🎸 add the /parquet endpoint * feat: 🎸 add parquet worker Note that it will not pass the CI because - the CI token is not allowed to push to refs/convert/parquet (should be in the "datasets-maintainers" org) - the refs/convert/parquet does not exist and cannot be created for now * ci: 🎡 add CI for the worker * feat: 🎸 remove the hffs dependency we don't use it, and it's private for now * feat: 🎸 change the response format associate each parquet file with a split and a config (based on path parsing) * fix: 🐛 handle the fact that "SSSSS-of-NNNNN" is "optional" thanks @lhoestq * fix: 🐛 fill two fields to known versions in case of error * feat: 🎸 upgrade datasets to 2.7.0 * ci: 🎡 fix action * feat: 🎸 create ref/convert/parquet if it does not exist * feat: 🎸 update pytest See pytest-dev/py#287 (comment) * feat: 🎸 unlock access to the gated datasets Gated datasets with extra fields are not supported. Note also that only one token is used now. * feat: 🎸 check if the dataset is supported only for existing one * fix: 🐛 fix config * fix: 🐛 fix the branch argument + fix case where ref is created * fix: 🐛 fix logic of the worker, to ensure we get the git sha Also fix the tests, and disable gated+private for now * fix: 🐛 fix gated datasets and update the tests * test: 💍 assert that gated with extra fields are not supported * fix: 🐛 add controls on the dataset_git_revision * feat: 🎸 upgrade datasets * feat: 🎸 add script to refresh parquet response * fix: 🐛 fix the condition to test if the split exists in list also: rename functions to be more accurate * refactor: 💡 use exceptions to make the flow clearer * feat: 🎸 add processing_steps * fix: 🐛 fix signature * chore: 🤖 adapt to poetry 1.2, use pip-audit * feat: 🎸 use ProcessingStep in api service * feat: 🎸 use ProcessingStep in admin service and replace the last scripts with the /cancel-jobs/xxx endpoints. * style: 💄 fix style * feat: 🎸 update libcommon (use processing_step) * refactor: 💡 merge libcache and libqueue into libcommon * feat: 🎸 upgrade to libcommon 0.4 * feat: 🎸 upgrade to libcommon 0.4 * fix: 🐛 upgrade poetry * feat: 🎸 use processing_step in workers * feat: 🎸 implement should_skip_job and process in generic Worker this will make the code of workers simpler * feat: 🎸 handle CustomError from the workers, with specific code * feat: 🎸 simplify compute method * refactor: 💡 fix typing * fix: 🐛 remove erroneous control * feat: 🎸 update libcommon to 0.4.2 * feat: 🎸 update to libcommon 0.4.2 * ci: 🎡 fix ci * docs: ✏️ fix docstring * feat: 🎸 update to libcommon 0.4.2 * refactor: 💡 use Mapping instead of Dict * feat: 🎸 update to libcommon 0.4.2 also: replace Dict with Mapping * fix: 🐛 use Dict because it must be mutable * fix: 🐛 missing import * feat: 🎸 remplace dependency with previous_step and next_steps * feat: 🎸 define the processing graph in the configuration * feat: 🎸 upgrade to libcommon 0.5 * feat: 🎸 upgrade to libcommon 0.5 * feat: 🎸 upgrade to libcommon 0.5 * feat: 🎸 upgrade to libcommon 0.5.0 * feat: 🎸 upgrade to libcommon 0.5 * feat: 🎸 upgrade to libcommon 0.5 * refactor: 💡 add logic methods to simplify services and workers * feat: 🎸 upgrade to libcommon 0.5.1 some tests have been moved (commented yet) to e2e, since it becomes hard to simulate all the Hub endpoints -> better to test the scenari against the real Hub instead * feat: 🎸 upgrade to libcommon 0.5.1 * feat: 🎸 remove parquet processing step since it's not the scope of this PR * style: 💄 fix stykle * ci: 🎡 remove parquet ci * feat: 🎸 upgrade docker images * test: 💍 add some tests for the webhook * test: 💍 update e2e tests (and error messages in openapi) * style: 💄 fix style * feat: 🎸 remove parquet code

I've removed this change.

natke · 2024-07-17T00:00:01Z

hi there, I am getting this CVE coming up in my project, which is using pybind with cmake, Any guidance on how I should update to remove the violation warning? Do I need to contact pybind to update their version of pytest?

RonnyPfannschmidt · 2024-07-17T18:42:32Z

please ask those downstream, most of the team here didnt work with pybind

RonnyPfannschmidt · 2024-07-17T18:52:18Z

im closing this issue now - this was a incorrectly filed issue right from the start, it showing up in tool reports simply indicates low quality of said tools

The-Compiler mentioned this issue Oct 19, 2022

CVE-2022-42969: security issue in library py used by this project pytest-dev/pytest#10392

Closed

The-Compiler mentioned this issue Oct 19, 2022

[GHSA-w596-4wvx-j9j6] ReDoS in py library github/advisory-database#761

Merged

The-Compiler mentioned this issue Oct 19, 2022

Plan for dropping/deprecating submodules of py and releasing v2.0 #288

Open

shirayu mentioned this issue Oct 19, 2022

CVE-2022-42969 shirayu/whispering#40

Closed

woodruffw mentioned this issue Oct 20, 2022

GHSA-w596-4wvx-j9j6: mark as withdrawn github/advisory-database#762

Closed

This was referenced Oct 20, 2022

Skip vulnerability reports that are marked as "withdrawn" pypa/pip-audit#385

Closed

Contested advisory: GHSA-w596-4wvx-j9j6 / CVE-2022-42969 pypa/advisory-database#104

Open

RonnyPfannschmidt mentioned this issue Oct 20, 2022

RFE: Replace use of pkg_resources with importlib.metadata #282

Closed

github-actions bot mentioned this issue Apr 11, 2023

locally generate global depedency report MeilleursAgents/deps-report#19

Draft

The-Compiler mentioned this issue Apr 13, 2023

New release? #293

Closed

sebastian-philipp mentioned this issue Apr 13, 2023

How to deal with vulnerabilities that won't be resolved anytime soon? pypa/pip-audit#593

Closed

sybrenstuvel added a commit to sybrenstuvel/python-rsa that referenced this issue Apr 23, 2023

Upgrade pytest to resolve security issue

af1881c

See pytest-dev/py#287 (comment) for more info.

uJhin added a commit to uJhin/upbit-client that referenced this issue May 21, 2023

Update requirements.txt

8d7d910

Update Python Package Version - find issue: pytest-dev/py#287

rvelaVenafi added a commit to Venafi/vcert-python that referenced this issue Jun 1, 2023

fix(dependencies): Ignore safety false-positives

40f863f

Ignore Safety ID 51457 dues to a false-positive reported here: pytest-dev/py#287

rvelaVenafi mentioned this issue Jun 1, 2023

fix(dependencies): Upgrade dependencies Venafi/vcert-python#126

Merged

stefpiatek added a commit to stefpiatek/bbc_meet_spotify that referenced this issue Jul 26, 2023

Update pytest

a85f07f

Resolves CVE: pytest-dev/py#287 (comment)

ghost mentioned this issue Aug 11, 2023

Upgrade dependencies nearspacelabs/stac-client-python#64

Open

beepscore added a commit to beepscore/websearcher that referenced this issue Sep 5, 2023

in pyproject.toml update pytest to fix pytest-dev/py#287

2dee559

pablospe mentioned this issue Oct 11, 2023

Update pytest to version 7.2.0 (which removes their dependency on py) pybind/pybind11#4880

Merged

mariuz referenced this issue in maxirobaina/django-firebird Nov 2, 2023

Update requirements.txt

f55de1e

fix security issues pytest upgrade to 7.2.0

pjaos pushed a commit to pjaos/ct6_meter_os that referenced this issue Jan 24, 2024

After reading through pytest-dev/py#287

e04558c

I've removed this change.

SpicyGarlicAlbacoreRoll mentioned this issue Apr 24, 2024

Removes py requirement per cve, upgrades pytest to 8.1.1 asfadmin/Discovery-PytestAutomation#65

Merged

RonnyPfannschmidt closed this as completed Jul 17, 2024

northwestwitch mentioned this issue Aug 15, 2024

Update pytest to address a ReDoS vulnerability Clinical-Genomics/chanjo2#342

Merged

6 tasks

The-Compiler mentioned this issue Aug 22, 2024

Found a possible security concern #297

Closed

github-actions bot mentioned this issue Sep 24, 2024

chore: fix an issue where package category would not be present MeilleursAgents/deps-report#20

Merged

github-actions bot mentioned this issue Dec 13, 2024

testing pipelines log8100-projet/Projet_INF8100#2

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

ReDoS vulnerability in svnurl.py #287

ReDoS vulnerability in svnurl.py #287

SCH227 commented Sep 22, 2022

The-Compiler commented Sep 22, 2022

bluetech commented Oct 16, 2022

skialpine commented Oct 18, 2022

jenstroeger commented Oct 19, 2022

RonnyPfannschmidt commented Oct 19, 2022

The-Compiler commented Oct 19, 2022 •

edited

Loading

RonnyPfannschmidt commented Oct 19, 2022

The-Compiler commented Oct 19, 2022

bluetech commented Oct 19, 2022 via email

RonnyPfannschmidt commented Oct 19, 2022

The-Compiler commented Oct 19, 2022

The-Compiler commented Oct 19, 2022

The-Compiler commented Oct 19, 2022

woodruffw commented Oct 20, 2022

woodruffw commented Oct 20, 2022

woodruffw commented Oct 20, 2022

jenstroeger commented Oct 20, 2022 •

edited

Loading

woodruffw commented Oct 20, 2022

Denelvo commented Oct 21, 2022

The-Compiler commented Oct 21, 2022

woodruffw commented Oct 21, 2022

SCH227 commented Oct 24, 2022

ret2libc commented Apr 11, 2023

RonnyPfannschmidt commented Apr 11, 2023

natke commented Jul 17, 2024

RonnyPfannschmidt commented Jul 17, 2024

RonnyPfannschmidt commented Jul 17, 2024

ReDoS vulnerability in svnurl.py #287

ReDoS vulnerability in svnurl.py #287

Comments

SCH227 commented Sep 22, 2022

PoC:

Attack vector:

Fix:

The-Compiler commented Sep 22, 2022

bluetech commented Oct 16, 2022

skialpine commented Oct 18, 2022

jenstroeger commented Oct 19, 2022

RonnyPfannschmidt commented Oct 19, 2022

The-Compiler commented Oct 19, 2022 • edited Loading

RonnyPfannschmidt commented Oct 19, 2022

The-Compiler commented Oct 19, 2022

bluetech commented Oct 19, 2022 via email

RonnyPfannschmidt commented Oct 19, 2022

The-Compiler commented Oct 19, 2022

The-Compiler commented Oct 19, 2022

The-Compiler commented Oct 19, 2022

woodruffw commented Oct 20, 2022

woodruffw commented Oct 20, 2022

woodruffw commented Oct 20, 2022

jenstroeger commented Oct 20, 2022 • edited Loading

woodruffw commented Oct 20, 2022

Denelvo commented Oct 21, 2022

The-Compiler commented Oct 21, 2022

woodruffw commented Oct 21, 2022

SCH227 commented Oct 24, 2022

ret2libc commented Apr 11, 2023

RonnyPfannschmidt commented Apr 11, 2023

natke commented Jul 17, 2024

RonnyPfannschmidt commented Jul 17, 2024

RonnyPfannschmidt commented Jul 17, 2024

The-Compiler commented Oct 19, 2022 •

edited

Loading

jenstroeger commented Oct 20, 2022 •

edited

Loading