Why were the patch versions for CVE-2022-25850 released so late?

[Silence-worker-02]

Hello, we are a research team working on Golang. During our investigation, we found CVE-2022-25850 was addressed in commit de67380. However, we noticed that the patch version was released after long time (130 days). We are curious about the reasons behind the delayed release of the patch version, as it may hinder the efficient distribution of patches to downstream users. Could the reason be

1.Issues with testing and CI checking.

2.Other commits have to be incorporated into one release.

3.By convention, versions are not frequently released.

4.Other reasons.

Thank you for your attention, and we look forward to receiving your reply.

[SamJakob]

Hi,

First, I’ll provide some comments on the CVE itself and the processes we went through to mitigate it:

I, the author and primary maintainer, had been hosting the proxy in a jailed environment so this issue was not evident to me — as on my systems it had no access to internal services like it did when it was moved to the Hoppscotch systems. As the Hoppscotch systems were cloud infrastructure (the XSRF manifested itself in the ability for an end user to access the maintenance URL for the cloud server account).

I therefore had not discovered this issue because when I conducted my own audit, I had not been looking for issues of this nature having (perhaps erroneously) assumed that the proxy server on the cloud infrastructure would also be hosted in such an environment (i.e., jailed).

To clarify the above, I thought mitigations in the code base would not be necessary as I knew it possible (and had in practice) mitigated such a vulnerability in my infrastructure rather than in the code base itself - it is not an inherent vulnerability in the software, rather one that manifests itself once a few conditions are met.

We then only learned about the CVE when we were emailed by the person who discovered it regarding disclosure. As I did not control the cloud servers myself, I then had to notify the members of the team who did, who then performed their own investigation and we devised a patch.

The code patch was agreed as a means of greater flexibility to our users who could then block URLs and hosts from being accessed via the Proxyscotch application itself instead of having to rely on external security. But note, again, that the code patch is not an automatic fix for the CVE as the CVE only becomes a problem in the presence of certain environments (i.e., when there is a protected internal URL).

Next, I’m assuming your 130 day window addresses the time delay between the patch entering the master branch and a release being generated.

Hoppscotch’s systems were patched immediately - we have CI jobs that automatically build from master and which immediately deploy on a successful build. The same day, I believe, the invocation was changed to add the problematic URL to the block list.

We had anticipated that all of our users who were running the software on a server would have updated to the master branch - in fact we anticipated very few people would use the original release from before the CVE patch was introduced, and certainly those who wanted to benefit from the additional functionality could have updated.

It was expected that the only users of the old release version would be desktop users who wouldn’t be vulnerable to the CVE either way (on account of their own system firewall and NAT).

In any case, note that updating the software version does not automatically fix the CVE, nor is the CVE automatically present in any version (even the one that was identified). The exploit is dependent on the environment in which Proxyscotch is running (i.e., in the presence of such protected URLs).

This could be mitigated in any version either by blocking problem URLs with the flag added by the patch or alternatively by using some form of jail in any version of the software.

I hope this answers any questions and sheds some light on the issue. Please feel free to ask if you would like to know anything else. :)

[Silence-worker-02]

Thank you for your answer.